Openship: guía práctica para desplegar sin cargar tu servidor

Montas un VPS de 4 GB para tu último side project. Instalas una de esas plataformas de self-hosting con panel bonito, conectas el repo y en cinco minutos tienes tu web en producción. Magia.

Y a los dos días te preguntas por qué la aplicación va a trompicones cada vez que despliegas.

La respuesta es que tu servidor está haciendo tres trabajos a la vez: servir a tus usuarios, mantener un panel de control encendido y, encima, compilar tus imágenes de Docker cuando le mandas un push. Todo compitiendo por la misma RAM.

Openship parte de una idea distinta, casi contraria: que tu servidor de producción solo debería servir tu aplicación. Nada más.

En este artículo vamos a ver:

• Qué es Openship y por qué su arquitectura le da la vuelta al calcetín del self-hosting
• Por qué construir las imágenes en tu máquina cambia cómo respira tu servidor
• El camino exacto que recorre tu código desde el git push hasta estar vivo
• Cómo se instala y qué puedes tocar hoy de verdad (con un aviso importante)
• Dónde encaja frente a Coolify, Dokku y los PaaS gestionados de toda la vida

Curso gratis · paso a paso

Automatizar el despliegue está bien; dar método a lo que despliegas, mejor

El ciclo completo de Spec Driven Development con OpenSpec sobre un proyecto de juguete: propuesta, spec, diseño, tareas y archivado. Lo ves funcionar entero antes de coger tú el volante.

Entra en el curso gratis →

Qué es Openship y en qué se diferencia ¶

Openship es una plataforma de despliegue de código abierto con CI/CD integrado. Conectas un repositorio, detecta tu stack, construye la imagen, configura dominios y certificados, y la deja en marcha. Sin ficheros de configuración, sin pipelines de YAML que escribir a mano.

Hasta aquí suena a lo de siempre. Lo interesante está debajo.

La mayoría de plataformas de self-hosting montan todo su plano de control dentro de tu servidor: el panel web, el sistema de builds, el runner de CI, la base de datos de la plataforma y, además, tus aplicaciones. Todo en la misma máquina, peleándose por los mismos recursos.

Openship separa las dos cosas. Las imágenes se construyen en tu ordenador (o en su nube), y al servidor solo llega el contenedor ya cocinado, listo para arrancar. En tu VPS no se instala ni un agente, ni un daemon, ni un panel. Solo tus aplicaciones.

🔑 La idea central de Openship cabe en una frase: tu máquina construye, tu servidor sirve. Nunca las dos cosas en el mismo sitio.

Es un proyecto joven —lo mantiene Oblien LLC y su repositorio oblien/openship ronda las 28 estrellas en el momento de escribir esto—, con licencia AGPL-3.0 y escrito casi por completo en TypeScript (un 94,7% del código, según el propio GitHub). Va en la misma corriente que las forjas open source que puedes alojar tú mismo: recuperar el control de las piezas que sostienen tu trabajo. Guárdate ese dato de las estrellas, porque más abajo hablaremos con honestidad de en qué punto está.

Por qué tu servidor no debería construir tus imágenes ¶

Piénsalo como una cocina de restaurante.

Puedes tener al mismo cocinero pelando patatas, montando los platos y sacándolos a las mesas. Funciona cuando hay cuatro comensales. En cuanto se llena el comedor, el servicio se cae.

O puedes preparar el grueso en una cocina aparte y que la sala solo se dedique a servir lo que ya está listo. Eso es exactamente lo que hace Openship con tus despliegues.

Cuando una plataforma construye la imagen en el servidor de producción, ese proceso consume CPU, RAM y disco justo mientras tu aplicación intenta responder peticiones. Un npm run build de un proyecto grande puede tumbar un VPS modesto durante minutos. Y si además ese mismo servidor aloja el panel de la plataforma y su base de datos interna, la cuenta de recursos se dispara antes de que hayas desplegado nada tuyo.

El modelo de Openship saca la compilación fuera. En tu máquina se genera la imagen, se etiqueta como un artefacto inmutable y versionado, y solo entonces viaja al servidor por SSH para arrancar como un contenedor nuevo. Tu producción no se entera del esfuerzo de build: recibe el resultado ya hecho.

