Leave VLLM_SERVER_DEV_MODE unset, keep profiling off, and enable the tokenizer info endpoint and runtime LoRA loading only if you can justify and guard them. The vLLM security docs say dev mode exposes arbitrary RPC execution, and that these routes sit outside API key protection.
Why a flag list is worth keeping
Inference servers grow features quickly. Many of them add HTTP routes that help in development and become hazards when copied into a production launch script. The fix is boring: keep an explicit list of switches that must not appear in production, and check it in review and in a deploy gate.
The list below comes from the vLLM security documentation. It is the developer preview version, so confirm against the docs for the release you run.
The switches and what they expose
| Switch | What it enables | What the docs say |
|---|---|---|
| VLLM_SERVER_DEV_MODE set to 1 | Development endpoints | Never in production. Includes an endpoint that executes arbitrary RPC methods on the engine, which the docs call extremely dangerous |
| Profiler configuration | Start and stop profiler routes | Never enable in production, local development only |
| Tokenizer info endpoint flag | An endpoint with tokenizer config and chat templates | Reveals chat templates that may hold sensitive implementation or prompt engineering detail |
| Runtime LoRA updating, with LoRA enabled | Routes to load and unload adapters | The docs note that this can alter model behavior |
The development group also includes routes to reset caches and put the engine to sleep, which the docs say can disrupt service or cause denial of service. The docs state that the dev mode routes are available only when that variable is set to 1.
Why the API key does not save you
The same page explains that the API key protects only certain path prefixes, and several operational endpoints sit outside them. So a flag that adds a route may add a route nobody authenticated. That is a separate argument for a reverse proxy with an allowlist, which the docs recommend as the most effective approach.
How to enforce the list
- Search your launch scripts, Dockerfiles, Helm values and environment files for the names above. Make this a CI check.
- In review, treat any new flag on an inference server like a new open port. Ask who needs it and where it is reachable.
- Add a startup check, or a deploy gate, that fails if the dev mode variable is present in a production namespace.
- Run a post-deploy test from outside the network that requests these routes without a token. You want an error from the proxy.
- If you must use runtime adapter updates, keep the server on an isolated network and require authentication at the proxy for those routes.
grep -R "VLLM_SERVER_DEV_MODE" deploy/ charts/ .env* 2>/dev/null
An empty result is the pass condition.
Staging is not a loophole
Teams often say dev mode is fine in staging. Staging often holds real model weights, real keys and a network path to production data. If a dev route can run arbitrary RPC there, an attacker with access gets a foothold. Use a separate, isolated environment for debugging, and tear it down afterwards.
Quick check
Is dev mode safe behind a VPN?
It is safer than public exposure, but the docs say never in production. Anyone on that network can reach a route that executes arbitrary RPC.
Do I need the tokenizer info endpoint?
Usually not. Enable it only if a client genuinely needs tokenizer configuration, and keep it behind your proxy.
Where should this list live?
In version control next to your deploy config, with a CI check that fails the build when a listed switch appears.
Where Safeguard fits
Safeguard applies policies and gates in CI, which suits this kind of rule: a check that blocks a release when a forbidden setting or an advisory-affected version is present. A free scan is a quick way to see your dependencies.
Sources
- vLLM security documentation, read 19 October 2026. This is the developer preview version of the docs.
Last reviewed: 19 October 2026.
