deploy-config
npx machina-cli add skill 686f6c61/alfred-dev/deploy-config --openclawConfigurar despliegue
Resumen
Este skill genera la configuración necesaria para desplegar la aplicación en el proveedor de hosting elegido. Cubre desde la configuración básica (variables de entorno, dominio, SSL) hasta aspectos avanzados como estrategias de despliegue y planes de rollback.
Cada proveedor tiene sus particularidades, pero los principios son universales: despliegue reproducible, configuración externalizada, rollback rápido y cero downtime siempre que sea posible.
Proceso
-
Identificar el proveedor de hosting. Detectar la plataforma o preguntar al usuario:
- PaaS: Vercel, Railway, Fly.io, Render, Heroku.
- IaaS/Cloud: AWS (ECS, Lambda, EC2), GCP (Cloud Run, GKE), Azure.
- Self-hosted: VPS con Docker, Kubernetes on-premise.
-
Configurar variables de entorno. Separar la configuración del código:
- Listar todas las variables necesarias (base de datos, APIs externas, secretos).
- Diferenciar entre variables de build y variables de runtime.
- Documentar cada variable: nombre, descripción, valor por defecto, si es obligatoria.
- Verificar que los secretos no tienen valores por defecto en el código.
-
Configurar dominio y SSL:
- Dominio personalizado: DNS, registros A/CNAME.
- SSL/TLS: certificado automático (Let's Encrypt) o gestionado por el proveedor.
- Redirección HTTP a HTTPS obligatoria.
- HSTS habilitado.
-
Elegir estrategia de despliegue. Según las necesidades del proyecto:
Estrategia Descripción Cuándo usarla Rolling Reemplaza instancias progresivamente Default, bajo riesgo Blue-green Dos entornos idénticos, cambio instantáneo Cuando se necesita rollback inmediato Canary Porcentaje pequeño de tráfico al nuevo deploy Features de alto riesgo, validación gradual Recreate Para todo, despliega nuevo Aceptable solo en entornos de desarrollo -
Definir plan de rollback. Qué hacer si el despliegue sale mal:
- Cómo detectar que algo va mal (métricas, alertas, health checks).
- Cómo volver a la versión anterior (comando concreto o proceso).
- Tiempo máximo para decidir si hacer rollback.
- Quién tiene autoridad para ejecutar el rollback.
-
Configurar health checks. El proveedor necesita saber si la aplicación está sana:
- Endpoint de salud (GET /health o similar).
- Criterios: respuesta 200, tiempo de respuesta < Xms.
- Período de gracia tras el despliegue (start period).
-
Generar ficheros de configuración. Según el proveedor:
- Vercel:
vercel.json. - Railway:
railway.tomlo Procfile. - Fly.io:
fly.toml. - AWS:
task-definition.json,appspec.yml, etc. - Docker Compose:
docker-compose.ymlpara entornos con múltiples servicios.
- Vercel:
-
Documentar el proceso. Dejar instrucciones claras de cómo desplegar manualmente si la automatización falla.
Criterios de éxito
- La configuración del proveedor está generada y lista para usar.
- Las variables de entorno están documentadas y los secretos no tienen valores por defecto.
- El dominio y SSL están configurados con redirección HTTPS.
- Hay una estrategia de despliegue elegida y justificada.
- Existe un plan de rollback documentado.
- Los health checks están configurados.
Source
git clone https://github.com/686f6c61/alfred-dev/blob/main/skills/devops/deploy-config/SKILL.mdView on GitHub Overview
Este skill genera la configuración necesaria para desplegar la aplicación en el proveedor de hosting elegido, desde variables de entorno y dominio/SSL hasta estrategias de despliegue y planes de rollback. Busca un despliegue reproducible, configuración externalizada y cero downtime cuando sea posible.
How This Skill Works
El proceso identifica el proveedor de hosting (PaaS, IaaS/Cloud o self-hosted), separa la configuración del código y documenta cada variable (nombre, descripción, valor por defecto y obligatoriedad). Configura dominio y SSL, elige una estrategia de despliegue y define un plan de rollback, además de health checks. Finalmente genera los ficheros de configuración específicos del proveedor (p. ej., vercel.json, railway.toml, fly.toml, task-definition.json, appspec.yml, docker-compose.yml) y documenta el proceso para una operación manual si falla la automatización.
When to Use It
- Necesitas desplegar una aplicación en un proveedor específico (Vercel, Railway, Fly.io, AWS, GCP, Docker) y quieres una configuración lista para usar.
- Quieres separar la configuración del código y documentar todas las variables de entorno, incluyendo secretos sin valores por defecto.
- Requieres que el dominio tenga SSL, redirección HTTP a HTTPS y HSTS configurado.
- Necesitas una estrategia de despliegue definida (Rolling, Blue-green, Canary o Recreate) con justificación.
- Necesitas un plan de rollback documentado y health checks para validar la salud de la app tras el despliegue.
Quick Start
- Step 1: Identifica el proveedor de hosting (PaaS/IaaS/self-hosted) y reúne la configuración básica (dominio, SSL, variables de entorno).
- Step 2: Lista y documenta todas las variables de entorno (base de datos, APIs, secretos) y separa build vs runtime; verifica que no haya valores por defecto en secretos.
- Step 3: Genera los ficheros de configuración del proveedor (p. ej., vercel.json, railway.toml, fly.toml, task-definition.json) y añade un plan de rollback y health checks; documenta el proceso de despliegue.
Best Practices
- Documenta cada variable de entorno: nombre, descripción, valor por defecto y si es obligatoria.
- Verifica que los secretos no contienen valores por defecto y se gestionan fuera del código.
- Configura dominio/SSL con redirección HTTPS obligatoria y HSTS habilitado.
- Elige una estrategia de despliegue alineada con el riesgo y la criticidad del proyecto.
- Define y valida un plan de rollback con métricas, alertas y autoridad para revertir.
Example Use Cases
- Proyecto desplegado en Vercel con vercel.json y variables de entorno correctamente documentadas.
- Despliegue en Railway usando railway.toml o Procfile para definir procesos y variables de entorno.
- Despliegue en Fly.io mediante fly.toml con configuración de health checks y dominios.
- Infra en AWS con task-definition.json y appspec.yml para despliegues con pipelines y rollback.
- Entorno multi-servicio con Docker Compose gestionando varios servicios en entornos de staging y producción.
