The primary distinction between AI agents (such as Claude Code) and traditional scripts lies in their extensive permissions. They can execute shell commands, modify the file system, and even initiate network requests. Running Claude Code as `root` on a VPS—especially one hosting databases, backend services, or shared resources—is akin to introducing a robot into your home that could spiral out of control at any moment.
Should an agent—due to a "hallucination"—execute a command like `rm -rf /`, or fall victim to a prompt injection attack that leads to the exposure of sensitive keys (such as `~/.ssh/id_rsa` or `.env` files), the consequences could be catastrophic.
Safely running an AI agent on a shared VPS does not require an overly complex architecture; however, it does necessitate adherence to a few fundamental isolation standards.
Configuration 1: User Isolation—Never Run AI as `root`
This is the most essential and cost-effective line of defense.
1. Create a dedicated system user
Establish a specific, non-privileged user account for the AI agent. This user should have access only to its own home directory and possess no `sudo` privileges.
sudo adduser claude-agentDisable shell login for this user (if manual access is not required):
sudo usermod -s /usr/sbin/nologin claude-agent2. Restrict directory permissions
Clone your project into `/home/claude-agent/workspace` and assign ownership to this user. Never expose sensitive directories—such as `/etc`, `/var`, or the home directories of other users—to the agent.
sudo chown -R claude-agent:claude-agent /home/claude-agent/workspace3. Execute as the designated user
If using `tmux`, switch to this user before launching the agent. If using `systemd` (as described in the first article), ensure that `User=claude-agent` is specified within the service file.
Configuration 2: Container Isolation—The Ultimate Sandbox
In scenarios involving multiple projects or shared access, the most straightforward way to prevent cross-contamination is by using Docker containers.
1. Utilize official or custom-built images
Avoid running the agent directly on the host machine. Building a Dockerfile for the Claude Code runtime environment:
```dockerfile
FROM node:18-alpine
WORKDIR /app
RUN npm install -g @anthropic-ai/claude-code
Create a non-root user
RUN addgroup -S agent && adduser -S agent -G agent
USER agentBuild and run:
docker build -t claude-sandbox .
Mount the local code directory into the container
docker run -it --rm -v /home/claude-agent/workspace:/app -w /app claude-sandboxThis approach strictly confines the agent’s file modifications and network activity to within the container, preventing it from accessing the host machine's system files.
Configuration 3: Resource Limits—Preventing the Agent from Crashing the Server
As mentioned earlier, Claude Code may occasionally experience memory leaks or abnormal resource consumption. In a shared environment, if it exhausts the available memory, it could trigger the OOM (Out-Of-Memory) Killer, potentially terminating other critical processes.
1. Using systemd cgroups for resource constraints
Add the following to your `claude.service` file:
```ini
[Service]
Limit maximum memory to 4GB
MemoryMax=4G
Limit CPU usage to 200% (equivalent to 2 cores)
CPUQuota=200%If Claude Code’s memory usage exceeds this threshold, the system will automatically terminate the process, thereby protecting the host machine.
2. Applying limits in Docker
Include resource constraints when starting the container:
docker run -it --rm --memory="4g" --cpus="2.0" -v ... claude-sandboxConfiguration 4: Network and Key Isolation
1. Protecting private keys on the host machine
When the agent runs as the `claude-agent` user, it cannot, by default, access the `.ssh` directories belonging to `root` or other users. Furthermore, if the agent is running inside a container, private keys from the host machine are not mapped into the container environment.
2. Minimizing API permissions
In the Anthropic console, generate distinct API keys for different agents whenever possible. Additionally, set conservative spending limits to prevent runaway code from causing an unexpectedly high API bill.
Why is a dedicated, clean VPS the best starting point? No matter how robust the isolation you implement within your system, infrastructure-level isolation remains the primary line of defense. Deploying AI agents alongside your core business operations on the same machine is inherently risky.
If you wish to carve out a dedicated, isolated space for your AI agents, Jtti’s Hong Kong Lightweight Cloud—offering 1 vCPU, 1GB of RAM, and 200Mbps of dedicated bandwidth—serves as an ideal "sandbox." It provides independent resources, ensures no bandwidth contention with other users, and maintains consistent pricing upon renewal, making the long-term costs of running persistent agents highly transparent. For enterprise-grade, multi-agent deployments, Jtti’s 2 vCPU/4GB RAM or 4 vCPU/8GB RAM configurations allow for further multi-dimensional resource partitioning at the container level.
The core logic behind this isolation is to assume that agents will inevitably make mistakes, and then to limit the potential "blast radius" of such errors through layered restrictions. From operating-system-level user isolation and container sandboxing to the underlying virtualization isolation provided by Jtti’s VPS, every layer acts as a safeguard for your data security.
