Reseña de Openship: PaaS autoalojado vs Coolify y Dokploy

Openship llegó al espacio de los PaaS autoalojados con una propuesta clara: sube tu código, obtén contenedores y conserva la propiedad total. El proyecto es Apache 2.0, vive en github.com/oblien/openship y ya ronda las 3.6k estrellas en GitHub, con una opción de cloud gestionado si no quieres ejecutar tú mismo el plano de control.

Ya uso y escribo sobre Coolify y Dokploy. Ambas resuelven el problema de «quiero Heroku en mi VPS». Openship es el nuevo en ese mismo cajón, con algunas ideas lo bastante diferentes como para fijarse en ellas: los builds pueden quedar fuera del servidor de producción, hay una CLI real más una app de escritorio, el modelo híbrido cloud/autoalojado forma parte del producto e incluye un servidor de correo integrado.

Esta guía cubre qué es Openship, cómo instalarlo (CLI, Docker Compose, escritorio, cloud), cómo se compara con Coolify y Dokploy y cuándo elegiría cada uno.

Necesitarás un VPS Linux (o un portátil para uso local/de escritorio). Hetzner y proveedores similares funcionan bien. Para más opciones de paneles, consulta los mejores paneles de servidor autoalojados y Coolify vs Dokploy vs Kamal 2.

Los precios de los VPS subieron en todos los proveedores en 2026 — si estás replanteándote un servidor alquilado, mira qué cambió y cuándo gana un mini PC.

¿Qué es Openship?

Openship es una plataforma de despliegue de código abierto con CI/CD integrado. Conectas un repositorio Git (o un proyecto local), detecta el stack, compila una imagen, despliega un contenedor y configura dominios y SSL.

Puedes ejecutarlo de tres formas:

1. Openship Cloud — plano de control y cómputo gestionados; pagas por uso
2. Autoalojado — stack completo en tu máquina Linux o VPS
3. Híbrido — mezcla servicios gestionados y tus propios servidores bajo un mismo flujo de trabajo

Las interfaces son más amplias que en la mayoría de paneles autoalojados:

• CLI (openship)
• Panel web
• App de escritorio (Mac, Windows, Linux AppImage)
• API REST y MCP para agentes de IA

La documentación oficial aún califica partes del producto como early, pero el camino principal (instalar, vincular proyecto, desplegar) está documentado en openship.io/docs. La versión actual en el momento de escribir esto está en el rango 0.1.x.

Cómo despliega aplicaciones Openship

El sitio de marketing describe un flujo que conviene entender antes de instalar nada:

1. Conectar — vincula un repositorio Git y elige un destino (Openship Cloud o tu servidor vía SSH). Su argumento es que nada pesado tiene que vivir en la máquina de destino como agente/panel permanente para cada nodo.
2. Compilar — el build de la imagen puede ejecutarse en tu máquina o en la nube, y luego se etiqueta como un artefacto inmutable. Producción se dedica solo a servir tráfico.
3. Enviar — la imagen viaja al destino por SSH y arranca como contenedor en una red privada.
4. Enrutar — OpenResty + Let’s Encrypt para dominios y SSL, con cambios sin tiempo de inactividad y rollbacks de un clic.
5. Operar — logs, métricas y rollbacks desde la CLI, la UI web, el escritorio o MCP.

Ese enfoque de «compilar en otro sitio y ejecutar contenedores simples en el servidor» es el principal contraste con Coolify y Dokploy, donde el plano de control y a menudo el build residen en el mismo VPS que ejecuta tus aplicaciones.

Funciones principales

La parte del correo es inusual. Coolify y Dokploy no intentan reemplazar a SES/Mailgun por ti. Openship sí, lo cual viene bien para resets de contraseña y recibos si quieres menos cuentas de terceros. Aun así, yo trataría la entregabilidad como algo que debes verificar por tu cuenta (reputación, DNS inverso, calentamiento), no como un pase gratis.

Requisitos del sistema

Según la documentación de instalación:

Para una máquina real con varias apps, yo empezaría con 4 GB de RAM, igual que hago con Dokploy. El modo Docker Compose también ejecuta Postgres + Redis + API + panel, así que no lo dejes corto de recursos.

