Git Deploy

La pestaña Git Deploy del Portal conecta tu servidor con un repositorio de Git en GitHub, GitLab, Gitea o Forgejo. Sus archivos se copian automáticamente a tu servidor en cada push, cuando publicas una release, cuando subes un tag o cuando haces clic en un botón. Si quieres, tu servidor se detiene de forma limpia antes del despliegue y se vuelve a iniciar después.

En resumen: sube tu código y unos segundos después se ejecuta en tu servidor. Se acabó subir archivos por SFTP, descomprimir ZIPs en el gestor de archivos y olvidarte de reiniciar.

Lo que aprenderás

• Cómo conectar un repositorio, con la app de GitHub Daki Git Deploy o con un token de acceso
• Cuándo se ejecuta un despliegue y cómo lanzarlo tú mismo
• Cómo mantener a salvo mundos, bases de datos y archivos .env con rutas protegidas
• Cómo funcionan los reinicios, el historial de despliegues, los rollbacks y el estado en tu repositorio
• Cómo dar a tu equipo los permisos adecuados

Para quién es

• Desarrolladores de bots de Discord y de apps en Node.js, Python o Java cuyo código ya está en GitHub o GitLab.
• Redes de Minecraft y equipos de servidores de juegos que guardan plugins, configuraciones o datapacks en un repositorio y quieren que los cambios se publiquen de forma trazable.
• Equipos: varias personas trabajan en el repositorio, el servidor siempre está al día y los permisos de subusuario deciden exactamente quién puede desplegar.
• Proyectos basados en releases: solo llegan al servidor las versiones publicadas (por ejemplo, un .jar terminado de una release), no cada trabajo en curso.

Antes de empezar

• Un servidor en el Portal que muestre la pestaña Git Deploy. Está en la navegación del servidor, bajo Essentials, justo después de Files por defecto.
• Un repositorio en GitHub (github.com), GitLab (gitlab.com o tu propia instancia; se incluyen subgrupos como group/subgroup/project), Gitea o Forgejo (por ejemplo Codeberg o tu propia instancia). Funcionan tanto repositorios públicos como privados.

Inicio rápido con GitHub (recomendado)

La forma más rápida: conéctate con Daki Git Deploy, la app oficial de GitHub de Daki Hosting. Inicias sesión en GitHub y eliges tus repositorios, sin necesidad de token ni webhook.

1. 1

   Abre la pestaña Git Deploy

   En el Portal, abre tu servidor y ve a la pestaña Git Deploy. En Git service, elige GitHub.

2. 2

   Conecta con GitHub

   En el cuadro GitHub access, haz clic en Connect with GitHub. Inicia sesión en GitHub y autoriza la app.

   La primera vez, GitHub te lleva directamente a elegir a qué repositorios puede acceder la app (All repositories o solo los seleccionados): un solo paso en lugar de dos. Después vuelves al Portal y el cuadro GitHub access muestra Connected via Daki Git Deploy as con tu nombre de GitHub. El cuadro Webhook confirma que no hay nada que configurar: los push y las releases llegan por la app por sí solos.

3. 3

   Elige tu repositorio y rama

   Haz clic en Choose from my repositories y selecciona tu repositorio, o pega la URL web o de clonado, o escribe la ruta. Haz clic en Load branches y elige la rama a desplegar. Déjala vacía para usar la rama por defecto del repositorio.

4. 4

   Elige cuándo y cómo desplegar

   En When to deploy, elige un modo (por ejemplo Every push). Después define la carpeta de destino, tus rutas protegidas y el comportamiento de reinicio.

5. 5

   Guarda

   Haz clic en Save settings en la barra inferior. Eso es todo: la cabecera de la pestaña muestra Automatic deploys on, y tu siguiente push se despliega automáticamente. Para desplegar ya mismo, haz clic en Deploy now arriba a la derecha.

• Permitir otro repositorio: Choose repositories on GitHub vuelve a abrir la selección de repositorios en GitHub, donde eliges a qué repositorios puede acceder Daki Git Deploy.
• Quitar la conexión: haz clic en Disconnect. Entonces el servidor ya no despliega desde repositorios privados.

Inicio rápido con un token de acceso

Para GitLab, Gitea y Forgejo (y para GitHub si lo prefieres), guardas un token de acceso personal. Los repositorios públicos funcionan sin ningún token.

