Desplegar Plane en VPS: guía y regresiones post-2.3.7

Una herramienta de seguimiento de tickets concentra lo más locuaz de un equipo: decisiones, archivos adjuntos, nombres de clientes, plazos. Alojarla en su VPS traslada el coste del número de puestos a la capacidad del servidor: usted paga recursos, no usuarios. Plane supera las 61 000 estrellas en GitHub, su código se publica bajo AGPL-3.0 y el editor anuncia en su blog más de 100 000 despliegues con Docker y más de 44 000 con Kubernetes, lo que da una idea de la base instalada y de la cantidad de experiencia pública disponible.

Hay una contrapartida que conviene conocer antes de empezar. La pila Community incluye varios servicios: interfaz web, API, workers, servidor en tiempo real, base de datos PostgreSQL, caché Valkey, cola de mensajes RabbitMQ, almacenamiento de objetos compatible con S3 y proxy inverso. El instalador oficial los orquesta con Docker Compose, pero usted sigue siendo responsable de las copias de seguridad, las actualizaciones y el estado del almacenamiento de objetos. Las secciones siguientes detallan cada punto, distinguiendo lo que los mantenedores han confirmado de lo que solo han informado los usuarios.

La documentación de Plane indica 2 núcleos y 4 GB de RAM como mínimo, con 8 GB recomendados en producción. Cuente con 2 vCPU y 8 GB de RAM si el equipo supera la decena de personas o si usa mucho las páginas y los ciclos: PostgreSQL, RabbitMQ, los workers y la API comparten la misma máquina. Prevea 20 GB de disco o más: las imágenes de Docker y la base pesan poco al principio, son los archivos subidos los que hacen crecer el volumen uploads.

Necesita un Docker reciente con el plugin Compose (el script llama a docker compose), un nombre de dominio o subdominio cuyo registro A apunte al VPS y los puertos 80 y 443 abiertos. Un certificado TLS es indispensable en producción: sin HTTPS, contraseñas y sesiones circulan en claro.

WEB_URL y CORS_ALLOWED_ORIGINS: la documentación pide fijar ambas a la dirección que realmente usa el navegador. Es la primera comprobación si el comportamiento es extraño tras iniciar sesión.

LISTEN_HTTP_PORT y LISTEN_HTTPS_PORT: puertos publicados por el proxy integrado, 80 y 443 por defecto. Cámbielos si Nginx ya ocupa los puertos estándar.

TRUSTED_PROXIES y NUM_PROXIES: determinan la dirección IP del cliente que ve la API y, por tanto, la limitación de tasa. Detrás de su propio proxy inverso, el README del instalador pide aumentar NUM_PROXIES en una unidad por salto adicional; si se deja vacío, se aplica el comportamiento por defecto.

UNSPLASH_ACCESS_KEY: opcional, alimenta el selector de imágenes de portada. Déjela vacía si no usa Unsplash; es el primer ajuste que hay que revisar ante un bucle de redirección, descrito más abajo.

APP_RELEASE: la versión seguida, stable al principio. El script la resuelve a un número de versión durante la instalación y en cada actualización.

Detenga la pila con la opción 3 antes de modificar plane.env y reinicie con la opción 4.

Síntoma. En una instalación nueva o en una actualización, la descarga de imágenes falla en el servicio de almacenamiento con el mensaje pull access denied for minio/minio, repository does not exist or may require 'docker login'. El registro responde 401 en lugar de 404 a un cliente anónimo, de ahí que el mensaje parezca un problema de credenciales: ningún docker login cambia nada.

Confirmado por el equipo de Plane. La organización minio ha desaparecido de Docker Hub. La PR #9829, fusionada en septiembre de 2026, lo constata y cambia las imágenes a quay.io. Las notas de la versión v1.4.3 precisan después que el almacenamiento de objetos integrado usa la imagen pgsty/silo, fijada a una etiqueta de versión en lugar de latest. Un colaborador del repositorio indicó además en el ticket #9834, abierto en septiembre de 2026, que la versión se había actualizado con otra imagen.

Solo informado por usuarios. La solución provisional con quay.io/minio/minio funcionó para algunos y, después, varios participantes informaron de errores 401 en ese registro a partir del 24 de septiembre de 2026. Esos mensajes son anteriores a la corrección de la versión; no los aplique a una instalación reciente.

Qué hacer. En una instalación nueva, use el script de la última versión y compruebe con grep -n 'image:' plane-app/docker-compose.yaml que ninguna línea cita minio/minio. En una instalación existente que aún la cita, haga una copia de seguridad y ejecute la opción 5 del script. Para producción, la propia PR #9829 recomienda preferir un almacenamiento S3 externo al MinIO integrado, cuya rama comunitaria está congelada aguas arriba según su autor: es una orientación del equipo de Plane, no una garantía.

