641 stars and 109 forks in its first 13 days: Zeabur landed on GitHub on 24 October 2026 and was still getting commits on 5 November. It is a self-hosted PaaS you install on your own Kubernetes, and its pitch stands out for what it doesn't do: it has no database, creates no custom resources (CRDs) and never acts with more rights than the person using it.
What it is and how it works
Zeabur shows the cluster as projects and services instead of namespaces and Deployments. Each project gets a map of its services, databases and connections; each service shows its rollout, CPU and memory against limits, and whether its domains answer. When something breaks, say a service stuck in a crash loop, it gives a diagnosis in plain words, with what to do and the evidence. And before creating a new service it shows the YAML for the Deployment, Service and Ingress it is about to apply.
The design choice I like most is that it keeps no state of its own. It works on the standard Kubernetes objects you already have and reads the cluster with the signed-in person's token, not with an all-powerful service account. If a user can't see their services, the first thing to check is their Kubernetes permissions. Adopting an existing namespace as a project just adds a label: it doesn't move Deployments, Services or data.
The backend is written in Rust, the licence is Apache-2.0, and releases ship signed with Sigstore and with build provenance attestations.
How to install it
There are three paths, depending on who it's for:
- A Linux server for a team: a web-based installer sets up K3s or RKE2, Zeabur Identity (the passkey sign-in provider) and Zeabur. It needs at least 4 GiB of memory.
- An existing cluster: a Helm chart, with Kubernetes 1.30 or later, an Ingress with TLS and Zeabur Identity already running.
- Personal use:
zeaburctl uiopens the UI on your machine against your current kubeconfig context, on a random loopback port.
On an existing cluster, once the client is registered in Zeabur Identity and its secret is stored in the zeabur namespace, installation looks like this (per the official docs):
helm install zeabur oci://ghcr.io/zeabur-oss/charts/zeabur \
--version <version> \
--namespace zeabur \
--set clusterName=production \
--set publicUrl=https://zeabur.example.com \
--set issuer.url=https://identity.example.com \
--set issuer.clientSecret.existingSecret=zeabur-oidc \
--set ingress.enabled=true \
--set ingress.className=traefik \
--set ingress.tls.secretName=zeabur-tls
kubectl -n zeabur rollout status deployment/zeaburThe chart creates the project member ClusterRoles and a ValidatingAdmissionPolicy that limits which Namespace fields developers can change, but it doesn't bind those roles to anyone: an admin does that from the Members page.
A word on the single-server install: the installer runs as root, and the docs launch it with an ssh one-liner that downloads the latest release and only checks its SHA-256. Verifying the signature and provenance as well is a separate procedure with cosign and gh attestation verify. On a server that matters, it's worth the extra minute.
What I like and what I don't
I like the approach. A layer with no state and no CRDs can be removed without migrating anything, and the docs have a whole section on leaving Zeabur. Running every action with the user's token means access control stays Kubernetes RBAC, not a parallel system. And pinning the installer and images by version and digest says a lot about the care behind the project.
What I don't: the README itself calls it pre-alpha, warns that the API may still change, that it has been tried on few clusters, and that you shouldn't point it at a cluster you can't afford to break. It has 43 open issues. And personal mode, the easiest one to try, has no users or permissions: whoever holds the kubeconfig controls the whole cluster, and KubeSolo doesn't enforce network policies, so there's no isolation between projects.
Zeabur vs Coolify
Coolify is the go-to self-hosted PaaS: over 65,000 stars since 2021 and the same Apache-2.0 licence. They tackle the same problem from opposite ends.
| Zeabur | Coolify | |
|---|---|---|
| Approach | Layer over Kubernetes, standard objects, no state of its own | Full platform on Docker servers managed over SSH |
| Deployment | Installer (K3s, RKE2, KubeSolo), Helm chart or local zeaburctl ui | curl | bash on a server; recommends one for Coolify and others for apps |
| Permissions | Kubernetes RBAC with each user's token | Its own team-based access control |
| Licence | Apache-2.0 | Apache-2.0 |
| Maturity | Pre-alpha, 641 stars | Established, over 65,000 stars, 360+ one-click services |
If you don't run Kubernetes and want to ship apps and databases on a couple of VPSs, Coolify is the sensible pick today: more mature, with far more ready-made services. Zeabur makes sense if you already operate Kubernetes and want to give your teams a PaaS-style interface without putting another source of truth between them and the cluster. For now, on a test cluster.
Sources
- zeabur-oss/zeabur, GitHub
- Install Zeabur in an existing cluster, Zeabur docs
- Personal use: install on a small machine, Zeabur docs
- Release files and verification, Zeabur docs
- coollabsio/coolify, GitHub