Deploy and Host NocoDB on Railway

NocoDB turns any database into a smart spreadsheet — grid, gallery, kanban and form views over your data, with roles, shares, an Airtable importer and a REST/GraphQL API on top. This template deploys the whole thing from NocoDB's own official image: the web app, a background worker, Postgres, a Valkey cache/queue, and managed object storage for attachments.

About Hosting NocoDB

Four services and a bucket, all from official upstream images:

NocoDB — the web app (dashboard, the REST/GraphQL API, email/password auth). The only service with a domain.
NocoDB Worker — the same image in worker mode. It pulls long-running jobs — Airtable/CSV imports, webhook delivery, exports — off the queue so they never block the web app.
Postgres — your bases, tables, rows and metadata, on a volume. NocoDB requires Postgres for a real deployment.
Valkey — the cache and the job queue that connects the web app to the worker. A drop-in Redis fork.
Bucket — Railway object storage for avatars and every file you attach to a record.

All variables are filled in and described on the deploy screen. There is nothing you have to supply — open the URL, register, and the first account becomes the super admin.

Four things this template does that are worth knowing about:

The image is pinned. Both other NocoDB templates ship nocodb/nocodb:latest, so a redeploy months from now can pull a different NocoDB under your live bases. This template pins a version (2026.08.0): a redeploy gives you exactly what you already ran, and you move up deliberately — bump the tag, back up first — instead of by surprise.

Attachments actually work, and the app tier is stateless. NocoDB signs presigned URLs that your browser fetches straight from storage. That means the addressing style matters: Railway storage only sends CORS headers on the path-style (host/bucket/key) endpoint, so NC_S3_FORCE_PATH_STYLE is on — with virtual-hosted URLs every attachment fails in the browser while curl still reports 200. Because attachments live in the bucket and everything else lives in Postgres, the web and worker containers hold no state: they share one attachment store, and a redeploy loses nothing. The other approach — attachments on a local disk — puts them on one container that the worker cannot see.

The cache has no volume, on purpose. Both other NocoDB templates give their Redis a persistent volume, and on Railway that is a trap: a fresh volume ships a lost+found directory the Redis image refuses to write around, so its first save fails and it then rejects every write — minutes after a deploy that went green. Here the queue and cache are Valkey with no volume, because a cache and a job queue have nothing to persist. Nothing to corrupt, nothing to back up.

Everything talks over the private network. Postgres and Valkey have no public proxy; the web app and worker reach them over Railway's private network. Your database is not on the internet.

Common Use Cases

A self-hosted Airtable: grid/kanban/gallery/form views over your own data, on a URL you control.
Moving off Airtable: the built-in importer pulls your existing Airtable bases in (add an Airtable API key).
A database UI for a team: point NocoDB at your data, hand out row/table-level roles, share views by link.
A backend with an API: every table is instantly a REST and GraphQL endpoint for your app or automations.

Dependencies for NocoDB Hosting

Deployment Dependencies

NocoDB — the upstream project and its official nocodb/nocodb image
Postgres for bases, tables, rows and metadata
Valkey (a Redis-compatible fork) for the cache and the background-job queue
An S3-compatible bucket for avatars and attachments

Implementation Details

The first person to register becomes the super admin. NocoDB signs in with email and password out of the box. Register first; then, if you do not want an open instance, invite the people you want and keep the rest out from Team & Settings.
The worker is a second copy of the image. It runs with NC_WORKER_CONTAINER=true, has no domain and no HTTP server, and shares the same JWT secret as the web app so tokens validate on both sides. A stopped worker means imports and webhooks queue up, not that anything is broken.
Email is optional. Invites and notifications need SMTP; NocoDB runs fine without it. Add the SMTP settings from NocoDB's Team & Settings when you want outgoing mail.
Telemetry is off. NC_DISABLE_TELE=true by default; set it to false to opt back in.

Resource Usage and Cost

NocoDB itself is a Node app; the weight of this template is the four services together — web, worker, Postgres and Valkey — plus the bucket. Measured on an idle deployment it sits in the low hundreds of megabytes of RAM across the services, with a spike while an import runs. Add the volume Postgres is given and whatever the bucket holds.

That puts a quiet instance at roughly $10–20/month, tracking how much you store and how busy the bases are rather than merely uptime. If you do not need background imports or webhooks at scale, you can delete the worker and the app still runs everything in-process.

Why Deploy NocoDB on Railway?

NocoDB wants four things that are tedious to wire up by hand: somewhere to run the app, a Postgres database, a Redis-compatible queue, and object storage the browser can upload attachments to directly. Railway supplies the storage as a managed bucket rather than a container you back up, keeps the database and cache on a private network with no public exposure, runs the import/webhook worker as its own service, and hands out the domain and certificate before the first deploy finishes. Register, and you have a working Airtable alternative with nothing left to configure.