Si vienes del mundo de los PaaS con panel, esto te sonará a la filosofía de Coolify que ya vimos en Web Reactiva, pero con una diferencia de fondo: allí el control vive en tu servidor; aquí, en tu escritorio.

¿Y si prefieres que los builds corran en el servidor de todas formas? Se puede. Es un flag de configuración, no una religión. Openship te deja elegir, pero por defecto apuesta por dejar la producción limpia.

Cómo va del git push a producción ¶

Aquí es donde la teoría se vuelve práctica. Openship describe cinco pasos, y merece la pena entenderlos porque explican por qué no hay cajas negras en el camino.

1. Connect. Enlazas un repositorio de Git y eliges un destino: la nube de Openship o tu propio servidor por SSH. En tu máquina destino no se instala nada.
2. Build. En cada push, la imagen se construye en tu equipo (o en la nube), se ejecutan tus tests y se etiqueta como artefacto versionado. Tu servidor de producción sigue a lo suyo.
3. Ship. La imagen ya construida viaja al destino por SSH y arranca como un contenedor fresco en una red privada aislada. Sin puertos expuestos, sin escribir Docker o Compose a mano.
4. Route. Tus dominios se cablean a través de OpenResty con SSL automático de Let’s Encrypt, y el tráfico cambia al nuevo contenedor sin cortes. La versión anterior se queda lista por si hay que volver atrás.
5. Operate. Ves los logs en directo, vigilas las métricas y puedes volver a cualquier versión anterior con un clic desde la CLI, el panel web, la app de escritorio o un agente de IA por MCP.

Fíjate en el detalle del paso 4: el cambio de tráfico se hace sin downtime y con la versión previa en la recámara. Eso significa que un rollback no es una operación de riesgo con las manos temblando en la terminal a las tres de la madrugada. Es un botón.

💡 Cada despliegue es una foto inmutable. Volver a la versión de ayer no reconstruye nada: solo apunta el tráfico al contenedor que ya estaba ahí.

Y como los contenedores son estándar (Docker, OCI), no hay un formato propietario que te ate. Si mañana quieres llevarte tus aplicaciones a otro sitio, son imágenes normales.

Ese paso 5 esconde algo que a quienes trabajamos con agentes nos interesa: cualquiera de esas operaciones se puede disparar desde un agente de IA por MCP. Si nunca has montado un servidor MCP, tenemos una guía paso a paso para instalarlo en Claude Code, Copilot y compañía, y un mapa de los protocolos que están definiendo la IA generativa para programar. Volvemos a ello más abajo con un ejemplo de configuración.

Instalación: lo que puedes tocar hoy ¶

La vía rápida son dos líneas en tu terminal:

# Instala la CLI de forma global e inicializa el proyecto
npm i -g openship
openship init

Si prefieres Docker, el patrón es el clásico de clonar, copiar el .env y levantar el compose:

# Clona, prepara el entorno y arranca con Docker Compose
git clone https://github.com/oblien/openship.git && cd openship
cp .env.example .env
docker compose up -d

Y si eres de interfaz gráfica, hay una app de escritorio nativa para Mac y Windows que te descargas desde openship.io.

Una vez dentro, la CLI cubre lo que esperarías del día a día:

openship deploy          # despliega la versión actual
openship logs --follow   # sigue los logs en directo
openship rollback        # vuelve a la versión anterior
openship domains         # gestiona dominios y SSL

Ahora la parte honesta, porque en Web Reactiva no vendemos humo.

Openship es un proyecto muy temprano. Su repositorio no tiene releases publicadas todavía, ronda medio centenar de commits y cero forks en el momento de escribir. La web oficial promete 42 capacidades repartidas en siete bloques; el repositorio es pequeño y está en plena ebullición. Esa distancia entre el escaparate y el código es normal en un producto que acaba de salir, pero conviene tenerla presente antes de meterlo en algo serio.

Hay además un detalle que verás con tus propios ojos: la documentación mezcla dos rutas de GitHub. El comando de instalación clona github.com/openship/openship, mientras que el repositorio real vive en oblien/openship. Comprueba la ruta antes de clonar, no vaya a ser que te quedes esperando en una que no existe.

⚠️ Antes de poner tu producción en manos de Openship: es software joven, sin releases publicadas y con una comunidad todavía pequeña. Genial para experimentar y para side projects; con cabeza para lo crítico.

