DesarrolladoresDespliegues y variables
Despliegues, variables y registros
Los ejemplos usan el atajo hw y $API del inicio rápido, y $APP es el uuid de una aplicación.
Variables de entorno#
Las variables llegan a tu app como variables de entorno en tiempo de ejecución, y también durante el build salvo que lo desactives.
| Llamada | Qué hace |
|---|---|
GET /applications/{uuid}/envs | Lístalas. Los valores son null salvo que el token tenga Lectura de datos sensibles. |
PATCH /applications/{uuid}/envs/bulk | Crea o actualiza varias a la vez: {"data": [{"key", "value"}, …]} |
POST /applications/{uuid}/envs | Crea una (409 si la clave existe) |
PATCH /applications/{uuid}/envs | Actualiza una por key |
DELETE /applications/{uuid}/envs/{env_uuid} | Elimina una |
hw -X PATCH $API/applications/$APP/envs/bulk -d '{"data": [
{"key": "LOG_LEVEL", "value": "info"},
{"key": "STRIPE_KEY", "value": "sk_live_…", "is_shown_once": true},
{"key": "GREETING", "value": "Hello $USER", "is_literal": true}
]}'
is_shown_once: el valor no se puede volver a leer nunca, ni en la consola ni en la API.is_literal: los$NAMESdentro del valor se mantienen como texto en lugar de expandirse.is_multiline: para valores como claves PEM.is_buildtime/is_runtime: cuándo está disponible la variable (en ambos casos por defecto).
Las variables compartidas se definen una vez y las usan muchas apps: {{team.KEY}}, {{project.KEY}} o {{environment.KEY}} en el valor de una variable de la app. Gestiónalas con /team/envs, /projects/{uuid}/envs y /projects/{uuid}/environments/{env}/envs.
Los contenedores en ejecución mantienen las variables con las que arrancaron. Despliega la app (abajo) después de cambiarlas.
Desplegar#
hw -X POST $API/applications/$APP/start # build and start
hw -X POST "$API/applications/$APP/start?force=true" # rebuild without the build cache
hw -X POST $API/applications/$APP/restart # restart without rebuilding
hw -X POST $API/applications/$APP/stop # take it offline
start responde {"message": "Deployment request queued.", "deployment_uuid": "…"}. Un despliegue pasa por queued → in_progress → finished, o termina como failed o cancelled-by-user. Si un build falla, la versión anterior sigue funcionando. Con un health check activado (health_check_enabled, health_check_path), una versión nueva solo toma el relevo cuando responde.
| Llamada | Qué hace |
|---|---|
GET /deployments/{uuid} | Estado de un despliegue, con su registro de build en logs |
GET /deployments/applications/{uuid}?skip=0&take=10 | Los despliegues de una app, los más recientes primero: {count, deployments} |
GET /deployments | Despliegues en cola o en curso en este momento, en todo el equipo |
POST /deployments/{uuid}/cancel | Cancela un despliegue en cola o en curso |
POST /deploy?uuid=a,b o ?tag=web | Despliega varias apps a la vez, por uuid o etiqueta |
El SDK tiene deployAndWait(appUuid) y deployments.wait(deploymentUuid), que consultan el estado por ti y lanzan un error con el final del registro de build cuando falla un despliegue.
Registros#
Los registros de build forman parte del despliegue. logs es una lista de líneas codificada en JSON; las líneas marcadas como hidden son comandos internos del build:
hw $API/deployments/$DEPLOYMENT | jq -r '.logs | fromjson | map(select(.hidden | not) | .output) | .[-50:][]'
Los registros de ejecución son la salida del contenedor en marcha (necesitan Lectura de datos sensibles):
hw "$API/applications/$APP/logs?lines=200&show_timestamps=true" | jq -r .logs
Una app detenida responde 400 Application is not running. Para CPU y memoria a lo largo del tiempo, usa GET /applications/{uuid}/metrics?minutes=60.
Rollback#
hw $API/applications/$APP/rollback-images | jq # images you can go back to
hw -X POST $API/applications/$APP/rollback -d '{"tag": ""}'
Un rollback vuelve a desplegar una imagen anterior sin volver a hacer el build.
Despliegues por push#
Para desplegar en cada git push, usa una de estas opciones:
- GitHub App (recomendada para GitHub): conéctala en la consola en Fuentes y luego crea apps desde sus repositorios (
POST /applications/private-github-app). Los push a la rama de la app se despliegan automáticamente; no hay que configurar ningún webhook. - Webhook del repositorio (cualquier repositorio público o con clave de despliegue en GitHub, GitLab, Bitbucket o Gitea): define un secreto en la app y luego añade un webhook en tu repositorio.
SECRET=$(openssl rand -hex 24)
hw -X PATCH $API/applications/$APP -d "{\"manual_webhook_secret_github\": \"$SECRET\"}"
En GitHub, abre Settings → Webhooks → Add webhook en el repositorio:
| Campo | Valor |
|---|---|
| Payload URL | https://console.app.hostwolf.net/webhooks/source/github/events/manual |
| Tipo de contenido | application/json |
| Secreto | el $SECRET de arriba |
| Eventos | Solo el evento push |
Para los demás servicios, usa manual_webhook_secret_gitlab, _bitbucket o _gitea y la URL /webhooks/source/<host>/events/manual correspondiente. La pestaña Webhooks de la app en la consola también muestra las URLs. Los secretos necesitan al menos 16 caracteres. Solo los push a la git_branch de la app la despliegan; watch_paths (p. ej. "src/**") limita los despliegues a cambios en esas rutas.
Desplegar desde CI#
Llama al endpoint de despliegue cuando pasen tus tests. Basta con un token que solo tenga los permisos Despliegue y Lectura:
curl -fsS -X POST "https://console.app.hostwolf.net/api/v1/deploy?uuid=$APP_UUID" \
-H "Authorization: Bearer $HOSTWOLF_APPS_TOKEN"
En GitHub Actions, guarda el token como secreto del repositorio:
# .github/workflows/deploy.yml
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Deploy to Hostwolf Apps
run: |
curl -fsS -X POST "https://console.app.hostwolf.net/api/v1/deploy?uuid=${{ vars.HOSTWOLF_APP }}" \
-H "Authorization: Bearer ${{ secrets.HOSTWOLF_APPS_TOKEN }}"
Para desplegar una imagen que tu pipeline ya construyó, crea la app a partir de esa imagen (POST /applications/dockerimage) y pasa docker_tag a /deploy.