Cómo alojar Etherpad por cuenta propia en 2026: pads, plugins y copias de seguridad de la base de datos

Si ya has intentado alojar Etherpad por cuenta propia, probablemente conozcas bien este estado frustrante: la interfaz aparece, pero las sesiones se desconectan porque los timeouts del proxy son demasiado cortos. Recrear el contenedor rara vez soluciona un desacuerdo entre las URL, el estado y las dependencias.

Esta guía utiliza un único criterio concreto de finalización: abrir un pad en dos navegadores, editarlo simultáneamente, inspeccionar las revisiones y exportar el resultado en el formato requerido. Cada decisión de configuración se evalúa según ese criterio, no según el indicador verde del contenedor.

Elige la topología mínima viable para Etherpad

La topología mínima responsable para Etherpad contiene un listener privado en el puerto 9001, una ruta de ingress y un límite de estado documentado. El contrato de red de Etherpad es Postgres u otra base de datos compatible para un uso multiusuario duradero. Mantén los endpoints privados en el DNS interno, permite solo las llamadas salientes necesarias y asigna a Etherpad una credencial de servicio con permisos limitados.

Valida la topología pidiendo a un cliente limpio que abra un pad en dos navegadores, lo edite simultáneamente, inspeccione las revisiones y exporte el resultado en el formato requerido. Observa las sesiones de WebSocket, el número de revisiones, las escrituras en la base de datos y la ejecución de plugins mientras se ejecuta. El resultado te indicará si la siguiente mejora corresponde a la memoria, el almacenamiento, la red o un worker independiente, en lugar de fomentar un dimensionamiento arbitrario del contenedor.

Crea un contenedor de Etherpad reemplazable

Utiliza el contenedor como un runtime reemplazable, no como la ubicación de la verdad.

docker run -d \
  --name etherpad \
  --restart unless-stopped \
  -p 127.0.0.1:9001:9001 \
  -v etherpad-data:/opt/etherpad-lite/var \
  -e ADMIN_PASSWORD=replace-with-a-long-random-value \
  etherpad/etherpad:latest

Añade la configuración de conexión revisada para Postgres u otra base de datos compatible para un uso multiusuario duradero; utiliza nombres privados para los servicios privados. Inspecciona el usuario del contenedor, las rutas con permisos de escritura y el listener enlazado antes de exponerlo. Ejecuta la acción completa —abrir un pad en dos navegadores, editarlo simultáneamente, inspeccionar las revisiones y exportar el resultado en el formato requerido— y guarda la referencia exacta de la imagen que produjo el resultado.

Evita que el éxito del proxy oculte un fallo de la aplicación

El navegador, el cliente de API y Etherpad deben coincidir en un mismo origen. Para conseguirlo, configura la URL pública y la compatibilidad del proxy con WebSocket. Conserva el host y el protocolo originales, y mantén el puerto 9001 fuera del alcance de cualquier dirección pública alternativa.

La guía de troubleshooting cuando el sitio está caído ayuda a distinguir entre una ruta inaccesible y una aplicación que responde. Esta distinción es importante aquí: las sesiones se desconectan porque los timeouts del proxy son demasiado cortos. Solo el primer caso se soluciona con cambios en el ingress; el segundo requiere inspeccionar los logs, el estado o la carga de trabajo de Etherpad.

Diseña la restauración de Etherpad antes del lanzamiento

Protege el estado de Etherpad antes de optimizar su contenedor. El conjunto necesario incluye la base de datos, los plugins subidos y la configuración. Monta /opt/etherpad-lite/var antes del bootstrap, escribe datos de ejemplo inocuos y reemplaza el contenedor para demostrar que esa ruta es realmente persistente. Si varios almacenes deben mantenerse coordinados, documenta el orden en que se pausan las escrituras y se realizan las copias de seguridad.

Conserva copias fuera del servidor de deployment y cifra el material que contenga credenciales o contenido privado. La recuperación es correcta cuando vuelven los pads, los autores, las revisiones y los plugins, y las ediciones simultáneas siguen convergiendo. La diferencia entre un mount persistente y una copia independiente se explica en almacenamiento persistente y snapshots.

Elige el límite de confianza de Etherpad

Cierra la ventana de bootstrap en cuanto exista el primer administrador de confianza. El riesgo concreto de Etherpad es distribuir una contraseña de administrador conocida o dejar los pads editables para cualquiera; el límite más seguro consiste en establecer una contraseña de administrador real, decidir quién puede crear pads y no asumir que una URL de pad poco evidente es privada.

