PaaSbox · closed alpha, 10 to 20 places
A copy of production for every change your AI agent makes
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
Built and tested on real servers
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.
A server for your app, in your Hetzner account
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.
Kept up to date and backed up
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.
No open door for PaaSbox
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.
Your app, deployed from Git
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).
AI agents can drive it
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.
A copy of production for each task
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 tries, you decide
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.
Production updates itself
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 can't reach production
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
Built and tested locally
Merged and tested on throwaway local clusters, not yet tried on real servers.
A copy with one callIn progress
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.
Copies of apps that use PostgresIn progress
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.
Bring your app from Docker ComposeIn progress
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.
Outgoing traffic only where allowedIn progress
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.
A mail catcher in every copyIn progress
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.
Back to the starting dataIn progress
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.
One certificate per teamIn progress
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.
Hetzner backups for productionIn progress
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.
Bring your app through the portalIn progress
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.
Separate secrets per environmentIn progress
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.
A limited login for the agentIn progress
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 check for every copyIn progress
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
What is missing
- A page that shows what the copy proved, next to the pull request.
- Testing alerts in a copy: provoke a fault, and check that the alert fires and clears.
- Restoring production onto a new server, and recovery tests on a schedule that prove the backups work.
- A lighter variant on Podman for small apps, with the target of a whole copy in 1 GB of RAM. A target, not yet a measurement.
- Copies on your Mac with ownpaas, and approvals on your phone with Cloud Viewer. Both apps exist; these features do not.
- Encrypted server disks.
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
10 to 20 alpha users
For people who run a web app on Hetzner, or want to, and let coding agents change it.
What you need
One app with its database, its deployment in Git, and a Hetzner account. Small apps with SQLite fit best today.
What you get
Copies of your app for your agent, set up with you, and direct contact with me. What you need decides what I build next.
Your account, your servers
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.