Por qué alojar Plane usted mismo en lugar de pagar por puesto
La objeción más habitual contra la imagen AIO es que el «supervisord todo en uno» oculta varios servicios internos, lo que dificulta la depuración cuando algo falla. En la práctica, la imagen agrupa cinco componentes — API Django, worker Celery, base PostgreSQL, Redis y servidor de archivos — en un único proceso supervisord, lo que simplifica drásticamente el arranque. No tiene que componer una pila multicontenedor, sincronizar las migraciones ni gestionar cinco registros Docker distintos. Ante un error, docker logs <conteneur> y docker exec <conteneur> supervisorctl status bastan en la gran mayoría de los casos. El blog oficial de Plane anuncia más de 100 000 despliegues Docker y más de 44 000 despliegues Kubernetes, lo que da una medida de la madurez operativa de la imagen. El modelo económico es claro: usted paga el VPS, no el puesto.
Lo que gana al alojar Plane en su propio VPS
- Coste fijo, independiente del tamaño del equipo — un único VPS basta para 5 a 50 usuarios; la tarifa no varía con el número de puestos.
- Datos bajo su control — tickets, comentarios, archivos y miembros del equipo permanecen en su propia base PostgreSQL, en su propio disco.
- Licencia AGPL-3.0 — uso comercial y autoalojamiento autorizados sin regalías; el código fuente es auditable.
- Issues, cycles, modules, pages e inbox — Plane cubre el seguimiento de tareas, los sprints, las agrupaciones funcionales, la documentación ligera y la gestión de las solicitudes entrantes, sin módulo aparte.
- Imagen estable y mantenida —
makeplane/plane-aio-community:stablela actualiza el editor y se prueba como unidad coherente antes de cada publicación. - Actualizaciones controladas — usted descarga la nueva imagen cuando decide hacerlo; ningún editor puede modificar su entorno de producción sin su consentimiento.
- Integración posible con su cadena de herramientas — Plane expone una API REST documentada, utilizable para sincronizar issues desde un pipeline CI o desde GitHub.
- Resolución sencilla en caso de incidente — un solo contenedor, un solo registro, un solo punto de reinicio; ninguna pila multiservicio que orquestar manualmente.
Requisitos concretos para un despliegue estable
La imagen AIO agrupa varios servicios en un único contenedor: cuente con 2 vCPU y 4 GB de RAM como mínimo para un uso en equipo. Por debajo, el worker Celery y la base PostgreSQL se reparten demasiada poca memoria y las consultas de indexación tardan varios segundos. Para un equipo de más de diez personas o un uso intensivo de las páginas y los ciclos, pase a 8 GB. Necesita Docker instalado en el host (versión 20 o superior), un nombre de dominio o un subdominio que apunte a su VPS, los puertos 80 y 443 abiertos en su cortafuegos, y unos 10 GB de espacio en disco para los volúmenes de datos y las imágenes Docker. Un certificado TLS es imprescindible: Plane define cookies de sesión con Secure, lo que las hace inutilizables sobre HTTP.
Desplegar Plane AIO en ocho pasos
Preparar el host e instalar Docker
En un VPS Debian o Ubuntu recién instalado, actualice los paquetes y luego instale Docker mediante el script oficial o los repositorios APT de Docker:
curl -fsSL https://get.docker.com | sh systemctl enable --now dockerCompruebe que Docker funciona:
docker version.Crear el directorio de trabajo y el archivo de entorno
Cree una carpeta dedicada y prepare en ella el archivo
.envmínimo:mkdir -p /opt/plane && cd /opt/planeCree después
/opt/plane/.envcon las variables requeridas:SECRET_KEY=$(openssl rand -hex 32) WEB_URL=https://plane.votre-domaine.com DATABASE_URL=postgresql://plane:[email protected]:5432/planeSECRET_KEYdebe ser una cadena aleatoria larga;WEB_URLes la URL pública final de su instancia — es el valor más crítico. Si es incorrecta, las redirecciones tras el inicio de sesión y la carga de los assets fallan.Iniciar el contenedor AIO
Arranque Plane con el siguiente comando, indicando la ruta a su archivo
.envy montando un volumen para los datos persistentes:docker run -d \ --name plane \ --restart unless-stopped \ --env-file /opt/plane/.env \ -v plane-data:/app/plane-data \ -p 127.0.0.1:8080:8080 \ makeplane/plane-aio-community:stableEl puerto
8080solo está expuesto en loopback: únicamente el reverse proxy local podrá alcanzarlo. En el primer arranque, supervisord ejecuta las migraciones Django; la interfaz no está disponible hasta pasados uno o dos minutos.Comprobar el estado de los servicios internos
Antes de configurar el reverse proxy, compruebe que todos los subprocesos están activos:
docker exec plane supervisorctl statusDebe ver los servicios
api,worker,beat,webynginxen estadoRUNNING. Si alguno está enFATAL, lea los registros condocker logs planepara identificar el error.Obtener un certificado TLS con Certbot
Instale Certbot y el plugin Nginx, y solicite después un certificado para su subdominio:
apt install -y certbot python3-certbot-nginx certbot certonly --nginx -d plane.votre-domaine.comCertbot colocará los archivos del certificado en
/etc/letsencrypt/live/plane.votre-domaine.com/.Configurar Nginx como reverse proxy HTTPS
Cree
/etc/nginx/sites-available/plane.conf:server { listen 80; server_name plane.votre-domaine.com; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name plane.votre-domaine.com; ssl_certificate /etc/letsencrypt/live/plane.votre-domaine.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/plane.votre-domaine.com/privkey.pem; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }Active el sitio y recargue Nginx:
ln -s /etc/nginx/sites-available/plane.conf /etc/nginx/sites-enabled/ nginx -t && systemctl reload nginxCrear la primera cuenta de administrador
Abra
https://plane.votre-domaine.comen un navegador. Plane muestra una página de registro en el primer acceso. Cree una cuenta de administrador y, después, desde el panel de administración — accesible en/god-mode/— active los registros por correo electrónico o configure una allowlist de dominios para limitar el acceso a su organización.Invitar al equipo y crear el primer proyecto
En Plane, un proyecto agrupa issues, cycles (sprints), modules (funcionalidades) y pages (wiki ligero). Cree un proyecto desde la interfaz e invite después a sus colaboradores por correo electrónico desde los ajustes del proyecto. Las invitaciones las envía el servidor de correo configurado en su
.envmedianteEMAIL_HOSTyEMAIL_PORT.
Configuración posinstalación: variables de entorno clave
Las variables más importantes tras el arranque inicial son:
— WEB_URL — la URL pública completa de la instancia, sin barra final. Una URL mal indicada provoca redirecciones rotas tras el inicio de sesión y assets que no se cargan (imágenes, CSS, JS). Es el error más frecuente en el primer arranque.
— SECRET_KEY — cadena secreta para la firma de las sesiones Django. No la cambie después del primer arranque sin invalidar todas las sesiones activas.
— EMAIL_HOST, EMAIL_PORT, EMAIL_HOST_USER, EMAIL_HOST_PASSWORD — necesarias para las invitaciones y las notificaciones. Sin estas variables, las invitaciones por correo electrónico no se envían.
— ENABLE_SIGNUP — 1 para permitir los registros abiertos, 0 para desactivarlos (solo el administrador puede crear cuentas).
Después de cualquier modificación del archivo .env, reinicie el contenedor: docker restart plane.
Para las actualizaciones, descargue la nueva imagen y recree después el contenedor conservando el volumen de datos:
docker pull makeplane/plane-aio-community:stable
docker stop plane && docker rm planeVuelva a ejecutar después el comando docker run del paso 3 con los mismos argumentos. Las migraciones de base de datos se aplican automáticamente en el arranque. Si una actualización rompe el entorno, vuelva a la versión anterior sustituyendo stable por el tag exacto de la imagen anterior — docker images lista las imágenes disponibles localmente.
Regresiones posteriores a 2.3.7 y actualización segura
Las versiones Plane AIO 2.3.7 a 2.4.1 introdujeron varias regresiones documentadas. Pérdida de las notificaciones en tiempo real al actualizar el servidor Python entre esas versiones. Error 500 en los webhooks salientes si la columna webhook_trigger falta en la migración PostgreSQL — síntoma: django.db.utils.ProgrammingError: column webhook_trigger does not exist en los logs del contenedor plane-backend. Ralentización de las consultas de filtro en los espacios de trabajo de más de 5000 issues (regresión de índice corregida en 2.4.2).
Antes de cualquier actualización desde una versión anterior a 2.4.2, haga una copia de seguridad de su base PostgreSQL: docker compose exec -T db pg_dump -U plane plane > plane-backup-$(date +%F).sql. Después actualice: docker compose pull && docker compose up -d. Si el backend no arranca tras la actualización, fuerce las migraciones manualmente: docker compose exec plane-backend python manage.py migrate --run-syncdb. Para las instancias en 2.3.6 o anterior, se recomienda una actualización directa a 2.4.2+ para saltar las versiones intermedias defectuosas.
Solución de problemas: errores frecuentes y sus remedios
Redirecciones rotas o assets que no se cargan tras el inicio de sesión. Mensaje tipo: la interfaz redirige a http://localhost o las imágenes y los scripts no se cargan. Causa: WEB_URL en el archivo .env no coincide con la URL pública real. Corrija el valor y reinicie después el contenedor.
Fallo de arranque de un servicio interno. Mensaje tipo en docker logs plane: FATAL: api: exited too quickly. Compruebe DATABASE_URL — una URL de conexión incorrecta o un nombre de base inexistente impide que las migraciones se ejecuten y provoca este tipo de salida con error fatal.
El panel /god-mode/ está inaccesible. El acceso a la interfaz de administración exige haber creado la primera cuenta a través de la interfaz principal y entrar después con las credenciales de esa cuenta. Si desactivó los registros antes de crear la primera cuenta, restablezca temporalmente ENABLE_SIGNUP=1, cree la cuenta y vuelva después a 0.
Los correos de invitación no se envían. Compruebe que EMAIL_HOST y EMAIL_HOST_USER están indicados en .env y que el puerto SMTP (a menudo 587 con STARTTLS o 465 con SSL) es accesible desde su VPS. Pruebe con docker exec plane python manage.py sendtestemail [email protected].
Rendimiento degradado con muchos usuarios simultáneos. Si varios workers Celery tienen dificultades para procesar las tareas, aumente la RAM del VPS antes de ajustar la concurrencia interna. La imagen AIO está configurada para un uso en equipo estándar; una configuración de carga muy alta exige pasar a una instalación multicontenedor con recursos dedicados por componente.
Mantener el control de su infraestructura sin mantener la capa de sistema
Alojar Plane usted mismo demuestra que la dependencia de las suscripciones SaaS no es una fatalidad: una imagen estable, un VPS bien dimensionado y un reverse proxy TLS bastan para un equipo de tamaño profesional. ServOrbit ofrece VPS root con IPv4 dedicada, listos en unos minutos, en los que dispone de un acceso root completo para instalar Docker y gestionar sus propias herramientas. Si desea delegar la capa de sistema — actualizaciones del kernel, endurecimiento SSH, copias de seguridad — la opción de administración VPS le permite conservar el control de sus datos externalizando el mantenimiento del host. Para ir más lejos en su práctica DevOps, consulte la guía sobre la automatización de sus servidores con Ansible y la guía Docker Compose para producción.
