# vLLM Self-Hosted LLM Production Checklist [2026]: Auth + Quotas

> A production-first checklist for self-hosting an OpenAI-compatible vLLM endpoint: auth, per-tenant quotas, streaming SSE, queueing, and redaction-safe logs.

- Canonical: https://www.kunalganglani.com/blog/vllm-production-checklist
- Author: Kunal Ganglani
- Published: 2026-09-28 · Updated: 2026-09-28
- Category: Cloud and DevOps · Tags: vllm, llm-serving, production-ai, kubernetes, api-gateway

## TL;DR

Running vLLM locally is easy. Making it reliable for multiple teams is the hard part. This production checklist shows how to put authentication in front of vLLM, enforce per-tenant limits (requests per minute, tokens per minute, and concurrency), and make streaming responses feel instant instead of buffered and broken. It also covers what to log in production without leaking sensitive prompts, plus the key metrics that prove your endpoint is healthy. If you’re replacing a managed LLM API with a self-hosted endpoint in 2026, this is the gap between a demo and something you can run with confidence.

You’re going to end up with a self-hosted vLLM endpoint that looks like a managed LLM API from the outside. OpenAI-compatible paths, streaming responses that don’t buffer, tenant-scoped auth, per-tenant quotas (requests/min, tokens/min, concurrency), and logs you can actually keep without waking up your privacy team.

This is a **production checklist** for the exact problem most teams hit in week two. The demo works. Then three internal teams point their agents at it, someone pastes a key into a CI log, the SSE stream buffers behind a proxy, and your GPU box turns into a noisy-neighbor fight club.

If you’re here for the keyword: **vllm self hosted llm production checklist**. That’s what this is.

## What is vLLM?

vLLM is an open-source large language model (LLM) inference server that boosts throughput under concurrent load using continuous batching and a memory management technique called PagedAttention.

