Ir al contenido

Buscar en la documentación

Busca en la documentación de Skiffly

Migrar desde Heroku

Los dynos pasan a ser servicios, los add-ons pasan a ser plantillas con volúmenes, las config vars pasan a ser variables y el Procfile pasa a ser un comando de inicio. Una mudanza paso a paso.

Correspondencia de conceptos#

HerokuSkifflyNotas
AppProyecto con uno o más serviciosun servicio por tipo de proceso
Tipo de dyno (web, worker)Servicioweb recibe un dominio; los workers corren sin uno
Etapas del pipeline (staging, production)Entornosun proyecto, entornos staging y production
Review appsEntornos de vista previa de PRactiva las vistas previas de PR en el proyecto
BuildpacksRailpackdetecta los mismos lenguajes; o agrega un Dockerfile
ProcfileComando de inicio por servicioweb: gunicorn app:app → comando de inicio gunicorn app:app
Config varsVariablesreferencias ${{Postgres.DATABASE_URL}} en lugar de URLs copiadas
Add-ons de Heroku Postgres / RedisPlantillas de Postgres / Redis con volúmenesla instancia y sus datos son tuyos
Heroku SchedulerProgramación cron en un servicio0 * * * *
heroku run bashskiffly sshshell en el contenedor en ejecución
heroku logs --tailskiffly logs -f
heroku ps:scale web=2réplicasConfiguración → Despliegue → Réplicas
Tamaños de dynoLímites de CPU / memoria por serviciocualquier valor dentro del plan
*.herokuapp.com*.skiffly.clouddominios propios con TLS automático
heroku.yml.skiffly/skiffly.tsconfiguración como código
Factura mensualSaldo prepagoPayPal o cripto

Paso a paso#

  1. Inicia sesión en app.skiffly.dev con GitHub; el código debe estar en GitHub (el remoto git de Heroku no sirve como origen).

  2. Crea el proyecto y un servicio por tipo de proceso: skiffly init en el repositorio, skiffly up para web. Para un worker, crea un segundo servicio desde el mismo repositorio y pon como comando de inicio la línea del worker del Procfile; déjalo sin dominio.

  3. Bases de datos. skiffly deploy --template postgres (y redis). Copia los datos:

    heroku pg:backups:capture -a my-app && heroku pg:backups:download -a my-app     # latest.dump
skiffly connect postgres --print
pg_restore -d "<url>" --no-owner --clean --if-exists latest.dump
skiffly proxy delete <port>

  4. Config vars. heroku config -s -a my-app > vars.env, quita las URLs de los add-ons y luego:

    skiffly variables set --skip-deploys $(cat vars.env | xargs)
skiffly variables set 'DATABASE_URL=${{Postgres.DATABASE_URL}}' 'REDIS_URL=${{Redis.REDIS_URL}}'
skiffly redeploy

  5. Puerto. Heroku define $PORT; Skiffly también. No hay nada que cambiar si la app ya lo lee.

  6. Release phase. No hay hook de release phase. Ejecuta las migraciones desde el comando de inicio (sh -c "npm run migrate && npm start") o como tarea puntual: skiffly ssh -- npm run migrate.

  7. Scheduler. Por cada tarea programada, crea un servicio desde el mismo repositorio con una programación cron y el comando de la tarea como comando de inicio.

  8. Dominio. Agrega el dominio propio, crea los registros CNAME y TXT, verifica y luego cambia el DNS desde Heroku cuando se emita el certificado.

  9. Apaga Heroku después de unos días de tráfico en Skiffly.

Diferencias que conviene conocer#

  • Los servicios de Skiffly no entran en reposo a menos que actives App Sleeping; las apps del plan Free y las apps hobby inactivas no se detienen por temporizador.
  • El sistema de archivos es efímero como el de un dyno, pero puedes adjuntar un volumen persistente para subidas de archivos o SQLite.
  • Los logs se conservan hasta las últimas 5 000 líneas por despliegue; reenvíalos desde la app si necesitas historial.
  • Marketplace de add-ons: elige en su lugar entre 136 plantillas; tú ejecutas la instancia y pagas por sus recursos, no un precio por add-on.