Deploy NocoBase

Deploy and Host NocoBase on Railway

NocoBase is an open-source no-code platform for building internal business applications — a self-hosted alternative to Retool, Budibase and Appsmith. Model your data as collections, assemble pages from blocks, wire up workflows and roles, extend anything through plugins. This template runs it with managed Postgres, a volume that keeps your installed plugins, and the two secrets and one timezone setting that are permanent in practice.

What This Template Deploys

Worth noting, since the names collide: NocoBase is not NocoDB. NocoDB puts a spreadsheet view on an existing database. NocoBase is an application platform — data models, pages and workflows, closer to an internal product than a table.

About Hosting

NocoBase is forgiving to run and unforgiving about three decisions made at deploy time. All three are cheap to get right now and expensive to change later.

The default root account exists before you ever log in. NocoBase ships a documented default administrator, and INIT_ROOT_EMAIL and INIT_ROOT_PASSWORD take effect on first boot only — once that user row is in Postgres, changing the variables does nothing. Deploy with the defaults and your public URL is protected by credentials published in the docs. Set your own before the first deploy.

Two encryption secrets, and only one is recoverable. APP_KEY signs sessions, so rotating it logs everyone out and they sign back in. ENCRYPTION_FIELD_KEY encrypts the contents of encrypted fields, and rotating or losing it makes that data unreadable in a way no database backup alone can fix. Treat it like a private key and store a copy wherever you keep your dumps.

Installed plugins live on the volume, not in the image. NocoBase's whole model is extension, and plugins added through the UI are written to /app/nocobase/storage rather than baked into the container. Without a volume, every redeploy returns a stock install with a database full of collections referencing plugins that are no longer there — which fails more confusingly than simply losing data.

Every enabled plugin loads into one Node process. Memory binds before CPU. A handful of plugins and a couple of editors is comfortable around 4 GB and cramped at 1 GB — and enabling plugins is exactly what users do without weighing the resource cost.

TZ is set once in practice. The container timezone governs how date fields are written. Change it after people have entered data and existing values are reinterpreted rather than converted, shifting every historical date by the offset. Pick the timezone your team works in before anyone enters a record.

Pick the image variant deliberately. The -full tag bundles database clients and LibreOffice for PDF template printing; it is far larger and wants more memory. Without PDF generation, the standard image deploys faster and costs less to run.

Typical cost: ~$25–45/month for NocoBase and Postgres at $10/GB/month RAM, $20/vCPU/month CPU and $0.15/GB/month volumes. The spread is almost entirely memory — this is a plugin-loading Node process, not a lightweight service.

How It Compares

The honest edge: Retool is more mature with better component depth, and if your organisation will pay per seat it gets you to a working tool faster. Budibase is the closest open-source comparison and simpler for straightforward CRUD screens. NocoBase earns its place when you expect what you build to keep growing — plugin architecture means a feature you need later is an extension rather than a workaround, and the editor count never reaches an invoice.

Deploy in Under 5 Minutes

1. Click Deploy and pick a workspace. Set INIT_ROOT_EMAIL and INIT_ROOT_PASSWORD here — they only apply on first boot and cannot be changed through variables afterwards.
2. Set TZ to the timezone your team works in, before anyone enters a record.
3. Wait for the first boot. NocoBase runs its installation and migrations, which takes a couple of minutes and is not a hang.
4. Open the domain and sign in with the credentials you set in step one. Confirm no default account is accessible.
5. Enable a plugin, then redeploy and check it is still enabled — that proves the storage volume is mounted correctly.

Verify before you rely on it: after that redeploy, confirm both the plugin and an uploaded file are still present. Postgres almost always survives; the volume is what people get wrong.

Common Use Cases

• Internal CRM — contacts, pipelines and activity logs with role-based access, no per-seat pricing across the team.
• Operations back-office — order, inventory or ticket management as collections with approval workflows attached.
• Admin panel over your own schema — connect an existing database and build interfaces on top rather than writing CRUD screens.

Configuration

Set the root credentials before the first deploy. NocoBase's default administrator is published in its documentation, and the init variables stop working the moment that account exists in Postgres.

Back up ENCRYPTION_FIELD_KEY with your database dumps. A restored database without it contains encrypted columns nobody can read, including you.

Dependencies for NocoBase Hosting

• Railway account — ~$25–45/month, dominated by memory for the application service.
• Bundled services — managed Postgres for all application data, wired over private networking.
• Volumes — one on Postgres, one on /app/nocobase/storage. Both required; the second holds your plugins.
• Optional — Redis for caching on busier instances, the -full image variant for PDF template printing.

Deployment Dependencies

• NocoBase on GitHub
• NocoBase documentation
• NocoBase environment variables
• Railway volumes

Implementation Details

NocoBase runs the official image on a pinned tag behind Railway's HTTPS edge, with Postgres reached by private hostname through reference variables. First boot runs the install command and applies migrations before the app answers, so the health check needs headroom — a short timeout kills the container mid-migration and produces a restart loop that looks like a broken image rather than an impatient probe.

State is split in a way that matters for backups and upgrades alike. Postgres holds collections, records, UI schemas, users, roles and workflows — everything you build. The volume holds uploaded files, application state and the plugins installed through the interface. Because plugins live on the volume while core lives in the image, the two drift after upgrades: pin the tag, and treat a core version bump as something to test rather than something that happens on redeploy.

For backups you need the database dump, the volume, and ENCRYPTION_FIELD_KEY stored separately from both. The third is the one people skip: encrypted-field contents are ciphertext in the dump, so restoring without the key gives you a working application with unreadable columns and no path to recovery.

Frequently Asked Questions

Is NocoBase the same as NocoDB? No. NocoDB puts a spreadsheet interface on an existing database. NocoBase is a platform for building applications — data models, pages, workflows and roles.

I set INIT_ROOT_PASSWORD but it didn't change anything. Those variables apply only on first boot. Once the root user exists in Postgres, change the password from inside the application instead.

Do my installed plugins survive a redeploy? Only with the volume mounted at /app/nocobase/storage. Plugins are written there, not baked into the image.

Why does it need so much memory? Every enabled plugin loads into a single Node process. Memory scales with how many you enable, not with traffic.

Can I change the timezone later? You can, but existing dates are reinterpreted rather than converted. Decide before people start entering records.

Why Deploy NocoBase on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying NocoBase on Railway you get the decisions that cannot be undone handled up front — your own root credentials rather than the published default, both encryption secrets generated once and held stable, a volume that keeps the plugins you install, and a timezone set before the first record is written.