Cómo autoalojar NocoDB en 2026: conexiones de base de datos, autenticación y persistencia

Hay dos versiones de «ejecutar NocoDB»: existe un contenedor o el servicio completa realmente su función. Solo importa la segunda. En este caso, la prueba consiste en conectar una base de datos de origen desechable, crear una cuadrícula y una vista filtrada, editar una fila, añadir un adjunto y llamar a la API REST.

NocoDB sirve para esto: una interfaz de hoja de cálculo sobre una base de datos real. El despliegue debe conservar las piezas que hacen posible ese comportamiento; un puerto, un volumen y un certificado son entradas, no el resultado.

Delimitar el perímetro de ejecución de NocoDB

El estado del proceso y el estado del producto son aspectos independientes en NocoDB. El puerto 8080 puede responder mientras la transacción que usa el usuario sigue fallando. El contrato de red de NocoDB para producción requiere PostgreSQL o MySQL para los metadatos, en lugar de un archivo local desechable. Mantén los endpoints privados en el DNS interno, permite únicamente las llamadas salientes necesarias y proporciona a NocoDB una credencial de servicio con permisos limitados.

Usa este ejercicio de preparación después de cambios de configuración relevantes: conecta una base de datos de origen desechable, crea una cuadrícula y una vista filtrada, edita una fila, añade un adjunto y llama a la API REST. Mantén las comprobaciones externas costosas fuera de las sondas de liveness para que una interrupción del proveedor no provoque un bucle de reinicios. El trabajo de capacidad debe hacer un seguimiento del número de filas, el tráfico de adjuntos, la latencia de la base de datos de metadatos y los usuarios simultáneos de cuadrículas, aspectos más cercanos a la presión real de NocoDB que las solicitudes de páginas.

Iniciar NocoDB con valores predeterminados observables

Inicia NocoDB de forma que la ruta permanezca privada hasta completar el bootstrap.

docker run -d \
  --name nocodb \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v nocodb-data:/usr/app/data \
  -e NC_AUTH_JWT_SECRET=replace-with-a-long-random-value \
  nocodb/nocodb:latest

Si el proceso entra en un bucle, compara el usuario esperado por la imagen con el propietario de cada ruta montada. Si permanece activo, prueba localmente el puerto 8080 y pasa directamente al flujo de trabajo: conecta una base de datos de origen desechable, crea una cuadrícula y una vista filtrada, edita una fila, añade un adjunto y llama a la API REST. Fija la versión de la imagen solo después de que esta comprobación de extremo a extremo se complete correctamente y registra la configuración exacta junto al servicio.

Dominios, cabeceras del proxy y puerto 8080

Elige el nombre de host definitivo de NocoDB antes de que los usuarios guarden callbacks o ajustes de cliente y, después, establece NC_PUBLIC_URL con la dirección HTTPS canónica. La ruta de la plataforma debe terminar TLS una sola vez y apuntar al puerto privado 8080.

Ejecuta la transacción de aceptación desde el exterior. Si el cliente nunca llega a NocoDB, utiliza la lista de comprobación para validar SSL para revisar el DNS y el certificado. Si la solicitud llega a NocoDB, pero la base de datos de metadatos no está disponible o las URL públicas apuntan a un host interno, deja de cambiar las redirecciones del proxy e inspecciona el perímetro específico de la aplicación.

Diseñar la restauración de NocoDB antes del lanzamiento

Define el punto y el tiempo de recuperación de NocoDB en función de la base de datos de metadatos, los adjuntos y cualquier base de datos de origen externa. Monta /usr/app/data antes del bootstrap, escribe datos de ejemplo inocuos y sustituye el contenedor para demostrar que esa ruta es realmente persistente. Un volumen con nombre resuelve la persistencia durante los redeploys, pero no protege frente a una intrusión ni frente a la pérdida del servidor.

Crea un entorno de restauración limpio, utiliza la misma versión fijada de la aplicación y demuestra que las bases, vistas, roles, adjuntos y asignaciones de origen vuelven a estar disponibles sin modificar las filas de la base de datos conectada. Registra los comandos, las correcciones de propiedad y el tiempo transcurrido. La guía de copias de seguridad ofrece un estándar útil: una copia de seguridad es fiable después de restaurarla, no después de subirla.

Decisiones de seguridad específicas de NocoDB

Cierra la ventana de bootstrap en cuanto exista el primer administrador de confianza. El problema concreto de NocoDB es reutilizar un secreto JWT débil o exponer las credenciales de las bases a todos los editores; el perímetro más seguro consiste en utilizar un secreto JWT estable, limitar quién puede crear conexiones a fuentes de datos externas y revisar la exposición de las vistas compartidas.

Genera NC_AUTH_JWT_SECRET como un valor aleatorio largo; rotarlo normalmente invalida las sesiones o los tokens, así que planifica el impacto para los usuarios en lugar de considerarlo una migración de cifrado. La red privada debe transportar las credenciales de las dependencias, y los roles dentro de NocoDB deben conceder la acción útil mínima. Mantén fuera de los logs habituales los cuerpos de solicitudes sensibles y las respuestas de los proveedores.

Comprobaciones de capacidad y actualización

Un contenedor en verde es necesario, pero no suficiente. El indicador de nivel de servicio es completar correctamente «conectar una base de datos de origen desechable, crear una cuadrícula y una vista filtrada, editar una fila, añadir un adjunto y llamar a la API REST», mientras que las señales de presión más probables son el número de filas, el tráfico de adjuntos, la latencia de la base de datos de metadatos y los usuarios simultáneos de cuadrículas.

El control de cambios es importante porque las migraciones de metadatos pueden afectar a las vistas y las automatizaciones aunque la base de datos de origen subyacente no se modifique. Conserva la imagen anterior, prueba las migraciones sobre un estado copiado y documenta si se admite la reversión después de mover el esquema. Si la base de datos de metadatos no está disponible o las URL públicas apuntan a un host interno, diagnostica el primer perímetro que difiera del entorno operativo.

Una ejecución de aceptación de NocoDB en producción

Antes de que lleguen los usuarios reales, crea una hoja de lanzamiento para NocoDB. Debe indicar la imagen fijada, el puerto 8080, el origen canónico, las rutas persistentes y el propietario de PostgreSQL o MySQL para los metadatos de producción, en lugar de un archivo local desechable. Adjunta el resultado esperado de esta transacción: conectar una base de datos de origen desechable, crear una cuadrícula y una vista filtrada, editar una fila, añadir un adjunto y llamar a la API REST.

Utiliza la hoja después de una sustitución normal y después de una restauración limpia. La recuperación solo se acepta si las bases, vistas, roles, adjuntos y asignaciones de origen vuelven a estar disponibles sin modificar las filas de la base de datos conectada. Recopila también un breve registro de recursos que cubra el número de filas, el tráfico de adjuntos, la latencia de la base de datos de metadatos y los usuarios simultáneos de cuadrículas; consérvalo junto a la versión para comparar futuros cambios de capacidad con la misma carga de trabajo.

Incluye un fallo controlado: deniega temporalmente a la identidad de prueba el acceso a PostgreSQL o MySQL para los metadatos de producción, en lugar de utilizar un archivo local desechable. Confirma que NocoDB informa del problema en el perímetro correcto, restablece la condición válida y vuelve a ejecutar la transacción. Esto comprueba la visibilidad de los errores, no solo el éxito, y evita que una interfaz con apariencia saludable oculte un worker, callback o conexión de base de datos defectuosos.

Cómo Dockup reduce el trabajo con NocoDB

En el caso de NocoDB, Dockup resulta especialmente útil en el límite entre una imagen y un servicio duradero. Mantiene asociadas la ruta al puerto 8080, TLS, los valores secretos y el almacenamiento durante las sustituciones de contenedores, tanto si el cómputo pertenece a Dockup como si pertenece a tu servidor conectado.

Termina aplicando los conocimientos específicos de la aplicación: establece NC_PUBLIC_URL con la dirección HTTPS canónica; conecta y prueba PostgreSQL o MySQL para los metadatos de producción, en lugar de un archivo local desechable; y ejecuta esta verificación: conecta una base de datos de origen desechable, crea una cuadrícula y una vista filtrada, edita una fila, añade un adjunto y llama a la API REST. Conserva el resultado como comprobación del despliegue para que la siguiente actualización de imagen se evalúe por su comportamiento y no por el estado del contenedor.

Preguntas frecuentes

¿Qué necesita NocoDB para un despliegue de producción?

Enruta el contenedor de NocoDB en el puerto 8080 a través de un único origen HTTPS. El requisito de red de soporte es PostgreSQL o MySQL para los metadatos de producción, en lugar de un archivo local desechable. No consideres NocoDB listo hasta que puedas conectar una base de datos de origen desechable, crear una cuadrícula y una vista filtrada, editar una fila, añadir un adjunto y llamar a la API REST.

¿Qué datos de NocoDB deben incluirse en una copia de seguridad?

Conserva /usr/app/data e incluye la base de datos de metadatos, los adjuntos y cualquier base de datos de origen externa en el mismo manifiesto de recuperación. Una restauración limpia de NocoDB solo es válida cuando las bases, vistas, roles, adjuntos y asignaciones de origen vuelven a estar disponibles sin modificar las filas de la base de datos conectada.

¿NocoDB necesita HTTPS detrás de un reverse proxy?

Utiliza HTTPS para el origen público de NocoDB y mantén el puerto 8080 en la ruta interna. Aplica correctamente el ajuste de NocoDB: establece NC_PUBLIC_URL con la dirección HTTPS canónica. En NocoDB, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

¿Cómo se debe probar una actualización de NocoDB?

Restaura el estado actual de NocoDB en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque las migraciones de metadatos pueden afectar a las vistas y las automatizaciones aunque la base de datos de origen subyacente no se modifique. Conserva la imagen anterior de NocoDB hasta comprender los límites de la migración de datos y de la reversión.