A copy of production for every change your AI agent makes

• 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.

• A copy with one call

  In 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 Postgres

  In 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 Compose

  In 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 allowed

  In 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 copy

  In 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 data

  In 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 team

  In 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 production

  In 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 portal

  In 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 environment

  In 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 agent

  In 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 copy

  In 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.

• 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.