Self-hosting Busabase
Which edition you need, what each deployment shape costs you in operational effort, and the measured hardware requirements — so you can decide before you download anything.
There are two reasons people run Busabase themselves. Either the data cannot leave the network, or the team wants to own the thing outright. Both are good reasons, and they lead to different editions.
Which edition
| Open source | Premium | Enterprise | |
|---|---|---|---|
| Price | Free (MIT) | $19 / seat / month | Contact us |
| Approval engine, all node types | ✅ | ✅ | ✅ |
| REST API, MCP, agent access | ✅ | ✅ | ✅ |
| Sign-in and user accounts | ❌ | ✅ | ✅ |
| Organisations, spaces, member roles | ❌ | ✅ | ✅ |
| System admin console, audit log export | ❌ | ✅ | ✅ |
| API keys and Vault secrets | ❌ | ✅ | ✅ |
| SSO / LDAP | ❌ | ❌ | ✅ |
| SLA and named support engineer | ❌ | ❌ | ✅ |
The open source edition is not a crippled Premium. It is the same engine with no user system at all — one machine, one person, no login screen. That is genuinely enough for a lot of people, and if it is enough for you, you should use it and stop reading here.
Premium is what you need the moment a second person has to sign in. Everything it adds is about more than one person sharing the same server: accounts, roles, who-changed-what, and the admin surface to manage them.
Premium is licensed per seat, counted as members who can sign in to the instance. An expired licence does not lock you out — the instance goes read-only, and your data stays readable and exportable. See Licensing.
Which deployment shape
| All-in-one | Compose | Kubernetes | |
|---|---|---|---|
| Processes | One container | Four services | Helm chart |
| Postgres | Inside the container | Its own service | Yours or in-cluster |
| Object storage | Inside the container | SeaweedFS service | Yours or in-cluster |
| Good for | Trials, ≤ 20 people | Production | Large or regulated estates |
| Upgrade | Pull, restart | Pull, compose up -d | helm upgrade |
| Status | Available | Available | Available |
Start with all-in-one. It is one docker run, and it is the fastest way to find out whether Busabase is the right thing at all. Moving to Compose later is a restore from backup into a new deployment, not a migration project.
The all-in-one image runs Postgres inside the container. That is a real Postgres, not an embedded substitute, but everything shares one container's lifecycle — a docker rm without a named volume takes the database with it. Always run it with -v busabase-data:/data.
What the host needs
Measured on a cold start with an empty volume (2026-09-05, Docker 29.6):
| Minimum | Measured | |
|---|---|---|
| CPU | 2 vCPU | — |
| Memory | 2 GB | 548 MiB idle |
| Disk | 10 GB | 50 MB in /data after first boot |
| Open ports | 3000/tcp, 8333/tcp | app + object storage |
| Start-up | — | 24s from docker run to a healthy /api/health |
The minimums add headroom over the measured idle figures rather than quoting them as requirements. 548 MiB idle is why memory says 2 GB and not 1 GB: the idle figure has no room for concurrent uploads, a migration run, or Postgres's own working memory under load.
Postgres is never published outside the container. Object storage is, and has to be: uploads are presigned PUTs and downloads are redirects, so the browser fetches storage directly — exactly as it does against S3 on Busabase Cloud. Publish both, and put a reverse proxy with TLS in front of both — see Production with Compose.
Where to go next
- Trying it out → Quickstart
- Going to production → Production with Compose
- No internet on the target network → Offline install
- Already running, need to activate → Licensing