The agent-native PaaS for self-hosting.

Ship your own apps on servers you rent yourself, on Kubernetes clusters in your own Hetzner project. In progress Run open-source services next to them, connected: built in a lab, not yet on cloud servers. Planned Every service hardened and backed up by default, and your agents operating them safely. Apache-2.0, being published.

Tell me when it ships See how it works

Every claim in the three promises below carries its status. Built runs end to end in a lab on a real cluster, even if not released. In progress is started, not finished. Planned is designed, not built.

1 · Your SaaSAn image becomes a URL with TLS. PostgreSQL with tested restores, a cache, scale to zero, a preview per branch.Built proven 2026-09-16, not released 2 · Your toolsSuites of connected open-source apps from a curated catalog. Each app gets its database, and a cache where it needs one, with credentials no other app can read.Built four apps, in a labPlanned the rest 3 · Your agentsSandboxes for coding agents, one gateway for models and tools with a budget per agent, an operations agent that may only do what a person on call may do.Planned designed, not built

Under all three: security and operations practices built in, and two ways to run the clusters: Gardener for fleets and the clusters run for you, Cluster API for a few clusters you run yourself.

Your SaaS

If you build and ship a SaaS app, alone, with a small team or with a coding agent doing much of the work, this is the layer between a container image and a URL your users can reach. Two objects, applied to your cluster:

apiVersion: paas.paasbox.com/v1alpha1
kind: App
metadata: { name: shop, namespace: shop }
spec:
  image: registry.example.com/acme/shop:1.4.2
  port: 8000
  uses: [{ name: db, kind: ManagedPostgres, prefix: DB_ }]
  scale: { min: 0, max: 5 }
---
apiVersion: paas.paasbox.com/v1alpha1
kind: ManagedPostgres
metadata: { name: db, namespace: shop }
spec:
  plan: s
  storage: 20Gi
  backup: { retention: 7d, objectStoreSecretRef: { name: s3-backups } }

kubectl apply -f app.yaml
pb status
# KIND             NAMESPACE  NAME  PHASE  READY  ENDPOINT
# App              shop       shop  Ready  True   https://shop.shop.apps.acme.paasbox.app
# ManagedPostgres   shop       db    Ready  True   db-rw.shop.svc:5432

Runs today Built

A URL with TLS, a certificate a client verifies, 6 seconds after kubectl apply in the measured run.
PostgreSQL with one resource: CloudNativePG, a credentials Secret, continuous backups to S3. A restore into a new instance is tested, with the data intact.
DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME and DB_URI reach the app as references into that Secret, never as copies.
A Redis-compatible cache or queue broker with one resource (ManagedValkey).
Scale to zero when idle, and back up on the first request: about 2 seconds at the median over 30 measured cold starts.
A background worker (type: worker) and a migration step before every rollout.
Scheduled tasks (spec.cron, with a time zone). Checked on its own on 2026-09-18: the CronJob ran on a real cluster, on which no app served.
A preview environment per branch, with its own database, with one command: pb preview up, pb preview down.
Tracing for the calls your app makes to an LLM (ManagedTracing).
A cluster hibernates and wakes with its apps and data intact. A hand-edited platform object is reverted; your own Knative Services and CNPG clusters next to it are never touched.

Being built

In progress Your own domain over HTTPS. The certificate is issued on a real cluster; serving it there has not passed yet.
In progress Builds from source: a rootless BuildKit Job in isolated build pods. Passes on a local test cluster only.
In progress Workspaces: a browser editor and SSH on the app’s source tree, stopped when idle, woken on request.
In progress Secrets an app can read and a person in the namespace cannot (ManagedSecret, in the cluster’s own OpenBao).
In progress Mail (ManagedMail). The sink that captures every message for development and previews ran on a real cluster; delivery through your SMTP provider has not.

