Your own coding-agent server: the setup I run 10+ agents on

A coding-agent server is an always-on cloud computer that runs Claude Code, Codex or another coding agent while you steer it from your phone or laptop. This playbook sets one up on AWS with Ubuntu, private access over Tailscale, background services and a git worktree per agent, so the work keeps going when your laptop is shut.

I now run all of my development work on a server. Before, it was really annoying: I'd have to prop my laptop open, or my work would stop when I closed the lid to go into a meeting. Now it's continuously going, all the time. It's game changing, and it's where development is going.

Allow about two hours for a first attempt, plus a paid server and any agent subscriptions you choose. You need basic terminal and git experience. I have not run this published walkthrough end to end on a fresh server. Read each command before running it, and use the check at the end of each step.

What you end up with: a server that's always on, agents you start and answer from your phone, each in its own git worktree so their edits stay separate, and no public SSH.

How I use my coding-agent server

I have 10+ agents running at all times. On a normal day they take the action items from my meetings, emails and Slack and work through them, and they check with me before they act on anything.

One example from this week: an agent picked up a follow-up email from one of my meetings and messaged me, "Hey, just drafting this, just confirming". I said "Yep" and it sent it.

That is the model for the rest of this guide. The agents live on the server. My phone and laptop are just the controls.

What do you need before starting a coding-agent server?

Run A, B or both. A is simplest if you only use Claude; B suits several models.

Step 1: How do you rent a coding-agent server on AWS?

We use AWS. Any provider works; if you'd rather use another, see the box at the end of this step.

Your AWS account (one time)

1. Create an account at aws.amazon.com. You'll sign in as the root user: the email and password you signed up with.
2. Add MFA to root: click your account name at the top right, then Security credentials → Assign MFA device. Root can close the account, so protect it and only use it for billing.
3. Create your everyday login through IAM Identity Center, with MFA and access limited to what you need.
4. Set a budget alert: Billing → Budgets → Create budget, choose a monthly cost budget you're comfortable with, and enter your email. Alerts can lag behind usage and do not cap spending.

Pick the server size

How many agents you run at once decides the size. Pick yours:

Price the size for your region in the AWS Pricing Calculator before you launch.

Launch the server (EC2)

1. At the top right, choose the region nearest you, for example Asia Pacific (Sydney) ap-southeast-2. Then go to EC2 → Instances → Launch instances.
2. Name: box. Image: Ubuntu Server 24.04 LTS, 64-bit x86, not Amazon Linux.
3. Instance type: the one the sizer gave you.
4. Key pair: Create new key pair, type ED25519, format .pem. On your laptop, move the download to ~/.ssh/box.pem and run chmod 400 ~/.ssh/box.pem. Back it up in your password manager.
5. Network settings → Edit: leave Auto-assign public IP on. Create a security group with two inbound rules:
   • SSH, port 22, Source: My IP. Temporary, for setup only. Never "Anywhere".
   • Custom UDP, port 41641, Source: Anywhere. This lets Tailscale make a direct connection to the server. Without it, AWS silently drops the direct attempts and you get a relayed connection that goes stale when idle. That missing rule cost us weeks of flaky connections.
6. Storage: set the root disk to the size the sizer gave you, type gp3.
7. Choose Launch instance, wait for Running and the status checks to pass, and copy the Public IPv4 address.

Connect from your laptop: ssh -i ~/.ssh/box.pem ubuntu@<public-ip>. Type yes the first time. You should see an Ubuntu welcome message and an ubuntu@... prompt.

Price the server before launching. Put your region, instance, disk and public IPv4 address into the AWS Pricing Calculator. Stopping the server pauses compute charges; the disk and other resources keep costing money.

Using another provider instead? Hetzner and DigitalOcean work too. Choose Ubuntu 24.04 and a size from the sizer, open UDP 41641 in their firewall, add your SSH public key, and create an ubuntu user with sudo if they log you in as root.

Step 2: How do you prepare Ubuntu on the coding-agent server?

As ubuntu on the server:

sudo apt update && sudo apt -y upgrade
sudo apt -y install git tmux build-essential unzip jq ripgrep ufw unattended-upgrades earlyoom gh
sudo timedatectl set-timezone Australia/Melbourne        # your own zone
# Key-only SSH. Keep your current SSH session open while you do this.
printf '%s\n' 'PasswordAuthentication no' 'KbdInteractiveAuthentication no' | sudo tee /etc/ssh/sshd_config.d/00-local-auth.conf
sudo sshd -t && sudo systemctl reload ssh

You should see no errors, and sudo whoami prints root. Before closing this session, check a second terminal can still connect with your key.

Step 3: How do you connect to the coding-agent server privately?

Tailscale gives the server a private address that works from anywhere, on any wifi, without SSH open to the internet. We use plain SSH with a key over Tailscale, not Tailscale SSH. Tailscale SSH in check mode asks you to re-verify in the browser, by default every 12 hours, and an unattended agent just hangs waiting for it.

