> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.hodi.host/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# 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.

||| ⚠️ 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 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) ?](https://help.hodi.host/fr/article/comment-faire-tourner-des-workers-en-arriere-plan-files-horizon-messenger-1fhfun/)
* **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.