Instalar Openship

Elige un camino. La CLI es lo más rápido para un solo servidor. Docker Compose es mejor si quieres el stack explícito y portable. El escritorio es para trabajo local. Cloud se salta la operación por completo.

Opción 1: CLI (autoalojado más rápido)

Funciona en Linux y macOS. Instala la CLI y luego arranca Openship como servicio en segundo plano (unidad de usuario de systemd con linger en Linux, launchd en macOS).

# Install CLI
curl -fsSL https://get.openship.io | sh

# Or via a JS package manager
npm i -g openship
# pnpm add -g openship
# bun add -g openship

Arranca la plataforma:

openship up

Eso levanta la API en :4000 y el panel en :3001. La primera ejecución descarga lo que necesita. El acceso local no requiere login.

Comandos útiles:

openship open              # open dashboard
openship status            # health check
openship stop              # stop service (no auto-restart on reboot)
openship up --foreground   # run attached in this terminal
openship up --no-ui        # API only

Opción 2: Docker Compose

Usa esta opción cuando quieras Postgres, Redis, la API, el panel y la app web como contenedores normales que puedes inspeccionar y respaldar como cualquier otro.

git clone https://github.com/oblien/openship.git
cd openship
cp .env.example .env

Edita .env antes de arrancar. Como mínimo, cambia los secretos:

# Generate secrets
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

Configura al menos:

CLOUD_MODE=false
DEPLOY_MODE=docker
POSTGRES_USER=openship
POSTGRES_PASSWORD=replace-with-strong-password
POSTGRES_DB=openship
BETTER_AUTH_SECRET=replace-with-32-byte-hex
INTERNAL_TOKEN=replace-with-another-32-byte-hex
BETTER_AUTH_URL=http://YOUR_SERVER_IP:4000
OPENSHIP_REQUIRE_REDIS=true

Luego compila y arranca:

docker compose up -d --build

Servicios del archivo compose del repositorio:

Comprueba el estado:

curl -s http://127.0.0.1:4000/api/health
docker compose ps
docker compose logs -f api

Abre http://YOUR_SERVER_IP:3001 para el panel. Pon Caddy/Nginx/Traefik delante con TLS antes de exponerlo en internet público.

Opción 3: App de escritorio

Útil para despliegues locales desde una carpeta sin montar un panel de servidor.

Linux AppImage:

curl -fsSL -o Openship.AppImage \
  https://github.com/oblien/openship/releases/latest/download/Openship.AppImage
chmod +x Openship.AppImage
./Openship.AppImage

Si falta FUSE en Debian/Ubuntu:

sudo apt-get install -y libfuse2
# or:
./Openship.AppImage --appimage-extract-and-run

macOS / Windows: descarga el DMG o ZIP más reciente de GitHub releases, o ejecuta openship install una vez instalada la CLI.

Opción 4: Openship Cloud

Si quieres cero mantenimiento del plano de control:

1. Regístrate en app.openship.io
2. Conecta un repositorio
3. Despliega

Desde una máquina con la CLI, puedes apuntar a una API remota en lugar de ejecutar en local:

openship login --api-url https://api.example.com --token YOUR_PAT

Despliega tu primera app

Una vez que la plataforma está en marcha:

cd your-project
openship init      # link directory to a project
openship deploy

openship init escribe .openship/project.json para que los comandos posteriores sepan qué proyecto usar. Despliegues de preview:

openship deploy --env preview

Desde ahí añades dominios personalizados, variables de entorno y autodespliegues Git en el panel o mediante la documentación del primer despliegue.

Los stacks soportados sobre el papel incluyen Next.js, Node, Python, Go, Rust, Docker, Postgres, Redis, Rails, Laravel, Django, Bun y más. Para apps existentes con compose, Openship afirma que puedes desplegar archivos compose tal cual, la misma idea general que los despliegues Compose de Dokploy.

Openship vs Coolify vs Dokploy

Me importan menos las listas de funciones que la fricción del día a día: el impuesto de RAM, cómo se comportan los builds bajo carga, cuán dolorosos son el SSL y los rollbacks, y si el proyecto seguirá existiendo el año que viene.