1. On the server:

   curl -fsSL https://tailscale.com/install.sh | sh
   sudo tailscale up
   tailscale ip -4          # note this address
   

   Open the link it prints and sign in. Rename the machine to box in the Tailscale admin console.

2. Install Tailscale on your laptop and phone (App Store, Play Store or tailscale.com) and sign in with the same account. All three devices should show as connected.

3. On your laptop, add a shortcut to ~/.ssh/config. We use the Tailscale IP rather than the name, because name lookup hangs on some networks while the connection itself works:

   Host box
     HostName <tailscale-ip>
     User ubuntu
     IdentityFile ~/.ssh/box.pem
     ServerAliveInterval 30
   

   Now ssh box logs you straight in.

4. Close the public door. Once ssh box works, run this on the server:

   sudo ufw allow in on tailscale0
   sudo ufw allow 41641/udp
   sudo ufw enable
   

   Then delete the port 22 rule from the AWS security group and keep the UDP 41641 rule. Connecting to the public IP now times out, and ssh box still works. Keep your current session open and check a second ssh box connects before you remove port 22. If you lock yourself out, the EC2 serial console is the way back in; check it works for your instance first.

Your editor on the server

In VS Code or Cursor, install the Remote-SSH extension, run Remote-SSH: Connect to Host and pick box. Open ~/projects/<repo>. You should see the server's files, and a terminal that runs on the server.

Step 4: How do you install developer tools on the coding-agent server?

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
gh auth login                       # GitHub.com, HTTPS, sign in with the browser code
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
source ~/.bashrc                    # load nvm into this shell
nvm install --lts                   # Node LTS; check T3's current version requirements
mkdir -p ~/projects && cd ~/projects && gh repo clone <you>/<repo>

Keep every full clone in ~/projects. Agents make their worktrees beside or inside these clones. gh auth status shows you're logged in, and node -v prints v20 or later.

Step 5: How do you keep the coding-agent server responsive?

Agents run builds and tests in parallel, and running out of memory is the number one way these servers die. Add swap, and turn on earlyoom so it kills a runaway build rather than letting it freeze SSH:

swapon --show                       # check first; don't overwrite an existing swapfile
sudo fallocate -l 8G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
sudo systemctl enable --now earlyoom

Turn on security updates with sudo dpkg-reconfigure -plow unattended-upgrades. Once a week, run df -h / and remove worktrees whose branch is merged (git worktree list, then git worktree remove <path>). free -h shows swap, and systemctl is-active earlyoom prints active.

Step 6A: How do you run Claude Remote Control on the coding-agent server?

You need a paid Claude plan (Pro, Max, Team or Enterprise).

Install and sign in

curl -fsSL https://claude.ai/install.sh | bash      # as ubuntu, no sudo
cd ~/projects/<repo> && claude

Open the sign-in link it prints, paste the code back, and say yes when it asks whether to trust the folder. Ask it "what's in this repo?" to check it works, then type /exit.

Make it reachable from your phone, permanently

claude remote-control turns the server into an environment in the Claude app. Run it as a system service so it starts at boot and you never need to SSH in to start work. First run claude remote-control --spawn worktree --capacity 4 once by hand in the repo, accept its first-run confirmation, connect once from your phone, then stop it.

Create /etc/systemd/system/claude-rc-<repo>.service with sudoedit, replacing every <repo> with the folder name:

[Unit]
Description=Claude Code Remote Control (<repo>)
After=network-online.target
Wants=network-online.target

[Service]
User=ubuntu
WorkingDirectory=/home/ubuntu/projects/<repo>
Environment=HOME=/home/ubuntu
Environment=CLAUDE_REMOTE_CONTROL_SESSION_NAME_PREFIX=<repo>
ExecStart=/home/ubuntu/.local/bin/claude remote-control --spawn worktree --capacity 4
Restart=on-failure
RestartSec=15

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload && sudo systemctl enable --now claude-rc-<repo>
systemctl status claude-rc-<repo> --no-pager | head -5

• --spawn worktree starts each session from your phone in its own git worktree. Shared ports and databases still need coordinating.
• --capacity 4 caps how many sessions run at once. Start lower and raise it while watching memory; builds use far more RAM than idle agents.
• One service per repo gives one environment per repo in the app. Or run a single catch-all service with WorkingDirectory=/home/ubuntu/projects and --spawn same-dir, and tell each session which repo to work in.

On your phone: open the Claude app, go to Code, pick the environment (named after the repo) and start a session. On a laptop, use claude.ai/code. The agent replies, and a new worktree appears under the repo on the server.

Two lessons learned the hard way

• Restarts interrupt sessions. I have seen old conversations become unavailable after a service restart. Finish or save active work before restarting, and keep committed code in git.
• Keep the approval prompts on. My agents check with me before they act, and I answer from my phone. The server still holds code, credentials and access to other services.

Step 6B: How do you run T3 Code on the coding-agent server?

T3 Code (t3.codes) is free and open source. It drives the agent CLIs you've installed and signed in to on the server, using your own subscriptions.

