PaaSbox runs your app on servers in your own Hetzner account. Before a change goes live, your AI agent tries it on a copy of production, and you decide whether it ships. Below is what works today, what is being built, and what is not there yet.
What works today
Each of these ran end to end on real Hetzner servers in a lab, on 10 and 13 October 2026. None of it is generally available yet: in the alpha I set it up with you, and run parts of it by hand.
PaaSbox creates a server with Kubernetes (k3s on Garden Linux) in your own Hetzner account, in about 3 to 4 minutes. Hetzner bills you for the server directly.
Updates come as signed releases. An update restarts the server: in the lab the Kubernetes API was down for 34 seconds. Snapshots go to your own S3 bucket and restore in place (160 seconds in the lab). Deleting a server deletes its disks too.
A small program on the server fetches its instructions from PaaSbox. The server listens on no port for PaaSbox, and every secret PaaSbox sends is encrypted for that one server.
Flux deploys your app from your Git repository. A SQLite database is backed up continuously to S3 by Litestream. Certificates come from Let's Encrypt (tested with its staging service).
With a team key, an agent creates, checks and deletes servers through an API or MCP tools, and gets temporary logins that only it can open. Every call is logged. Deleting needs the server's name typed as confirmation.
For a task, the agent gets a copy of production in a second Hetzner account: the same app and configuration from Git, and the data from production's latest backup, with personal data replaced by your rules. In the lab the copy was ready in 4 minutes.
The agent deploys its change to the copy and reads what happens. When it works, it opens a pull request, which it cannot merge. In the lab its first try failed on the copy's real data (a unique index on texts that repeat), and production never saw it.
After you merge, production pulls the change from Git by itself: 19 seconds in the lab. The copy is then deleted with its server and its data: 15 seconds.
The copy runs in a separate Hetzner account with its own keys and its own backups. In the lab none of production's keys was in the copy, and the agent's key could not see production.
Being built now
Merged and tested on throwaway local clusters, not yet tried on real servers.
The agent asks for a copy of production for its task and its Git branch, and gets the server, the app from the branch and the masked data. A copy deletes itself after 8 hours; the agent can extend it once, to at most 72 hours.
The Postgres data goes into a fresh database with personal data replaced, so the copy never holds an original value, not even in old database files.
A converter turns your compose file into a deploy repository for production and copies, with a report of everything it could not convert. Values from your .env file never leave your machine.
A copy reaches only the addresses you allow, and mail can go only to one mail catcher you set, so a copy cannot mail your users or call a live payment API you did not allow.
Every copy gets its own Mailpit. The app's mail lands there, and the agent reads and checks it through the portal's MCP tools. Before a copy is deleted, its mail list is kept as part of the proof.
Right after its data arrives, a copy takes a snapshot. Between two tries the agent puts the data back in seconds instead of making a new copy. SQLite apps first.
PaaSbox gets one wildcard certificate for all copies of a team, so every copy has a real HTTPS name at once, without hitting Let's Encrypt's limits.
Production can use Hetzner's daily backups of the whole server as an extra layer next to S3, with a confirmed restore. Before a server is deleted, its newest backup can be kept as a snapshot.
A page in the portal walks through the steps: convert the compose file, create production, let PaaSbox set up its Git sync, move the data, switch DNS, make the first copy.
Your app's secrets go into Git encrypted. Production and the copies each get their own key from PaaSbox, so a copy can read only its own test values, never production's.
In a copy the agent gets access to its app's namespace, not admin rights over the whole server. It cannot open public ports, and what it pushes to Git can only change its own app.
A script compares every secret in a copy with every secret in production, and with keys you list that live outside the server, and fails if one matches.
Not there yet Planned
Later, as an upgrade that costs more at Hetzner: servers without public addresses behind a gateway, a small hub server in your account that manages them, a redundant gateway pair, and clusters with several servers.
The alpha
For people who run a web app on Hetzner, or want to, and let coding agents change it.
One app with its database, its deployment in Git, and a Hetzner account. Small apps with SQLite fit best today.
Copies of your app for your agent, set up with you, and direct contact with me. What you need decides what I build next.
Everything runs in your Hetzner account, and Hetzner bills you for the servers: a copy runs on one small server for as long as its task, at cents per hour.
To apply, write to mitja@mitjamartini.com: what you run, where it runs today, and how you work with agents. I read every mail and reply, usually within one business day.
Already invited? Open the link in your invitation mail to create your account.