Dokploy: Instala tu propio PaaS de código abierto y despliega aplicaciones en tu VPS

Dokploy: el PaaS de código abierto que puedes instalar en tu propio VPS

Si alguna vez has desplegado en Vercel, Netlify o Heroku, sabes lo cómodo que es pulsar “deploy” y que todo funcione: build, SSL, dominios. Pero también conoces sus límites: costes por uso, límites de ancho de banda y control limitado sobre la infraestructura. Dokploy propone lo mejor de ambos mundos: la experiencia de un PaaS, pero instalada en tu propio servidor y con código abierto.

¿Por qué elegir Dokploy en lugar de un PaaS comercial?

Dokploy no quiere inventar la rueda: ya existe Docker, ya existe Traefik. Lo que aporta es centralizar y automatizar todo lo que rodea al despliegue para que tú te centres en el código. Sus ventajas principales:

• Eficiencia: elimina la configuración manual del servidor. Crear un proyecto, conectar Git y publicar tu aplicación lleva minutos, no horas.
• Autonomía: al ser self-hosted no dependes de los límites ni del coste de las plataformas PaaS comerciales. Pagas tu VPS y nada más.
• Resiliencia: Docker Swarm y Traefik proporcionan un entorno robusto y seguro, con tráfico gestionado y certificados SSL automáticos.
• Escalabilidad: agrupa servicios por proyecto y entorno, y monitoriza recursos de forma centralizada, facilitando el crecimiento de tu aplicación.

Cómo funciona Dokploy por dentro: Docker Swarm y Traefik

Bajo el capó, Dokploy combina dos piezas tecnológicas clave:

• Docker Swarm actúa como el orquestador que gestiona los contenedores de tus aplicaciones: los crea, los mantiene funcionando y los replica cuando hace falta.
• Traefik actúa como el proxy inverso: recibe el tráfico de internet y lo enruta al contenedor correcto según el dominio solicitado, renovando los certificados SSL automáticamente.

En la práctica, cuando añades un dominio a una aplicación, Dokploy se encarga de que Traefik lo atienda y emita el certificado Let’s Encrypt. No tocas Nginx ni gestionas certificados a mano.

Requisitos previos para instalar Dokploy

Antes de empezar, asegúrate de tener:

1. Un servidor VPS: cualquier proveedor (Hetzner, AWS, DigitalOcean, etc.) con Ubuntu instalado.
2. Un nombre de dominio: es obligatorio para poder emitir certificados SSL y servir tu aplicación por HTTPS.
3. Puertos habilitados: el servidor debe tener abiertos los puertos 80 (HTTP), 443 (HTTPS) y 3000 (panel de administración de Dokploy).

Nota: el puerto 3000 sirve para el panel en los primeros pasos; una vez configures tu dominio (por ejemplo dokploy.tudominio.com), podrás acceder a Dokploy por HTTPS en la misma zona del sitio, igual que a cualquier otra aplicación.

Instalación de Dokploy paso a paso

Paso 1: Accede al VPS por SSH

Después de crear el servidor en tu proveedor, conéctate desde tu terminal local:

ssh root@IP_DEL_SERVIDOR

Paso 2: Ejecuta el script oficial de instalación

Dokploy simplifica la puesta en marcha con un script automatizado que instala Docker, Docker Swarm, Traefik y todas las dependencias necesarias:

sudo curl -sSL https://dokploy.com/install.sh | sh

Este script configura automáticamente la red interna (dokploy-network) y deja el entorno listo para desplegar tus servicios. Solo tienes que esperar a que termine.

Paso 3: Primer acceso al panel

Cuando la instalación finalice, abre el panel de administración en tu navegador:

http://IP_DEL_SERVIDOR:3000

Ahí deberás registrar tu cuenta de administrador. A partir de ese momento ya tienes tu propio PaaS funcionando en tu VPS.

Gestión de proyectos en Dokploy: qué hace realmente la plataforma

Dokploy se coloca encima de Docker para simplificar el despliegue y la administración de aplicaciones. Sin él, tendríamos que gestionar a mano toda esta cadena:

Código
  ↓
Git
  ↓
Docker build
  ↓
Docker container
  ↓
Red
  ↓
Nginx / Traefik
  ↓
HTTPS
  ↓
Logs
  ↓
Reinicios
  ↓
Variables de entorno
  ↓
Actualizaciones

Dokploy centraliza ese proceso en una sola interfaz: se encarga del build (crear la imagen), del deploy (desplegar el contenedor) y del manage (logs, red, dominios, variables de entorno, backups y monitorización).

