Budibase is an open-source low-code platform for building internal tools — admin panels, CRUD apps, approval forms — on top of your existing databases or its built-in datastore. Self-hosting keeps your internal data inside your own infrastructure. The deployment is more than a single container, so understanding the pieces up front saves pain.
What's inside Budibase
A Budibase deployment is composed of several services:
| Service | Role |
|---|---|
app service | Runs published apps |
worker service | Auth, global config, background tasks |
| CouchDB | Stores app definitions + internal data |
| Object store (MinIO/S3) | Static assets, attachments |
| Redis | Sessions and caching |
| Proxy (nginx) | Routes between services |
The key stateful dependencies are CouchDB (Budibase's metadata and built-in tables live here) and an S3-compatible object store for files. Everything else is comparatively stateless.
Required secrets
Budibase relies on several shared secrets that must be identical across the app and worker services and stable across restarts:
INTERNAL_API_KEY=long-random-secret
JWT_SECRET=long-random-secret
MINIO_ACCESS_KEY=...
MINIO_SECRET_KEY=...
COUCH_DB_USER=...
COUCH_DB_PASSWORD=...
REDIS_PASSWORD=...If JWT_SECRET or INTERNAL_API_KEY differ between the app and worker, inter-service auth breaks with cryptic errors. Generate them once and inject them as platform secrets to both services.
Deployment approach
Budibase publishes a single-image option and a multi-service Compose/Helm setup. For production, the multi-service layout is healthier because you can scale and persist each component independently.
On a managed platform, the realistic plan is:
- 1Deploy the
appandworkerservices from the Budibase images, sharing secrets. - 2Use managed Redis instead of a Redis container — attach it and point
REDIS_URLat it. - 3Run CouchDB with persistent storage (it's Budibase's primary datastore; it must not be ephemeral).
- 4Configure an S3-compatible object store for attachments.
PandaStack's managed Redis (via KubeBlocks) slots in directly for the cache/session layer, removing one stateful container you'd otherwise babysit.
Connecting external data sources
Budibase's strength is building UIs over data you already have. Once deployed, you connect to external PostgreSQL, MySQL, MongoDB, REST APIs, and more from the Budibase data panel. If your application data lives in a PandaStack managed PostgreSQL, point Budibase at its connection details and build internal admin tools over your production tables — with Budibase's row-level access controls in front.
Persistence is the make-or-break
The most common failed Budibase self-host is one where CouchDB and the object store run on ephemeral container disk. On restart, every app the team built disappears. Mount persistent volumes for CouchDB and use real object storage for files. Back up CouchDB on a schedule — a cronjob that runs a CouchDB replication or dump to object storage is the simplest insurance.
Go-live checklist
- App + worker share identical
JWT_SECRETandINTERNAL_API_KEY - CouchDB on a persistent volume, backed up
- S3-compatible object store configured
- Managed Redis attached
- Custom domain with automatic SSL
- Admin account created and SSO configured if needed
References
- [Budibase self-hosting docs](https://docs.budibase.com/docs/hosting-methods)
- [Budibase environment variables](https://docs.budibase.com/docs/environment-variables)
- [Budibase data sources](https://docs.budibase.com/docs/data-sources)
- [Budibase GitHub](https://github.com/Budibase/budibase)
Budibase's app + worker services run as PandaStack containers, with managed Redis taking the session layer off your hands and managed databases ready as data sources. Start building internal tools on the free tier at [dashboard.pandastack.io](https://dashboard.pandastack.io).