Proven, not released (as of 2026-09-16): the items marked Built ran end to end on a real, paid Hetzner landscape, not just a test cluster; scheduled tasks are dated on their own line. The version in development since then replaces the gateway in front of the apps and has not served an app on a paid run yet; the date above moves only with a new paid run. There is no public repository or package to install yet. The PaaS docs →

Your tools

Planned

Mostly planned. Built today, in a lab: one command installs a suite of four curated apps, each wired to its database, and to a cache where it needs one. Sign-in, buckets, mail, volume backups and the wider catalog are planned.

Run the open-source tools your team depends on as a suite: one file that names the apps and how each of their needs is met. Every app gets its own credentials, and no other app can read them. This is the suite the lab installs:

apiVersion: catalog.paasbox.com/v1alpha1
kind: Suite
metadata: { name: team }
spec:
  apps:
    umami: {}
    listmonk: {}
    forgejo: {}
    vaultwarden: {}
  bindings:
    umami.db:       { provider: cnpg-shared }      # a database and a role on one shared Postgres
    forgejo.db:     { provider: cnpg-shared }
    forgejo.cache:  { provider: valkey }           # its password generated in the cluster
    vaultwarden.db: { provider: cnpg-dedicated, params: { size: 1Gi } }

A plan says what will be installed, and refuses before writing anything when the cluster lacks something. Then the suite is applied directly, or rendered as files into your deploy repository and applied by Flux. This ran on local kind and k3s clusters and a local VM, not yet on cloud servers, and is not merged or released.

Runs in the lab Built

Four curated apps: Umami, Forgejo, Vaultwarden, Listmonk.
Each app’s credentials sit in a binding no other app can read. Its Postgres role can log in only to its own database.
Apps share one Postgres server, each with its own database and role, or get a dedicated one.
Passwords are generated in the cluster by External Secrets and never written to git.
GitOps: the suite as files in your deploy repository, applied by Flux. Or applied directly.
A plan that refuses, with every reason, before anything is written.

Designed

Planned Hundreds of services: 410 candidates to import, 25 curated entries. Today there are 4.
Planned A sign-in for every app from one identity provider (Zitadel), with a sign-in proxy for apps without OIDC.
Planned An S3 bucket and a mail account wired into each app that needs them.
Planned Backups for every app (Velero for volumes, barman for Postgres), with restores tested by scheduled drills.
Planned SQLite apps replicated continuously with Litestream.
Planned Per curated app: dashboards, alerts with runbooks, typed actions, and updates that take a backup first.
Planned Test, staging and production per suite; promotion is a pull request with gates.
Planned The curated catalog published as a signed OCI artifact, linked by URL with a pin.
Planned Every connection shown as a graph you edit, in ownpaas, a separate desktop app.

Your agents

Planned

Mostly planned. Of this section, only the typed commands exist today. The rest is the design, published so you can see where this goes.

Agents are users of the platform, workloads on it and, within limits, its operators. The design: an agent gets what any other app gets: a binding, its own key, a budget and a list of tools. A sketch of the planned format:

# Planned: a sketch, not a released format
apiVersion: catalog.paasbox.com/v1alpha1
kind: Suite
metadata: { name: agents }
spec:
  apps:
    opencode: {}                  # runs in a sandbox (gVisor), on its own nodes
  bindings:
    opencode.llm:                 # its own key; the provider keys stay in the gateway
      provider: ai-gateway
      params: { models: [code], budget: { perMonth: 40 EUR } }
    opencode.mcp:                 # only these tools; destructive ones wait for a person
      provider: ai-gateway
      params: { tools: [forgejo.list_issues, forgejo.create_pull_request] }

Planned A leaked agent key would be revoked alone and could spend at most its budget.