Importante: Dokploy no sustituye a Docker. Lo utiliza como una de sus piezas fundamentales; entender esa relación te ahorrará sorpresas al depurar problemas.

La jerarquía: Proyecto → Entorno → Servicio

Uno de los conceptos que más conviene interiorizar es cómo organiza Dokploy los recursos:

Dokploy
   │
   └── Proyecto
          │
          └── Entorno
                 │
                 ├── Aplicación
                 ├── Aplicación
                 ├── Base de datos
                 └── Docker Compose

• Proyecto: es la agrupación lógica de nivel superior para separar tus aplicaciones, clientes o grandes iniciativas. Puedes tener un proyecto “E-commerce” y otro “Blog Personal”.
• Entorno: dentro de cada proyecto aísla las fases del ciclo de vida del software. Por defecto ofrece entornos típicos como Production, Staging y Development.
• Servicio: cualquier recurso que necesita tu aplicación para funcionar. Puedes desplegar Aplicaciones (Node.js, Python, PHP, contenedores Docker puros) y Bases de datos (PostgreSQL, MySQL, MongoDB, Redis, MariaDB).

Un ejemplo real de un proyecto de tienda online:

Mi tienda online
│
└── Production
    │
    ├── Frontend
    ├── Backend
    ├── PostgreSQL
    └── Redis

Un servicio representa una unidad que Dokploy sabe desplegar y administrar. No es solo un contenedor de Docker: puede ser un conjunto de contenedores.

Vincular Git con Dokploy para despliegue automatizado

Antes de desplegar código desde un repositorio, debes conectar tu cuenta de Git a Dokploy:

1. Ve al apartado de Proveedores de Git (Git Providers) y selecciona tu proveedor (por ejemplo, GitHub).
2. Cuando crees una GitHub App para Dokploy, estarás levantando un puente oficial y seguro entre tu servidor y GitHub: Dokploy podrá leer tus repositorios y enterarse de cuándo hay código nuevo para actualizar tus aplicaciones de forma automática.
3. Una vez creada la app, verás una etiqueta de “Action Required”. Pulsa el icono que aparece a su lado; esto te redirige a GitHub para instalar y autorizar la aplicación correctamente.

Recomendación de seguridad: no des acceso a todos los repositorios. Selecciona únicamente los que necesites desplegar (Only select repositories). Si en el futuro necesitas más proyectos, edita los permisos de la app instalada desde tu cuenta de GitHub (en Installed GitHub Apps).

Desplegar una aplicación con el servicio Application

El servicio de tipo Application representa normalmente una aplicación individual (Next.js, Laravel, Astro…). Cada aplicación:

• Tiene su propio ciclo de vida y su rama de Git conectada (por ejemplo main para producción y dev para staging).
• Tiene sus variables de entorno.
• Tiene su dominio o subdominio asignado, con gestión automática de certificados SSL (Let’s Encrypt).

El proveedor: repositorio y rama

Al crear el servicio, rellenas el formulario y se crea dentro del proyecto. Después configuras el proveedor: el repositorio y la rama que se desplegarán. Por ejemplo, apuntando a un repositorio que contiene una web realizada en Astro.

Build Type: cómo se construye tu código

El Build Type es el método que usa Dokploy para transformar el código fuente en una imagen de Docker lista para ejecutarse. Los tipos más habituales son:

Dockerfile (recomendado si tienes uno propio): Le dice a Dokploy que busque un Dockerfile en la raíz del proyecto y siga sus instrucciones para construir la imagen. Es el método más flexible, porque controlas exactamente la versión de Node.js, los paquetes que se instalan y cómo se copia todo.

Nixpacks: Herramienta inteligente (creada por Railway) que analiza el código automáticamente. Detecta un package.json con Astro, deduce que es una app de Node.js, instala Node, ejecuta npm run build sin que escribas un Dockerfile y empaqueta la aplicación.

Static / HTML: Pensado exclusivamente para web 100% estática (HTML/CSS puro o sitios generados sin servidor). Dokploy compila los archivos estáticos y los sirve con un servidor web ligero (como Nginx). Aquí tendrás que indicar el directorio donde están los archivos estáticos generados.

Run Command: arranca tu aplicación en producción

En la sección de avanzados, el Run Command es el comando que Dokploy ejecuta para arrancar la aplicación. En un framework como Astro no puedes usar el servidor de desarrollo local (astro dev) en un contenedor: el contenedor se detendría al salir del proceso. Lo correcto es una secuencia de producción: compilar primero y servir después.

Para ello añadimos un script personalizado en package.json:

{
  "scripts": {
    "dev": "astro dev",
    "start": "astro dev",
    "build": "astro check && astro build",
    "preview": "astro preview",
    "astro": "astro",
    "dokploy": "npm run build && npm run preview -- --host 0.0.0.0"
  }
}

De este modo, en el Run Command de Dokploy escribimos simplemente:

npm run dokploy

Dato clave: es obligatorio añadir --host 0.0.0.0 (o configurar el servidor para que escuche en todas las interfaces). Por defecto, los contenedores Docker aíslan sus servicios en su propio localhost (127.0.0.1). Si no abres la escucha a 0.0.0.0, el contenedor está “sordo” y el proxy inverso no puede comunicarse con él.

Puertos y dominios: cómo entra el tráfico

Esta sección gestiona la entrada de tráfico a tu aplicación:

• Dominio o Subdominio: asignas un dominio y Traefik recibe las peticiones por los puertos estándar (80 y 443), gestionando los certificados SSL automáticamente.
• Ports: para pruebas directas o accesos aislados por IP, puedes mapear un puerto del host hacia el puerto interno del contenedor. Por ejemplo, redirigir el puerto 9090 de la máquina al 4321 (el que usa Astro para su servidor de preview).

Variables de entorno: conecta el frontend con el backend

Los servicios pueden tener variables de entorno. Imaginemos una arquitectura sencilla con un frontend y un backend en Node.js/Express, ambos escuchando en 0.0.0.0:3000.

El frontend:

const express = require('express');
const app = express();

const PORT = process.env.PORT || 3000;

app.use(express.json());

app.get('/api/health', (req, res) => {
  res.json({ status: 'ok', service: 'frontend' });
});

app.get('/api/data', async (req, res) => {
  const backendUrl = `http://${process.env.BACKEND_HOST}:3000`;
  try {
    const response = await fetch(`${backendUrl}/api/hello`);
    const data = await response.json();
    res.json({ frontend: 'hello', backend: data });
  } catch (error) {
    res.status(500).json({ error: 'Failed to reach backend' });
  }
});

app.listen(PORT, '0.0.0.0', () => {
  console.log(`Frontend running on port ${PORT}`);
});

El backend:

const express = require('express');
const app = express();

const PORT = process.env.PORT || 3000;

app.use(express.json());

app.get('/api/health', (req, res) => {
  res.json({ status: 'ok', service: 'backend' });
});

app.get('/api/hello', (req, res) => {
  res.json({ message: 'Hello from backend!' });
});

app.listen(PORT, '0.0.0.0', () => {
  console.log(`Backend running on port ${PORT}`);
});

El objetivo es que el frontend sea accesible públicamente y el backend no: solo debe hablarse con él a través de la red interna de Docker.

Para lograrlo:

1. Crea dos servicios de tipo Application (con repositorio o subiendo el código en ZIP).
2. En el frontend, expones un puerto de la máquina hacia el puerto interno del contenedor (o configuras un dominio).
3. El backend no se expone con ningún puerto ni dominio hacia el exterior; se comunica usando el nombre del servicio en la red interna de Docker.

En los contenedores activos verás algo así:

CONTAINER ID   IMAGE                                       COMMAND                  NAMES
93d93efbd5d2   front-bacend-frontend-ofwndo:latest         "/bin/bash -l -c 'np…"    front-bacend-frontend-ofwndo.1.ter30yxrjtr9d8s00ostc6uo4
fbbf04acc099   front-bacend-backend-r6pqep:latest          "/bin/bash -l -c 'np…"    front-bacend-backend-r6pqep.1.hvcseyvx7rd8xnzm74cu29h0k

Para que el frontend encuentre al backend, añade la variable de entorno que espera el código (en la pestaña de environment settings del servicio, que no hay que confundir con las variables de entorno del proyecto). El nombre del servidor interno es el que aparece hasta el primer punto:

BACKEND_HOST=front-bacend-backend-r6pqep

Con esto, el fetch interno resuelve http://front-bacend-backend-r6pqep:3000 desde el frontend, sin exponer el backend a internet: comunicación interna estable y segura.

Conclusión

Dokploy te da lo mejor de dos mundos: la comodidad de un PaaS y el control de tu propia infraestructura. Lo mejor es que no tienes que elegir entre usar Docker a fondo o una plataforma cerrada: Dokploy usa Docker Swarm y Traefik por debajo, y te ahorra la parte repetitiva —build, red, dominios, SSL, logs, reinicios— delegándola al panel.

Si te interesa el despliegue de sitios estáticos y la gestión de dominios y DNS, completa este artículo con la guía de Despliegue Continuo en Cloudflare Pages: Dominio Propio, DNS y Redirección WWW. Y en el pilar de DevOps tienes el resto de la documentación sobre infraestructura y automatización.