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, Vinext, Nuxt, TanStack Start, 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.

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 et Vinext (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, Vinext, Nuxt, TanStack Start, 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é.
• Vinext (Next.js sur Vite) lit votre next.config comme Next.js : il est déployé en application Node, et output: 'export' le publie en statique. Il nécessite Node 22 ou plus récent : retirez toute version de Node plus ancienne fixée dans .nvmrc ou engines.node. Un projet Vinext configuré pour Cloudflare Workers (@cloudflare/vite-plugin dans la configuration Vite) ne peut pas fonctionner ici : retirez ce plugin, ou chargez-le uniquement pour un déploiement sur Cloudflare.
• Remix et React Router v7 sont des applications Node. Un build ssr: false est publié en statique.
• TanStack Start est une application Node : elle est construite par Nitro, et ses fonctions serveur ont besoin d'un serveur pour y répondre. spa et prerender n'y changent rien. Demandez un build statique à Nitro (nitro: { preset: 'static' } dans la config Vite) et le site est publié en statique, sans application à faire tourner.

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.
• Files d'attente et workers en arrière-plan : pris en charge. Laravel queue:work, Laravel Horizon et Symfony Messenger tournent comme des processus supervisés, mis en place automatiquement à chaque déploiement quand votre application en a besoin, et redémarrés pour qu'ils exécutent toujours votre nouveau code. Vous pouvez aussi les gérer à la main dans cPanel > Workers. Plus d'infos : Comment faire tourner des workers en arrière-plan (files, Horizon, Messenger) ?
• Non disponible : les serveurs WebSockets (Reverb, Soketi) et Laravel Octane. Pour du temps réel, utilisez du polling, ou un serveur virtuel ou dédié où vous maîtrisez toute la pile.

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 : 07/10/2026