Quickstart

LiteLLM ships as a ready-to-run gateway. You start it with one command (or one click), then do everything else in your browser: connect providers, add models, create keys, and send test requests from the built-in Admin UI. No config files are required for this guide.

Up and running in a minute

curl -fsSL https://raw.githubusercontent.com/BerriAI/litellm/main/scripts/quickstart.sh | sh

When the command finishes, open the Admin UI. Then you can add your models, create virtual keys, and call the gateway from your apps.

For detailed installation steps, follow the rest of the guide. By the end you will have LiteLLM running at http://localhost:4000 with a model connected, a virtual key issued, and a request served through the gateway.

1. Start LiteLLM

curl -sSLO https://github.com/BerriAI/litellm/raw/main/docker/docker-compose.quickstart.yml
printf 'LITELLM_MASTER_KEY=sk-%s\nLITELLM_SALT_KEY=sk-%s\n' "$(openssl rand -hex 32)" "$(openssl rand -hex 32)" > .env
docker compose -f docker-compose.quickstart.yml up -d

This brings up the gateway on port 4000 and a Postgres database that stores your models, keys, and spend logs. The compose file defines just those two services and now sits in your working directory, so you can read it before starting it, and edit it afterwards to pin a specific release tag.

The second command generates your master key, which is the credential you will use for every request below. The proxy refuses to start without it. Keep the .env file: regenerating LITELLM_SALT_KEY makes credentials already stored in the database unreadable.

Deploy to the cloud in one click

Same gateway and Postgres, hosted for you. Use your deployment's URL wherever this guide says http://localhost:4000.

What the two keys do

Running locally, the command above generated both into .env and the compose file refuses to start without them. On a 1-click deploy, set them in the provider's environment.

LITELLM_MASTER_KEY is the root credential for the gateway: it authorizes every management API call and, by default, doubles as the Admin UI password. Anyone holding it has full admin access, so treat it like a root password, keep it out of source control, and rotate it if it ever leaks. The sk- prefix in the generated value is a convention, not a requirement

LITELLM_SALT_KEY encrypts the provider API keys you add in the UI. It has no in-place rotation, so keep the generated value: changing it later makes every stored credential unreadable until you re-enter it. See key rotations for how the two keys relate.

2. Log in to the Admin UI

Open http://localhost:4000/ui. The username is admin and the password is your LITELLM_MASTER_KEY value, the one in the .env file you just generated.

3. Add your first model

Go to Models + Endpoints, open the Add Model tab, pick your provider and the models you want to expose, and paste your provider API key. LiteLLM ships with each provider's model catalog, so you select models rather than type them.

Click Test Connect to verify the key against the provider, then Add Model. It appears under Deployed Models with its pricing already mapped:

Keep provider keys out of the UI

If you prefer to manage provider keys as environment variables, download the compose file, add them to the litellm service (for example OPENAI_API_KEY: ${OPENAI_API_KEY}), and enter os.environ/OPENAI_API_KEY in the API key field instead of the raw key.

4. Send a test message

Go to Playground, select your model, and send a message. The request goes through the gateway to your provider, and the response comes back with latency and token counts:

Your gateway works end to end. The Get Code button in the Playground generates the equivalent API call for your language.

5. Create a virtual key

Virtual keys are what you hand to applications and teammates instead of raw provider keys. Each key can carry its own budget, rate limits, and model access, and all its spend is tracked automatically.

Go to Virtual Keys, click + Create New Key, give it a name, and click Create Key:

Copy the key now; it is shown only once.

6. Call the gateway from your app

The gateway is OpenAI-compatible, so any OpenAI SDK works by pointing it at http://localhost:4000 with your virtual key.

curl

curl http://localhost:4000/v1/chat/completions \
  -H 'Authorization: Bearer sk-<your-virtual-key>' \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gpt-5.6-terra",
    "messages": [{"role": "user", "content": "Say hello in five words."}]
  }'

Expected response:

{
  "id": "chatcmpl-DzGKiNRbQ4fe9Mgt8HSHFQ6ApfRJi",
  "model": "gpt-5.6-terra",
  "object": "chat.completion",
  "choices": [
    {
      "finish_reason": "stop",
      "index": 0,
      "message": {
        "content": "Hello, nice to meet you.",
        "role": "assistant"
      }
    }
  ],
  "usage": {
    "completion_tokens": 70,
    "prompt_tokens": 12,
    "total_tokens": 82
  }
}

OpenAI Python SDK

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:4000",
    api_key="sk-<your-virtual-key>",
)

response = client.chat.completions.create(
    model="gpt-5.6-terra",
    messages=[{"role": "user", "content": "Say hello in five words."}],
)
print(response.choices[0].message.content)

OpenAI JS SDK

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "http://localhost:4000",
  apiKey: "sk-<your-virtual-key>",
});

const response = await client.chat.completions.create({
  model: "gpt-5.6-terra",
  messages: [{ role: "user", content: "Say hello in five words." }],
});
console.log(response.choices[0].message.content);

The whole flow, end to end

Running without a database

If you only need the OpenAI-compatible API (no Admin UI model management, virtual keys, or spend tracking), you can run the plain litellm image with a config file instead:

# litellm_config.yaml
model_list:
  - model_name: gpt-5.6-terra
    litellm_params:
      model: openai/gpt-5.6-terra
      api_key: os.environ/OPENAI_API_KEY

docker run \
  -v $(pwd)/litellm_config.yaml:/app/config.yaml \
  -e OPENAI_API_KEY=<your-openai-key> \
  -e LITELLM_MASTER_KEY=sk-<paste-a-long-random-key> \
  -p 4000:4000 \
  docker.litellm.ai/berriai/litellm:latest \
  --config /app/config.yaml

Requests authenticate with the master key. See the full config reference for everything the file supports.

Budgets are not enforced without a database

litellm_settings.max_budget is not a spend cap on this path. Loading the proxy's global spend requires a database client, so without one the running total stays unknown and the global budget check never fires; a proxy configured with max_budget: 100 keeps serving requests past $100 with no per-request error and no budget alert. The proxy does log a one-time warning at startup when a budget is configured with no database connected, and that startup line is the only signal you get

Key and team budgets are not an alternative here either, because virtual keys themselves need a database (requests carrying one fail with No connected db.), so the master key is the only credential and it has no budget of its own

If a budget is part of how you bound spend, run LiteLLM with a database as shown at the top of this page. Without one, bound spend upstream instead, at your provider's own spending limits

Next steps

Going to production: the Production Deployment guide covers Helm, Terraform, and Kubernetes on AWS, GCP, and Azure, and the production checklist covers hardening and tuning. Full container and database options, including Redis and Prometheus, are covered in the repo docker-compose.yml.