Claude Code on a VPS vs SSH From Your Laptop

Start on your laptop unless persistence solves a real problem

You are choosing whether Claude Code runs beside your local repository or directly on the VPS serving your application. We recommend starting on your laptop, with narrowly scoped SSH access to an Ubuntu 24.04 LTS server, and moving the agent onto a VPS only when a persistent remote workspace earns its maintenance.

For routine operations, a local checkout gives Claude Code enough context to explain a deployment script or prepare a configuration change. You can approve a specific remote inspection when the task needs live evidence. Keeping the agent off production also keeps its own process and development dependencies from competing with the application.

A server installation becomes useful when your working files already live remotely or you regularly need to reconnect from another computer. That convenience does not require installing the agent on the production machine. A separate development VPS is often the better place for a persistent workspace once you have a concrete need for one.

Choose the jobs before choosing the location. Our AI operations delegation playbook helps separate investigation from actions that deserve a human decision, such as changing production access.

Identify where Claude Code and its commands actually run

An SSH terminal on your laptop does not tell you where Claude Code runs. If you connect to the VPS and launch claude inside that remote shell, the agent process runs on the VPS. If you launch it locally and it invokes SSH, its remote commands run on the server while the agent process stays on your laptop.

Installing Claude Code on a VPS does not turn that VPS into a self-contained inference server. The standard setup requires network access and authentication to a supported service. Ubuntu 24.04 LTS is suitable for the CLI; follow the official installation and authentication instructions under the account that will run it.

Neither arrangement keeps everything the agent reads confined to that machine. Treat files and command output supplied to Claude Code as information that may enter the service conversation. Collect the relevant log excerpt instead of handing over a complete environment file simply because it is convenient.

Use laptop access for bounded production work

We prefer a local agent when production access is occasional and the repository contains the operational instructions. Ask Claude Code to inspect the deployment code first, then request only the remote evidence needed to resolve uncertainty. This makes it easier to notice when a task expands from diagnosing a failure into changing the server.

Use a dedicated remote account with permissions appropriate to those investigations. A different SSH key makes access easier to revoke, but it does not reduce authority if it logs into the same unrestricted administrator account. For tighter separation, enforce restrictions on the server account or expose a narrowly scoped inspection command.

• Let the inspection account read selected application logs, after considering whether those logs contain credentials or personal data.
• Require a separate approval for deployment commands, with the exact target and operation visible.
• Keep database administration credentials out of the agent's ordinary environment.
• Avoid blanket approval for arbitrary SSH commands, because their remote effects vary with the command and account.

The laptop is still part of the security boundary. Claude Code may have access to local credentials available to its operating-system account, so a dedicated production key does not automatically isolate your other keys. Keep SSH agent forwarding disabled unless a specific workflow requires it, and verify unfamiliar host keys through your provider's console before connecting.

Do not depend on a laptop session for work that must continue unattended. Sleep or a lost connection can interrupt the agent, while a remote command might continue or stop depending on how it was launched. After reconnecting, inspect the deployment state before retrying anything that could execute twice.

Put Claude Code on a VPS when the workspace must persist

A persistent remote workspace is useful when a task spans several sessions or you switch computers regularly. The checkout and running terminal stay together, reducing the need to reconstruct your working state. On the production host, direct access to local files also removes some SSH command plumbing.

That shorter path also makes mistakes easier to apply directly. A build launched beside the application can compete for memory, and a broad file edit can affect a live checkout if ownership permits it. We would use a separate workspace directory and keep deployment behind an explicit promotion step.

For session persistence, start Claude Code inside tmux rather than relying on an ordinary SSH shell. A tmux session can remain running when its client disconnects, and you can attach again later. The tmux getting-started guide documents session creation and reattachment.

Persistence has limits: tmux does not preserve a running process through a reboot or a machine failure. It also cannot answer an approval prompt while you are away. Before relying on it, detach during a harmless task, reconnect, and confirm that you return to the same session.

Size the workspace for the commands it will execute, especially builds, rather than treating the CLI as the whole workload. If your application already has little spare memory, use a separate machine. When that need is established, compare hosting options for Claude Code by available memory and recovery access before choosing a provider.

Restrict authority before approving production commands

The decisive safety question is what the operating-system account can do. A local agent with unrestricted SSH access can damage production just as effectively as a remote agent with unrestricted sudo. Running from a project directory does not prevent an approved shell command from reaching other paths that the account can access.

Use Claude Code's permission controls to make consequential actions visible, then enforce the hard limits outside the conversation. Anthropic's security documentation explains that the working-directory boundary is a permission prompt and that approved shell commands can operate with the user's filesystem authority. Instructions in a project file help communicate policy, but they do not change that authority.

We would keep explicit approval for production mutations and avoid permission-bypass modes on a production-connected account. Review the effective rules through /permissions, including inherited approvals. The permission configuration reference describes how modes and rules affect which actions prompt.

• Run the agent under an account without unrestricted sudo or access to the Docker socket.
• Keep production secrets unreadable by the agent account unless a specific task requires access.
• Keep privileged deployment scripts and every parent directory outside the agent's write permissions.
• Review shell expansions and command chaining before approving a remote operation.
• Treat instructions found in logs or repository content as untrusted input, especially when they request credentials or broader access.

A narrow sudo rule is ineffective if the permitted script accepts arbitrary commands or the agent can rewrite it. Read the script and check its ownership before treating it as a boundary. Use the production agent guardrails guide to turn those restrictions into an operating policy you can verify.

Keep deployment and recovery independent of the agent

Claude Code should prepare changes that your normal deployment procedure can apply and reverse. Avoid a workflow where the only record of a production edit is buried in a conversation. Keep the proposed diff reviewable, and record the deployed revision alongside the result of the application health check.

This matters particularly when the agent runs on the application VPS. If that machine becomes unreachable, you lose both the service and the agent workspace at the same time. Retain an independent administrator login and confirm that you can use the provider's recovery console.

Keep backups outside the VPS and make restoring them a procedure you can perform without Claude Code. A persistent terminal is useful working state, but it is not a recovery system. Follow the independent VPS backup procedure before allowing an agent to participate in production changes.

For long operations, prefer a reviewed deployment job with durable status over an ad hoc command tied to the agent's terminal. When a connection fails, inspect that job's status before restarting it. A retry is safe only when you understand what the previous attempt already changed.

Run a bounded investigation before expanding access

Begin with Claude Code on your laptop unless you have already identified a persistence requirement. Choose a harmless investigation, such as explaining how the application starts from its deployment files and a sanitized service-status excerpt. Give the agent a specific question and require approval before any remote command.

1. Open the relevant checkout and identify the intended production host and remote account.
2. Review that account's effective permissions, including supplementary groups and sudo rules, from your administrator session.
3. Ask Claude Code to propose the exact inspection command and explain what evidence it expects.
4. Approve the bounded inspection, then compare its answer with the actual command output.

If you chose a VPS workspace, repeat the exercise there under its restricted account, then verify tmux reattachment during a harmless session. Confirm that the account cannot read a protected test file or write outside its assigned workspace where your policy forbids it. Use disposable files for these checks, never real secrets.

Write down the approved inspection task and the access it required. Keep that as the starting permission set for the next session. Expand access only when a concrete task fails for a reason you understand, and review the proposed change before granting it.