Claude Code runs most reliably on your own server when every role gets its own working folder and its own tmux session with claude remote-control running permanently inside it. You then steer it from your phone through the Claude app or through one Slack bot per role, recurring jobs run as claude -p on a schedule, and a Git sync saves the working state every 15 minutes. That is how five of my AI employees have worked since 11 October 2026, on a small Linux server in Hetzner Cloud instead of my Mac: content, office, marketing, SEO, and website. The server has no open port, credentials sit encrypted in the repository, and anything with an effect outside still needs my explicit go-ahead.
This piece describes my setup, not a general guide for every server. If you have never installed Claude Code, start with Install Claude Code: Windows, Mac, Linux.
Why the workforce moved from the Mac to a server
Until October 2026 every employee ran on my Mac. The goal of the move was simple: the workforce runs around the clock, even when my Mac is off, I steer it from my phone, and no port on the server is reachable from the internet. Everything had to be reproducible, meaning the server can be rebuilt at any time with Terraform and cloud-init, and the few manual steps are numbered and documented.
The server
The workforce itself lives in a Git repository: one folder per employee with personnel file, working instructions, skills, knowledge, and job folders. How such a folder is built is in Creating an AI Employee: How to Start.
One tmux session per employee, with Remote Control
Every employee runs in its own tmux session, started by a systemd user unit in its folder. Inside it, Claude Code runs in Remote Control server mode:
claude remote-control --name "Sebastian" --permission-mode acceptEdits \
--no-chrome --remote-control-session-name-prefix <prefix>
The session then shows up in the Claude app under "Code", and I can steer it from my phone. Everything executes on the server; the app is only the remote. Three things have proven themselves:
- tmux is a must. The Claude Code docs recommend it themselves: if you start
claude on a remote machine, start it inside tmux or screen so the session survives the end of the SSH connection. You look in with tmux attach and leave with Ctrl-b d, never with exit.
- Restarts by systemd. In server mode, Claude Code gives up after roughly ten minutes without network and exits. The unit restarts it after 30 seconds. According to the docs, sessions can be resumed for about four hours; what gets lost after that is only the session, not the work, because the work lives in files.
- Answer one-time questions first. On the first start, Claude Code asks whether to trust the folder, whether to enable Remote Control and how to create new sessions. I answer that once over SSH on the first start.
You need a Claude subscription with a claude.ai login; an API key is not enough for Remote Control. My server is logged in with my Team account, where an Owner first has to switch Remote Control on in the admin settings. The login applies to every employee on the server; when it rotates, I sign in again once over SSH.
Slack as the everyday channel
Remote Control is good for long, interactive work. Day to day I use Slack: every employee has its own Slack bot and its own channel. Behind it, one small service per employee, the open-source project claude-threads (Apache-2.0), connects the channel to a Claude session in that employee's folder.
- No public address. The bots use Slack's Socket Mode; the server opens the connection itself.
- One channel is one session. After 30 minutes of quiet it expires, and the next message picks it back up. The working state lives in files anyway, not in the chat.
- Approvals by reaction. When Claude asks permission for a tool, I answer with an emoji reaction in the channel. Each bot only accepts jobs and approvals from my own Slack account; it ignores every other message in the channel.
- Reports into a shared channel. Results of scheduled runs and error messages land in a private news channel.
I learned two limits along the way. Slack's free plan allows ten installed apps (as of October 2026); with the five employee bots our workspace was at that limit. And direct messages to a bot do not work with this gateway in Slack, only the channel. Slack and Remote Control work on the same folder, so I never run the same job in both at once.
Schedules and runs without a screen: claude -p
Recurring jobs, such as a morning status report, sit in a single file with name, employee, time, and the job as a text file. A script turns that into systemd timers. Every run starts Claude Code without an interface:
claude -p --permission-mode acceptEdits --max-turns 60 --max-budget-usd 5 "$(cat auftrag.md)"
- Always set a permission mode. Without one, a run starts in the built-in starting mode, which according to the docs can also be
auto. So I set it myself. In a run without a screen, nobody can answer a prompt; anything that would need approval is denied.
- Set limits.
--max-turns caps the steps, --max-budget-usd the estimated cost. Both only apply in print mode.
- The result arrives as a letter. The run drops its result as a file in the employee's mailbox folder. If it fails, a letter goes to Kai, my AI employee for leadership, who reviews the others' reports.
Comparison tests with and without a tool run the same way for me: two separate claude -p runs, one of them with --disallowedTools, so that, for example, the tools of an MCP server were technically unavailable in that run.
Git sync instead of file sharing
Every 15 minutes a timer commits the employees' folders on the server, pulls changes with git pull --rebase, and pushes to our own Git server. On the Mac I pull as usual. On a conflict the sync aborts and writes a letter instead of overwriting anything; a force push is ruled out.
The most important rule here: an employee works either on the Mac or on the server, never both. The folder of every employee who has moved contains a note saying exactly that. Whatever differs per machine, such as paths, available tools, and reporting channels, is not in the shared CLAUDE.md but in a CLAUDE.local.md that Git ignores and that an install script creates on the server. That keeps the Mac and the server identical in the repository.
Credentials: encrypted in the repository, decrypted only on the server
Keys for APIs, webmaster accounts, and MCP servers sit in the repository encrypted with SOPS. The server has its own age key as a second recipient; my private key is never on the server. During installation, a script decrypts each employee's credentials into a .env and renders config templates such as a .mcp.json, which in the repository contains only placeholders like ${API_KEY}. The target files are ignored by Git and readable only by the working user; the script aborts if a target file is not ignored. If an employee needs a credential only briefly, it decrypts it into a temporary directory and deletes it afterwards.
On top of that, what I described in Set Up a Claude MCP Server applies: what an employee must not do, I block technically. Tools that delete data on an MCP server sit as deny rules in the settings, not as a request in the working instructions.
What does not work on the server
The approval rules do not change because of the server. Anything that leaves the house or changes something, an email, a deploy, an ad, only goes out on my explicit word, and the employee records that word with a timestamp in the log. Who holds which role is in My AI Workforce: Fourteen Employees, One Boss.
Frequently asked questions
Can you run Claude Code on a server?
Yes. Claude Code is a command-line program and runs on Linux. For persistent sessions you start it in tmux, for remote steering with claude remote-control, and for scheduled jobs with claude -p. Remote Control needs a Claude subscription with a claude.ai login; an API key is not enough. On the server I use a Team account, which is covered by Anthropic's commercial terms. According to Anthropic, Pro and Max are meant for ordinary, individual use; for round-the-clock schedules in a company, use a Team or Enterprise account or an API key.
How do I control Claude Code from my phone?
With Remote Control. On the server, claude remote-control runs, the session appears in the Claude app under "Code", and you type there like in a chat. Everything executes on the server. On Team and Enterprise accounts, an Owner has to enable the feature in the admin settings first.
Why tmux for Claude Code?
Because otherwise the session ends as soon as the SSH connection drops. In tmux, Claude Code keeps running, and you can attach again at any time and watch. The Claude Code docs recommend tmux or screen for exactly this case.
What does a server like this cost?
In my case 10.49 euros a month before VAT for the server (Hetzner CAX21, as of October 2026), plus the data volume and storage for backups. The Claude subscription comes on top; the server does not replace it. On the server I use a Team account, which is covered by Anthropic's commercial terms. According to Anthropic, Pro and Max are meant for ordinary, individual use; for round-the-clock schedules in a company, use a Team or Enterprise account or an API key. The model's compute still runs at Anthropic; only Claude Code, the tools, and the files run on the server.
Is it secure?
More secure than a machine with an open SSH port, but not without risk. On my server no port answers from outside, access is only through a private network, the data is encrypted, credentials are encrypted with SOPS, and the working user has almost no root rights. That does not protect against everything, which is why dangerous tools are additionally blocked technically.
Where to go from here
Do not start with the server, start with one employee who works reliably on your own machine. Only once folders, working instructions, and approvals are in place is the move worth it. The entry point is Claude Code: A Guide for Beginners. How I build my employees, lead them, and bring them onto the server is what I show in my community Claude Practitioners.
