Cet article est aussi disponible en :

Que puis-je déployer sur Hodifly ?

Types de déploiement

Site statique : HTML/CSS/JS (y compris les sites produits par un générateur de site statique). Servi directement sous forme de fichiers. C'est le plus rapide et le plus simple.
Application PHP : Laravel, Symfony, et plus largement toute application Composer dotée d'un contrôleur frontal (Lumen, CodeIgniter, Yii, CakePHP, Slim…). Composer, les migrations et la mise en cache sont exécutés automatiquement à chaque déploiement.
Application Node : un serveur Node persistant (Express, Fastify, NestJS) ou un framework en rendu serveur : Next.js, Nuxt, Astro, SvelteKit, Remix.
Application Python : une application WSGI (Flask, Django, FastAPI).
Application Ruby : une application Rack (Ruby on Rails, Sinatra). Bundler, la précompilation des assets et les migrations sont exécutés automatiquement.

Hodifly choisit le bon type automatiquement.

⚠️ Attention : les applications Node, Python et Ruby nécessitent un hébergement web SITE PRO. Les sites statiques (y compris ceux construits avec Node ou Python) et les applications PHP, en revanche, sont compatibles avec tous les hébergements web : PHP est servi par le serveur web lui-même.

Quels frameworks sont détectés automatiquement ?

Hodifly lit votre package.json, votre composer.json, vos fichiers de configuration et quelques manifestes pour pré-remplir la commande de build et le dossier de sortie. Détectés d'origine :

Builds statiques : Next.js (export statique), Nuxt, Astro, SvelteKit, Gatsby, Angular, Eleventy, Docusaurus, Vue, Svelte, React (CRA et Vite), Hugo, Jekyll, ainsi que le HTML statique simple.
Applications Node (rendu serveur) : Express, Fastify, Koa, Hapi, NestJS, ainsi que Next.js, Nuxt, Astro, SvelteKit, Remix et React Router v7 dès qu'ils sont configurés pour le rendu serveur (voir ci-dessous).
Applications PHP : Laravel, Symfony, Lumen, CodeIgniter 4, Yii 2, CakePHP et Slim, reconnus à partir du composer.json, ainsi que toute autre application disposant d'un contrôleur frontal.
Applications Python : Django, Flask, FastAPI (via requirements.txt / pyproject.toml / manage.py / passenger_wsgi.py).
Applications Ruby : Ruby on Rails, Sinatra et toute application Rack, reconnues à partir du Gemfile et du config.ru.

La détection reste une estimation au plus juste : vous pouvez toujours modifier la commande de build, le dossier de build, le runtime et le type avant de déployer.

Statique ou rendu serveur ? C'est votre dépôt qui décide

Plusieurs frameworks JavaScript savent produire les deux. Hodifly ne devine pas : il lit votre configuration.

Nuxt est en rendu serveur par défaut, et déployé en application Node. Passez-le en ssr: false dans nuxt.config pour obtenir un site pré-rendu (nuxt generate).
Astro est statique, sauf si l'adaptateur @astrojs/node est installé : il devient alors une application Node. Les autres adaptateurs (Cloudflare, Vercel, Netlify) ne peuvent pas fonctionner ici et restent sur la voie statique.
SvelteKit suit son adaptateur : @sveltejs/adapter-node donne une application Node, sinon adapter-static est supposé.
Remix et React Router v7 sont des applications Node. Un build ssr: false est publié en statique.

Applications PHP : ce que Hodifly fait pour vous

Pour un projet Laravel ou Symfony, il n'y a en principe aucune commande de build à saisir.

