How to Self-Host NocoDB 2026

TL;DR

NocoDB (AGPL 3.0, ~49K GitHub stars, Node.js) turns any SQL database — PostgreSQL, MySQL, SQLite, SQL Server — into an Airtable-style spreadsheet UI. Connect it to your existing database and get grid, gallery, form, and kanban views instantly. Airtable charges $20/user/month. NocoDB is free, connects to databases you already have, and generates REST + GraphQL APIs on every table automatically.

Key Takeaways

NocoDB: AGPL 3.0, ~49K stars — Airtable UI on top of any SQL database
Bring your own DB: Connect to existing PostgreSQL/MySQL instead of a black-box proprietary format
Auto-generated APIs: Every table gets REST and GraphQL endpoints immediately
Views: Grid, Gallery, Form, Kanban, Calendar, Map — on any table
Automations: Webhooks, email, Slack, Zapier — triggered by row changes
Airtable import: Import Airtable base directly from Airtable API key

NocoDB vs Airtable vs Grist

Feature	NocoDB	Airtable	Grist
License	AGPL 3.0	Proprietary	Apache 2.0
GitHub Stars	~49K	—	~7K
Cost	Free	$20/user/mo	Free
Connects to existing DB	Yes	No	No
Formula language	Excel-like	Airtable formulas	Python
Auto REST/GraphQL API	Yes	Yes (paid)	Yes
Views	Grid/Gallery/Form/Kanban/Calendar	All types	Grid/Card/Chart
Automations	Yes	Yes	Limited
Row permissions	No	No	Yes
GitHub Stars	~49K	—	~7K

Part 1: Docker Setup

Option A: Fresh SQLite (quickest start)

# docker-compose.yml
services:
  nocodb:
    image: nocodb/nocodb:latest
    container_name: nocodb
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - nocodb_data:/usr/app/data
    environment:
      NC_DB: "sqlite3:///usr/app/data/noco.db"

volumes:
  nocodb_data:

Option B: PostgreSQL backend (recommended for production)

services:
  nocodb:
    image: nocodb/nocodb:latest
    container_name: nocodb
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - nocodb_data:/usr/app/data
    environment:
      NC_DB: "pg://postgres:5432?u=nocodb&p=${POSTGRES_PASSWORD}&d=nocodb"
      NC_AUTH_JWT_SECRET: "${JWT_SECRET}"
      NC_PUBLIC_URL: "https://noco.yourdomain.com"
      # Optional: disable sign-up
      NC_DISABLE_SIGNUP: "false"
      # Optional: SMTP
      NC_SMTP_HOST: "smtp.yourdomain.com"
      NC_SMTP_PORT: 587
      NC_SMTP_USERNAME: "${SMTP_USER}"
      NC_SMTP_PASSWORD: "${SMTP_PASS}"
      NC_SMTP_FROM: "nocodb@yourdomain.com"
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: nocodb
      POSTGRES_PASSWORD: "${POSTGRES_PASSWORD}"
      POSTGRES_DB: nocodb
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U nocodb"]
      interval: 10s
      start_period: 20s

volumes:
  nocodb_data:
  postgres_data:

# .env
POSTGRES_PASSWORD=your-secure-db-password
JWT_SECRET=$(openssl rand -hex 32)

docker compose up -d

Visit http://your-server:8080 — create your admin account.

Part 2: HTTPS with Caddy

noco.yourdomain.com {
    reverse_proxy localhost:8080
}

Part 3: Connect an Existing Database

The killer feature: connect NocoDB to a database you already have.

Home → + New Project → Connect to existing database
Choose PostgreSQL / MySQL / SQL Server
Enter connection string or individual host/port/user/pass/db
NocoDB reads all existing tables and creates views automatically

Connection: postgres://myuser:mypass@db.internal:5432/myapp

NocoDB reflects existing tables — changes in NocoDB write back to your actual database. No data migration needed.

Use cases:

Manage PostgreSQL tables via a spreadsheet UI
Give non-technical teammates a friendly view into the database
Build forms that insert directly into production tables (with care)
Generate REST API on top of legacy database tables

Part 4: Views

Every table supports multiple views — all views show the same data, just differently:

Grid View

Standard spreadsheet. Sort, filter, group, hide columns, lock rows.

Gallery View

Card-based display. Useful for image-heavy data (products, people, media).

Kanban View

Group by any Choice column. Drag cards between columns.

Tasks table → Kanban grouped by "Status"
├── Todo
│   ├── Task A
│   └── Task B
├── In Progress
│   └── Task C
└── Done
    └── Task D

Form View

Auto-generated form for data entry — share a link for public submissions.

+ Add View → Form
Choose which fields to show
Share the form link (no NocoDB account needed to submit)

Calendar View

Group by any Date column — see events in day/week/month layout.

Part 5: Auto-Generated REST API

Every table in NocoDB automatically has a REST API:

# Get your API token:
# Account → Team & Auth → API Tokens → Add token

TOKEN="your-api-token"
BASE_URL="https://noco.yourdomain.com"
TABLE_ID="md_xxxxx"     # From URL when viewing a table

# List records:
curl "${BASE_URL}/api/v1/db/data/noco/${TABLE_ID}" \
  -H "xc-token: $TOKEN" | jq

# Filter + sort:
curl "${BASE_URL}/api/v1/db/data/noco/${TABLE_ID}?where=(Status,eq,Active)&sort=-CreatedAt&limit=20" \
  -H "xc-token: $TOKEN"

# Create a record:
curl -X POST "${BASE_URL}/api/v1/db/data/noco/${TABLE_ID}" \
  -H "xc-token: $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"Name": "New item", "Status": "Active"}'

# Update:
curl -X PATCH "${BASE_URL}/api/v1/db/data/noco/${TABLE_ID}/42" \
  -H "xc-token: $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"Status": "Inactive"}'

# Delete:
curl -X DELETE "${BASE_URL}/api/v1/db/data/noco/${TABLE_ID}/42" \
  -H "xc-token: $TOKEN"

Swagger UI

NocoDB has a built-in API explorer:

Visit https://noco.yourdomain.com/api/v1/swagger
Try all endpoints interactively with your token

Part 6: Automations

Trigger actions when rows change:

Table → Automation → + Add Automation
Trigger: Record created / updated / deleted
Actions:
- Webhook — POST to any URL (Slack, Discord, n8n, etc.)
- Send email — via configured SMTP
- Slack message — direct Slack integration
- Create another record — cross-table automation

// Example webhook payload (row created):
{
  "type": "records.after.insert",
  "table": "Orders",
  "record": {
    "Id": 42,
    "Customer": "Alice",
    "Total": 99.99,
    "Status": "Pending"
  }
}

Part 7: Import from Airtable

NocoDB can import directly from Airtable using your API key:

+ New Project → Import Airtable
Enter your Airtable Personal Access Token
Select which bases to import
NocoDB imports tables, field types, views, and records

# Airtable personal access token:
# airtable.com/create/tokens → Create token with "data.records:read" scope

Note: Formulas may need manual re-creation. Images import as attachment URLs.

Workspace roles

Owner: Full access, manage billing
Creator: Create/delete tables and bases
Editor: Edit records, create views
Commenter: Comment, no edit
Viewer: Read-only

Click share icon on any view
Toggle Enable public access
Optionally enable password protection
Share the generated URL — no account needed to view

Part 9: Backup and Restore

# Backup PostgreSQL:
docker exec nocodb-postgres-1 pg_dump -U nocodb nocodb \
  | gzip > nocodb-backup-$(date +%Y%m%d).sql.gz

# Backup SQLite:
docker cp nocodb:/usr/app/data/noco.db ./noco-backup-$(date +%Y%m%d).db

# Restore PostgreSQL:
gunzip < nocodb-backup-20260101.sql.gz | \
  docker exec -i nocodb-postgres-1 psql -U nocodb nocodb

# Backup uploads (attachments):
tar -czf nocodb-uploads-$(date +%Y%m%d).tar.gz \
  $(docker volume inspect nocodb_nocodb_data --format '{{.Mountpoint}}')/uploads/

Maintenance

# Update NocoDB:
docker compose pull
docker compose up -d

# Logs:
docker compose logs -f nocodb

# Check NocoDB version:
curl https://noco.yourdomain.com/api/v1/meta/version | jq

See all open source database and no-code tools at OSSAlt.com/categories/productivity.

See open source alternatives to NocoDB on OSSAlt.

Monitoring and Operational Health

Deploying a self-hosted service without monitoring is running blind. At minimum, set up three layers: uptime monitoring, resource monitoring, and log retention.

Uptime monitoring with Uptime Kuma gives you HTTP endpoint checks every 30-60 seconds with alerts to Telegram, Slack, email, or webhook. Create a monitor for your primary application URL and any API health endpoints. The status page feature lets you communicate incidents to users without custom tooling.

Resource monitoring tells you when a container is leaking memory or when disk is filling up. Prometheus + Grafana is the standard self-hosted monitoring stack — Prometheus scrapes container metrics via cAdvisor, Grafana visualizes them with pre-built Docker dashboards. Set alerts for memory above 80% and disk above 75%; both give you time to act before they become incidents.

Log retention: Docker container logs are ephemeral by default. Add logging: driver: json-file; options: max-size: 100m; max-file: 3 to your docker-compose.yml to limit log growth and retain recent logs for debugging. For centralized log search across multiple containers, Loki integrates with the same Grafana instance.

Backup discipline: Schedule automated backups of your Docker volumes using Duplicati or Restic. Back up to remote storage (Backblaze B2 or Cloudflare R2 cost $0.006/GB/month). Run a restore drill monthly — a backup that has never been tested is not a reliable backup. Your restore procedure documentation should live somewhere accessible from outside the failed server.