Sustituye inmediatamente el valor de ejemplo de ADMIN_PASSWORD, guárdalo fuera de la imagen y rótalo como cualquier credencial de administrador si queda expuesto. La red privada debe transportar las credenciales de las dependencias, y los roles dentro de Etherpad deben conceder la acción útil mínima. Mantén fuera de los logs habituales los cuerpos de las solicitudes y las respuestas de los proveedores que contengan información sensible.

Actualiza Etherpad sin hacer suposiciones

Observa el trabajo que realiza Etherpad: sesiones de WebSocket, número de revisiones, escrituras en la base de datos y ejecución de plugins. Establece límites con margen para ese trabajo y evita una liveness probe que compita con él. La comprobación operativa debe seguir intentando abrir un pad en dos navegadores, editarlo simultáneamente, inspeccionar las revisiones y exportar el resultado en el formato requerido según una periodicidad definida.

Para las actualizaciones, recuerda que las versiones de los plugins de Etherpad, la sintaxis de configuración y las migraciones de la base de datos deben probarse conjuntamente. Despliega la versión candidata sobre una copia restaurada y repite la prueba conocida. Si las sesiones se desconectan porque los timeouts del proxy son demasiado cortos, utiliza los logs del runtime y la solicitud de red real para descubrir qué supuesto ha cambiado.

Qué debe superar las pruebas antes de que lleguen datos reales a Etherpad

Para Etherpad, define una transacción conocida como correcta antes del lanzamiento: abrir un pad en dos navegadores, editarlo simultáneamente, inspeccionar las revisiones y exportar el resultado en el formato requerido. Guarda sus prerrequisitos, la respuesta esperada y los pasos de limpieza en el control de versiones, sin valores secretos. Fija la imagen utilizada para establecer esa referencia.

Utiliza la transacción para validar un reemplazo y una restauración independiente. El servicio restaurado solo será aceptable cuando vuelvan los pads, los autores, las revisiones y los plugins, y las ediciones simultáneas sigan convergiendo. Al mismo tiempo, observa las sesiones de WebSocket, el número de revisiones, las escrituras en la base de datos y la ejecución de plugins, y convierte la parte más lenta o limitada en una alerta de nivel de servicio.

El gate también necesita un caso negativo: deniega temporalmente al identity de prueba el acceso a Postgres u otra base de datos compatible para un uso multiusuario duradero. Confirma que Etherpad produce un error accionable mientras conserva los datos, restaura la condición válida y repite la transacción conocida como correcta. Conservar ambos resultados evita que un endpoint de health superficial se convierta en la única evidencia en producción.

Despliega Etherpad en Dockup sin perder sus límites

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

Termina aplicando conocimiento de la aplicación: configura la URL pública y la compatibilidad del proxy con WebSocket; conecta y prueba Postgres u otra base de datos compatible para un uso multiusuario duradero; y ejecuta esta verificación: abre un pad en dos navegadores, edítalo simultáneamente, inspecciona las revisiones y exporta el resultado en el formato requerido. Conserva el resultado como comprobación del deployment para que la siguiente actualización de la imagen se evalúe por su comportamiento y no por el estado del contenedor.

Preguntas frecuentes

¿Qué necesita Etherpad para un deployment en producción?

Dirige el contenedor de Etherpad, que escucha en el puerto 9001, a través de un único origen HTTPS. El requisito de red de soporte es Postgres u otra base de datos compatible para un uso multiusuario duradero. No consideres Etherpad listo hasta que puedas abrir un pad en dos navegadores, editarlo simultáneamente, inspeccionar las revisiones y exportar el resultado en el formato requerido.

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

Haz persistir /opt/etherpad-lite/var e incluye la base de datos, los plugins subidos y la configuración en el mismo manifiesto de recuperación. Una restauración limpia de Etherpad solo supera la prueba cuando vuelven los pads, los autores, las revisiones y los plugins, y las ediciones simultáneas siguen convergiendo.

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

Utiliza HTTPS para el origen público de Etherpad y mantén el puerto 9001 en la ruta interna. Aplica correctamente la configuración de Etherpad: establece la URL pública y la compatibilidad del proxy con WebSocket. En Etherpad, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente que depende del origen.

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

Restaura el estado actual de Etherpad en un deployment aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención, porque las versiones de los plugins de Etherpad, la sintaxis de configuración y las migraciones de la base de datos deben probarse conjuntamente. Conserva la imagen anterior de Etherpad hasta comprender sus límites de migración de datos y rollback.