Claude code self hosted means you run the command line program on your own server, while the model keeps running on the provider infrastructure.
Condition: this route fits when your goal is to hold repositories, API keys, and work logs on your own machine.
Limit: Claude model weights are not distributed for installation on your server, so conversation content still leaves over the network to the provider API.
I wrote this after I read the official documentation line by line. Then I separated what you can truly hold from what you cannot. One term first, to make the rest easy. A CLI is a program you run by typing a command in a terminal, the way you type ls to list a folder. Claude Code is that kind of program. It sits on your machine, reads your files, and calls the model over the internet.
The trouble is that people use the phrase "self hosted" for 4 different things. All 4 are legitimate. What differs is who holds the key and where the data flows.
At a glance: 4 things people call self hosted
Read the last column first. Your decision lives there.
| Route | Runs on your machine | Stays with the provider | Key holder |
|---|---|---|---|
| CLI on your VPS | CLI, repository, session logs | Model | You |
| Official self hosted runner | Runner, checkout, build output | Model, session control plane | Your organization |
| Your own gateway | Gateway, staff sign-in | Model | The gateway server |
| Open weight model on your machine | Everything, the model included | Nothing | You |
The official documentation states that sessions in a terminal or an IDE always run on the developer's own machine. So the first row is not a trick. That is the default behavior.
What sits on your machine, on the wire, and with the provider
I use 3 columns to explain it. The left column is fully yours. The right column is not yours. The middle column is the part people forget, and the risk sits there.
The documentation states that Claude Code runs locally. To interact with the model, the program sends data over the network. That data includes all user prompts and model outputs, encrypted in transit with TLS 1.2 or later.
So the sentence "I self host Claude Code" is correct about the program and wrong about the model. This is not a product weakness. It is the shape of the architecture, and you must know that shape before you promise anything to your legal team.
Claude code self hosted on your own VPS
This is the cheapest route and the one I use most. You rent 1 VPS, install the CLI, put your own API key there, and keep the repository on that disk. The documentation shows installation through 1 download command for macOS, Linux, and WSL. When the ANTHROPIC_API_KEY variable is already set, the CLI skips the login screen and only asks you to approve that key.
Three things need your attention, and all 3 concern traces on disk.
First, transcripts. The client stores session transcripts locally in plaintext under ~/.claude/projects/ for 30 days by default, so a session can resume. You change that period with cleanupPeriodDays. Plaintext means anyone who can read that disk can read your work.
Second, telemetry. The documentation names 2 kinds of operational traffic: metrics and error reports. Metrics never include your code, prompts, or file paths. You turn metrics off with DISABLE_TELEMETRY=1, error reports with DISABLE_ERROR_REPORTING=1, or all non-essential traffic at once with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC.
Third, the work boundary. In manual mode, the CLI can only write to the folder where it started and the subfolders below it. It also asks before it reads paths outside that boundary. That boundary keeps 1 session from wandering across your whole server.
For the daily working pattern on top of this route, I wrote it up separately in the Claude Code loop workflow for daily coding and in how to use dynamic workflows correctly.
The official self hosted runner for teams
There is an official route that goes further than a CLI on a VPS. The documentation calls it a self-hosted environment. Its status when I read it: public beta for Team and Enterprise organizations, and off by default.
It works like a self hosted CI runner. You run a runner program on hosts inside your network. That runner claims a session from a queue, clones the repository, and starts a Claude Code process on your host.
Two sentences matter for your decision. Repository checkouts, build artifacts, secrets, and files a session creates stay on the machines you provision. The conversation itself, prompts, responses, and tool results included, still goes to the provider API for inference, and the session transcript is stored there so you can resume the session from another surface.
I noted 3 limits. Every connection is outbound from your network, and none is inbound. Inference uses the provider API and cannot be routed through Amazon Bedrock, Google Cloud, Microsoft Foundry, or an LLM gateway. Organizations with Zero Data Retention cannot use this route.
Your own gateway: the key moves off the laptop
This route often drops out of the discussion, even though it answers the real worry. That worry is rarely "where does the model run". It is usually "why do 12 laptops hold the company API key".
The documentation describes Claude apps gateway as a self hosted service that sits between your Claude Code clients and your model provider. Developers sign in with your corporate identity provider instead of holding API keys or cloud credentials. The gateway holds the upstream credential. It also enforces model access and managed settings by identity group, then relays usage telemetry to your own observability stack.
One practical detail: the gateway ships inside the claude binary. The same executable that runs Claude Code on a laptop runs the gateway server with claude gateway --config gateway.yaml.
If you only need to steer traffic, a smaller door exists. A corporate proxy is set with HTTPS_PROXY or HTTP_PROXY. An LLM gateway is set with ANTHROPIC_BASE_URL and its per-provider siblings.
When the weights must sit on your machine
Sometimes the rule is hard: no text may leave the building. If that is your rule, Claude is not the answer, and I prefer to say so plainly.
The official documentation compares the places inference can run: the provider API, Amazon Bedrock, Claude Platform on AWS, Google Cloud, and Microsoft Foundry. The provider operates all of them, not you. No option puts the model weights on hardware you own.
One nuance from their encryption table deserves a note. On Microsoft Foundry with the hosted on Azure option, prompts and completions remain within Azure, and only usage metadata and content flagged by safety systems leaves to the provider. That is not self hosting, but it is a shorter data path for some residency rules.
For weights on your own machine you need an open weight model family and hardware that can run it. This next point is my observation from practice, not a documentation quote: the reasoning quality of open weight models that fit on 1 single GPU does not yet match frontier models, so recount the work you plan to hand over.
How to choose in 1 minute
I start with 1 question: what must never leave your machine? The answer picks the branch.
| Option | Deciding condition | Price you pay |
|---|---|---|
| CLI on your VPS | Repository and logs must stay on your machine | You handle patches and server access |
| Self hosted runner | Sessions must reach internal services | You maintain the image and the runner fleet |
| Your own gateway | API keys must not sit on laptops | You operate 1 more service |
| Local open weight model | No text may leave at all | Answer quality drops, GPU cost rises |
Simulation: 1 VPS, 1 key, 1 agent
The numbers below are dummy data, not a client result. I use them to show the order of steps and the shape of the output.
Starting condition: 1 team VPS with 4 vCPU, 3 developers, 1 online shop repository, and 1 API key that now sits on 3 laptops.
Input: 1 task request, "fix 12 lint errors in the checkout module, then open 1 branch".
Step 1: install the CLI on the VPS, not on a laptop. Step 2: keep the API key only on that VPS. Step 3: start the session inside the repository folder, not in the home folder. Step 4: set DISABLE_TELEMETRY=1 and cleanupPeriodDays to 7. Step 5: limit SSH access to 3 public keys.
Observable output: 1 new branch in the local repository, 12 lint errors gone, the session transcript on the VPS disk, and no API key on any laptop.
Decision from the simulation: 3 laptops drop to 0 key holders, but 1 VPS becomes a new target. That is why step 5 is a requirement, not an extra. I published the hardening list I use in the production ready VPS hardening checklist.
Checklist before you call it safe
- Keep the API key in 1 place, then delete the copies from laptops.
- Start sessions inside the repository folder, so the write boundary stays narrow.
- Shorten the local transcript period with
cleanupPeriodDays. - Turn telemetry and error reports off when your policy demands it.
- Record who can SSH into that server, then review the list each month.
- Write permission rules in the project settings file, not in 1 person's head.
- Keep client repositories on a different server from internal repositories.
- Test recovery once: delete a session, then confirm the work still lives in git.
On settings files, the documentation names 4 layers: user settings, shared project settings, project local settings, and managed organization settings. The managed layer wins over all the others, and that is the layer a security team uses to set policy.
Questions and answers
Can Claude Code run without internet access? No. The program runs locally, but each request to the model travels over the network, so a session stops when the connection drops.
Is my code used to train the model? For commercial Team, Enterprise, and API accounts, the documentation names a standard 30 day retention period, and Zero Data Retention is available to qualified Enterprise accounts.
Can I use my own API key on my own server? Yes. Set the ANTHROPIC_API_KEY variable on that server, and the CLI then skips the login screen and asks you to approve that key.
How does a self hosted runner differ from a CLI on a VPS? The runner executes cloud sessions started from the web or a phone inside your network, while a CLI on a VPS serves only the sessions you start in that terminal.
Does my own gateway stop data from reaching the provider? No. The gateway moves the credential to your server and turns off session usage analytics, but conversation content still goes to the model provider for inference.
How long do transcripts stay on my machine? The default is 30 days in plaintext under the Claude projects folder, and you can shorten it through the cleanup period setting.
Sources
- Claude Code overview supports the CLI definition, the list of surfaces, and the installation method.
- Claude Code data usage supports the data path, the local transcript period, and the telemetry opt-out variables.
- Self-hosted environments supports the beta status, how a runner works, and the list of what stays on your infrastructure.
- Claude apps gateway supports the role of a self hosted gateway and the command that runs it.
- Enterprise deployment overview supports the list of places inference runs and the proxy and gateway variables.
- Settings files and precedence supports the 4 settings layers and the precedence of the managed layer.
- Claude Code security supports the working directory boundary and the per action permission model.
I read those 7 pages on 11 September 2026. The claims in this article are limited to what those pages stated on that date.
Next step
If you want an agent running on your server with access limits, user roles, and an audit log, that is installation work, not prompt writing. I do it through the AI agent ops install service. Send me 1 sentence about your machine and the data that must not leave, and I will tell you whether the route you picked actually fits.
