Budibase

Last reviewed Aug 26, 2026 · 798 words

Budibase turns a database table into an internal app with forms, filters and role-based screens in an afternoon, and that is the job to hire it for. It also has an automation engine, and the mistake I see most often is picking Budibase because of that engine and then discovering it is not a replacement for n8n. Get the roles straight and the 6-container, 2 GB stack is reasonable; get them wrong and you have paid that cost for the wrong tool.

The stack behind port 10000

A self-hosted Budibase is an app server, a worker for auth and admin duties, an nginx proxy that presents everything on port 10000, CouchDB for the internal database and app definitions, MinIO for file storage, and Redis for sessions and queues. The official compose file and the budi hosting --init CLI both generate the same thing with a .env holding JWT_SECRET, MINIO_ACCESS_KEY, MINIO_SECRET_KEY, COUCH_DB_PASSWORD and INTERNAL_API_KEY. Generate those once and keep them; CouchDB holds every app you build, so that password and the CouchDB volume are the backup set. Idle memory is around 1.5 GB across the services, so the 2 GB minimum is a minimum and 4 GB is comfortable with a few apps published.

Where it shines: CRUD over data you already have

Connect Postgres, MySQL, SQL Server, MongoDB, a REST API or Google Sheets, and Budibase reads the schema and generates a working table screen with search, filters and a row form. From there you drag components, bind fields, and assign screens to roles (Basic, Power, Admin, or custom). Users authenticate through Budibase's own accounts or OIDC. Typical wins: an inventory screen for the warehouse, a support lookup over the customer table, an approval form that writes to a Postgres table an existing system reads. The internal database (CouchDB under the hood) is fine for small tables you don't already have elsewhere, but the sweet spot is existing SQL.

The automation engine is for app events, not integration

Automations trigger on row created or updated, an app action button, a cron schedule, or an incoming webhook, and then run steps: query a data source, send an email, call an external API, run a JavaScript snippet, branch, loop. That is enough for "when a request is approved, email the requester and update the ticket". It is not enough for a 40-node pipeline with retries, error branches and 300 service connectors, and it is not meant to be. The pattern that works is Budibase for the UI and its own row-level events, n8n for anything that touches more than 2 external systems, connected in either direction by webhook. The wider automation category is really two categories, app builders and workflow engines, and this one belongs to the first.

Appsmith, NocoDB, or Budibase

Appsmith is the pick when the builder is a developer who wants to write JavaScript in every property. NocoDB is the pick when the "app" is really a shared table with views. Budibase is the pick for a non-developer who needs a proper multi-screen app with roles and a couple of automations, and its data-source list is the broadest of the three. It is also, in my experience, the one an ops manager can pick up without help.

The licensing line to read before you commit

Self-hosting is free without a user cap and covers the core builder, all data sources and automations. A handful of features sit behind paid tiers at last check, and the list moves, so check the pricing page for the specific one you care about before promising it to your team; environment variables for data source secrets and app backups have been on that boundary. This is the same model as the Retool it competes with, just with a far larger free surface.

What I'd do

Budibase on a 4 GB VM, official compose, secrets generated once and stored, CouchDB volume backed up nightly with MinIO alongside it, OIDC login from whatever identity provider you already run. Build the first app on an existing Postgres table rather than the internal database, keep automations to single-app events, and hand anything cross-system to n8n through a webhook. That split has run cleanly for me for years, and it is the arrangement I would set up again tomorrow.