Comparación rápida

Donde Openship parece fuerte

Varios clientes para el mismo backend. Coolify y Dokploy priorizan el panel. Openship trata la CLI y el escritorio como ciudadanos de primera clase, más cercano a cómo trabaja realmente mucha gente de devops. MCP encima es útil si ya manejas infra desde agentes.

Build fuera del servidor de producción. En un VPS de 2–4 GB, un build con Nixpacks/Railpack puede dejar sin memoria a la misma máquina que sirve tráfico. El modelo de Openship «compila en local o en la nube y envía la imagen» es la forma correcta para máquinas pequeñas. Kamal hace algo parecido con un registro; Openship empaqueta más plataforma alrededor.

Historia híbrida y de salida. Cloud ⇄ autoalojado sin reescribir la app es un argumento de venta real si estás cansado del lock-in estilo Vercel. Todo se despliega como contenedores normales.

Correo integrado. Es de nicho, pero si odias acoplar otro proveedor de email transaccional para un proyecto secundario, es un diferenciador.

Donde Openship es más débil hoy

Edad y ecosistema. Coolify tiene años de casos límite reportados y corregidos. Dokploy tiene un montón de plantillas compose y guías de la comunidad (incluidas varias en este sitio). La documentación de Openship aún dice que están completándola. Espera bordes rugosos.

Biblioteca de plantillas. Si quieres Plausible, Outline, n8n y compañía con un clic, Coolify sigue ganando. Dokploy es más ligero pero puedes pegar archivos compose fácilmente. Openship es más «trae tu app» que «tienda de apps para el autoalojado».

Historial operativo. Núcleo listo para producción es lo que afirman. Para una app de negocio con SLA de disponibilidad, yo seguiría poniendo primero Coolify o Dokploy hasta que Openship tenga más cicatrices de batalla públicas y un historial de versiones más largo.

La historia de recursos no es «cero sobrecarga». El modo CLI con BD embebida es más ligero que el Compose completo, pero el modo Compose es un stack multiservicio real. No es el modelo de Kamal de «casi nada en el servidor». Mira la sección de Kamal en Coolify vs Dokploy vs Kamal 2 si eso es lo que buscas.

Desglose por funciones

Cuándo elegir cada herramienta

Consejos prácticos si autoalojas Openship

1. Pon TLS delante pronto. El panel en :3001 y la API en :4000 no deberían quedar expuestos en 0.0.0.0 durante mucho tiempo.
2. Respalda los volúmenes de Postgres si usas Compose. Trata postgres_data como cualquier otro volumen con estado.
3. Fija una versión al clonar para Compose (git checkout v0.1.x) para que un git pull aleatorio no te sorprenda a mitad de semana.
4. Mantén el firewall ajustado. Solo 80/443 público si usas proxy inverso; limita SSH a claves.
5. Prueba el rollback en una app desechable antes de confiarle algo que te importe.
6. Lee las notas de seguridad del repo (SECURITY.md) y rota INTERNAL_TOKEN / los secretos de autenticación si alguna vez se filtran a logs o chats.

Preguntas frecuentes

Enlaces útiles

• Sitio: openship.io
• Documentación: openship.io/docs
• GitHub: github.com/oblien/openship
• npm: npmjs.com/package/openship
• Relacionado en bitdoze: instalación de Dokploy, instalación de Coolify, reseña de Coolify v5, Coolify vs Dokploy vs Kamal, mejores paneles autoalojados

Conclusión

Openship es una nueva entrada creíble en el espacio de los PaaS autoalojados. Lo interesante es la UX multisuperficie (CLI, escritorio, web, MCP), los builds fuera del servidor, la historia híbrida de cloud y la licencia Apache 2.0. Lo débil es lo obvio en un proyecto joven: comunidad más pequeña, ecosistema de plantillas más escaso y menos historial operativo probado a largo plazo que Coolify o Dokploy.

Si ya te gusta Dokploy en un VPS pequeño, no necesitas migrar. Si disfrutas probando nuevas herramientas de despliegue y quieres algo más cercano a un producto moderno que a un panel puro, instálalo con la CLI o el stack Compose de arriba y despliega primero una app desechable.