curl -fsSL https://claude.ai/install.sh | bash && claude auth login   # Claude Code
npm install -g @openai/codex && codex login --device-auth             # Codex (optional)
# Install T3 from the official instructions first: https://t3.codes/download
t3 --version
t3 connect link --headless      # sign in to T3 Connect with the device code
t3 service install              # background service that survives reboots
t3 service status
t3 project add ~/projects/<repo> --title "<repo>"   # repeat per repo
t3 connect publish              # optional: push notifications on your phone

On your phone and laptop: install the T3 app and sign in with the same T3 Connect account. You should see the server and its projects. Start a thread, pick Claude or Codex, and choose a separate worktree for each parallel thread.

These commands were checked against t3 v0.1.0 on 25 October 2026. Run t3 connect --help if your release differs.

Leave T3 on localhost, the default: T3 Connect reaches it through its own outbound tunnel, so it needs no open port. Run t3 update between turns, because it restarts the service.

Step 7: How do you give coding agents your project instructions?

• Global instructions: ~/.claude/CLAUDE.md on the server holds your preferences ("always branch before editing", "never push to main", "check with me before sending anything"). Codex reads ~/.codex/AGENTS.md.
• Per-repo instructions: a CLAUDE.md or AGENTS.md at the repo root: how to install, run, test and deploy, and what not to touch. This is the most valuable file you'll write.
• Tools (MCP): connect Slack, email and your meeting notes on the server itself with claude mcp add .... A connection made on your laptop doesn't carry over. This is what lets my agents work from my meetings, emails and Slack.
• Branch, then pull request: agents work on a branch and open a PR with gh pr create. You review and merge from the GitHub app. Protect main with required checks so this is enforced.

Step 8: How do you give coding agents secrets through 1Password?

Agents need API keys. Never paste one into an agent chat, and never commit one. This takes about 15 minutes.

1. One vault for the server. Create a 1Password vault (for example dev-server) holding only the keys the server should read.

2. A read-only service account. On 1password.com, Developer → Service Accounts → New, with read access to that one vault only. Copy the token, which is shown once, and save it in 1Password.

3. Install the 1Password CLI using the Ubuntu steps at developer.1password.com/docs/cli/get-started. op --version prints a version.

4. Store the token with tight permissions and load it:

   umask 077 && mkdir -p ~/.secrets && chmod 700 ~/.secrets
   read -rsp 'Service account token: ' SERVER_OP_TOKEN
   printf '%s' "$SERVER_OP_TOKEN" > ~/.secrets/op-token && unset SERVER_OP_TOKEN
   chmod 600 ~/.secrets/op-token
   export OP_SERVICE_ACCOUNT_TOKEN="$(cat ~/.secrets/op-token)"
   op vault list            # should list only your server vault
   

5. Pass references, not values. Each project keeps a .env.op file that is safe to commit because it holds references:

   OPENAI_API_KEY=op://dev-server/OpenAI/credential
   DATABASE_URL="op://dev-server/Prod DB/url"
   

   Then run things through 1Password: op run --env-file=.env.op -- npm run dev. Tell your agents to do the same in CLAUDE.md or AGENTS.md.

A systemd service does not read .bashrc, so load the token in each shell or launcher that needs it. If the server is ever compromised, revoke the service account and rotate that one vault's keys. Not using 1Password? Bitwarden's bws follows the same pattern.

What is the hard part of setting up a coding-agent server?

Getting it working. While you're figuring it out, the server often goes down or won't connect. Two causes we found the slow way: the missing UDP 41641 rule from Step 1, which left Tailscale on a relay that went stale and gave us weeks of flaky connections, and Tailscale SSH asking to re-verify, which hung agents that were running on their own.

Push through it, because once you get it working it's magical.

How do you know the coding-agent server is working?

The real test is that you stop thinking about your laptop. I have 10+ agents running at all times, and the work carries on through meetings with the lid shut.

Before trusting the setup overnight, run this acceptance check:

How do you troubleshoot a coding-agent server?

What does a coding-agent server cost?

AWS servers are reasonably expensive, so price the size you picked for your region in the AWS Pricing Calculator before you launch. But you can easily get a bunch of free AWS credits, so it's easier than it looks. On top of the server you pay for your Claude or ChatGPT plan; T3 Code itself is free. You pay for the disk even while the server is stopped, so check every branch is pushed before you delete it.

Where does a coding-agent server fall short?

A server does not make an agent work forever: usage limits, questions, approvals and failed tests still stop it. It also adds a machine you have to patch, back up and pay for. If you only code now and then, the agent on your laptop is enough.

For hardware-dependent work, or data that cannot leave a controlled network, use an environment that meets those rules.

How can you reuse this coding-agent server guide?

This guide is published under Creative Commons Attribution 4.0. Copy and adapt it with credit to Finlay Ekins and Hourglass AI, and mark your changes.

If a step fails, send us the step and your CLI version, with credentials removed. For more of the setup behind our work, browse AI Open Sauce and the build and automate library.