Built Every command reports typed JSON progress; installs, deletions, enrolments and updates print a JSON plan first, so an agent reads it before anything changes. Built for clusters, the platform install and suites, in ownpaas-mgmt, the command-line tool of the ownpaas desktop app.
Planned Sandboxes for coding agents: gVisor or Kata, SSH, egress allowlists, on their own nodes.
Planned One gateway for models: provider keys only in the gateway, a key and a budget per agent.
Planned One gateway for tools (MCP): each agent sees only the tools its binding lists; destructive tools wait for a person.
Planned Coding agents as catalog entries: opencode, pi, Pi Durable, Claude Code, Codex.
Planned Curated tools and skills per app, sorted into read, write and destructive.
Planned Runbook actions as named, typed commands with parameters, no free shell, the same for people and agents.
Planned An operations agent that may only do what a person on call may do: it reads, proposes typed actions, waits for approval on dangerous ones, and every step is traced.

Security and operations, built in

Planned

Mostly planned. Built today: tested Postgres restores, a rehearsed restore of the whole landscape, credentials isolated per app, an admission policy for platform secrets. Network policies, hardening, scans and evidence for CIS and BSI controls are planned.

The same practices are meant to run through all three promises. The goal: what an app may reach follows from its connections, every database has a backup with a tested restore, and the platform produces evidence for security controls. Today the PaaS databases have continuous backups and a tested restore; the rest is in the list of planned items below. Your auditor decides what the evidence proves; paasbox does not claim compliance or a certificate.

Runs today Built

Continuous Postgres backups, and a restore into a new instance tested with the data intact.
The landscape’s etcd backed up to object storage, its restore rehearsed after losing every server.
Each app’s credentials readable only through its own binding (in the lab).
An admission policy refuses any tenant workload that mounts a platform-managed secret.

Designed

Planned Network policies generated from the connections: an app cannot reach another app’s database. Today any pod can reach any database port.
Planned Hardened by construction: Pod Security levels, quotas, image digests, non-root pods.
Planned Policies enforced (Kyverno) and images scanned (Trivy, SBOMs) before and after install.
Planned Evidence for CIS Kubernetes Benchmark controls (kube-bench, Trivy Operator).
Planned Evidence for BSI IT-Grundschutz controls, as OSCAL assessment results.
Planned Encryption in transit (WireGuard) and at rest (LUKS under the node’s volumes).
Planned Security events forwarded to your SIEM.

Two ways to run the clusters

Every app and service lives on a Kubernetes cluster in your own Hetzner project. There are two backends, each for what it does well. Planned The platform above them renders the same objects on both.

Gardener

For fleets, and for the clusters run for you.

Built paasbox garden up turns one Hetzner project into a Gardener landscape that creates, upgrades, backs up and deletes clusters, in about 40 minutes.
Built Clusters run for you: the control plane on my landscape, the workers in your Hetzner project.
Planned The CLI’s public release. There is no public repository or package yet.

Cluster API

For a few clusters you run yourself.

Built Create, scale, upgrade and delete clusters on Hetzner, with etcd snapshots to object storage.
Built Single-node clusters on a rented server, with OS and Kubernetes updates that roll back on failure.
Built One command turns a cluster into a platform: certificates, TLS, observability, a Postgres operator and more, as capabilities.
Built A gateway in front of your clusters terminates TLS and puts a sign-in (OIDC) and rate limits in front of protected routes.

With Gardener, one command builds the landscape, and one more creates a cluster from it. Not published yet:

paasbox garden up my-garden                                        # check → up → flux → garden → images → status
paasbox garden shoot create my-garden first --machine cpx32 --k8s 1.36

What you need

A Hetzner project and a token

The one precondition is a Hetzner Cloud project with a read/write API token. Everything else, DNS, backups, the server size, a dedicated box instead of a cloud server, is a choice, not a requirement, and the CLI does the rest.