1. 1

   Elige el servicio de Git

   Abre tu servidor → Git Deploy y elige el Git service. Para tu propia instancia de GitLab, Gitea o Forgejo, introduce la URL del servidor (por ejemplo https://codeberg.org o https://git.example.com). Para gitlab.com, déjala vacía.

2. 2

   Introduce el repositorio

   Escribe el repositorio como ruta (owner/name) o pega simplemente su URL web o de clonado. Para un repositorio público, eso es todo lo que necesitas — sin token, el cuadro de acceso muestra No token – public repositories only.

3. 3

   Guarda un token para repositorios privados

   Con GitHub, primero haz clic en Use an own access token instead en el cuadro GitHub access. Luego crea un token en tu proveedor de Git (el enlace Create a token on … del Portal te lleva directamente a la página correcta) y guárdalo en Personal access token. El Portal comprueba el token al momento. Consulta Permisos del token para ver los permisos que necesita.

4. 4

   Elige tus ajustes y guarda

   Elige cuándo desplegar, la carpeta de destino, las rutas protegidas y el comportamiento de reinicio, y haz clic en Save settings.

5. 5

   Añade el webhook

   El cuadro Webhook muestra la Payload URL y el Secret, cada uno con un botón de copiar. Añádelos a tu repositorio como se describe en Configura el webhook. Debajo del cuadro, Last delivery indica si el webhook llega.

6. 6

   Activa los despliegues automáticos

   Activa Automatic deploys active.

Permisos del token

Si solo falta el permiso de escritura para el estado, tu servidor se despliega igualmente: el registro del despliegue muestra una nota.

Configura el webhook

Cuándo se hace un despliegue

En When to deploy, elige uno de los cuatro modos:

Disparadores

• Webhook: tu proveedor de Git informa de los cambios al momento, y el despliegue empieza en segundos. Con la app de GitHub esto ocurre automáticamente, sin un webhook propio.
• Comprobaciones de actualizaciones (polling): opcional, para los casos en que tu proveedor de Git no puede acceder al Portal. Intervalos de 5 minutos a 1 día.
• Deploy now: en cualquier momento, con un clic. En modo release puedes elegir una release concreta.
• Saltar un push: pon [skip deploy] en el mensaje del commit y ese push no se despliega. [deploy skip] y [no deploy] también funcionan.

Esperar a los checks de CI

Con Wait for CI checks activado (solo en modo Every push), un commit se despliega solo cuando su CI está en verde: se admiten GitHub Actions, GitLab CI y Gitea/Forgejo Actions. Si el CI falla, el despliegue se omite.

Todos los ajustes explicados

Los cambios solo se aplican cuando haces clic en Save settings. Mientras haya algo sin guardar, una barra en la parte inferior muestra Discard y Save settings, y Deploy now queda bloqueado.

Remove files that were deleted from the repository solo elimina los archivos que un despliegue anterior escribió por sí mismo: nunca las rutas protegidas ni los archivos que creaste tú. Las carpetas vacías se mantienen.

Rutas protegidas

Los archivos y carpetas en Protected paths nunca se sobrescriben ni se eliminan en un despliegue. Si todavía no existen, se crean una sola vez. Perfecto para mundos de juego, bases de datos y contraseñas.

Escribe una regla por línea, relativa a la carpeta de destino. Las líneas vacías y las que empiezan por # se ignoran. * nunca coincide a través de un /.

Ejemplos típicos:

world/
world_nether/
world_the_end/
plugins/*/config.yml
whitelist.json
ops.json
banned-*.json

.env
*.db
*.sqlite
node_modules/
data/

.env
*.db
venv/

Comportamiento al reiniciar

If the server does not stop: algunos programas, sobre todo las apps en Node.js, ignoran la señal de parada. Entonces el servidor se mata tras el tiempo que elijas (inmediatamente, de 5 segundos a 5 minutos; Kill after 10 seconds por defecto) para que el despliegue no se quede colgado. Matar al instante es lo más rápido, pero no da tiempo al servidor a guardar nada.

Qué ocurre durante un despliegue

1. Un disparador (push, release, tag, comprobación de actualizaciones o botón) crea un despliegue.
2. Si Wait for CI checks está activado, espera a que los checks de CI estén en verde (Waiting).
3. El Portal descarga el archivo comprimido de tu proveedor de Git. Tus credenciales nunca salen del Portal ni llegan a tu servidor.
4. El archivo se prepara: solo la carpeta elegida, sin las rutas protegidas, y se descarta el contenido no seguro, como los enlaces simbólicos.
5. Según tus ajustes, el servidor se detiene (y se mata tras el tiempo elegido si hace falta).
6. Los archivos se escriben en la carpeta de destino; opcionalmente, se eliminan los archivos borrados.
7. Según tus ajustes, el servidor se vuelve a iniciar.
8. El resultado y el registro completo aparecen en el historial y, si está activado, como estado en el commit.

Un despliegue suele tardar 10–40 segundos, más el tiempo que tu servidor necesite para detenerse.

Historial, registros y rollback

La lista Deployments al final de la pestaña muestra cada despliegue con su estado, rama y commit (por ejemplo main @ 75cd0a1), número, disparador, la persona que lo inició, la hora y el mensaje del commit. La cabecera de la pestaña muestra cuándo se desplegó el servidor por última vez.

• Registro: cada despliegue tiene un registro en vivo que se actualiza mientras se ejecuta. Hide log lo vuelve a cerrar.
• Rollback en un clic: haz clic en Deploy again en un despliegue anterior para volver a publicar ese estado.
• Cancelar: los despliegues en espera o programados se pueden cancelar.

Varios servidores pueden desplegar al mismo tiempo, pero cada servidor solo ejecuta un despliegue a la vez. Un nuevo disparador reemplaza un despliegue anterior que todavía esté en espera.

Estado en tu repositorio

Con Show deploys in the repository activado, tu commit muestra un estado Daki Hosting / nombre de tu servidor: amarillo mientras se ejecuta el despliegue, después una marca verde o una cruz roja, con un enlace a la pestaña Git Deploy.

• En GitHub, el despliegue también aparece en Deployments, con el nombre de tu servidor como entorno.
• Con la app de GitHub, el estado lo escribe Daki Git Deploy y muestra su logo; no hay nada más que configurar. Con un token, muestra la imagen de la cuenta del token, y el token necesita permisos de escritura (consulta Permisos del token).
• Puedes desactivarlo por servidor. Solo el estado y el enlace son públicos: sin registros ni detalles de errores.

Equipos y permisos de subusuarios

Los subusuarios obtienen su propio grupo de permisos Git Deploy:

Los subusuarios no tienen acceso a Git Deploy por defecto: tú decides quién recibe cada permiso. El propietario del servidor siempre puede hacerlo todo.

Seguridad

• Los tokens y secretos se guardan cifrados y nunca se envían a tu navegador.
• Con la app de GitHub, no hay ningún token tuyo de larga duración para los despliegues: cada despliegue usa una clave de corta duración (1 hora) que llega solo al repositorio de tu servidor.
• Tu propio acceso a GitHub decide qué repositorios puedes conectar. Nadie puede traer repositorios de otra persona a su servidor.
• Los webhooks van firmados con un secreto propio para cada servidor. Las entregas con un secreto incorrecto o de otro repositorio se rechazan.
• Solo la persona que guardó el token puede cambiar el repositorio, así que los subusuarios no pueden usar el token del propietario para cargar otros repositorios privados.
• Si cambias el Git service o la URL del servidor, el token guardado se elimina automáticamente al guardar.
• Las rutas protegidas nunca se sobrescriben, y Remove files that were deleted from the repository solo elimina lo que Git Deploy escribió.
• El estado público en tu repositorio no contiene registros ni detalles de errores.

Límites conocidos

• Un repositorio y un acceso por servidor.
• Cada servidor solo ejecuta un despliegue a la vez.
• El estado en tu repositorio solo aparece cuando el despliegue empieza de verdad, no mientras espera al CI.
• Los archivos de release solo se extraen si son .zip; un .tar.gz se sube como archivo.
• Las carpetas vacías se mantienen tras Remove files that were deleted from the repository.
• Los enlaces simbólicos del repositorio no se despliegan.
• GitLab no tiene pre-releases; una release con fecha futura cuenta como pre-release.
• GitLab: los archivos de release subidos al proyecto (/uploads/…) no se pueden descargar con un token desde proyectos privados; sí funcionan los enlaces al registro de paquetes.
• Connect with GitHub solo está disponible para GitHub; GitLab, Gitea y Forgejo usan un token.

Preguntas frecuentes y solución de problemas

Próximos pasos

• Subusuarios: da acceso a tu equipo y decide quién puede desplegar.
• Variables de entorno: mantén tokens y contraseñas fuera de tu repositorio.
• Ajustes de inicio: define el comando de inicio con el que se ejecuta tu código desplegado.
• Copias de seguridad: guarda copias de seguridad automáticas de tu servidor en Google Drive.