En marzo de 2026, un usuario abrió el ticket #8708 para describir una instalación difícil. Tras pasar de la versión 2.3.3 a la 2.3.7, los permisos de los archivos subidos estaban rotos; un volumen declarado con comillas simples en un archivo de la imagen AIO se interpretaba mal; y el primer botón propuesto al administrador llevaba a /god-mode sin barra final, una página que se quedaba bloqueada.

Lo que los mantenedores confirmaron cabe en una frase: la versión 2.3.7 no es una versión oficial, se produjo para un cliente concreto y la 2.4.0 resuelve el problema. No confirmaron ninguna de las tres anomalías. El autor respondió que el defecto de las comillas persistía en el Dockerfile y el ticket se cerró sin corrección asociada.

Retenga tres consignas. Instale solo versiones publicadas en la página Releases del repositorio, cuya última es v1.4.3; no descargue una versión intermedia. Haga una copia de seguridad antes de cada actualización de versión. Tras actualizar, abra un adjunto antiguo y uno reciente: si la apertura falla, inspeccione los permisos del volumen de uploads con docker volume inspect antes de modificar nada, con la copia de seguridad a mano.

Síntoma (ticket #6694, abierto en marzo de 2025 y aún abierto el 24 de octubre de 2026). Detrás de un nombre de dominio, abrir https://your-domain.com/profile/ redirige a https://your-domain.com/?next_path=/profile/ y la página entra en bucle. En el registro de la API del autor, casi todas las peticiones responden 200, salvo una que reaparece en cada vuelta: GET /api/unsplash/?query= HTTP/1.1" 401, seguida de Unauthorized: /api/unsplash/.

Establecido. El autor usaba Docker Compose con un Nginx externo delante de Plane. Los mantenedores preguntaron por el modo de despliegue y luego por la presencia de un proxy inverso, y respondieron en marzo de 2025 que estaban investigando. No han publicado ninguna causa.

Informado. En julio de 2026, un participante encontró el mismo síntoma: había introducido la clave secreta de Unsplash en lugar de la clave de acceso en UNSPLASH_ACCESS_KEY. Una PR propuesta por un colaborador externo, la #10108, aún abierta el 31 de octubre de 2026, plantea la explicación: la API devuelve tal cual el 401 de Unsplash y la aplicación web trata cualquier 401 como una sesión caducada, de ahí la redirección; propone responder 502 en su lugar. Es una hipótesis de colaborador, respaldada por un solo testimonio, no una constatación de los mantenedores, y no cubre necesariamente todos los bucles de redirección.

Qué hacer, por orden. Primero, busque la línea en el registro: docker compose -f plane-app/docker-compose.yaml --env-file plane-app/plane.env logs api | grep unsplash. Si no aparece, su bucle tiene otra causa: revise WEB_URL y CORS_ALLOWED_ORIGINS. Si aparece con un 401, revise UNSPLASH_ACCESS_KEY en plane.env y en la sección Images del panel /god-mode/: hace falta la clave de acceso (Access Key), no la clave secreta. Si no usa Unsplash, vacíe el valor y reinicie la pila; según la PR, una clave ausente devuelve una lista vacía sin error.

Redirecciones a http://localhost o recursos que no cargan. WEB_URL y CORS_ALLOWED_ORIGINS no coinciden con la dirección pública. Corrija ambas y después detenga y reinicie la pila.

pull access denied for minio/minio. Vea la sección sobre el almacenamiento de objetos: pase a una versión reciente con la opción 5 del script.

502 Bad Gateway devuelto por Nginx. El proxy integrado no escucha en el puerto previsto. Compare LISTEN_HTTP_PORT en plane.env con el destino de proxy_pass y pruebe curl -I http://127.0.0.1:8080 desde el VPS. Si la respuesta tarda, docker compose -f plane-app/docker-compose.yaml --env-file plane-app/plane.env ps muestra qué contenedor se reinicia en bucle.

Los correos de invitación no salen. Indique el servidor SMTP en los ajustes de correo de la instancia, desde /god-mode/, y envíe una invitación de prueba. Compruebe también que el proveedor no filtre el puerto SMTP de salida.

Lentitud con muchos usuarios. Observe docker stats: si la memoria está saturada, aumente la RAM antes de cualquier otro ajuste y plantéese después sacar PostgreSQL y el almacenamiento de objetos del VPS.

Alojar Plane usted mismo demuestra que la dependencia de las suscripciones SaaS no es una fatalidad: el instalador oficial, un VPS bien dimensionado y un proxy inverso TLS bastan para un equipo de tamaño profesional. ServOrbit ofrece VPS root con IPv4 dedicada, listos en pocos minutos, en los que tiene acceso root completo para instalar Docker y gestionar sus propias herramientas. Si desea delegar la capa de sistema — actualizaciones del kernel, refuerzo de SSH, copias de seguridad —, la opción de administración del VPS le permite conservar el control de sus datos y externalizar el mantenimiento del host. Para profundizar en su práctica DevOps, consulte la guía sobre la automatización de sus servidores con Ansible y la guía de Docker Compose para producción.