Running an AI agent autonomously on a VPS — and why I move to Bedrock in production

Putting an AI agent on a VPS takes about twenty minutes. One apt install, an API key in a .env file, a cron entry, and you have a machine that triages your logs every night. It genuinely works, and it feels good.

The trouble comes later: the day that setup stops running on your own server and starts running at a client's, with their data, their bill, and their IT lead asking questions. At that point the API key in the .env becomes a real problem, and there is no elegant patch for it.

This article does both: the setup that works, then the version I actually deploy in production, built on Amazon Bedrock. Switching from one to the other comes down to a single environment variable — that is all that separates a side project from an auditable piece of infrastructure.

The basic setup: claude -p on a VPS

Claude Code is not only an interactive terminal interface. The -p flag (or --print) switches it into non-interactive mode: it reads standard input, writes to standard output and returns an exit code. In other words it behaves like grep or jq, and can be driven from any shell script.

That is what makes the agent deployable: no session, no TTY, no lingering tmux. An entry-level VPS is enough — inference runs on the API side, the machine only orchestrates.

curl -fsSL https://claude.ai/install.sh | bash

export ANTHROPIC_API_KEY="sk-ant-..."

claude -p "Summarize the errors in this log" < /var/log/app/error.log

The four flags that matter

• --bare — disables auto-discovery of hooks, skills, plugins, MCP servers and CLAUDE.md files. Without it, your agent loads whatever happens to sit in the working directory and in ~/.claude. In production this is the flag that guarantees the command does the same thing on every machine.
• --output-format json — returns a structured object instead of free text: the result, the session ID, token usage and the cost of the run. That is what makes orchestration possible: parse it with jq and branch on the output.
• --allowedTools — the allowlist of tools the agent may use without asking. The syntax supports prefix matching: Bash(git diff *) allows any command starting with git diff. The space before the asterisk is significant.
• --append-system-prompt — adds instructions to the system prompt without replacing default behavior. This is where you define the agent's role: security reviewer, incident triager, report writer.

#!/usr/bin/env bash
set -euo pipefail

cd /srv/project

git diff origin/main | claude --bare -p \
  --append-system-prompt "You are a security engineer. Report only
  exploitable vulnerabilities, with file and line." \
  --output-format json \
  --allowedTools "Read" \
  | jq -r '.result' > /var/reports/review-$(date +%F).md

A systemd timer, a cron entry, and you have an agent producing a review report every morning. It is genuinely useful, and it costs a few cents per run.

What breaks the moment it stops being a side project

The setup above is perfectly viable on your own server. It becomes hard to defend the day it runs at a client's. Four things block, and none of them is solved by tidier file layout.

The production version: the same agent, through Amazon Bedrock

Amazon Bedrock serves Claude models from inside an AWS account. For the agent, nothing changes: same commands, same tools, same prompt. What changes is everything around the call.

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=eu-west-3

# Model pinning (strongly recommended)
export ANTHROPIC_MODEL='eu.anthropic.claude-sonnet-4-5-20250929-v1:0'

claude --bare -p "Summarize the errors in this log" < /var/log/app/error.log

There is no ANTHROPIC_API_KEY in the environment anymore. Claude Code uses the standard AWS SDK credential chain: on an EC2 instance it picks up temporary credentials from the IAM role attached to the machine. No secret is written to disk, and rotation is handled by AWS.

The minimal IAM policy

This is the heart of it: the agent's permissions become a declarative resource, versioned in your Terraform, reviewed in a pull request.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "bedrock:InvokeModel",
      "bedrock:InvokeModelWithResponseStream",
      "bedrock:ListInferenceProfiles",
      "bedrock:GetInferenceProfile"
    ],
    "Resource": [
      "arn:aws:bedrock:*:*:inference-profile/*",
      "arn:aws:bedrock:*:*:foundation-model/*"
    ]
  }]
}

Narrow the resource down to the ARNs of the inference profiles the agent is actually allowed to call and you get a clean perimeter: this agent, on these models, in this account.

What that changes in practice

aws bedrock list-inference-profiles --region eu-west-3

Pin your models

Without explicit pinning, the sonnet and opus aliases resolve to Claude Code's built-in defaults, which shift across versions and may not be enabled in the client's account. Across a fleet of machines, that guarantees behavior changing on its own one morning — and the bill changing with it, since an Opus model costs noticeably more than a Sonnet.

export ANTHROPIC_DEFAULT_SONNET_MODEL='eu.anthropic.claude-sonnet-4-5-20250929-v1:0'
export ANTHROPIC_DEFAULT_HAIKU_MODEL='eu.anthropic.claude-haiku-4-5-20251001-v1:0'

In an enterprise setting you go further: application inference profiles let you route each model version to an ARN managed by the organization, with its own quotas and its own cost tracking.

What if the client isn't on AWS?

The argument in this article is not "use Bedrock". It is that a production agent must not carry a static secret, and must be traceable, capped, and controlled as to where its data is processed. Bedrock is one way to get those four properties when the client is already on AWS. It is not the only one.

On GCP, Azure or a mixed estate, the usual answer is an LLM gateway — LiteLLM being the most widely deployed open-source implementation. It sits between the agent and the provider and delivers exactly the same thing: the provider key stays server-side, each service or developer gets its own credential, usage is attributed, budgets and rate limits are enforced in one place, and every request is logged.

On the agent side, the switch is once again a single variable:

export ANTHROPIC_BASE_URL=https://gateway.internal.example.com

A gateway even brings one property Bedrock does not: switching provider happens in the gateway's configuration, without touching the machines running the agents.

The trade-off is real, and worth stating before you commit: the gateway becomes infrastructure you operate. It has to keep pace with the client — a gateway that fails to forward a new capability breaks the corresponding feature. And Anthropic does not maintain or audit third-party gateway products.

Before you let it run: what to lock down

An autonomous agent on an exposed machine is a process running shell commands chosen by a model, based on content it reads. That content — a log, a GitHub issue, a file dropped by a third party — is not trusted. Five rules, in order of importance:

• No --dangerously-skip-permissions on an exposed machine. The right setting is an allowlist via --allowedTools, optionally combined with the dontAsk mode, which denies anything not covered by your allow rules or the read-only command set. An agent that fails because it lacks a permission is a useful signal; an agent with every permission emits none.
• A dedicated, unprivileged system user. No root, no shared deploy account. The agent only reaches the directories it must work on, with an IAM role carrying just the Bedrock actions it needs — and certainly not the account's administrative credentials.
• Restricted network egress. An outbound security group limited to what the agent actually needs. That is the net that limits damage if malicious content manages to influence a command.
• An execution time cap. A TimeoutStartSec on the systemd side, or a timeout around the call. On SIGTERM, Claude Code aborts the in-progress turn, terminates the process tree of any running command and exits with code 143 — the shutdown is clean, but something still has to trigger it.
• Retained logs. Redirect the JSON output to a file or to CloudWatch. The day the agent does something unexpected, the full session trace is the only thing that lets you understand it.

API key or Bedrock: the table

The verdict is fairly simple. For prototyping, exploring, automating your own tasks: the API key, without hesitation — it is faster and the governance overhead is not justified. As soon as there is a client, data that is not yours, or a budget to defend: a governed architecture — Bedrock if the client is already on AWS, an LLM gateway otherwise. Either way, the move happens without rewriting a single line of the agent.

Frequently asked questions