De GitHub a producción con Dokploy: un sitio de prueba por cada PR

Dokploy es una plataforma de despliegue self-hosted que gestiona tus aplicaciones sobre Docker y Traefik, una alternativa a Vercel o Netlify sin salir de tu propio servidor. Una de sus combinaciones más potentes es usarla junto a GitHub para tener un flujo de despliegue completo: un sitio de prueba aislado por cada pull request y, al hacer merge, la rama principal desplegándose en producción automáticamente.

El objetivo

El ciclo que queremos es este:

1. Trabajas en una rama feature.
2. Abres un pull request hacia main.
3. Dokploy levanta un preview deployment de esa rama en una URL aislada.
4. Revisas y pruebas la versión en esa URL. Cada nuevo commit al PR actualiza el preview.
5. Al hacer merge, el preview se elimina solo y main se despliega en producción.

Sin intervención manual en ningún paso.

Paso 1 — Conectar GitHub y crear la aplicación

En Dokploy, conecta tu cuenta de GitHub (la integración oficial de la plataforma) y crea una Application vinculada a tu repositorio. Eliges el repositorio, la rama y cómo se construye: imagen de Docker, Dockerfile, Docker Compose o buildpack.

Paso 2 — Rama de producción y auto-deploy

Dentro de la aplicación, selecciona la rama que representa producción (normalmente main). Dokploy activa el auto-deploy para esa rama: cada push a main dispara un despliegue automático, y los pushes a otras ramas no disparan nada. Esto mantiene producción estable mientras desarrollas en cualquier otra rama.

Paso 3 — Activar los Preview Deployments

Los preview deployments se generan automáticamente cuando se abre un pull request contra la rama objetivo configurada. Solo hay que activarlos en la aplicación y definir algunos parámetros:

• Dominio: por defecto Dokploy usa dominios gratuitos con el patrón preview-${appName}-${uniqueId}.traefik.me. Si prefieres tu propio dominio, configura un patrón wildcard como *.midominio.com y apunta el registro DNS wildcard a la IP de tu servidor.
• Puerto: el puerto en el que responde tu aplicación dentro del contenedor (por defecto 3000; ajustable a tu app).
• Límite de previews: cuántos previews simultáneos admite la aplicación (por defecto 3).
• Labels: opcional. Puedes indicar que solo los PR con ciertas etiquetas generen preview, para ahorrar recursos en cambios triviales.

La URL generada está disponible en las variables de entorno del preview mediante ${{DOKPLOY_DEPLOY_URL}}, útil si tu aplicación necesita conocerse a sí misma:

APP_URL=https://${{DOKPLOY_DEPLOY_URL}}

Paso 4 — El ciclo completo en la práctica

Con todo configurado, el flujo es transparente:

Es un aislamiento completo: cada preview tiene su propio contenedor, sus propias variables y su propia URL, así que probar una rama nunca afecta a otra ni a producción.

Variante: disparar el deploy desde CI

Si prefieres que producción se despliegue desde tu pipeline (por ejemplo, para correr tests antes), puedes generarlo con GitHub Actions: crea una API key en Dokploy y llama al endpoint de despliegue:

name: Deploy
on:
  push:
    branches: ["main"]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Dokploy deployment
        run: |
          curl -X 'POST' \
            'https://tudokploy.example.com/api/application.deploy' \
            -H 'accept: application/json' \
            -H 'x-api-key: ${{ secrets.DOKPLOY_API_KEY }}' \
            -H 'Content-Type: application/json' \
            -d '{"applicationId": "TU-APP-ID"}'

Conclusión

Combinar GitHub con los preview deployments de Dokploy convierte el despliegue en parte natural del flujo de trabajo: cada pull request llega con su sitio de prueba listo para revisar, y el merge a producción no requiere ni un clic. Los previews se crean y se destruyen solos, así que el costo se limita a los PR realmente en revisión y el equipo gana confianza de que lo que mergea ya fue probado en un entorno idéntico al de producción.