DNS, three ways. Your own domain in Hetzner DNS; or a free name like acme.paasbox.app that the CLI obtains for you with one sign-in; or none at all, to try it.
Backups, optional at the landscape level, mandatory for every database. An etcd snapshot to an S3 bucket in your project every ten minutes, and continuous backups for every ManagedPostgres.
Two sizes. solo is one 32 GB server, about €130 net a month at Hetzner’s list price, and holds the landscape plus a few clusters. ha is three 16 GB servers, about €208, survives the loss of one. Either way, budget about €12 more a month for the two load balancers Gardener puts in front of its two istio ingress gateways.
Your own dedicated server. A server: block puts the landscape on a Hetzner Robot box you already rent. A 64 GB box from the Serverbörse starts near €60 a month.
Rehearse for free. --stub runs every command against an in-memory fake of Hetzner, SSH and Kubernetes. No server, no cost.

paasbox control plane

API server · etcd · scheduler · controllers

operated by the platform

kubeconfig⇄

your Hetzner nodes

your project · your grandfathered price

Everything runs in your project, on your token; nobody else’s account is in the path. Your own Gardener has the full sizing table, the DNS decision and the dedicated-server option.

What is open source

In progress The building blocks are licensed Apache-2.0 and are being published one release at a time; most of their repositories are not public yet. How it is built lists every component and its licence.

paasbox-cli

Planned Not published yet. The CLI and the bootstrap it drives: init, up, status, restore, upgrade, update and teardown for the landscape; create, list, kubeconfig and delete for clusters. CLI docs →

paasbox-paas

Planned Not published yet. The App, ManagedPostgres, ManagedValkey and ManagedTracing layer, and pb, the CLI for the three things kubectl is bad at: a deploy that only bumps the image, a status table, and previews. PaaS docs →

The catalog

Built In a lab, not merged yet. Contracts, providers and suites: the resolver that plans a suite against a cluster and the renderer that writes its objects, for a cluster or a deploy repository.

The Hetzner extensions

In progress Repositories created, code not published yet. provider-hcloud, the machine controller, DNS records, backup buckets, the cert-manager webhook and the node images. What Gardener needs to run clusters on Hetzner Cloud. Component list →

Tested on real hardware

Every change runs against an in-memory fake on every push. After a release is tagged, a paid run checks it on real Hetzner servers. The records are available on request. How it is tested →

Learn it in a course

Two live online courses, four sessions each, ten people at most. Dates are announced to the people who ask for them; there is no date on this site until the first cohort is confirmed.

Your own managed Kubernetes on Hetzner

For Hetzner customers who run, or will run, more than one cluster.

What Kubernetes gives you and what it costs. In session two you stand up your own Gardener landscape in your project. Then you create a cluster from it, upgrade it, back it up, hibernate it, delete it and make another. Session four is what it costs, what it takes to run, and when not to.

Kubernetes course details →

Agentic DevOps

For engineers who own infrastructure and use coding agents on it.

How to trust infrastructure an agent wrote when nobody read all of it. The method this project runs on: a spec with dated decisions, a stateful fake with one invariant per lesson, a paid drill on real hardware, and a record. You build each artifact for your own project and prove it with a gate.

Agentic DevOps course details →

Clusters run for you

If you want clusters and not a landscape, I run a small Gardener landscape of my own and can run clusters for you on it. Your nodes stay in your Hetzner project. It is a courtesy, not a product built to scale: one person, best effort, business hours, and you can leave at any time with your backups already in your project. A test cluster is €49 a month, a production cluster with a highly available control plane €99.

Planned The app layer above (App, ManagedPostgres and the rest) on the clusters run for you.

Pricing and what is included →

Operated in the open

I build paasbox with agents that write, test, drill and investigate. I decide, and I am the only one who touches a live system. What the agents may do, what only I do, which drills every change runs, and what I publish each month is written down.

How it is operated →

The agent-native PaaS.On servers you rent yourself.

Tell me when it ships See the PaaS docs

Stay in the loop

Follow new releases and guides via the blog RSS feed, on X or GitHub. An email newsletter is coming with launch.