Despliega PHP en Nodion

Despliega PHP paso a paso

1. Añade composer.json y haz commit de composer.lock Nodion detecta PHP por el composer.json. Un repositorio que solo tiene un index.php no se detecta; si aún no tienes composer.json, basta con uno pequeño como este. La build ejecuta composer install --no-dev --optimize-autoloader, así que todo lo que la app necesita en tiempo de ejecución va en require, no en require-dev. Haz commit de composer.lock para que la build instale las versiones que has probado. composer.json

   {
     "require": {
       "php": "8.4.*"
     }
   }

2. Guarda los archivos públicos en public/ FrankenPHP usa public/ como document root. Si no existe, Nodion usa web/, y si no existe ninguno de los dos, la raíz del repositorio. Pon index.php y tus assets en public/ y deja vendor/, la configuración y el código fuente al lado, para que solo se sirvan los archivos pensados para la web.

   composer.json
   composer.lock
   src/
   public/
     index.php

3. Elige el servidor web FrankenPHP es la opción por defecto y no necesita configuración. Para usar php-fpm detrás de nginx o Apache httpd, añade BP_PHP_SERVER con el valor nginx o apache en la pestaña Environment y marca la casilla Build. Apache también lee tus archivos .htaccess. Con cualquier otro valor, la build falla.
4. Crea la app y vincula una base de datos En el dashboard, crea una aplicación desde tu repositorio de GitHub, GitLab, Bitbucket o Gitea, elige la rama y la región EU Central, y deja la estrategia de build en Buildpacks. Después crea una base de datos MySQL o PostgreSQL en la misma región y vincúlala en la pestaña Environment: la app recibe DATABASE_URL en el siguiente despliegue, solo en tiempo de ejecución. Marca las contraseñas y las claves de API como secretas.
5. Ejecuta las migraciones en cada despliegue Una línea release: en un Procfile se ejecuta una vez por build, después de la build y antes de que arranque la nueva versión. Si falla, el despliegue se detiene y la versión en ejecución sigue activa. Deja la herramienta de migraciones, por ejemplo Doctrine Migrations o Phinx, en require. Procfile

   release: vendor/bin/doctrine-migrations migrate --no-interaction

A tener en cuenta

• Fija la versión de PHPNodion lee primero .php-version y después require.php en composer.json; si no hay ninguno de los dos, obtienes PHP 8.3. Un rango elige la versión más reciente que lo cumpla, así que con "^8.2" obtienes PHP 8.5. Para quedarte en una misma versión menor, escribe 8.3 en .php-version o exige "8.3.*".
• SymfonyNodion reconoce Symfony por bin/console junto con symfony.lock, ejecuta bin/console cache:warmup --env=prod durante la build y define APP_ENV=prod y APP_DEBUG=0 en tiempo de ejecución. Añade también APP_ENV=prod con la casilla Build marcada, para que los scripts de Composer que se ejecutan durante la instalación no usen dev de tu .env. Nodion no ejecuta asset-map:compile; si usas AssetMapper, añádelo a los auto-scripts de composer.json. Para builds con Encore o Vite, usa un Dockerfile.
• WorkersPara un worker de colas, añade al Procfile una línea como worker: php bin/worker.php junto con una línea web: explícita, porque sin ella la primera entrada del Procfile que no sea release: se convierte en el comando por defecto. El log de la build muestra el comando de arranque por defecto; para FrankenPHP funciona web: frankenphp php-server --listen :$PORT --root public/. Después añade en la pestaña Processes un proceso llamado worker sin puerto.
• Ruta del health checkEl tráfico pasa a una nueva release en cuanto / responde con 2xx o 3xx. Si / responde con 401 o 404, define en los ajustes de la app una ruta de health check que devuelva 200.

Lo que Nodion gestiona por ti

• Despliegues sin downtime Haz push a tu rama y Nodion construye una nueva release. El tráfico pasa a las nuevas instancias cuando superan el health check; si una release falla, la que está en marcha sigue activa. En cambio, las apps con un volumen local se reinician porque el disco pertenece a una sola instancia.
• Bases de datos junto a la app PostgreSQL, pgvector, MySQL, Valkey y ClickHouse gestionados en la misma región. Al vincular una base de datos, sus datos de conexión llegan como DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Previews por pull request Activa las previews: cada pull request de tu repositorio tendrá su propia app, con URL y bases de datos nuevas y vacías. Puedes crearla automáticamente o a mano. Se omiten las pull requests de forks y bots.
• Workers, cron jobs y escalado Ejecuta workers como procesos adicionales de la misma app, programa tareas en la pestaña Cron y escala cada proceso hasta 16 instancias.
• Paso de release Con buildpacks, una línea release: del Procfile se ejecuta con cada nueva build. Las apps con Dockerfile, así como los redeploys o rollbacks a una imagen anterior, usan un comando de release definido en la propia app, que además tiene prioridad sobre la línea del Procfile. En los sitios estáticos, el paso de release se ejecuta en una imagen que solo contiene los archivos generados por la build.
• Logs y métricas Logs de build, release y runtime, además de métricas de CPU, memoria, disco y red de cada instancia, en el dashboard.
• Dominios y HTTPS Un nombre de host predeterminado con HTTPS desde el primer despliegue; tus propios dominios reciben certificados automáticamente.

Para seguir leyendo

• Dockerfile vs buildpacks: ¿cuál deberías usar? Los dos convierten tu código en una imagen de contenedor. Lo que cambia es quién escribe los pasos de la build, y eso decide el control, el mantenimiento y las actualizaciones de seguridad.
• Cloud Native Buildpacks: qué son y cómo funcionan Los buildpacks convierten tu código fuente en una imagen de contenedor sin Dockerfile. Te explicamos qué son y cómo funcionan.

PHP en Nodion: preguntas y respuestas