Symfony (PHP)
Symfony fonctionne sur Kavio, avec quelques réglages à connaître.
1. Variables d'environnement
Dans le panneau de configuration à l'import (ou dans la section Variables d'environnement de la page projet), déclarez :
| Variable | Valeur | Pourquoi |
|---|---|---|
RAILPACK_PHP_ROOT_DIR | /app/public | Le point d'entrée d'une app Symfony est public/index.php, pas la racine du dépôt. Sans cette variable, votre app répond 404 sur toutes les routes. |
APP_ENV | prod | Sans elle, l'app tourne en environnement dev — plus lent, et pas ce que vous voulez servir à vos visiteurs. |
APP_SECRET | une chaîne aléatoire de votre choix | Requis par Symfony, absent du dépôt par convention (comme n'importe quel secret). |
2. Votre CSS ou vos scripts (Stimulus) ne s'affichent pas ? Passez par npm
Si votre projet utilise symfonycasts/sass-bundle et/ou AssetMapper (la config par défaut), votre site se déploie cassé — sans style, ou carrément en erreur 500 si un composant Stimulus (comme le sélecteur de langue) est utilisé quelque part. Kavio n'exécute pas ces compilations automatiques — c'est npm qu'il faut utiliser à la place, pour les deux.
La solution, un package.json à la racine du dépôt qui fait les deux choses en une seule commande :
{
"scripts": {
"build": "sass assets/styles/app.scss public/build/app.css && php bin/console importmap:install --env=prod --no-interaction"
},
"devDependencies": { "sass": "^1.77.0" }
}
Puis, dans votre template, un <link> classique à la place du chargement automatique par AssetMapper :
<link rel="stylesheet" href="{{ asset('build/app.css') }}">
Kavio lance npm run build automatiquement à chaque déploiement, juste après l'installation des dépendances PHP — bin/console et vendor/ sont donc déjà disponibles à ce moment-là. Rien d'autre à configurer.
Déjà sur Webpack Encore ? Rien à faire, ça fonctionne tel quel (pas d'AssetMapper, donc pas ce problème).
⚠️ Piège si vous retirez une dépendance : ne touchez jamais à composer.lock
En retirant symfonycasts/sass-bundle de composer.json, ne supprimez pas composer.lock pour autant, même si Composer râle sur un fichier plus tout à fait à jour. Le paquet retiré restera simplement présent dans vendor/ sans être chargé (inoffensif) — mais supprimer le lock force une résolution complète à zéro de toutes vos dépendances, ce qui peut produire des versions légèrement différentes de celles testées et casser des choses sans rapport apparent, jusqu'à l'enregistrement des services Symfony eux-mêmes. Gardez le lock, il n'y a aucune raison de le régénérer pour retirer un seul paquet.
Ce qui n'est pas nécessaire
Vous n'avez rien à faire concernant :
PORT— automatiquement imposé par la plateforme, votre app n'a pas à le déclarer ni à le lire.- Les assets publics (
public/) — servis normalement, exactement comme le reste de votre code. - Le cache et les logs (
var/cache/,var/log/) — le disque applicatif est inscriptible sur Kavio. Symfony y écrit son cache compilé et ses logs normalement, sans aucune redirection à configurer dansKernel.php.