Desplegar una app con base de datos (plan App)

Inicios de sesión, pedidos, un panel con datos: entonces tu proyecto es una app Node o Next, no una web estática. Con nosotros funciona en su propio contenedor con su propia base de datos Postgres (€ 15 al mes tras 14 días de prueba). La imagen se construye en GitHub, nunca en nuestro servidor, así que esto va siempre por un workflow en tu repositorio:

name: Deploy app to Dorelli
on:
  push:
    branches: [main]

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: dorelli-cloud/action@v1
        with:
          plan: app
          email: you@example.com
          site-id: ${{ secrets.DORELLI_SITE_ID }}
          registry-user: ${{ secrets.DORELLI_REGISTRY_USER }}
          registry-password: ${{ secrets.DORELLI_REGISTRY_PASSWORD }}

La primera ejecución crea la web y un token de registry, vincula la web a tu repositorio y te dice qué tres secretos poner: el id de la web y los dos valores de registry. Con permissions: id-token: write, cada ejecución siguiente demuestra que viene de tu repositorio, así que no hay ningún token de despliegue que guardar; los valores de registry se quedan, porque docker push los necesita. En un repositorio público cualquiera puede leer lo que muestra una ejecución, así que crea la contraseña de registry en el portal, como se explica más abajo. ¿Ya hubo una primera publicación en un repositorio público? Crea entonces también un token de despliegue nuevo en el portal, y haz una ejecución con ese token (deploy-token) y bind-github: true: un token que alguna vez apareció en una ejecución deja de funcionar, y la web vuelve a estar vinculada. Mantén el workflow en on: push a main y evita pull_request_target: la plataforma confía en cada ejecución desde tu repositorio, así que un workflow que también corra para pull requests de desconocidos les dejaría publicar tu web. Las ejecuciones iniciadas por pull_request_target, issues, issue_comment, discussion o discussion_comment se rechazan de todos modos. ¿Ya tienes una web con token de despliegue? Pon bind-github: true en el paso durante una ejecución: la plataforma vincula entonces la web a tu repositorio, y el token puede desaparecer. Tu app recibe DATABASE_URL y PORT (3000 por defecto) como variables de entorno. No hace falta Dockerfile: entonces usamos npm ci, npm run build, npm start. ¿Tienes tu propio Dockerfile? Se usa tal cual. ¿Perdiste la contraseña del registry, o una ejecución falla en docker login? En el portal, pestaña Agents de tu app, bajo Token de registry, pulsa Nueva contraseña y pon la contraseña en el secreto DORELLI_REGISTRY_PASSWORD; el usuario sigue siendo el mismo, y solo vale la última contraseña mostrada.

Tus propios secretos, como una clave de API: guárdalos en los secretos de tu repositorio y añade al paso un bloque secrets, un NOMBRE=valor por línea, por ejemplo API_KEY=${{ secrets.API_KEY }}. Solo van a tu contenedor y llegan como variables de entorno, a partir de la segunda ejecución, cuando el contenedor ya existe; guardamos los nombres, nunca los valores. Los nombres son mayúsculas, cifras y _, como mucho 20 por app; PORT, DATABASE_URL, POSTGRES_URL, REDIS_URL, STORAGE_CONNECTION_STRING (también con un sufijo) y DORELLI_* los ponemos nosotros. Los secretos funcionan en nuestras propias ubicaciones de Azure; un sitio en pausa no los recibe hasta que vuelve a funcionar.

La app escala a cero sin tráfico; la primera visita después de un rato en silencio tarda de 10 a 30 segundos, mira Arranques en frío. Los logs, el reinicio y las variables de entorno están en tu portal, mira Logs, reinicio y variables.