# Using Atlas with vLLM in 2026 > vLLM serves an OpenAI-compatible API on port 8000, so a GPU box on your network can back Atlas for the whole team. Atlas runs against vLLM by pointing at the OpenAI-compatible API vLLM serves on port 8000, so a GPU box on your network can back Atlas for the whole team. Serve a model with vllm serve Qwen/Qwen3-Coder-30B-A3B-Instruct --host 0.0.0.0 --port 8000, then add the endpoint in atlas.json as a provider with baseURL http://localhost:8000/v1 and the matching apiKey. vLLM has no authentication by default, so enable it with --api-key or the VLLM_API_KEY env var before you expose the port. ## vLLM as the shared inference backend for a team of Atlas users vLLM serves an OpenAI-compatible API on port 8000, so a GPU box on your network can back Atlas for the whole team. vLLM is the inference backend and Atlas remains the MCP client, which means one server serves many laptops without touching any laptop's tool configuration. The multi-user shape is what separates vLLM from a single-laptop runtime. vLLM is built for throughput and concurrent requests, so a single GPU host can serve many simultaneous Atlas agent loops rather than one developer's session. Run vLLM on a shared GPU host and let every Atlas laptop point at the same base URL. Each developer keeps their own MCP servers, their own repository, and their own approvals; only the tokens come from the shared box. ## Serving a model with vllm serve on port 8000 Serve a model with vllm serve Qwen/Qwen3-Coder-30B-A3B-Instruct --host 0.0.0.0 --port 8000, which exposes the OpenAI API at http://localhost:8000/v1. The --host 0.0.0.0 flag is what makes the endpoint reachable from other machines rather than only from the GPU box itself. The model argument is a Hugging Face repository identifier, and Qwen/Qwen3-Coder-30B-A3B-Instruct is a coding model sized for a shared GPU host. Binding to 0.0.0.0 rather than localhost is deliberate: a team server that only answers itself is not a team server. Port 8000 is vLLM's default for the OpenAI-compatible API, and once the process is up, http://localhost:8000/v1 on the box and the box's network address elsewhere both resolve to the same endpoint. ## vLLM has no authentication by default, so turn it on vLLM has no authentication by default, so enable it with --api-key or the VLLM_API_KEY env var before you expose the port. Serving on --host 0.0.0.0 without a key means anyone who can route to port 8000 can run inference on your GPU, for free, without asking. Order of operations matters here. Add the key first, then open the host binding, not the other way around, because an unauthenticated server on a routable interface is exposed for exactly as long as it takes you to notice. --api-key sets it on the command line, and VLLM_API_KEY sets it through the environment, which is the better fit for a systemd unit or a container. Whichever you choose, the same value goes into the apiKey field on the Atlas side. ## Configuring the vLLM provider in atlas.json Add the vLLM endpoint in atlas.json as a provider with baseURL http://localhost:8000/v1 and the matching apiKey. Unlike a local runtime that ignores the key, vLLM actually checks it once you have enabled authentication, so the apiKey field must carry the real value you configured. On the GPU host itself, baseURL is http://localhost:8000/v1. On a teammate's laptop it becomes the host's address on your network with the same port and /v1 path. The apiKey must equal whatever you passed to --api-key or set in VLLM_API_KEY, and a mismatch returns an authentication error rather than a connection error, which is a useful distinction when you are debugging why one laptop works and another does not. ## Sizing the context window with --max-model-len Size the window with --max-model-len so Atlas's long agent loops are not truncated mid-plan. An agent that reads files, runs commands, and accumulates tool output consumes far more context than a chat turn, so a vLLM server on port 8000 configured for short prompts will cut the plan off partway through. Truncation in the middle of an agent loop does not fail loudly. The model simply loses the earlier half of what it was doing and produces something confidently wrong, which reads as a capability problem rather than a configuration one. Set --max-model-len deliberately, sized against how long your Atlas sessions actually run, and remember the tradeoff: a longer window costs GPU memory per concurrent request, which matters precisely because the box is shared. ## MCP stays on the Atlas side, because vLLM has no MCP server There is no official vLLM MCP server. vLLM is the inference backend and Atlas stays the MCP client, so every tool your team relies on is configured per laptop in Atlas rather than centrally on the GPU host serving port 8000. Do not go looking for a way to attach GitHub or a filesystem server to vLLM; the responsibility does not live there. vLLM's contract ends at the OpenAI-compatible API, and Atlas owns the agent loop, the tool calls, and the approvals. In practice this is convenient: a developer can change their MCP servers freely without any coordination with whoever operates the shared GPU host, and the host operator never becomes a bottleneck for tooling changes. ## Setup 1. Serve a model with vllm serve Qwen/Qwen3-Coder-30B-A3B-Instruct --host 0.0.0.0 --port 8000, which exposes the OpenAI API at http://localhost:8000/v1 2. vLLM has no authentication by default, so enable it with --api-key or the VLLM_API_KEY env var before you expose the port. 3. Add the endpoint in atlas.json as a provider with baseURL http://localhost:8000/v1 and the matching apiKey. 4. Size the window with --max-model-len so Atlas's long agent loops are not truncated mid-plan. 5. Keep your MCP servers in Atlas: there is no official vLLM MCP server, since vLLM is the inference backend and Atlas stays the MCP client. 6. Run vLLM on a shared GPU host and let every Atlas laptop point at the same base URL. ## FAQ ### how do I use Atlas with vLLM Serve a model with vllm serve Qwen/Qwen3-Coder-30B-A3B-Instruct --host 0.0.0.0 --port 8000, then add the endpoint in atlas.json as a provider with baseURL http://localhost:8000/v1 and the matching apiKey. ### does vLLM require an API key Not by default, which is the problem. vLLM has no authentication by default, so enable it with --api-key or the VLLM_API_KEY env var before you expose the port. ### is there a vLLM MCP server No. There is no official vLLM MCP server. vLLM is the inference backend and Atlas stays the MCP client, so your tools remain configured in Atlas. ### can a whole team share one vLLM server for an AI coding agent Yes. Run vLLM on a shared GPU host and let every Atlas laptop point at the same base URL. vLLM serves an OpenAI-compatible API on port 8000 and handles concurrent requests. ### why does my agent plan get cut off with vLLM The context window is likely too small. Size the window with --max-model-len so Atlas's long agent loops are not truncated mid-plan. ### what port does vLLM use with Atlas Port 8000. vllm serve --host 0.0.0.0 --port 8000 exposes the OpenAI API at http://localhost:8000/v1, which is the baseURL you set in atlas.json. ### what model should I serve with vLLM for coding Qwen/Qwen3-Coder-30B-A3B-Instruct is a coding model sized for a shared GPU host. Serve it with vllm serve Qwen/Qwen3-Coder-30B-A3B-Instruct --host 0.0.0.0 --port 8000. --- Canonical HTML: https://runatlas.sh/resources/integrations/vllm Source of truth: aeo_pages row `/resources/integrations/vllm` (segment: Integrations) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.