Racine du site : le domaine pointe vers le dossier du contrôleur frontal de la version déployée. Ce dossier est public/ pour Laravel, Symfony, Lumen, CodeIgniter et Slim, web/ pour Yii, webroot/ pour CakePHP. .env, vendor/, app/, config/ et storage/ ne sont donc pas accessibles en HTTP. Ce dossier reste corrigeable dans les réglages du projet si votre application est atypique.
Composer : install --no-dev --prefer-dist --optimize-autoloader est exécuté à chaque déploiement. Versionnez votre composer.lock.
Fichier .env : il est généré à chaque déploiement à partir des variables d'environnement du projet. Ne versionnez pas de .env : un fichier commité est ignoré, avec un avertissement dans le journal de déploiement. APP_KEY (Laravel) et APP_SECRET (Symfony) sont générés une fois et conservés hors des versions, pour que les sessions et les colonnes chiffrées survivent aux déploiements.
Migrations : elles sont jouées automatiquement avant la mise en ligne de la nouvelle version (php artisan migrate --force, ou doctrine:migrations:migrate si le bundle Doctrine Migrations est présent). Une migration en échec fait échouer le déploiement, et la version précédente continue de répondre. Posez la variable d'environnement HODIFLY_SKIP_MIGRATIONS=1 pour désactiver ce comportement. Attention : un retour arrière restaure le code, mais pas le schéma de la base de données.
Données persistantes : le storage/ de Laravel (fichiers envoyés, journaux, sessions) ainsi que les var/log et var/sessions de Symfony vivent hors des versions et sont liés à chacune. Ils survivent donc aux déploiements et aux retours arrière. Ce que l'application écrit ailleurs dans son propre dossier est perdu au déploiement suivant.
Assets front-end : Vite, Laravel Mix et Webpack Encore sont construits automatiquement si votre package.json contient un script build.
Tâches planifiées : si l'application planifie des tâches (routes/console.php ou app/Console/Kernel.php), Hodifly maintient une entrée * * * * * php artisan schedule:run dans le crontab du compte, visible et modifiable dans cPanel > Tâches Cron.
Non disponible : les WebSockets et les processus persistants (Octane, Horizon, Reverb, workers Messenger). Pour les files d'attente, ajoutez une tâche cron * * * * * php artisan queue:work --stop-when-empty --max-time=55, ou utilisez QUEUE_CONNECTION=sync pour les faibles volumes.

Paramètres de build avancés

Chemin du paquet (prise en charge des monorepos)

Si votre application se trouve dans un sous-dossier du dépôt (un monorepo), indiquez ce dossier dans le chemin du paquet (Package path). L'installation des dépendances, le build et la publication s'y exécutent alors. Vous pouvez déployer plusieurs applications depuis un même dépôt en créant un projet par sous-dossier : chacun se reconstruit uniquement quand les fichiers de son propre dossier changent.

Commande de build et dossier de build

Commande de build : ce que Hodifly exécute (par exemple npm run build). Laissez ce champ vide pour un dépôt déjà pré-construit, ou pour une application Laravel ou Symfony dont Composer et les assets sont gérés automatiquement.
Dossier de build : le répertoire produit par votre build et que Hodifly publie (par exemple dist, build, out, public, _site).

Runtime

Choisissez la version de PHP, de Node, de Python ou de Ruby utilisée pour construire et exécuter votre projet. Pour un projet PHP, la version est pré-remplie à partir de la contrainte de votre composer.json (">=8.2" donne 8.2) et vous pouvez la monter si une dépendance l'exige ; Hodifly aligne aussi la version MultiPHP du domaine, donc ne la modifiez pas ensuite dans cPanel. Sélectionnez Aucun pour un site statique livré déjà construit, sans étape de build (cela ignore l'étape npm install).

Variables d'environnement

Ajoutez vos variables clé/valeur sous Variables d'environnement. Elles sont transmises à votre commande de build (par exemple API_URL, NODE_ENV), à l'application en cours d'exécution pour les applications Node et Python, et servent à générer le .env des applications PHP. Elles sont :

Stockées sur votre propre serveur, jamais envoyées au plan de contrôle de Hodifly.
Chiffrées au repos.
Non affichées publiquement.

Mis à jour le : 15/08/2026

Cet article a-t-il répondu à vos questions ?

Merci !