Deploy Budibase

Deploy and Host Budibase on Railway

Budibase is an open-source operations platform for building internal tools — admin panels, CRUD apps, approval flows and scheduled automations — on the databases and APIs a team already runs. Rather than writing a frontend and backend for every internal request, you connect PostgreSQL, MySQL, MongoDB, S3 or a REST API, drag components onto a screen, and ship the same day. It is the self-hosted answer to Retool.

Self-host Budibase on Railway with this template and you get the topology Budibase's own Helm chart runs, not one all-in-one container. An nginx edge service is the only thing published: it routes builder and app traffic to the apps service, identity traffic to the worker, and file requests to object storage. A dedicated automation worker consumes automation jobs, so long-running workflows never block API requests. CouchDB stores workspaces and internal tables, MinIO holds attachments and app bundles, Redis carries sessions and queues.

Getting Started with Budibase on Railway

Set BB_ADMIN_USER_EMAIL and BB_ADMIN_USER_PASSWORD before you deploy. Budibase reads them once, while its user table is empty, and creates the first admin — there is no open signup page and no default password to change. Everything else has a working default.

When the deploy goes green, open the public URL. It redirects to /builder, where you sign in and land on the workspace home. Click Data tables and choose Use sample data for the fastest proof the stack is wired correctly: Budibase writes four tables — Employees, Expenses, Inventory and Jobs — into CouchDB and opens them in a spreadsheet-style grid. If rows appear, the database, the search index and the apps service are healthy. From there, connect a real datasource or keep building on the sample. Next, create an app, add a Table component and point it at Employees; it binds and renders live rows in the canvas. Publish then serves the app at its own /app/... route.

About Hosting Budibase

Budibase splits into cooperating services, and self-hosting it well means running each one rather than collapsing them into one process. The apps service serves the builder, the published apps and the data API. The worker service owns identity: users, roles, SMTP, SSO and settings. The automation worker runs the apps image with APP_FEATURES=automations, so a slow webhook cannot starve the API. The proxy is the only public entry point.

Storage splits three ways. CouchDB is the system of record for workspaces, screens, automations and internal tables, and ships with Clouseau and a SQLite search service that back grid queries. MinIO holds attachments, app bundles and plugins across six buckets. Redis carries sessions, caches and the automation queues — which is what makes the separate tier possible.

Key features:

• Visual app builder with a component library, bindings and JavaScript expressions
• Built-in database with a spreadsheet-style grid, views and relationships
• Connectors for PostgreSQL, MySQL, MSSQL, Oracle, Snowflake, MongoDB, S3, Google Sheets and any REST API
• Automations with triggers, conditions, loops, webhooks and schedules
• Access control down to the screen and the row, plus self-hosted SSO

Why Deploy Budibase on Railway

Railway removes the operational work self-hosted Budibase usually needs:

• Six services from one template, private networking already wired
• Persistent volumes for CouchDB and MinIO created and mounted
• Managed Redis, so there is no queue server to patch
• Health checks and restart policies per service
• TLS on the proxy; everything else unreachable from the internet
• Per-service scaling, so the automation tier grows independently

Common Use Cases

• Internal admin panels over a production PostgreSQL or MySQL database, with per-role permissions instead of shared credentials
• Approval workflows — procurement, time off, refunds — where a form writes a row and an automation notifies a channel or calls an API
• Operations dashboards joining a warehouse table, an S3 bucket and a REST endpoint into one screen
• Supplier portals on scoped roles, so an external user sees only their own rows

Dependencies for Budibase

• budibase/apps:v3.43.0 — builder, published apps and the data API; a second copy runs the automation tier via APP_FEATURES=automations
• budibase/worker:v3.43.0 — users, roles, SMTP, SSO and settings
• budibase/proxy:v3.43.0 — nginx edge, built from gridalpha/budibase-railway with its resolver and object-storage rules tuned for Railway
• budibase/database:2.1.0 — CouchDB 3.3.3 with Clouseau and the SQLite search service
• minio/minio:RELEASE.2025-09-07T16-13-09Z — S3-compatible object storage
• Railway managed redis:8.2 — sessions, caches and automation queues

Environment Variables Reference

The shared secrets are set once on the apps service and referenced by the other two. Changing API_ENCRYPTION_KEY once a datasource is saved makes its credentials undecryptable, so treat it as permanent.

Deployment Dependencies

• github.com/Budibase/budibase · docs.budibase.com · images: apps, worker, proxy, database

Hardware Requirements for Self-Hosting Budibase

How Much Does Budibase Cost to Self-Host?

Budibase is open source and the self-hosted edition is free — unlimited apps, automations and users, with SSO included. You pay only for infrastructure, which on Railway is usage-based across six services and two volumes. Budibase's own cloud runs $19–$299/month plus per-user add-ons. A paid self-hosted Enterprise tier exists for teams needing audit logs and support.

Self-Hosting Budibase

Budibase publishes a docker-compose file for local evaluation. Clone it and start the stack:

git clone https://github.com/Budibase/budibase.git
cd budibase/hosting
cp .env.example .env   # then edit the secrets
docker compose up -d

That runs every service on one host with data in local Docker volumes. Replace the placeholder secrets first.

To split out the automation tier as this template does, run a second container from the apps image with the automations flag:

docker run -d --name budibase-automation-worker \
  -e APP_FEATURES=automations \
  -e COUCH_DB_URL="http://user:pass@couchdb-service:5984" \
  -e REDIS_URL="redis-service:6379" \
  budibase/apps:v3.43.0

Both containers must share JWT_SECRET, API_ENCRYPTION_KEY and INTERNAL_API_KEY, and use the same CouchDB, Redis and storage.

FAQ

What is Budibase?

An open-source platform for building internal tools. Connect a database or API, design screens from a component library, add automations, and publish an app with role-based access — no frontend or backend code required.

What does this Railway template deploy?

Six services: an nginx proxy (the only public one), the apps service, an automation worker, the worker service for identity, CouchDB and MinIO on volumes, and managed Redis.

Why does Budibase need CouchDB and MinIO instead of just PostgreSQL?

CouchDB is Budibase's own system of record — workspaces, screens, automations and internal tables live there, and its search components back the data grid. MinIO stores attachments and app bundles. SQL databases are supported as datasources you build apps on, not replacements.

Do I need SMTP to use self-hosted Budibase?

No. The first admin comes from environment variables, so you can sign in immediately. Add SMTP on the worker when you want to invite teammates or offer password resets.

How do I scale automations in self-hosted Budibase?

Raise the replica count on the automation worker. It pulls jobs from the shared Redis queue, so extra containers pick up work with no further configuration. Scale the apps service separately for interactive traffic.

Why is only the proxy given a public domain?

The proxy is Budibase's router and its security boundary: it applies rate limits, sets security headers, and controls which paths reach the apps service, the worker and object storage. Publishing the backends directly bypasses all of it.