Despliega tu primer proyecto paso a paso ¶

Vamos a lo concreto. Estos son los pasos para llevar una aplicación (pongamos un Next.js o una API de Node) desde tu portátil a un VPS tuyo, sin instalar nada raro en el servidor.

1. Ten a mano un servidor Linux con acceso SSH. Cualquiera vale: Hetzner, DigitalOcean, un homelab. No hace falta preinstalar Docker ni paneles: la imagen llega ya construida y arranca sola.

2. Instala la CLI en tu máquina y arranca el proyecto desde la raíz del repositorio:

# En tu ordenador, no en el servidor
npm i -g openship
openship init

3. Conecta el repositorio y elige destino durante el init: tu servidor por SSH o la nube de Openship. Aquí decides dónde vivirá la aplicación.

4. Lanza el primer despliegue. Openship detecta el stack, construye la imagen en tu equipo y envía el contenedor al destino:

openship deploy

5. Cablea tu dominio y el SSL. Los certificados de Let’s Encrypt se generan y renuevan sin que tú toques Nginx a mano:

openship domains

6. Vigila el arranque en directo. Si algo no cuadra, lo ves en el momento, no cinco minutos después por email:

openship logs --follow

7. ¿Se rompió algo tras el deploy? Vuelves a la versión buena sin reconstruir nada:

openship rollback

Fíjate en un detalle práctico: en ningún paso has escrito un Dockerfile ni un docker-compose.yml. Si ya tienes uno, Openship despliega tu Compose tal cual; si no lo tienes, no lo necesitas. Esa es buena parte de la promesa de “zero config”.

💡 La prueba de fuego: cronometra un deploy con carga real en el servidor mientras haces openship logs --follow. Si la app no se resiente durante el build, el modelo de construcción local está haciendo su trabajo.

El deploy es solo el principio

Y cuando ese primer despliegue ya está vivo, empieza lo interesante

Te llevas el flujo real de una webapp construida 100% con IA: las cuatro preguntas que disparan el modo plan, por qué desplegar pronto salva el proyecto y la cagada que se pagó en producción cuando la IA duplicó suscripciones en Stripe.

Destripar el caso real →

Audio premium · incluido en la suscripción Web Reactiva Premium

Las tres interfaces (y la cuarta que nos importa) ¶

Openship se maneja desde tres sitios con el mismo backend detrás:

• App de escritorio. GUI completa, logs en tiempo real, todo a un clic. Nativa en Mac y Windows.
• Panel web. La misma interfaz en el navegador, pensada para equipos.
• CLI. Un único binario, guionizable y amigable con CI.

Pero hay una cuarta vía que a quienes ya trabajamos con agentes nos interesa especialmente: Openship expone una API REST y un servidor MCP.

MCP es el Model Context Protocol, el estándar abierto que Anthropic presentó en noviembre de 2024 para que los agentes de IA se conecten con herramientas externas. Su adopción ha sido rápida: según PulseMCP, el registro de servidores MCP ya supera las 10.000 entradas. Que Openship publique el suyo significa que se suma a ese ecosistema en vez de inventarse una integración propia.

¿Qué significa esto en la práctica? Que puedes pedirle a Claude o a Cursor que despliegue, que te traiga los logs o que haga un rollback, y el agente lo ejecuta contra Openship con herramientas estándar y autenticadas. Un cliente MCP se configura con un bloque como este (los valores exactos del comando los da la documentación de Openship):

{
  "mcpServers": {
    "openship": {
      // Comando y argumentos exactos: consúltalos en openship.io/docs
      "command": "openship",
      "args": ["mcp"]
    }
  }
}

Con eso, tu asistente ve las tools de despliegue y las invoca cuando se lo pides. El despliegue deja de ser una pestaña más y pasa a ser algo que tu agente puede pilotar de principio a fin: escribe el código, lo prueba y lo manda a producción sin que tú cambies de ventana. Si te interesa hasta dónde llega esa idea de darle a un agente las llaves de una máquina entera, hace poco analizamos un ordenador en la nube con IA persistente que empuja el concepto todavía más lejos.

Openship frente a Coolify, Dokku y los gestionados ¶