Update strategy: Pin Docker image versions in your compose file rather than using latest. Create a monthly maintenance window to review changelogs and update images. Major version updates often require running migration scripts before the new container starts — check the release notes before pulling.

NocoDB is most useful as part of a broader self-hosted productivity stack. n8n integrates with NocoDB via API to automate data entry, trigger notifications when records change, or sync NocoDB data with external services. Plausible Analytics can send event data to NocoDB via n8n for custom analytics dashboards that combine web traffic data with your application-specific records.

Network Security and Hardening

Self-hosted services exposed to the internet require baseline hardening. The default Docker networking model exposes container ports directly — without additional configuration, any open port is accessible from anywhere.

Firewall configuration: Use ufw (Uncomplicated Firewall) on Ubuntu/Debian or firewalld on RHEL-based systems. Allow only ports 22 (SSH), 80 (HTTP redirect), and 443 (HTTPS). Block all other inbound ports. Docker bypasses ufw's OUTPUT rules by default — install the ufw-docker package or configure Docker's iptables integration to prevent containers from opening ports that bypass your firewall rules.

SSH hardening: Disable password authentication and root login in /etc/ssh/sshd_config. Use key-based authentication only. Consider changing the default SSH port (22) to a non-standard port to reduce brute-force noise in your logs.

Fail2ban: Install fail2ban to automatically ban IPs that make repeated failed authentication attempts. Configure jails for SSH, Nginx, and any application-level authentication endpoints.

TLS/SSL: Use Let's Encrypt certificates via Certbot or Traefik's automatic ACME integration. Never expose services over HTTP in production. Configure HSTS headers to prevent protocol downgrade attacks. Check your SSL configuration with SSL Labs' server test — aim for an A or A+ rating.

Container isolation: Avoid running containers as root. Add user: "1000:1000" to your docker-compose.yml service definitions where the application supports non-root execution. Use read-only volumes (volumes: - /host/path:/container/path:ro) for configuration files the container only needs to read.

Secrets management: Never put passwords and API keys directly in docker-compose.yml files committed to version control. Use Docker secrets, environment files (.env), or a secrets manager like Vault for sensitive configuration. Add .env to your .gitignore before your first commit.

Production Deployment Checklist

Before treating any self-hosted service as production-ready, work through this checklist. Each item represents a class of failure that will eventually affect your service if left unaddressed.

Infrastructure

Server OS is running latest security patches (apt upgrade / dnf upgrade)
Firewall configured: only ports 22, 80, 443 open
SSH key-only authentication (password auth disabled)
Docker and Docker Compose are current stable versions
Swap space configured (at minimum equal to RAM for <4GB servers)

Application

Docker image version pinned (not latest) in docker-compose.yml
Data directories backed by named volumes (not bind mounts to ephemeral paths)
Environment variables stored in .env file (not hardcoded in compose)
Container restart policy set to unless-stopped or always
Health check configured in Compose or Dockerfile

Networking

SSL certificate issued and auto-renewal configured
HTTP requests redirect to HTTPS
Domain points to server IP (verify with dig +short your.domain)
Reverse proxy (Nginx/Traefik) handles SSL termination

Monitoring and Backup

Uptime monitoring configured with alerting
Automated daily backup of Docker volumes to remote storage
Backup tested with a successful restore drill
Log retention configured (no unbounded log accumulation)

Access Control

Default admin credentials changed
Email confirmation configured if the app supports it
User registration disabled if the service is private
Authentication middleware added if the service lacks native login

Getting Started

The best time to set up monitoring and backups is before you need them. Deploy your service, configure it, and immediately add it to your monitoring stack and backup schedule. These three steps — deploy, monitor, backup — are the complete foundation of a reliable self-hosted service. Everything else is incremental improvement.

NocoDB fills the gap between spreadsheets and custom database applications. It gives non-technical team members a familiar grid interface to data that lives in PostgreSQL, MySQL, or SQLite — without exposing the raw database. For internal tools where you need CRUD operations, form submissions, and basic reporting without building a custom admin interface, NocoDB is often the fastest path from database to operational tool. The self-hosted deployment runs efficiently on modest hardware; a single-container NocoDB instance serving a team of 20 runs comfortably on a $6/month VPS alongside other services.

NocoDB's REST and GraphQL APIs let you integrate your database views with other tools. Any table you expose via NocoDB generates a documented REST endpoint that n8n, Zapier, or custom code can query and modify. This makes NocoDB a useful internal data API layer for teams that want structured CRUD access to database records without building custom API endpoints. Combined with role-based view sharing — where external collaborators can access specific views without login — NocoDB can serve as a lightweight data portal for contractors, clients, or partners.

The SaaS-to-Self-Hosted Migration Guide (Free PDF)