Skip to main content

Launch a No-Code Database (NocoDB)

The nocode-db stack gives you a spreadsheet-style, no-code front end on top of a real PostgreSQL database. You pick a base, draw tables, edit rows in a grid, build views, and get an auto-generated REST API, without writing migrations or wiring an app to a database by hand. Underneath the friendly grid is an ordinary managed PostgreSQL service that is fully yours: you can query it with SQL, scale it, back it up, and connect any other application to it.

No-code database stack · compose & launch
RUNNING Stack wired · no-code grid + REST API live
Stack Templatenocode-dblaunch ⇉PostgreSQLmanagedNocoDBNC_DB → dbserve →No-code UIgrid + REST API
Template · endpointPostgreSQLNocoDB appwiring (NC_DB injected)

Who it is for​

  • Teams who want an internal tool, a CRM, an inventory tracker, or a project board without standing up a backend.
  • Developers who like Airtable's editing experience but want a real SQL database underneath, in their own account, resident in Europe.
  • Anyone who needs a quick admin UI over data that other services will read and write through a standard REST API.

What it composes​

The stack launches two resources and wires them together for you:

ResourceWhat it isSpec
dbA managed PostgreSQL 17 database. This is where every table, row, and view actually lives.tier-1, 25 GB standard storage
appA NocoDB application, the open-source Airtable alternative. It connects to the database and renders it as grids, views, and a REST API.tier-1, 10 GB standard storage

NocoDB is a no-code interface, not a separate datastore. It reads and writes your PostgreSQL directly, so the data you see in the grid is the same data you would see with psql. Delete the NocoDB app and your tables are still there in Postgres. That is the point: the spreadsheet is just a view onto a database you own.

Prerequisites​

  • An API token. See Authentication.
  • That is all. Unlike the rag-chatbot stack, nocode-db needs no inference provider and no Files bucket. It is just a database and an app.

Export your token so the commands below work as written:

export FOUNDRYDB_TOKEN="your-api-token"

Launch it​

You can launch from the console with one click, or from the API. Both run the same engine.

Option A: the console​

  1. Open Stacks in the FoundryDB console.
  2. Pick Launch a no-code database.
  3. Review the cost preview and click Launch.

A few minutes later the stack reaches Running and the console shows a live link to the NocoDB UI.

Option B: the API​

The launch is a two-step flow: preview the cost first, then launch with the cost you accepted. This guarantees you always see an up-to-date estimate before any billable resource is created.

Step 1: Preview the cost.

curl -X POST https://api.foundrydb.com/stacks/preview \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"template_name": "nocode-db"}'

The response breaks down the two resources and gives you a total:

{
  "template_name": "nocode-db",
  "currency": "EUR",
  "monthly_total": 43.00,
  "line_items": [
    {
      "symbolic_name": "db",
      "kind": "database",
      "description": "PostgreSQL tier-1 (1 vCPU, 2 GB) + 25 GB standard storage",
      "monthly_cost": 25.00,
      "is_ceiling": false
    },
    {
      "symbolic_name": "app",
      "kind": "app",
      "description": "NocoDB app, tier-1 (1 vCPU, 2 GB) + 10 GB standard storage",
      "monthly_cost": 18.00,
      "is_ceiling": false
    }
  ],
  "warnings": []
}

monthly_total is the figure you pass to the launch request. The exact numbers depend on your plan; always read them from your own preview response rather than copying them.

Step 2: Launch.

Pass the monthly_total from the preview as accepted_monthly_cost:

curl -X POST https://api.foundrydb.com/stacks \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-nocode-db",
    "template_name": "nocode-db",
    "accepted_monthly_cost": 43.00
  }'

The response is 201 Created with the stack in Pending status. Capture its id for polling:

export STACK_ID="the-id-from-the-201-response"

If you omit accepted_monthly_cost you get 400 Bad Request. If the estimate has drifted from what you accepted by more than the allowed tolerance, you get 409 Conflict and need to re-preview. See Launch a Stack for the full cost-gate table and for overrides.

Step 3: Poll for status.

The stack provisions asynchronously. Poll until status reaches Running:

curl https://api.foundrydb.com/stacks/$STACK_ID \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN"

