---
title: "Deploy NocoBase"
description: "Host NocoBase [Oct'26] — build CRMs and internal tools on Postgres"
category: "CMS"
url: https://railway.com/deploy/nocobase-low-code-apps
---

# Deploy NocoBase

Host NocoBase [Oct'26] — build CRMs and internal tools on Postgres

**[Deploy NocoBase on Railway](https://railway.com/template/nocobase-low-code-apps)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/nocobase-low-code-apps/manifest.json

- **Creator:** SB
- **Category:** CMS

## Template content

### Postgres https://devicons.railway.app/i/postgresql.svg

- **Image:** ghcr.io/railwayapp-templates/postgres-ssl:18

### Nocobase https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/png/nocobase-light.png

- **Image:** nocobase/nocobase:latest-full
- **Public domain:** Yes

## Documentation

# 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

| Service | Purpose |
| --- | --- |
| `nocobase` | Application and admin UI behind Railway's HTTPS proxy. Public domain. |
| `Postgres` | Collections, records, UI schemas, users, roles and workflow definitions. Volume attached. |
| Volume | `/app/nocobase/storage` — uploads, application state, and **installed plugins**. |

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

| | NocoBase (self-hosted) | Retool | Budibase | Airtable |
| --- | --- | --- | --- | --- |
| Cost model | Flat infrastructure | Per seat | Per seat or self-host | Per seat |
| Self-hostable | Yes | Enterprise only | Yes | No |

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

| Variable | Required | Description |
| --- | --- | --- |
| `APP_KEY` | Generated | Signs user tokens and sessions. Changing it logs everyone out. |
| `ENCRYPTION_FIELD_KEY` | Generated | Encrypts encrypted-field data. Losing it is unrecoverable. |
| `DB_HOST`, `DB_PORT`, `DB_DATABASE`, `DB_USER`, `DB_PASSWORD` | Auto | Reference variables on the private Postgres hostname. |
| `INIT_ROOT_EMAIL`, `INIT_ROOT_PASSWORD` | Required | Initial administrator. **First boot only** — later changes are ignored. |
| `TZ` | Required | Timezone for date fields. Changing it later reinterprets existing dates. |
| Storage volume | Pre-set | `/app/nocobase/storage` — uploads, state and installed plugins. |

> **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](https://github.com/nocobase/nocobase)
- [NocoBase documentation](https://docs.nocobase.com/)
- [NocoBase environment variables](https://docs.nocobase.com/welcome/getting-started/env)
- [Railway volumes](https://docs.railway.com/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.

## Similar templates

- [Libredesk - Complete Setup](https://railway.com/deploy/libredesk-complete-setup) — Complete self-hosted omnichannel customer support desk.
- [Paperless-ngx](https://railway.com/deploy/paperless-ngx-3) — Paperless-ngx — document management with OCR and full-text search
- [Instatic CMS - Postgres](https://railway.com/deploy/instatic-cms-postgres) — Design, build and manage powerful static sites from state-of-the-art CMS

Open this page in a browser: https://railway.com/deploy/nocobase-low-code-apps