Encaja en estos escenarios:

• Un equipo pequeño quiere una alternativa de código abierto a Airtable.
• Tienes un montón de Excel / CSV y quieres pasarlos a una base de datos para gestionarlos de forma unificada.
• Operaciones, atención al cliente y ventas necesitan editar datos, pero no deberían entrar directamente en la base de datos.
• Quieres poner una interfaz de gestión low-code sobre PostgreSQL / MySQL.
• Ya tienes un VPS y no quieres pagar por usuario por otra herramienta de colaboración en tablas.

No encaja tan bien en estos escenarios:

• Solo eres una persona anotando algunas tareas; Notion o Feishu Sheets son más sencillos.
• No quieres mantener en absoluto un servidor, una base de datos y copias de seguridad.
• Necesitas permisos empresariales, auditoría y flujos de aprobación extremadamente complejos.
• Piensas tener a cientos de personas editando en línea al mismo tiempo; un VPS pequeño puede no aguantarlo.

Mi recomendación: proyectos personales, equipos pequeños, herramientas internas, CRM ligero, tablas de inventario y planificación de contenidos encajan muy bien. Si de verdad quieres un backend empresarial grande, NocoDB puede servir como interfaz auxiliar, pero no lo trates como un ERP todopoderoso.

El quickstart oficial de NocoDB ejecuta cuatro contenedores:

Se puede empezar desde 1 núcleo y 1 GB, pero no recomiendo ser tan tacaño en producción.

Lo que realmente importa es el disco y las copias de seguridad. NocoDB en sí no es pesado; el problema es que, una vez que metes datos de clientes, pedidos y archivos adjuntos, se convierte en el centro de datos de tu negocio. Un VPS barato sirve, pero no puedes prescindir de las copias de seguridad.

Este artículo asume:

• Ubuntu 22.04 / 24.04 o Debian 12.
• Docker y Docker Compose V2 ya instalados.
• Tienes un dominio, por ejemplo nocodb.example.com.
• El registro A del dominio apunta a la IP pública del VPS.
• Los puertos 80 y 443 pueden abrirse para que Caddy obtenga HTTPS automáticamente.

Verifica Docker:

docker version
docker compose version

Si aún no has instalado Docker, puedes leer primero el artículo de este sitio sobre Docker Compose en producción. Aquí no repetiré la instalación básica.

NocoDB ofrece oficialmente scripts de quickstart e instalación de servidor único, que ciertamente son cómodos:

curl -fsSL https://install.nocodb.com/noco.sh | bash

Te generará un stack de Compose, e incluso el modo de servidor único puede gestionar Traefik y Let's Encrypt.

Pero no recomiendo mucho que los principiantes ejecuten el script directamente la primera vez. La razón es simple: cuando surge un problema, no sabes qué generó, dónde están los datos, cómo hacer copias de seguridad ni cómo migrar.

Este artículo adopta el enfoque de escribir el Compose a mano. La configuración es un poco más larga, pero puedes ver cada contenedor, cada volumen y cada contraseña. El mantenimiento posterior también es más sólido.

Crea el directorio de despliegue:

sudo mkdir -p /opt/nocodb
sudo chown -R "$USER":"$USER" /opt/nocodb
cd /opt/nocodb
mkdir -p postgres-data redis-data nocodb-data backups caddy-data caddy-config

Genera algunas claves aleatorias:

openssl rand -base64 32
openssl rand -base64 32
openssl rand -hex 32

Se usan respectivamente para:

• Contraseña de PostgreSQL
• NocoDB JWT Secret
• Clave de cifrado de la conexión a la base de datos

No uses password123 ni copies las contraseñas del tutorial. NocoDB puede guardar más adelante información de conexión a bases de datos externas, así que una contraseña débil es cavarte un hoyo.

Crea .env:

nano .env

Escribe el siguiente contenido, sustituyendo el dominio y las contraseñas por los tuyos:

NOCODB_DOMAIN=nocodb.example.com
POSTGRES_PASSWORD=replace_with_a_long_postgres_password
NC_AUTH_JWT_SECRET=replace_with_a_long_random_secret
NC_CONNECTION_ENCRYPT_KEY=replace_with_64_hex_chars

