Deploy NocoDB

Deploy and Host NocoDB on Railway

NocoDB is an open-source Airtable alternative that does what Airtable cannot: put a spreadsheet interface on a database you already own. Grid, kanban, gallery, calendar and form views over Postgres, MySQL or SQL Server, unlimited users, no per-seat pricing. This template runs it with its own Postgres metadata store, a volume for attachments, and the settings that decide whether pointing it at a real database is safe.

What This Template Deploys

Read that table carefully, because this is where most NocoDB deployments go wrong: the bundled Postgres is NocoDB's own bookkeeping, not a home for your business data. Bases you create inside NocoDB live there; databases you connect stay where they are.

About Hosting

NocoDB is two products in one — a place to build new tables, and a front end for databases that already exist. The second is why people choose it, and the one every deployment guide skips.

Connecting a database gives NocoDB write access to its schema. This is not a read-only viewer. NocoDB creates its own bookkeeping tables in any database you connect, and the UI lets anyone with edit rights add columns, change types and drop fields against your real schema, immediately. Never point it at production with an owner-level account — use a user scoped to one schema, or a replica.

NC_AUTH_JWT_SECRET encrypts your saved connections, not just sessions. Upstream describes it as the secret used for auth and for storing other secrets — so the credentials for every external database you connect are encrypted with it. Rotate it and you have not merely logged everyone out, you have made every saved data-source credential unreadable.

The first person to open the URL becomes the owner. A fresh NocoDB has no admin until someone signs up, and signup is open. Deploy, get distracted, and your workspace belongs to whoever found the domain first. Claim it immediately and close public signup before connecting anything.

NC_DB does not take a standard Postgres URL. NocoDB uses its own format — pg://host:port?u=user&p=password&d=database. A postgresql:// URL that works everywhere else fails here, and the failure is a container that will not start rather than a clear error.

Attachments are files on disk, separate from everything else. Metadata lives in Postgres; uploaded files go to /usr/app/data. Setting up Postgres and assuming you are safe is the common mistake — without a volume, a redeploy keeps every table and loses every attachment.

Set NC_PUBLIC_URL or your links point nowhere. Invitation emails and shared-view URLs are built from it. Left unset, people receive links they cannot open, and the instance itself looks fine from where you are sitting.

Typical cost: ~$10–20/month for NocoDB, Postgres and volumes at $10/GB/month RAM, $20/vCPU/month CPU and $0.15/GB/month volumes. NocoDB's community edition is free with unlimited users; SSO and audit logging are paid tiers.

How It Compares

The honest edge: Airtable is more polished, and its automations and interface builder are ahead of NocoDB's — starting from nothing, with per-seat cost no object, it is the better tool. Retool is stronger for bespoke internal apps. NocoDB wins on one axis neither matches: it sits on a database you already run, so your application and your spreadsheet view are the same rows — no sync, no export, no second copy of the truth.

Deploy in Under 5 Minutes

1. Click Deploy and pick a workspace. NocoDB and Postgres come up wired, with NC_AUTH_JWT_SECRET generated once and pinned.
2. Open the URL immediately and create your account — the first signup owns the workspace. Then disable public signup.
3. Confirm NC_PUBLIC_URL matches your domain so invites and shared views resolve.
4. Create a base to confirm the metadata store works, and upload a file to confirm the volume is writable.
5. Only then connect an external database — with a restricted user, not an owner account.

Verify before you rely on it: redeploy, then reopen that base and the attachment. Both still there means Postgres and the volume are doing their jobs; the attachment is the one that usually isn't.

Common Use Cases

• A spreadsheet view of your production data — give ops and support a readable interface over a replica, with no admin panel to build.
• Replacing per-seat Airtable — move a team off row caps and seat pricing onto a database you size yourself.
• Internal CRUD without building one — forms, filtered views and kanban over existing tables, no front end to maintain.

Configuration

Never rotate NC_AUTH_JWT_SECRET on a live instance. Every stored external-database credential is encrypted with it, so rotating means re-entering every connection by hand — not just signing people back in.

Connect external databases with a restricted user. NocoDB creates its own tables in whatever you connect and exposes schema editing in the UI. An owner-level account on a production database is a bad afternoon waiting to happen.

Dependencies for NocoDB Hosting

• Railway account — ~$10–20/month for NocoDB, Postgres and volumes.
• Bundled services — managed Postgres for NocoDB's metadata, wired over private networking.
• Volumes — one on Postgres, one on /usr/app/data for attachments. Both required unless you use S3.
• Optional — S3-compatible object storage for attachments, Redis if you later add a worker service, and an existing database to connect.

Deployment Dependencies

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

Implementation Details

NocoDB runs the official image on a pinned release tag rather than latest, serving port 8080 behind Railway's HTTPS edge. NC_DB is assembled from Railway reference variables into NocoDB's own format — the pg://host:port?u=&p=&d= shape, not a postgresql:// URL — because the application parses its own scheme and a standard URL produces a container that will not start rather than a readable error.

The split between the two stores is what to internalise. Postgres holds NocoDB's metadata: base and table definitions, views, filters, user accounts, and the encrypted credentials for every external database you connect. The volume at /usr/app/data holds attachment bytes, written to disk and never landing in the database. A backup of one without the other gives you tables full of broken file references. Past a few gigabytes, NC_S3_* moves attachments off the volume and removes the single-service constraint a volume imposes.

Connected databases deserve the most care. NocoDB stores connection credentials encrypted with NC_AUTH_JWT_SECRET, reads your schema to build views, and writes its own bookkeeping tables into whatever it connects to. It also surfaces schema editing in the UI, so a user with edit rights can alter your real tables from a spreadsheet. Grant accordingly: a user scoped to one schema, or a read replica if a view is all you need.

Frequently Asked Questions

Is the bundled Postgres where my data goes? Only for bases you create inside NocoDB. It is primarily the metadata store. Databases you connect from elsewhere stay where they are.

Can NocoDB change my database schema? Yes. It creates its own tables in any database you connect and exposes column editing in the UI. Use a restricted user or a replica.

Why won't the container start? Most often NC_DB in standard postgresql:// form. NocoDB needs its own pg://host:port?u=&p=&d= format.

Do my attachments survive a redeploy? Only with the volume mounted at /usr/app/data. Postgres persistence alone does not cover files.

Someone else created the first account. What happened? NocoDB has no admin until someone signs up, and signup is open by default. The first visitor to a fresh instance owns the workspace.

Why Deploy NocoDB 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 NocoDB on Railway you get the configuration that makes connecting a real database safe — metadata in Postgres rather than container-local SQLite, a JWT secret generated once so your saved connections stay readable, attachments on a volume, and a public URL set so the links you send actually open.