No hay herramienta mejor en abstracto. Hay una que encaja mejor con lo que estás construyendo. Esta tabla resume dónde se sitúa cada opción, según la comparación que hace la propia web de Openship.

La lectura honesta: si quieres cero mantenimiento y no te importa pagar por comodidad, un gestionado como Vercel te lo pone fácil —y si estás en esa fase, tienes doce hostings gratuitos donde publicar sin tarjeta para salir del paso. Si ya vives cómodo con Coolify o Dokku y te va bien que el panel viva en el servidor, no hay urgencia por cambiar. Openship brilla cuando quieres poseer tu infraestructura sin sacrificar la comodidad del push-to-deploy, y cuando te molesta que la producción cargue con el peso del build.

Ese es su hueco. Ni mata a Vercel, ni entierra a Coolify. Ocupa un punto intermedio con una decisión arquitectónica clara.

Qué te da la plataforma y qué es promesa ¶

Aquí toca separar el grano de la paja, porque el escaparate de una web y el estado real de un repositorio joven no siempre van del brazo.

El núcleo que la propia gente de Openship declara como listo para producción incluye lo esencial de un PaaS moderno: push-to-deploy, entornos de preview por cada pull request, rollbacks inmutables, detección automática del stack (Node, Python, Go, Rust, PHP, Ruby, Java, .NET, Docker, monorepos), dominios ilimitados con SSL de Let’s Encrypt y despliegues sin downtime.

Por encima de eso, la web lista un catálogo ambicioso agrupado en bloques como Deploy, Run, Connect, Services, Manage, Secure y Collaborate. Entre las piezas que más llaman la atención:

• Un servidor de correo transaccional desde tu propio dominio, con SPF, DKIM y DMARC configurados por ti. Adiós a la factura de Sendgrid, si cumple lo que promete.
• CDN con aceleración de assets estáticos e invalidación de caché en cada despliegue.
• Backups programados de bases de datos y volúmenes, con restauración a un clic.
• Bases de datos gestionadas: PostgreSQL (versiones 14 a 17), Redis, MongoDB y MySQL.
• Un vault de secretos cifrado en reposo y rotable sin necesidad de volver a desplegar.

Y una decisión que a muchos nos gustará: la telemetría está desactivada por defecto. Te espía cero salvo que tú decidas activarla para ayudar a mejorar la plataforma.

🛡️ Trata el catálogo largo como una hoja de ruta, no como un contrato. El núcleo de despliegue es lo que puedes tocar hoy; funciones como el clúster multinodo o el editor visual de pipelines figuran como lo que viene después.

La otra pata interesante es la portabilidad entre modos. Puedes tener todo en la nube de Openship, todo en tus servidores, o en híbrido: la nube para los picos, tus máquinas para los datos sensibles. Y, según ellos, moverte de un lado a otro es cuestión de un clic, sin reconstruir nada, porque tus aplicaciones son contenedores normales. Si eso se cumple en la práctica, es de las mejores defensas contra el lock-in que puede ofrecer una plataforma de este tipo.

Cuándo tiene sentido probarlo ¶

Vamos a ser prácticos y sin medias tintas.

Dale una oportunidad si eres un desarrollador solo que despliega side projects y te apetece un flujo tipo Vercel pero en tu propio VPS de Hetzner o DigitalOcean. También si trabajas en un equipo pequeño que valora poseer su infraestructura y te seduce la idea de pilotar despliegues desde un agente de IA por MCP. Y desde luego si te pica la curiosidad de un proyecto open source en sus primeros pasos, donde tu feedback y tus issues pesan de verdad.

Piénsatelo dos veces si necesitas meter mañana una carga crítica en producción con SLA de por medio. La ausencia de releases publicadas y una comunidad todavía pequeña son señales de que el proyecto está madurando. Para eso, hoy, una plataforma con más rodaje te dará noches más tranquilas.

La forma sensata de acercarse: monta un VPS barato, despliega algo tuyo que no te quite el sueño si se rompe, y comprueba con tus propios ojos si el modelo de build local te ahorra los dolores de cabeza que promete. Es la única manera de saber si encaja con tu forma de trabajar.

Porque al final, la pregunta no es si Openship es la plataforma definitiva. Es si mereces un servidor de producción que solo se dedique a lo suyo. Y a esa, creo, ya sabes responder.