Unas cuantas variables explicadas:

• POSTGRES_PASSWORD: contraseña de la base de datos PostgreSQL.
• NC_AUTH_JWT_SECRET: clave relacionada con las sesiones de inicio de sesión; debe ser fija en producción.
• NC_CONNECTION_ENCRYPT_KEY: se usa para cifrar la información de conexión a bases de datos externas; se recomienda configurarla desde el principio.
• NOCODB_DOMAIN: el dominio que usa el proxy inverso de Caddy.

No subas el archivo .env a un repositorio Git. Es tu secreto de producción.

Crea docker-compose.yml:

nano docker-compose.yml

Escribe:

services:
  nocodb:
    image: nocodb/nocodb:latest
    container_name: nocodb
    restart: unless-stopped
    env_file:
      - .env
    environment:
      NC_DB: "pg://db:5432?u=nocodb&p=${POSTGRES_PASSWORD}&d=nocodb"
      NC_REDIS_URL: "redis://redis:6379"
      NC_SITE_URL: "https://${NOCODB_DOMAIN}"
      NC_AUTH_JWT_SECRET: "${NC_AUTH_JWT_SECRET}"
      NC_CONNECTION_ENCRYPT_KEY: "${NC_CONNECTION_ENCRYPT_KEY}"
      NC_DISABLE_MUX: "true"
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    volumes:
      - ./nocodb-data:/usr/app/data
    ports:
      - "127.0.0.1:8080:8080"
    healthcheck:
      test: ["CMD-SHELL", "wget -q --tries=1 --spider http://localhost:8080/api/v1/health || exit 1"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 30s

  worker:
    image: nocodb/nocodb:latest
    container_name: nocodb-worker
    restart: unless-stopped
    env_file:
      - .env
    environment:
      NC_DB: "pg://db:5432?u=nocodb&p=${POSTGRES_PASSWORD}&d=nocodb"
      NC_REDIS_URL: "redis://redis:6379"
      NC_SITE_URL: "https://${NOCODB_DOMAIN}"
      NC_AUTH_JWT_SECRET: "${NC_AUTH_JWT_SECRET}"
      NC_CONNECTION_ENCRYPT_KEY: "${NC_CONNECTION_ENCRYPT_KEY}"
      NC_WORKER_CONTAINER: "true"
    depends_on:
      nocodb:
        condition: service_healthy
    volumes:
      - ./nocodb-data:/usr/app/data

  db:
    image: postgres:17-alpine
    container_name: nocodb-db
    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 -d nocodb"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    container_name: nocodb-redis
    restart: unless-stopped
    volumes:
      - ./redis-data:/data
    command: redis-server --appendonly yes
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

  caddy:
    image: caddy:2-alpine
    container_name: nocodb-caddy
    restart: unless-stopped
    env_file:
      - .env
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy-data:/data
      - ./caddy-config:/config
    depends_on:
      - nocodb

Hay varias cosas escritas así a propósito:

• nocodb solo se enlaza a 127.0.0.1:8080, por lo que el puerto 8080 no es accesible directamente desde internet.
• Lo que realmente se expone al exterior son los puertos 80/443 de Caddy.
• PostgreSQL no mapea 5432, así que los escaneos de internet no encuentran la base de datos.
• Redis tampoco mapea 6379.
• nocodb-data, postgres-data y redis-data son directorios del host, así que los encuentras de un vistazo al hacer copias de seguridad.

Una práctica más estable en producción es fijar nocodb/nocodb:latest a la etiqueta de la versión estable actual. Para el primer despliegue puedes usar latest para que funcione; antes de ponerlo en marcha, consulta la versión actual en NocoDB GitHub Releases o Docker Hub y fíjala manualmente.

Crea Caddyfile:

nano Caddyfile

Escribe:

{$NOCODB_DOMAIN} {
    encode zstd gzip
    reverse_proxy 127.0.0.1:8080
}

Asegúrate de que el dominio ya resuelve al VPS y luego abre el firewall:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw reload

Si tu proveedor de nube también tiene grupos de seguridad, permite 80 y 443 allí también. Mucha gente los abre en el sistema pero no en la consola de la nube, y al final Caddy no consigue el certificado.

Ejecuta:

cd /opt/nocodb
docker compose up -d

Ver el estado de los contenedores:

docker compose ps

Ver los registros:

docker compose logs -f --tail=100 nocodb

El primer arranque descargará imágenes e inicializará la base de datos, así que esperar unos minutos es normal. Cuando nocodb esté healthy, abre en el navegador:

https://nocodb.example.com

El primer usuario registrado se convierte en superadministrador. Justo después de registrarte, ve a la configuración y revisa el correo, la URL del sitio, el idioma y los permisos; no pases el enlace a toda la empresa sin más.

NocoDB tiene varias formas de uso:

1. Crear un proyecto vacío y luego crear tablas en la interfaz.
2. Importar CSV / Excel.
3. Conectar una base de datos PostgreSQL / MySQL existente.
4. Generar una API REST para una tabla.

Si migras desde Excel, recomiendo importar primero una copia; no conectes los datos de producción de inmediato.

Por ejemplo, una tabla de clientes puede organizarse primero así:

Deja que el equipo lo pruebe durante 1-2 semanas antes de decidir si conectar la base de datos real del negocio. El mayor problema de las herramientas low-code no es el despliegue, sino que todos diseñan los campos de forma caótica desde el principio.

NocoDB puede conectarse a bases de datos externas, y esa es también su característica más valiosa. Pero aquí hay que ser prudente.

Recomendaciones:

• Crea primero una cuenta de solo lectura para NocoDB.
• No uses directamente el usuario root de la base de datos.
• No expongas el 5432 / 3306 de la base de datos de producción a internet.
• Lo mejor es que NocoDB y la base de datos se comuniquen dentro de la misma intranet o red de Docker.
• Verifica primero campos, relaciones y permisos en una base de datos de prueba.

Por ejemplo, un usuario de solo lectura de PostgreSQL se parece más o menos a esto:

CREATE USER nocodb_readonly WITH PASSWORD 'change_this_password';
GRANT CONNECT ON DATABASE appdb TO nocodb_readonly;
GRANT USAGE ON SCHEMA public TO nocodb_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO nocodb_readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO nocodb_readonly;

Si de verdad quieres que operaciones edite datos en NocoDB, crea una cuenta separada con permisos controlados y abre solo las tablas que necesitan edición. No entregues todos los permisos de la base de datos solo por comodidad.

NocoDB requiere respaldar dos tipos de cosas:

• Base de datos PostgreSQL: proyectos, estructuras de tablas, metadatos de NocoDB, datos de negocio.
• /usr/app/data: archivos adjuntos, archivos locales y otros datos.

Primero crea un script de copia de seguridad:

nano backup-nocodb.sh

Escribe:

#!/usr/bin/env bash
set -euo pipefail

APP_DIR="/opt/nocodb"
BACKUP_DIR="$APP_DIR/backups"
DATE="$(date +%F-%H%M)"

mkdir -p "$BACKUP_DIR/$DATE"
cd "$APP_DIR"

docker exec nocodb-db pg_dump -U nocodb nocodb | gzip > "$BACKUP_DIR/$DATE/nocodb.sql.gz"
tar czf "$BACKUP_DIR/$DATE/nocodb-data.tar.gz" nocodb-data Caddyfile docker-compose.yml .env

find "$BACKUP_DIR" -mindepth 1 -maxdepth 1 -type d -mtime +14 -exec rm -rf {} \;

echo "Backup saved to $BACKUP_DIR/$DATE"

Añade permiso de ejecución y prueba:

chmod +x backup-nocodb.sh
./backup-nocodb.sh
ls -lh backups

Después de confirmar que se genera el archivo de copia de seguridad, añade una tarea programada:

crontab -e

Copia de seguridad todos los días a las 3 de la madrugada:

0 3 * * * /opt/nocodb/backup-nocodb.sh >> /opt/nocodb/backups/backup.log 2>&1

Esto es solo una copia local. Una práctica más segura es usar además rclone para sincronizar con almacenamiento de objetos, otro VPS o un NAS. Si solo haces copias en la misma máquina, cuando el disco falla se pierde todo junto.

Si una copia de seguridad nunca se ha restaurado, no se puede considerar realmente utilizable.

Busca un VPS de prueba y copia allí los archivos de copia de seguridad:

mkdir -p /opt/nocodb-restore
cd /opt/nocodb-restore

Extrae la configuración y los archivos adjuntos:

tar xzf nocodb-data.tar.gz

Inicia la base de datos y luego restaura el SQL:

docker compose up -d db redis
sleep 20
gunzip -c nocodb.sql.gz | docker exec -i nocodb-db psql -U nocodb nocodb

docker compose up -d

En una restauración real, puede que haya que cambiar el dominio, el certificado y el dominio en .env. No esperes al día de un incidente en producción para practicar este proceso por primera vez.

Haz una copia de seguridad antes de actualizar:

cd /opt/nocodb
./backup-nocodb.sh

Si todavía usas latest:

docker compose pull
docker compose up -d

Si ya has fijado una etiqueta de versión, primero cambia la versión de la imagen en docker-compose.yml y luego ejecuta el mismo comando.

Después de actualizar, comprueba:

docker compose ps
docker compose logs --tail=100 nocodb

Luego abre la página web y revisa al menos tres cosas:

• Si puedes iniciar sesión.
• Si las tablas se abren.
• Si la importación, la exportación y los archivos adjuntos funcionan correctamente.

Una vez que una herramienta como NocoDB se integra en el flujo de trabajo del equipo, no actualices con demasiada ligereza. Se recomienda hacerlo en horas de baja actividad, avisar al equipo antes de actualizar y conservar una copia de seguridad para revertir.

NocoDB es una herramienta interna, pero una vez expuesta a internet hay que tratarla como un sistema formal.

Como mínimo, haz lo siguiente:

• Abre solo 80/443, no 8080, 5432 ni 6379.
• Usa contraseñas fuertes para los administradores.
• Desactiva el registro público que no necesites.
• Asigna el mínimo privilegio a cada equipo.
• Usa cuentas de bajo privilegio para las conexiones a bases de datos externas.
• No pongas .env ni los archivos de copia de seguridad en directorios accesibles desde la web.
• Actualiza periódicamente las imágenes y los parches de seguridad del sistema.
• Sincroniza las copias de seguridad fuera del sitio.
• Activa el historial de cambios en las tablas importantes o haz una auditoría aparte.

Si vas a dejar que lo usen clientes o colaboradores externos, lo mejor es añadir una capa de Cloudflare Access, Tailscale, VPN o al menos HTTP Basic Auth. No dejes una interfaz interna de gestión de datos expuesta a toda internet.

Comprueba antes del uso formal:

• El dominio ya resuelve al VPS.
• 80/443 están permitidos en el firewall del sistema y en el grupo de seguridad de la nube.
• 8080 solo se enlaza a 127.0.0.1.
• PostgreSQL y Redis no exponen puertos públicos.
• Las contraseñas y claves de .env se han sustituido todas.
• NC_SITE_URL es un dominio HTTPS real.
• Se ha creado la primera cuenta de administrador.
• El script de copia de seguridad local se ha ejecutado correctamente.
• Se ha hecho al menos una restauración de prueba.
• Los permisos del equipo y los campos de las tablas están organizados.

Si solo eres una persona llevando cuentas y escribiendo tareas, NocoDB puede ser algo pesado. Notion, Feishu Sheets y Google Sheets son más sencillos.

Pero si ya tienes un VPS y quieres convertir Excel, CSV y bases de datos en una herramienta interna colaborativa, con control de permisos y capaz de generar API, NocoDB merece mucho la pena. No pretende sustituir todos los sistemas backend, sino llenar el hueco entre "el desarrollo es demasiado lento, Excel es demasiado desordenado y Airtable es demasiado caro".

Recomiendo probarlo primero con datos no críticos, como planificación de contenidos, clientes potenciales o registros de inventario. Cuando el equipo se sienta cómodo, ve conectando datos más importantes poco a poco. Lo que más temen las herramientas low-code es cargar con el negocio principal desde el principio; valida a pequeña escala primero y luego amplía, así los problemas son más fáciles de contener.