The typical progression is Pending to Provisioning to Wiring to Running. The PostgreSQL database comes up first; the NocoDB app waits for it, then attaches during the Wiring phase. Most launches complete within a few minutes.

Once the stack is Running, the endpoint_url field carries the live NocoDB URL:

curl https://api.foundrydb.com/stacks/$STACK_ID \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN" \
  | grep endpoint_url

The resources array in the same response shows each child's own status and a service_id pointer, so you can also find the PostgreSQL service under Databases and the NocoDB app under Apps in the console.

First run​

Open the endpoint_url in your browser. NocoDB serves over HTTPS at a real FoundryDB hostname with a valid certificate.

1. Create the first admin​

On the very first visit NocoDB asks you to create the super-admin account. Set an email and a strong password. This account owns the NocoDB instance, so treat it like any other admin credential. After sign-up you land in the NocoDB dashboard.

2. Create a base over your PostgreSQL​

In NocoDB a base is a collection of tables. Because the stack already injected your PostgreSQL connection (see the wiring section below), you do not need to type a connection string. Create a new base and NocoDB builds it directly on the attached database.

If your PostgreSQL already has tables, NocoDB can import them and render each one as a grid immediately. If it is empty, start from scratch in the next step.

3. Build a table​

Add a table, then add fields. NocoDB offers rich field types (single line text, number, date, attachment, checkbox, single select, formula, link to another record) and maps each to an appropriate PostgreSQL column under the hood. Adding a "Date" field creates a real date/timestamp column; adding a "Link to another record" creates the foreign-key relationship in Postgres.

Try a simple inventory table:

  • name (single line text)
  • quantity (number)
  • category (single select)
  • last_restocked (date)

4. Edit in the grid, build views​

The grid is your spreadsheet. Click a cell to edit, drag to fill, and add rows inline. Every edit is a write to PostgreSQL.

Then layer views on top of the same data:

  • Grid for the spreadsheet view.
  • Gallery or Kanban to organize records as cards by a select field.
  • Form to collect new rows from people who never see the grid.

Views are presentation only. They filter, sort, and group the same underlying rows; they do not copy data.

5. Use the auto-generated REST API​

This is where the no-code database becomes a backend. NocoDB exposes a REST API for every table automatically. From the table menu, open the API snippets to see the exact endpoints and an auth token. A typical read looks like:

curl "https://<your-nocodb-host>/api/v2/tables/<table-id>/records" \
  -H "xc-token: <your-nocodb-api-token>"

You now have CRUD over your PostgreSQL data through a documented HTTP API, with zero backend code. Point a front end, a script, or another FoundryDB app at it.

How the wiring works​

When you launch the stack, the engine does the plumbing you would otherwise do by hand:

  1. Provision the database. It creates the managed PostgreSQL service and waits for it to reach Running.
  2. Provision the app. It creates the NocoDB app service. The catalog declares app as attached_to: [$db] and dependencies.app: [db], so the engine knows the app must not finish wiring until the database is up.
  3. Attach and inject. During the Wiring phase the engine attaches the NocoDB app to the database and injects the connection as the NC_DB environment variable that NocoDB reads at startup. That single injected connection string is what lets NocoDB open the database, enumerate tables, and serve the grid.

You never copy a connection string, open a firewall rule, or paste credentials into a settings panel. The attach step does it, and the result is the same managed database you can also reach with psql or wire into another service.

Cost and EU residency​

Both resources are billed through your normal plan as ordinary services: a tier-1 PostgreSQL with 25 GB of standard storage, and a tier-1 NocoDB app with 10 GB. The preview response is the source of truth for the exact monthly figure, and the cost gate makes sure you accept it before anything is created.

Everything the stack creates is EU-resident. The PostgreSQL database and the NocoDB app both run inside the platform's European footprint. Residency is where the platform runs, not a setting you remember to flip. Your tables, your rows, and your no-code UI all stay in Europe.

Teardown​

Deleting the stack removes both child resources atomically, in reverse dependency order, with no orphans left behind:

curl -X DELETE https://api.foundrydb.com/stacks/$STACK_ID \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN"

Returns 202 Accepted. The reconciler deletes the NocoDB app first, then the PostgreSQL database. Teardown is irreversible, so export any data you want to keep before you delete. Because the data lives in Postgres, a plain pg_dump of the database is the simplest way to take a backup before teardown.

Next steps​