![Nvidia logo on a green background with abstract spheres](https://cdn.sanity.io/images/vzekdneq/production/dbeab446066aa6f90fb1bbf620a492a8623506e7-1200x675.webp)

If you’ve only used it as “run a container, hit `/v1/chat/completions`, celebrate,” you’ve seen the fun part. The boring part is what makes it usable by more than one person.

Aleksei Aleinikov nails the positioning: vLLM is about **production throughput at concurrency**, while tools like Ollama and `llama.cpp` are optimized for “run locally with almost no setup.” That’s not a value judgement. It’s a routing decision. If you need multi-user capacity, you need the checklist.

Internal context that helps:

- If you’re still deciding between “local-first UX” and “multi-tenant serving,” start with my [local LLM](/blog/local-llms-complete-guide) hub and the production angle in [AI in production](/blog/multi-agent-ai-systems-production).
- If you already chose vLLM, you’re in the land of [production AI](/blog/llm-observability-metrics), not hobby setups.
## Getting Started With Each (vLLM vs Ollama) — pick the right tool first

[Watch: How to Self-Host an LLM: Local AI Inference with vLLM](https://www.youtube.com/watch?v=OuBxnfPA15g)

This section exists because I’ve watched teams do the wrong thing: they pick an inference server based on the easiest demo, then spend months trying to retrofit multi-tenancy.

![Two nvidia titan x graphics cards side by side](https://cdn.sanity.io/images/vzekdneq/production/b6e62bfa053ea230e29467b971c39f8af28e7a26-1200x675.webp)

Here’s the stance:

- If you’re serving **one developer** on **one machine**, pick Ollama.
- If you’re serving **many users**, **many services**, or **agents** that will spike concurrency, pick vLLM.
And yes, you can start with Ollama and migrate. But migration is rarely clean because the first thing people do is let clients grow “API surface area” you didn’t design.

Quick comparison (this table is here on purpose. AI Overviews love it, and so do humans):

| Problem you will hit in production | vLLM answer | Ollama answer | Where it belongs |
| --- | --- | --- | --- |
| Multi-tenant auth (keys/JWT) | Bring your own gateway | Bring your own gateway | API gateway / reverse proxy |
| High concurrency throughput | Continuous batching | Not the goal | Inference server |
| Token-based quotas (TPM) | Needs external accounting | Needs external accounting | Gateway + app-side meter |
| Streaming SSE under load | Works, but proxy must be tuned | Works locally, less proxy complexity | Proxy + client |
| Kubernetes scaling | Designed for it | Possible, awkward | K8s + autoscaling |
| Developer “it just runs” | Not the point | Core product | Local dev |

If you want more on choosing runtimes, my post on [How to serve a local LLM to multiple users](/blog/serve-local-llm-multiple-users) is the “decision tree” version of this.

## The Real Business Bottleneck: Reliability Under Load

The business bottleneck is not “can we run the model.” It’s “can we run it **predictably** when five things go wrong at once.”

![Nvidia logo on a green background with abstract 3D elements](https://cdn.sanity.io/images/vzekdneq/production/f40384b138d01ca47aa0d4cddccc3cefafeab306-1200x675.webp)

Jangwook Kim frames this perfectly in his SLA-oriented writeup: reliability under load is the thing that actually matters when you move from notebook to a service. He points to a public vLLM issue reporting **throughput plateauing when concurrency scaled from 4 to 16 on an NVIDIA H100 with vLLM 0.19.1**. That’s the part most teams miss.

You can do everything “right” and still hit a scaling wall.

Three practical implications:

1) **Benchmark per model, per GPU, per vLLM version.** The 0.19.1 vs 0.20.x bump can change behavior. Your model family can change it too.

2) **Admit your endpoint is a shared resource.** If you let tenants fight for it, your p95 looks like a lie.

3) **Your SLOs must be LLM-native.** “Request latency” is not enough. You need TTFT, tokens/sec, queue time, and aborted streams.

If you haven’t done this measurement work before, start with my [Local LLM benchmark methodology](/blog/local-llm-benchmark-methodology) and [LLM latency benchmark methodology: streaming UX metrics](/blog/llm-latency-benchmark-methodology).

## Production Architecture & Code Blueprints (Auth, Quotas, Streaming, Logs)

I’m going to describe the architecture in layers, because that’s how you actually ship it.

**Layer 0: vLLM pods**

- Runs the OpenAI-compatible API.
- You treat it like a dumb engine. No tenancy logic. Minimal logging.
**Layer 1: gateway / reverse proxy**

- TLS termination.
- Auth.
- Basic rate limiting.
- Correct SSE streaming behavior.
**Layer 2: policy + accounting service (thin control plane)**

- Token metering (TPM) and budgets.
- Per-tenant concurrency caps.
- Queueing/fairness.
- Audit logs with redaction.
If you’re allergic to adding services: I get it. But the alternative is pushing policy into every client, which is worse. A self-hosted endpoint without a control plane becomes a free-for-all within weeks.

### 1) How do you put authentication in front of vLLM’s OpenAI-compatible API?

You have three realistic patterns.

**Pattern A: API keys (fastest to ship)**

- Each tenant gets a key.
- Gateway validates key and injects `x-tenant-id` header.
- Downstream systems never see raw keys.
**Pattern B: JWT / OIDC (best for internal multi-team)**

- Your IdP issues JWTs.
- Gateway validates signature + `aud`.
- Map claims (`sub`, `org`, `entitlements`) to tenant.
**Pattern C: mTLS + service identity (best for service-to-service)**

- SPIFFE/SPIRE or mesh identity.
- Usually paired with JWT for humans.
If you’re doing agent tooling, treat auth like you would for an MCP server. I wrote about the failure modes in [MCP OAuth security](/blog/mcp-oauth-security-impersonation) and the safer setup patterns in [How to secure MCP servers: auth + authZ](/blog/mcp-server-authentication-authorization).

Concrete rule I use:

- **Humans** get OIDC.
- **Services** get mTLS or workload identity.
- **Everything** gets a tenant header derived at the edge.
Also: do not let the client send `x-tenant-id`. That’s how you end up with tenant data leakage. You derive tenant identity from auth, not from user-controlled headers. This is basic [LLM security](/blog/ai-security-complete-guide) hygiene.

### 2) How do you enforce per-tenant quotas (requests/min, tokens/min, concurrency) for a self-hosted LLM?

You need quotas in **three units**, because LLM usage is not one-dimensional:

- **RPM (requests per minute)**: protects your HTTP layer.
- **Concurrent requests**: protects GPU scheduling and memory.
- **TPM (tokens per minute)**: protects cost and fairness.
If you only do RPM, one tenant can send 1 request/minute with `max_tokens=8192` and still wreck you.

If you only do concurrency, a tenant can run 1 long request forever.

If you only do TPM, a tenant can DoS your queue with lots of tiny requests.

My recommended enforcement split:

- **Gateway** enforces RPM and burst limits.
- **Control plane** enforces TPM, max tokens, max context, and concurrency reservations.
- **vLLM** enforces hard caps where possible (max model length, max tokens per request). Treat this as last resort.
Token accounting specifics (what actually works):

- Pre-charge an **estimated token cost** at admission time using a tokenizer.
- Reconcile with actual usage after completion.
- When streaming, update counters periodically (every N tokens) so you can cut off abusive streams.
This ties directly into [LLM cost](/blog/ai-agent-cost-per-task-2026) and [agent per-task cost calculation](/blog/agent-per-task-cost-calculation). If you don’t meter tokens, you don’t control spend.

Noisy-neighbor prevention (the practical version):

- Global max concurrency for the whole cluster (protects you).
- Per-tenant concurrency (protects everyone else).
- Optional priority tiers (prod > batch).
If you want a mental model, treat it like database connection pooling. The GPU is the database.

### 3) How should streaming (SSE) be implemented end-to-end to avoid buffering and broken UX?

Streaming is where “it works on my laptop” dies.

A good streaming UX has measurable properties:

- **TTFT p95** stays bounded under load.
- Streams don’t buffer behind the proxy.
- Client disconnects stop GPU work quickly.
- Retries don’t double-bill tokens.
Checklist I use for SSE (proxy + server + client):

1. **Disable proxy buffering for SSE routes.** If your gateway buffers, users see nothing for 20 seconds then a wall of text.
1. **Set read timeouts for long streams.** Default 60s timeouts are a footgun.
1. **Send heartbeats.** A comment line every 10–15 seconds prevents idle timeouts.
1. **Handle client disconnects.** When the browser tab closes, stop generation.
1. **Backpressure matters.** If the client can’t read fast enough, don’t queue infinite chunks.
1. **Retry semantics must be explicit.** If a stream breaks at token 500, do you resume, restart, or fail? Pick one and document it.
You can’t hand-wave this. Streaming is part of your product.

If you’re building agents, streaming also changes tool-call behavior. A half-streamed response that triggers a tool call is how you get weird partial states. Tie this into your [agent orchestration](/blog/ai-agent-control-flow-architecture) and [agentic AI](/blog/rise-of-agentic-ai) decisions.

### 4) What should you log (and redact) for prompts/responses in production?

Log everything and you will leak everything.

Log nothing and you won’t be able to debug outages, abuse, or customer issues.

The right answer is “log the minimum useful data, redact by default, and retain for a short window.”

My baseline schema:

- Always log: timestamp, tenant id, request id, model name, prompt token count, completion token count, TTFT, total latency, status code, stream aborted (bool).
- Sometimes log: prompt/response **hashes** (not raw), top-level classifier labels, policy decisions (allowed/denied + reason).
- Rarely log: raw prompts/responses, only for opt-in tenants or sampled debug sessions with tight retention.
Redaction rules:

- Treat prompts like user data. Because they are.
- Redact secrets and identifiers before persistence.
- Never log Authorization headers.
If you want deeper patterns here, read my [LLM data leakage playbook](/blog/llm-data-leakage-playbook) and [AI agent observability logging schema](/blog/ai-agent-observability-logging-schema). They cover retention and correlation IDs in a way that’s actually implementable.

Abuse prevention note: prompt injection shows up in logs. That means logs become sensitive. Tie this into [prompt injection](/blog/prompt-injection-2026-owasp-llm-vulnerability) and [how to stop repo prompt injection in coding agents](/blog/repository-prompt-injection-coding-agent).

## Deploy vLLM on Kubernetes with NVIDIA GPU (and the gotchas that waste days)

You can absolutely run vLLM on Kubernetes. Most production teams do, because the alternative is a pets-not-cattle GPU box that nobody wants to own.

The key is accepting a boring truth: Kubernetes GPU scheduling is a *separate* system you must get right before you debug vLLM.

A few concrete “this will bite you” details pulled from Vishnu Hari Dadhich’s Minikube/WSL2 guide:

- Docker Desktop’s built-in Kubernetes on Windows/WSL2 can fail to expose GPUs to pods even when `nvidia-smi` works on the host.
- Using Minikube plus the NVIDIA device plugin/toolkit configuration is a reliable workaround.
- The `/dev/shm` shared memory gotcha is real. Insufficient shared memory breaks inference in ways that look like random instability.
If you’re running consumer GPUs, also cross-check my [ROCm](/blog/amd-rocm-vs-cuda-local-ai-open-source-guide) coverage if you’re on AMD, and the broader [local AI](/blog/ai-hardware-complete-guide) decisions if you’re still choosing hardware.

One number to keep in your head: Jangwook Kim references an architecture footprint serving across **24 NVIDIA B300 GPUs**. You don’t need 24 GPUs to start. But it’s a good reminder that “SLA-grade” means routing, replicas, warmups, and measurement. Not one pod.

### Troubleshooting vLLM GPU Support on Docker Desktop WSL2 Kubernetes

This is the fastest way to lose a day: everything works in `docker run --gpus all`, then your pod shows zero GPUs.

Common failure modes:

- NVIDIA device plugin not installed or misconfigured.
- Container runtime mismatch (`containerd` config not using NVIDIA runtime).
- Docker Desktop Kubernetes limitations on Windows/WSL2.
Vishnu’s takeaway is pragmatic: Docker Desktop Kubernetes may simply not detect your GPU in WSL2 scenarios, and Minikube with the right setup is more reliable.

Also, don’t ignore shared memory.

If you see weird crashes under load, check `/dev/shm` sizing before you start blaming “vLLM bugs.”

## The 15-item production checklist (auth, quotas, streaming, safety)

Here’s the actual checklist I’d use to declare “this endpoint is production-shaped.” It’s intentionally blunt.

1. TLS termination at the edge. No plaintext in-cluster unless you have a reason.
1. Auth in front of vLLM (`Authorization: Bearer …`). Never expose vLLM directly.
1. Tenant identity derived from auth, injected as `x-tenant-id`.
1. RPM and burst rate limits at the gateway.
1. Per-tenant concurrency caps (hard).
1. Per-tenant TPM budgets with token accounting.
1. Request guardrails: max input tokens, max output tokens, max context.
1. Global admission control when GPU queue time exceeds SLO.
1. Streaming SSE configured to not buffer at the proxy.
1. Client disconnect stops generation.
1. Structured logs with correlation IDs and tenant ids.
1. Redaction-first logging. No raw prompts by default.
1. SLIs: TTFT p95, total latency p95, tokens/sec, 429 rate, queue wait time, aborted streams.
1. Rollout plan: canary model version, warmup, and rollback within minutes.
1. Showback: per-tenant token usage reporting, weekly.
If you only do 5 things from this list, do: 2, 4, 5, 9, 13.

## A practical rollout strategy that won’t break OpenAI SDK clients

The easiest way to burn trust is breaking client integrations because you swapped a model or changed behavior.

Rules for safe rollouts:

- **Pin compatibility**: keep OpenAI-compatible endpoints stable. Add new behavior behind headers or new model IDs.
- **Canary by tenant**: route 1 tenant (or 1%) to the new model version first.
- **Warm up**: pre-load weights before shifting traffic. Cold loads create fake incidents.
- **Version your policy**: quota rules, moderation rules, and default max tokens should be versioned. Otherwise you can’t explain behavior changes.
This is the same kind of discipline I’ve learned running this site’s multi-agent publishing pipeline: deterministic gates catch issues before they become user-visible incidents. In my pipeline, deterministic checks have been more effective than simply “use a bigger model to review the output.” The boring gate wins.

If your clients are agents, add regression tests. Use the same mindset as [AI engineering evals: regression gates](/blog/ai-engineering-evals-gates) or agent tool call failure testing.

Here’s the prediction: by mid-2027, self-hosted inference endpoints that don’t ship with token budgets, tenant isolation, and streaming metrics will look as irresponsible as unauthenticated Redis on the public internet. If you’re self-hosting vLLM now, you can get ahead of that expectation. Or you can wait until an internal team turns your GPU into a shared tragedy of the commons.

Here’s the challenge. Pick one thing you’re currently hand-waving. Auth, quotas, streaming, logging, rollouts. Then implement it end-to-end this week. Production doesn’t reward vibes.

Photo by imgix on Unsplash.