---
title: "Reseña de Openship: PaaS autoalojado vs Coolify y Dokploy"
description: "Análisis práctico de Openship, la nueva plataforma de despliegue de código abierto. Instálala con la CLI o Docker Compose, compárala con Coolify y Dokploy y descubre cuándo encaja cada herramienta."
date: 2026-07-20
categories: ["self-hosting"]
tags: ["openship","self-hosted","docker"]
---
import ListCheck from "@components/widgets/ListCheck.astro";
import Notice from "@components/widgets/Notice.astro";
import Accordion from "@components/widgets/Accordion.astro";
import Tabs from "@components/widgets/Tabs.astro";
import Tab from "@components/widgets/Tab.astro";
import Button from "@components/widgets/Button.astro";
import { Picture } from "astro:assets";
import openshipUi from "@assets/images/26/07/openshipui.webp";
[Openship](https://openship.io/) 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](https://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](/es/instalar-coolify-alternativa-heroku/) y [Dokploy](/dokploy-install/). 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.
Qué hace realmente Openship y cómo funciona el flujo de despliegue
Opciones de instalación: servicio CLI, Docker Compose, app de escritorio, cloud gestionado
Comparación de funciones con Coolify y Dokploy
Quién debería probar Openship ahora y quién seguir con un panel maduro
Necesitarás un VPS Linux (o un portátil para uso local/de escritorio). [Hetzner](https://go.bitdoze.com/hetzner) y proveedores similares funcionan bien. Para más opciones de paneles, consulta los [mejores paneles de servidor autoalojados](/best-self-hosted-panels/) y [Coolify vs Dokploy vs Kamal 2](/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](/es/subidas-precios-vps/)._
## ¿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](https://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
| Área | Lo que obtienes |
| :--- | :--- |
| CI/CD | Push-to-deploy, entornos de preview, rollbacks, despliegues inmutables |
| Stacks | Node, Python, Go, Rust, PHP, Ruby, Java, .NET, Docker, monorepos |
| Datos | Postgres, MySQL, MongoDB, Redis, almacenamiento de objetos, workers |
| Redes | Dominios personalizados, wildcards, SSL automático, redes privadas |
| Operación | Logs en vivo, métricas, tareas programadas, backups |
| Correo | Correo transaccional integrado con configuración SPF/DKIM/DMARC |
| Interfaces | CLI, web, escritorio, REST, MCP |
| Licencia | Apache 2.0 |
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](https://openship.io/docs/installation):
| Componente | Mínimo | Recomendado |
| :--- | :--- | :--- |
| CPU | 2 núcleos | 4+ núcleos |
| RAM | 2 GB | 4+ GB |
| Disco | 20 GB | 50+ GB SSD |
| SO | Ubuntu 22.04+ | Ubuntu 24.04 |
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).
```bash
# 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:
```bash
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:
```bash
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.
```bash
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:
```bash
# Generate secrets
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
```
Configura al menos:
```env
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:
```bash
docker compose up -d --build
```
Servicios del archivo compose del repositorio:
| Servicio | Puerto | Rol |
| :--- | :--- | :--- |
| `postgres` | interno 5432 | BD de la plataforma |
| `redis` | interno 6379 | Cola, caché, límites de tasa |
| `api` | 4000 | Plano de control |
| `dashboard` | 3001 | UI de la app |
| `web` | 3000 | Sitio de marketing/docs |
Comprueba el estado:
```bash
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.
Los valores de `.env` de ejemplo son para pruebas locales. Cambia `POSTGRES_PASSWORD`, `BETTER_AUTH_SECRET` e `INTERNAL_TOKEN` en cualquier VPS. La API se niega a arrancar sin un `INTERNAL_TOKEN` real en despliegues que no sean de escritorio.
### Opción 3: App de escritorio
Útil para despliegues locales desde una carpeta sin montar un panel de servidor.
**Linux AppImage:**
```bash
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:
```bash
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](https://github.com/oblien/openship/releases/latest), 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](https://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:
```bash
openship login --api-url https://api.example.com --token YOUR_PAT
```
## Despliega tu primera app
Una vez que la plataforma está en marcha:
```bash
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:
```bash
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](https://openship.io/docs/first-deployment).
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](/dokploy-docker-compose-app/).
## 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
| | Openship | Coolify | Dokploy |
| :--- | :--- | :--- | :--- |
| **Madurez** | Nuevo (`0.1.x`, creciendo rápido) | Maduro (v4 estable, v5 multiservidor en progreso) | Maduro, muy activo |
| **Estrellas en GitHub (aprox.)** | ~3.6k | ~50k+ | ~30k+ |
| **Licencia** | Apache 2.0 | Apache 2.0 | Mixta (núcleo abierto, parte source-available) |
| **UI** | Web + escritorio + CLI | Panel web | Panel web |
| **Ubicación del build** | Puede compilar en tu máquina / fuera de prod | Normalmente en el servidor Coolify | Normalmente en el servidor Dokploy |
| **Proxy inverso** | OpenResty | Caddy | Traefik |
| **Consumo en reposo** | El stack Compose necesita Postgres+Redis+API+UI | ~1,5–2 GB | ~400–500 MB |
| **Plantillas de un clic** | Menos / early | 280+ | Docenas |
| **Bases de datos** | Postgres, MySQL, Mongo, Redis + herramientas | UI potente + backups | Suficiente + backups a S3/R2 |
| **Servidor de correo** | Integrado | No (trae el tuyo) | No (trae el tuyo) |
| **MCP / agentes de IA** | Sí | Sí (v4.1+) | Limitado / en evolución |
| **Opción cloud** | Openship Cloud propio + híbrido | Existe Coolify Cloud | Enfocado sobre todo al autoalojado |
| **Mejor encaje hoy** | Experimentadores que quieren CLI/escritorio/híbrido | Centro todo en uno, muchos servicios | PaaS ligero para VPS |
### 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](/coolify-vs-dokploy-vs-kamal-2/) si eso es lo que buscas.
### Desglose por funciones
- **Coolify** — la UI más rica, el mayor catálogo de servicios, el mayor consumo de RAM. Mejor cuando el panel *es* tu consola de operaciones para muchas apps. [Reseña completa de Coolify v5](/coolify-v5-self-hosted-paas-review/).
- **Dokploy** — UI limpia, poca RAM en reposo, Swarm cuando un nodo se queda pequeño. Mi opción por defecto en VPS baratos. [Guía de instalación](/dokploy-install/).
- **Openship** — CLI + escritorio + web. Se siente más cerca de un kit de despliegue productizado que de un panel de hosting puro. Mejor si vives en la terminal o quieres una GUI local sin hacer SSH a un panel.
- **Coolify / Dokploy** — webhook de git → build en el servidor → reinicio del contenedor detrás de Caddy/Traefik.
- **Openship** — conecta repo o directorio local → build (a menudo fuera del servidor) → envía la imagen por SSH → enruta vía OpenResty → rollback desde versiones inmutables.
- **Implicación** — Openship puede ahorrar a los VPS pequeños los picos de build; Coolify/Dokploy mantienen todo el ciclo en una máquina que ya gestionas.
| Necesidad | Preferir |
| :--- | :--- |
| Más de 280 apps de un clic | Coolify |
| VPS pequeño, despliegues SaaS simples | Dokploy |
| CLI + escritorio + MCP | Openship |
| Backups programados de BD a R2 | Dokploy ([guía](/dokploy-backups-cloudflare-r2/)) o Coolify |
| Correo transaccional integrado | Openship |
| Multiservidor hoy | Dokploy Swarm; multiservidor de Coolify madurando en v5 |
| Plan B de cloud gestionado | Openship Cloud o Coolify Cloud |
## Cuándo elegir cada herramienta
Quieres probar un PaaS moderno con licencia Apache, CLI y escritorio, te gusta la idea de compilar fuera del servidor de producción, o quieres un camino entre el cloud gestionado y tu propio VPS sin dos productos distintos. Bueno para proyectos secundarios, laboratorios y equipos que ya se sienten cómodos con una herramienta joven `0.1.x`.
Quieres un único panel para muchos servicios, una cobertura enorme de plantillas y una comunidad grande. Tienes al menos 4 GB de RAM (sinceramente 8 GB si apilas apps). Consulta la [instalación de Coolify](/es/instalar-coolify-alternativa-heroku/).
Quieres un panel ligero tipo Heroku en un VPS de 2 GB, soporte nativo de Compose y Swarm opcional. Sigue siendo mi recomendación por defecto para la mayoría de lectores. Empieza con la [instalación de Dokploy](/dokploy-install/).
Quieres una sobrecarga del plano de control casi nula y te va bien solo YAML + CLI. Está cubierto en la [comparación a tres bandas](/coolify-vs-dokploy-vs-kamal-2/).
## 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
Los mantenedores describen un núcleo listo para producción que aún se mueve rápido. Para apps no críticas y herramientas internas, sin duda. Para producción crítica para el negocio con un equipo de operaciones pequeño, yo haría primero una prueba piloto y mantendría Coolify o Dokploy como opción segura hasta que la línea de versiones y la documentación se asienten más.
Todavía no para la mayoría. Se solapa, pero la forma del producto es distinta (CLI/escritorio/híbrido/correo). Piensa en él como otra opción en el estante de los PaaS autoalojados, no como una ruta de actualización automática.
Eso forma parte del argumento de diseño: contenedores simples e imágenes estándar. Aun así, deberías exportar tú mismo las variables de entorno, los volúmenes y el DNS. No existe un botón mágico de «exporta toda mi empresa» que elimine el trabajo de operaciones.
CLI si quieres la instalación de servicio soportada por el proveedor y la ruta de BD embebida. Compose si quieres contenedores visibles, Postgres/Redis estándar y el mismo modelo mental que el resto de tus hosts Docker.
## Enlaces útiles
- Sitio: [openship.io](https://openship.io/)
- Documentación: [openship.io/docs](https://openship.io/docs)
- GitHub: [github.com/oblien/openship](https://github.com/oblien/openship)
- npm: [npmjs.com/package/openship](https://www.npmjs.com/package/openship)
- Relacionado en bitdoze: [instalación de Dokploy](/dokploy-install/), [instalación de Coolify](/es/instalar-coolify-alternativa-heroku/), [reseña de Coolify v5](/coolify-v5-self-hosted-paas-review/), [Coolify vs Dokploy vs Kamal](/coolify-vs-dokploy-vs-kamal-2/), [mejores paneles autoalojados](/best-self-hosted-panels/)
## 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.