TL;DR ¶

• 🚀 Openship es una plataforma de despliegue open source (AGPL-3) que construye las imágenes en tu máquina y envía solo contenedores al servidor.
• 🧹 Su gran diferencia frente a Coolify o Dokku: no instala panel ni agente en tu VPS, así que tu producción solo sirve tus apps.
• 🔁 El flujo va de git push a producción en cinco pasos, con despliegues sin downtime y rollbacks inmutables a un clic.
• 🤖 Expone API REST y servidor MCP, así que puedes desplegar y hacer rollback desde un agente de IA como Claude o Cursor.
• ⚠️ Es un proyecto muy joven (unas 28 estrellas, sin releases publicadas): ideal para experimentar y side projects, con cabeza para lo crítico.

Preguntas frecuentes ¶

¿Qué es Openship?

Openship es una plataforma de despliegue de código abierto con CI/CD integrado, licenciada bajo AGPL-3.0 y mantenida por Oblien LLC. Conectas un repositorio, detecta tu stack, construye la imagen y la despliega en la nube de Openship o en tu propio servidor Linux, sin ficheros de configuración ni pipelines de YAML.

¿En qué se diferencia Openship de Coolify?

La diferencia clave es dónde se construye la imagen. Coolify monta su panel de control, el sistema de builds y la base de datos dentro de tu servidor. Openship construye en tu máquina (o en su nube) y envía al servidor solo el contenedor ya hecho, dejando la producción libre para servir tus aplicaciones.

¿Necesito escribir ficheros Docker o YAML para usar Openship?

No. Openship detecta el stack de forma automática (Node, Python, Go, Rust, PHP, Ruby, Java, .NET, Docker y monorepos) y configura build, dominios y certificados sin que tengas que escribir Dockerfiles ni pipelines a mano. Aun así, puede desplegar ficheros Docker Compose existentes tal cual si ya los tienes.

¿Puedo usar Openship en mi propio VPS?

Sí. Funciona sobre cualquier servidor Linux al que tengas acceso SSH: Hetzner, DigitalOcean, Linode, OVH, bare metal o incluso un homelab. La imagen viaja al servidor por SSH y arranca en una red privada aislada, sin puertos expuestos.

¿Openship es gratis?

El proyecto es open source bajo AGPL-3.0 y puedes levantar toda la plataforma en tus servidores sin límites de uso ni telemetría. Existe además una modalidad de nube gestionada (Openship Cloud) donde pagas por cómputo y ancho de banda.

¿Cómo se instala Openship?

La vía rápida es npm i -g openship seguido de openship init. También puedes levantarlo con Docker Compose clonando el repositorio y ejecutando docker compose up -d, o descargar la app de escritorio para Mac y Windows desde openship.io.

¿Openship soporta agentes de IA?

Sí. Expone un servidor MCP (Model Context Protocol) además de una API REST, de modo que agentes como Claude o Cursor pueden lanzar despliegues, consultar logs o hacer rollbacks mediante herramientas estándar y autenticadas.

¿Qué pasa con los rollbacks en Openship?

Cada despliegue se guarda como un artefacto inmutable y versionado. Volver a una versión anterior es apuntar el tráfico al contenedor que ya estaba listo, sin reconstruir nada y sin downtime. Se hace con un clic desde la CLI, el panel web, la app de escritorio o un agente por MCP.

¿Está Openship listo para producción?

Su núcleo de despliegue se declara listo para producción, pero el proyecto es muy joven: sin releases publicadas, con una comunidad todavía pequeña y un catálogo amplio del que parte figura como hoja de ruta. Es una buena opción para side projects y experimentación; para cargas críticas, conviene evaluarlo con cautela.

¿Openship evita el vendor lock-in?

En buena medida, sí. Tus aplicaciones son contenedores Docker estándar y tus servicios son imágenes normales, así que puedes moverte entre la nube de Openship y tus propios servidores sin reescribir ni reconstruir. La licencia AGPL-3.0 permite además forkear y auditar todo el código.

Fuentes ¶

• oblien, “Openship: Self-hosted deployment platform” (README en GitHub)
• Openship, “Deploy Anything. Own Everything.” (web oficial)
• Anthropic, “Introducing the Model Context Protocol”

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter