Cómo autoalojar Baserow en 2026: datos, URLs y copias de seguridad en un solo lugar

Un contenedor de Baserow puede aparecer en verde mientras el proceso que realmente necesitan los usuarios está fallando. En Baserow, ese fallo oculto suele consistir en que la URL pública cambia después de que los usuarios hayan generado enlaces para compartir y callbacks. Esta guía considera como prueba de aceptación “crear una base de datos y una vista, importar un CSV, editar filas desde dos sesiones y subir un archivo antes de reiniciar el stack all-in-one” y diseña el despliegue hacia atrás a partir de ese resultado.

Baserow tiene un papel específico en el stack: bases de datos al estilo de Airtable respaldadas por Postgres y Redis. Por tanto, la cuestión en producción no es si el puerto 80 responde una vez, sino si el estado, las dependencias y la dirección pública siguen siendo coherentes después de un reinicio, una actualización y una restauración.

De qué depende Baserow

La salud del proceso y la salud del producto son aspectos distintos en Baserow. El puerto 80 puede responder mientras la transacción que ve el usuario sigue fallando. El requisito del runtime local es disponer de memoria suficiente para Postgres, Redis, el backend y los workers incluidos. Mantén explícito su ciclo de vida para que mover Baserow entre hosts no cambie su comportamiento silenciosamente.

Utiliza este ejercicio de readiness después de cambios de configuración importantes: crea una base de datos y una vista, importa un CSV, edita filas desde dos sesiones y sube un archivo antes de reiniciar el stack all-in-one. Mantén las comprobaciones externas costosas fuera de las probes de liveness para que una interrupción del proveedor no provoque un bucle de reinicios. El trabajo de capacity planning debe seguir el estado de Postgres y Redis incluidos, los workers de Celery, el número de filas, el tamaño de las importaciones y los editores simultáneos, factores más cercanos a la presión real de Baserow que las solicitudes de páginas.

Una base de Docker para Baserow

El siguiente comando hace visible el límite del contenedor sin pretender aprovisionar todos los servicios externos.

docker run -d \
  --name baserow \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v baserow-data:/baserow/data \
  -e SECRET_KEY=replace-with-a-long-random-value \
  baserow/baserow:latest

Antes de abrir el ingress, inspecciona el entorno resuelto, los mounts y el listener. Confirma el requisito local antes de exponerlo: memoria suficiente para Postgres, Redis, el backend y los workers incluidos. Un lanzamiento correcto termina cuando puedes crear una base de datos y una vista, importar un CSV, editar filas desde dos sesiones y subir un archivo antes de reiniciar el stack all-in-one, no cuando docker ps muestra Up.

Dominios, headers del proxy y el puerto 80

Expón un único hostname HTTPS para Baserow y mantén privado el puerto 80 sin cifrar. Define BASEROW_PUBLIC_URL con el origin externo exacto. Así evitarás que los navegadores y los clientes de API conozcan dos direcciones en conflicto.

Desde un cliente limpio, ejecuta la transacción conocida como correcta e inspecciona la primera solicitud que falle. Usa la guía de dominios personalizados cuando el DNS o TLS no sean correctos. Trata “la URL pública cambia después de que los usuarios hayan generado enlaces para compartir y callbacks” como un diagnóstico independiente de la aplicación una vez que la ruta esté validada.

Haz copias de seguridad del estado que Baserow no puede recrear

Define el recovery point y el recovery time de Baserow en función del árbol completo /baserow/data y de exportaciones lógicas periódicas de la base de datos. Monta /baserow/data antes del bootstrap, escribe datos de muestra inocuos y reemplaza el contenedor para demostrar que esa ruta es realmente persistente. Un named volume resuelve la persistencia durante los redeploys; no resuelve una intrusión ni la pérdida del servidor.

Prepara un entorno de restauración limpio, utiliza la misma versión fijada de la aplicación y demuestra que las tablas, vistas, usuarios, automatizaciones y archivos se recuperan desde la copia de seguridad completa de /baserow/data. Registra los comandos, las correcciones de ownership y el tiempo transcurrido. La guía de copias de seguridad ofrece un estándar útil: una copia de seguridad se considera fiable después de restaurarla, no después de subirla.

No le des a Baserow todo el host

Haz un threat model de las acciones que realiza Baserow, no solo de su formulario de inicio de sesión. En este caso, el error de mayor riesgo es usar la imagen all-in-one sin un plan de copias de seguridad para sus servicios incluidos. Implementa este límite: cierra el registro cuando corresponda, conserva SECRET_KEY y limita las vistas públicas compartidas a los datos previstos.

Genera SECRET_KEY una sola vez, mantenlo fuera de Git y consérvalo junto con el recovery manifest, ya que cambiarlo puede invalidar el estado cifrado o firmado de la aplicación. No soluciones un error de permisos ejecutando el contenedor como root ni montando el host de forma amplia. Los límites de recursos también forman parte del diseño de seguridad cuando los usuarios pueden provocar actividad en Postgres, Redis y los workers de Celery incluidos, así como aumentar el número de filas, el tamaño de las importaciones y la cantidad de editores simultáneos.

Logs que responden a la siguiente pregunta

Un health check en reposo dice muy poco sobre Baserow. Supervisa Postgres, Redis y los workers de Celery incluidos, el número de filas, el tamaño de las importaciones y los editores simultáneos; después, genera alertas sobre el síntoma que experimentan los usuarios: el fallo de la acción “crear una base de datos y una vista, importar un CSV, editar filas desde dos sesiones y subir un archivo antes de reiniciar el stack all-in-one”. Mantén el liveness local y barato; deja que el readiness informe de las migraciones o la inicialización sin provocar una tormenta de reinicios.

El área de riesgo durante una actualización es que la imagen all-in-one mueve varios servicios a la vez, por lo que las migraciones de la base de datos y de la aplicación necesitan un ensayo basado en snapshots. Lee las release notes, crea un snapshot del estado, despliega la versión objetivo sobre una copia restaurada y repite la acción de aceptación. Si la URL pública cambia después de que los usuarios hayan generado enlaces para compartir y callbacks, relaciona la solicitud del cliente con el primer log relevante de la aplicación en lugar de eliminar el estado o añadir redirects a ciegas.

Cinco comprobaciones más sólidas que la salud del contenedor

Antes de que lleguen los usuarios reales, prepara una release worksheet para Baserow. Debe indicar la imagen fijada, el puerto 80, el origin canónico, las rutas persistentes y la persona responsable de garantizar memoria suficiente para Postgres, Redis, el backend y los workers incluidos. Añade el resultado esperado de esta transacción: crear una base de datos y una vista, importar un CSV, editar filas desde dos sesiones y subir un archivo antes de reiniciar el stack all-in-one.

Utiliza la worksheet después de un reemplazo normal y después de una restauración limpia. La recuperación solo se acepta si las tablas, vistas, usuarios, automatizaciones y archivos regresan desde la copia de seguridad completa de /baserow/data. Recopila también un resource trace breve que cubra Postgres, Redis y los workers de Celery incluidos, el número de filas, el tamaño de las importaciones y los editores simultáneos; guárdalo junto a la release para comparar los futuros cambios de capacidad con la misma carga de trabajo.

Incluye un fallo controlado: envía datos de prueba inocuos cerca del límite de recursos o de formato asociado a este límite: la URL pública cambia después de que los usuarios hayan generado enlaces para compartir y callbacks. Confirma que Baserow informa del problema en el límite 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 aparentemente saludable oculte un worker, callback o conexión con la base de datos averiados.

Conecta Baserow al ciclo de vida de Dockup

El despliegue de Baserow con un clic de Dockup debe hacer que los reemplazos sean seguros: la ruta debe seguir apuntando al puerto 80, los secrets no deben estar integrados en la imagen y las rutas persistentes deben reaparecer en el contenedor nuevo. El mismo despliegue puede ejecutarse en el compute de Dockup o en una máquina conectada.

Completa el trabajo específico de la aplicación confirmando el requisito local —memoria suficiente para Postgres, Redis, el backend y los workers incluidos—, aplicando la dirección pública canónica y ejecutando esta comprobación de aceptación: crear una base de datos y una vista, importar un CSV, editar filas desde dos sesiones y subir un archivo antes de reiniciar el stack all-in-one. Añade el resultado de la restauración al runbook antes de que lleguen los usuarios reales.

Preguntas frecuentes

¿Qué necesita Baserow para un despliegue en producción?

Enruta el contenedor de Baserow por el puerto 80 a través de un único origin HTTPS. El requisito del runtime local es disponer de memoria suficiente para Postgres, Redis, el backend y los workers incluidos. No consideres Baserow listo hasta que puedas crear una base de datos y una vista, importar un CSV, editar filas desde dos sesiones y subir un archivo antes de reiniciar el stack all-in-one.

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

Haz persistente /baserow/data e incluye el árbol completo /baserow/data y exportaciones lógicas periódicas de la base de datos en el mismo recovery manifest. Una restauración limpia de Baserow solo se considera correcta cuando las tablas, vistas, usuarios, automatizaciones y archivos regresan desde la copia de seguridad completa de /baserow/data.

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

Usa HTTPS para el origin público de Baserow y mantén el puerto 80 en la ruta interna. Aplica correctamente la configuración de Baserow: define BASEROW_PUBLIC_URL con el origin externo exacto. En Baserow, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente dependiente del origin.

¿Cómo debe probarse una actualización de Baserow?

Restaura el estado actual de Baserow en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque la imagen all-in-one mueve varios servicios a la vez, por lo que las migraciones de la base de datos y de la aplicación necesitan un ensayo basado en snapshots. Conserva la imagen anterior de Baserow hasta comprender sus límites de migración de datos y rollback.