# Créer un site Laravel, WordPress, Next.js et plus

> Créez un site sur votre serveur à partir d'un preset comme Laravel, WordPress ou Next.js, avec dépôt, base de données, domaine et adresse de test gratuite.

Un **site** dans Vimonto Deploy est un site web ou une application sur l'un de vos serveurs : son propre domaine, sa configuration Nginx, son code, son `.env` et ses déploiements. Vous le créez à partir d'un preset de framework (Laravel, WordPress, Next.js et d'autres), qui choisit le runtime, le répertoire web, la commande de build et un script de déploiement adapté.

Quand vous créez un site, Vimonto Deploy le configure sur le serveur, lie son dépôt et le déploie aussitôt. Quelques minutes plus tard, le site est en ligne sur une adresse `on-deploy.link` générée, avant même que vous ayez touché au DNS.

![Le formulaire de nouveau site avec un serveur, un dépôt, une base de données et une adresse générée renseignés](https://ops.vimonto.com/docs-media/fr/create-site.webp?v=161e760d "Création d'un site Laravel")

![Remplissage du formulaire de nouveau site et création du site](https://ops.vimonto.com/docs-media/fr/create-site.mp4?v=161e760d)

## Retrouver tous vos sites

L'onglet **Sites** de la barre supérieure liste tous les sites de l'organisation, sur l'ensemble de ses serveurs. Chaque ligne affiche le domaine avec l'icône du framework, et en dessous le serveur, le framework, la version de PHP et la branche. **Déployé** indique depuis combien de temps le site a été déployé pour la dernière fois (ou **pas encore déployé**), et **Statut** montre s'il est prêt ou encore occupé. Recherchez par domaine, triez par colonne et cliquez sur une ligne pour ouvrir le site.

Si votre organisation utilise des [équipes](https://ops.vimonto.com/docs/fr/organization/teams), vous ne voyez que les sites des serveurs auxquels vous avez accès. La page **Sites** d'un serveur ne liste que les sites de ce serveur.

![La liste des sites de l'organisation avec, pour chaque site, son serveur, son framework, son dernier déploiement et son statut](https://ops.vimonto.com/docs-media/fr/sites-list.webp?v=161e760d "Les sites de l'organisation")

## Démarrer un nouveau site

1. Ouvrez un serveur et allez sur sa page **Sites**.
2. Cliquez sur **Nouveau site** et choisissez la technologie du site, par exemple **Laravel** ou **WordPress**.
3. Remplissez le formulaire (chaque champ est décrit ci-dessous) et cliquez sur **Créer le site**.

**Nouveau site** dans la liste **Sites** de l'organisation propose le même menu de frameworks. Le formulaire vous laisse ensuite choisir le serveur, et son lien **← Sites** ramène à la liste de l'organisation plutôt qu'à celle du serveur.

Les sites se placent sur des serveurs qui servent des sites web : un serveur d'application ou un serveur web. Un load balancer n'accueille que des sites à charge répartie (consultez [répartition de charge](https://ops.vimonto.com/docs/fr/sites/load-balancing)). S'il n'existe pas encore de serveur adapté, le formulaire affiche **Pas encore de serveur pour les sites** et propose **Nouveau serveur**. Consultez [types de serveurs](https://ops.vimonto.com/docs/fr/servers/server-types) pour savoir ce qu'installe chaque type.

Il vous faut la permission de gérer les sites dans l'organisation ; consultez [membres et rôles](https://ops.vimonto.com/docs/fr/organization/members-and-roles). L'offre gratuite comprend 3 sites pour l'ensemble des serveurs de l'organisation ; quand ils sont utilisés, le formulaire affiche **Votre offre est pleine** avec **Voir les offres**. Consultez la [facturation](https://ops.vimonto.com/docs/fr/organization/billing).

## Quels frameworks pouvez-vous choisir ?

Le menu **Nouveau site** regroupe les presets par langage. Chaque preset définit le runtime (la façon dont Nginx sert le site) et des valeurs par défaut adaptées, que vous pouvez modifier sous **Paramètres avancés**.

| Preset | Runtime | Répertoire web | Composer | Commande de build par défaut | Dépôt |
|---|---|---|---|---|---|
| Laravel | Laravel (PHP) | `/public` | Oui | `npm run build` | Oui |
| Symfony | PHP | `/public` | Oui | aucune | Oui |
| Statamic | Laravel (PHP) | `/public` | Oui | `npm run build` | Oui |
| WordPress | PHP | `/` | Non | aucune | Non, installé pour vous |
| phpMyAdmin | PHP | `/` | Non | aucune | Non, installé pour vous |
| PHP | PHP | `/public` | Oui | aucune | Oui |
| Next.js | Node.js | non utilisé | Non | `npm run build` | Oui |
| Nuxt | Node.js | non utilisé | Non | `npm run build` | Oui |
| HTML | Statique | `/` | Non | aucune | Oui |
| Autre | PHP | `/` | Non | aucune | Oui |
| Load balancer | Proxy vers vos serveurs d'application | non utilisé | Non | aucune | Non |

Ce que signifient les runtimes :

- **Laravel** : PHP-FPM derrière Nginx, avec le dossier `storage/` de Laravel partagé entre les releases, des queue workers et le planificateur.
- **PHP** : toute application PHP avec un `index.php`, comme Symfony ou WordPress.
- **Statique** : du HTML, ou un frontend compilé en fichiers (Vite, Astro, un export statique de Next.js).
- **Node.js** : une application qui écoute sur un port ; Nginx lui transmet les requêtes.

Le preset **Load balancer**, sous **Répartition de charge** dans le menu, est réservé aux serveurs load balancer et c'est le seul type de site qu'ils accueillent. Il n'a ni code ni déploiements : il transmet les requêtes à vos serveurs d'application. Son formulaire n'a ni dépôt, ni base de données, ni **Paramètres avancés**, puisqu'il n'y a rien à construire ni à isoler. Consultez [répartition de charge](https://ops.vimonto.com/docs/fr/sites/load-balancing).

### WordPress et phpMyAdmin

WordPress et phpMyAdmin n'ont pas besoin de dépôt. Vimonto Deploy télécharge la dernière version sur le serveur et écrit sa configuration :

- **WordPress** reçoit un `wp-config.php` avec le nom, l'utilisateur et le mot de passe de la base de données, ainsi que de nouvelles clés et salts de sécurité. WordPress a toujours besoin d'une base de données : **Connecter une base de données** ne peut donc pas être désactivé.
- **phpMyAdmin** reçoit un `config.inc.php` qui se connecte, avec une authentification par cookie, au serveur de base de données de la même machine.

Ouvrez ensuite le site pour terminer l'installation de WordPress dans le navigateur.

## Remplir le formulaire

### Serveur

Choisissez le serveur sur lequel placer le site. Seuls les serveurs actifs pouvant héberger ce type de site sont listés, avec leur adresse IP : les serveurs d'application et les serveurs web pour tous les presets, les load balancers uniquement pour le preset **Load balancer**.

### Code source, dépôt et branche

Sous **Code source**, choisissez l'une de vos [connexions Git](https://ops.vimonto.com/docs/fr/connections/source-control) (GitHub, GitLab ou Bitbucket), ou **URL Git personnalisée**.

- Avec une connexion, choisissez le **Dépôt** (éventuellement filtré par **Organisation**) et la **Branche**.
- Avec **URL Git personnalisée**, saisissez l'**URL Git**, comme `git@github.com:you/project.git` ou `https://github.com/you/project.git`, et la **Branche**.

Le dépôt est facultatif. Sans dépôt, le site est configuré avec une page d'attente et vous pouvez connecter un dépôt plus tard sur la page [Déploiements](https://ops.vimonto.com/docs/fr/sites/deployments).

### Connecter une base de données

Sur un serveur doté d'une base de données, **Connecter une base de données** est activé par défaut avec une nouvelle base nommée d'après le site (par exemple `shop_example_com`). Vous pouvez :

- Cliquer sur **Modifier** ou **Créer la base de données** pour choisir le nom, un **Utilisateur** dédié et un **Mot de passe**. Laissez l'utilisateur vide pour utiliser l'utilisateur de base de données propre au serveur. Laissez le mot de passe vide et un mot de passe est généré.
- Choisir une base de données existante dans la liste. Le site reçoit alors son propre utilisateur de base de données pour celle-ci, afin de ne jamais partager un mot de passe avec un autre site.

Pour les sites Laravel et Statamic, le nom, l'utilisateur et le mot de passe de la base de données sont écrits dans le `.env` du site. Consultez [bases de données](https://ops.vimonto.com/docs/fr/servers/databases) pour les gérer ensuite.

### Domaine ou adresse générée

Chaque site peut recevoir une adresse gratuite sur `on-deploy.link`, comme `kalme-rivier-4821.on-deploy.link`. Vous pouvez modifier la première partie du nom dans le champ **Adresse on-deploy.link**. Elle fonctionne immédiatement, sans aucun DNS de votre part, ce qui est pratique pour tester et partager. Un site qui tourne sur cette adresse reçoit aussi HTTPS automatiquement (voir ci-dessous).

Pour utiliser votre propre domaine, cliquez sur **Utiliser un domaine personnalisé** et saisissez-le, par exemple `shop.example.com`. Laissez **Aussi …on-deploy.link** coché si le site doit aussi répondre sur l'adresse générée.

Le domaine a ensuite besoin d'enregistrements DNS qui pointent vers le serveur. Avec des intégrations DNS, l'indication sous le domaine dit « Nous cherchons le domaine chez tes fournisseurs DNS et configurons ses enregistrements automatiquement. » Pendant la saisie, un encadré **DNS** indique si l'une de vos [intégrations](https://ops.vimonto.com/docs/fr/connections/integrations) (Hetzner Cloud, DigitalOcean, Vultr, Akamai, AWS, Google Cloud ou Cloudflare) le gère ; leurs listes de domaines sont récupérées en direct :

- Si c'est le cas, **Le faire pointer automatiquement avec …** est choisi. L'encadré liste les enregistrements (un enregistrement A pour le domaine et un CNAME pour `www.`) comme **Nouveau**, **Déjà correct** ou **Modifications**, avec un avertissement pour tout ce qui change ou est supprimé. Si des enregistrements existants changent, cochez **Modifier ces enregistrements**. Après la configuration, Vimonto Deploy met à jour les enregistrements, attend que le domaine soit résolu et demande HTTPS de lui-même. Choisissez **Je gère le DNS moi-même** pour ne pas toucher au DNS.
- Si aucune ne le gère mais que vous avez des intégrations DNS, activez **Ajouter le domaine à un fournisseur DNS** et choisissez le **Fournisseur** et la **Zone** (par défaut le domaine sans son sous-domaine, par exemple `example.com`). Vimonto Deploy y crée la zone, configure les enregistrements et liste dans la sortie de la tâche les serveurs de noms à configurer chez votre registraire ; HTTPS suit dès que le DNS est résolu.
- Sinon, faites vous-même pointer le domaine vers l'adresse IP du serveur avec un enregistrement A chez votre fournisseur DNS.

> [!TIP]
> Le DNS de votre domaine peut être configuré pour vous. Connectez Cloudflare, Hetzner Cloud, DigitalOcean, Vultr, Akamai, AWS ou Google Cloud dans les [intégrations](https://ops.vimonto.com/docs/fr/connections/integrations) : Vimonto Deploy y trouve le domaine, crée ses enregistrements et demande HTTPS lui-même. Sans connexion, le formulaire du domaine affiche **Astuce : laissez-nous configurer les enregistrements DNS** avec un lien pour en connecter une.

Consultez [domaines et SSL](https://ops.vimonto.com/docs/fr/sites/domains-and-ssl#faire-pointer-votre-domaine-automatiquement-avec-une-intégration-dns) pour la signification de chaque avertissement.

Vous pourrez ajouter d'autres domaines, désactiver l'adresse générée et activer HTTPS plus tard ; consultez [domaines et SSL](https://ops.vimonto.com/docs/fr/sites/domains-and-ssl).

### Installer les paquets Composer

Pour les sites Laravel, Symfony, Statamic et PHP avec un dépôt, **Installer les paquets Composer** ajoute `composer install` au script de déploiement. Désactivez-le si votre projet n'a pas de `composer.json` ou installe ses paquets autrement.

### Clé de déploiement dédiée

Avec **Clé de déploiement dédiée pour GitHub** (ou GitLab, Bitbucket ; **Clé de déploiement dédiée pour votre hébergeur Git** avec une URL Git personnalisée) activé, ce qui est le cas par défaut, le site reçoit sa propre clé SSH pour son dépôt. Avec un hébergeur Git connecté, Vimonto Deploy l'enregistre comme deploy key en lecture seule sur le dépôt. Avec une URL Git personnalisée, vous copiez la clé depuis la page Déploiements et l'ajoutez vous-même chez votre hébergeur Git.

Un dépôt d'un hébergeur Git connecté reçoit aussi **Déployer à chaque push** activé : Vimonto Deploy ajoute un webhook, et chaque push sur la branche lance un déploiement. Vous pouvez le désactiver sur la page [Déploiements](https://ops.vimonto.com/docs/fr/sites/deployments#push-to-deploy).

## Paramètres avancés

Cliquez sur **Paramètres avancés** pour modifier les valeurs par défaut du preset. Cliquez sur **Enregistrer les paramètres** pour les conserver.

| Réglage | Effet |
|---|---|
| **Répertoire racine** | L'emplacement de l'application dans le dépôt. `/` correspond au dépôt entier ; utilisez `/backend` ou similaire pour un monorepo. |
| **Répertoire web** | Ce que Nginx sert, dans le répertoire racine, comme `/public` ou `/dist`. Non affiché pour les sites Node.js. |
| **Version de PHP** | L'une des versions de PHP installées sur le serveur. Consultez [PHP](https://ops.vimonto.com/docs/fr/servers/php). |
| **Gestionnaire de paquets frontend** | npm (par défaut), yarn, pnpm ou bun. Yarn et pnpm passent par Corepack. |
| **Commande de build** | S'exécute après l'installation des paquets, comme `npm run build`. Vide : rien n'est compilé. |
| **Isolation des sites** | Donne au site son propre utilisateur Linux, avec un **Nom d'utilisateur** de votre choix. |
| **Déploiements sans interruption** | Construit chaque déploiement dans une nouvelle release et ne bascule qu'une fois celui-ci réussi. Activé par défaut. |
| **Authentification Composer** | Hôte, nom d'utilisateur et mot de passe ou token pour les paquets Composer privés, comme `repo.packagist.com`. |
| **Authentification npm** | Registre et token pour un registre npm privé, comme `https://npm.pkg.github.com`. |

### Déployer un monorepo

Définissez le **Répertoire racine** sur le dossier de l'application, par exemple `/backend`. Le dépôt entier est cloné, mais le script de déploiement s'exécute dans ce dossier, le `.env` y est lié et le répertoire web y est recherché. Un déploiement échoue avec un message clair si le dossier n'existe pas dans le dépôt.

### Isolation des sites

Un site isolé tourne sous son propre utilisateur Linux, avec un répertoire personnel que les autres sites ne peuvent pas lire. Un site PHP reçoit aussi son propre pool PHP-FPM, qui tourne sous cet utilisateur. Nginx peut toujours servir les fichiers, car l'utilisateur système du serveur rejoint le groupe du site. Utilisez-la quand plusieurs clients ou projets partagent un même serveur.

L'utilisateur est choisi à la création du site. Le nom doit se composer de lettres minuscules, de chiffres, de `_` et de `-`, commencer par une lettre, et ne pas être un nom système comme `root` ou `www-data`.

### Déploiements sans interruption

Avec les déploiements sans interruption, chaque déploiement est construit dans un nouveau répertoire de release et passe en ligne en une seule bascule atomique : les visiteurs ne voient jamais un site à moitié construit et vous pouvez revenir en arrière. Désactivés, une seule release est mise à jour sur place : c'est plus rapide, mais les visiteurs peuvent voir le build se dérouler et il n'y a pas de rollback. Vous pouvez changer cela plus tard dans les [paramètres du site](https://ops.vimonto.com/docs/fr/sites/site-settings). Consultez [déploiements](https://ops.vimonto.com/docs/fr/sites/deployments) pour les détails.

### Paquets Composer et npm privés

Les identifiants saisis sous **Authentification Composer** et **Authentification npm** sont stockés chiffrés et utilisés uniquement pendant le build : Composer les lit depuis `COMPOSER_AUTH`, et npm depuis un fichier de configuration temporaire supprimé ensuite. Vous pouvez les ajouter, les modifier ou les supprimer plus tard dans les **Paramètres** du site, onglets **Composer** et **npm** : voir [identifiants Composer et npm](https://ops.vimonto.com/docs/fr/sites/site-settings#identifiants-composer-et-npm).

## Que se passe-t-il après avoir cliqué sur Créer le site ?

Vous arrivez sur la page du site, qui n'affiche que la configuration tant que le site n'est pas en ligne : les phases, l'étape en cours et le log de chaque tâche. Vous pouvez quitter la page à tout moment ; le travail continue en arrière-plan.

1. **Configurer** : Vimonto Deploy crée l'enregistrement DNS de l'adresse générée, crée la base de données et son utilisateur, crée les répertoires du site, écrit le `.env`, le pool PHP-FPM (si le site est isolé) et la configuration Nginx. Jusqu'au premier déploiement, le site affiche une page indiquant qu'il est prêt. WordPress et phpMyAdmin sont installés pendant cette phase.
2. **Lien** : avec un dépôt, la deploy key est placée sur le serveur et, avec un hébergeur Git connecté, enregistrée sur le dépôt en même temps que le webhook de push.
3. **Récupérer, Build, En ligne** : le premier déploiement clone la branche, exécute le script de déploiement et met la release en ligne.
4. **HTTPS** : pour un site dont l'adresse est l'adresse `on-deploy.link` générée, et pour un site sur son propre domaine qu'une intégration DNS fait pointer. Pour son propre domaine, Vimonto Deploy met d'abord à jour les enregistrements DNS comme le plan l'indiquait. Il attend ensuite que le nom pointe vers le serveur (au maximum 10 minutes), puis demande un certificat Let's Encrypt gratuit et passe le site en HTTPS. Cette phase se déroule en parallèle du premier déploiement et c'est la dernière affichée. Si elle échoue, le site continue de fonctionner en HTTP ; demandez un certificat plus tard dans [domaines et SSL](https://ops.vimonto.com/docs/fr/sites/domains-and-ssl).

Un site créé avec son propre domaine dont vous gérez vous-même le DNS saute la phase HTTPS, car son DNS ne pointe peut-être pas encore vers le serveur. Demandez son certificat une fois que c'est le cas.

Pendant la mise en place (installation, connexion du dépôt, premier déploiement et premier certificat HTTPS), cette vue d'ensemble avec ses étapes est la seule page du site, avec le log du premier déploiement : il n'y a pas de barre latérale, et les autres pages du site y ramènent.

Une fois tout terminé, la page devient la vue d'ensemble habituelle du site, avec sa barre latérale. La première fois que vous (ou quelqu'un d'autre de l'organisation) l'ouvrez ensuite, elle commence par **Votre site est en ligne**, la durée de la mise en place et un bouton **Ouvrir** ; **Fermer** le masque, et les visites suivantes n'affichent que la vue d'ensemble.

Sur le disque, chaque site se trouve dans `/home/{user}/{domain}`, avec `releases/`, `shared/` et un lien symbolique `current`. Le répertoire garde son nom quand vous changez plus tard le domaine du site.

Si une phase échoue, la page affiche **Échec de l'installation**, **La connexion du dépôt a échoué** ou **Le premier déploiement a échoué**, avec l'erreur et le log de l'étape en cause (sous **Détails et log**). Corrigez la cause (un nom de branche, une deploy key manquante) et utilisez le bouton de la page : **Réessayer**, **Reconnecter** ou **Redéployer**. Quand une phase a échoué, la barre latérale et toutes les pages du site reviennent, pour corriger la cause sur les pages **Déploiements** et **Environnement**.

### Et ensuite ?

- Pour un site sur son propre domaine dont vous gérez vous-même le DNS, activez HTTPS avec un certificat Let's Encrypt gratuit dans [domaines et SSL](https://ops.vimonto.com/docs/fr/sites/domains-and-ssl).
- Vérifiez le `.env` dans [environnement](https://ops.vimonto.com/docs/fr/sites/environment).
- Pour Laravel, ajoutez des queue workers et le planificateur dans [files d'attente et planificateur](https://ops.vimonto.com/docs/fr/sites/queues-and-scheduler), ou activez Horizon dans le menu des [fonctionnalités de site](https://ops.vimonto.com/docs/fr/sites/site-features).
- Avec une URL Git personnalisée, appelez l'[URL de déploiement](https://ops.vimonto.com/docs/fr/sites/deployments#déployer-depuis-la-ci-avec-lurl-de-déploiement) depuis votre hébergeur Git ou votre CI pour déployer à chaque push.

![Les sites d'un serveur avec leurs domaines et leurs derniers déploiements](https://ops.vimonto.com/docs-media/fr/server-sites.webp?v=161e760d "Les sites d'un serveur")

## Questions fréquentes

### Ai-je besoin d'un domaine pour créer un site ?

Non. Chaque site peut recevoir une adresse `on-deploy.link` générée qui fonctionne immédiatement. Ajoutez votre propre domaine quand vous êtes prêt.

### Puis-je héberger plusieurs sites sur un serveur ?

Oui. Un serveur peut accueillir autant de sites que ses ressources le permettent. Chaque site a sa propre configuration Nginx et son propre répertoire ; activez l'isolation des sites pour donner aussi à chacun son propre utilisateur Linux.

### Quel dépôt WordPress utilise-t-il ?

Aucun. WordPress et phpMyAdmin sont téléchargés et installés sur le serveur à la création du site. Si vous gardez un projet WordPress dans Git, choisissez plutôt le preset **PHP** et connectez votre dépôt.

### Comment déployer une application Next.js ou Nuxt ?

Choisissez **Next.js** ou **Nuxt**. Le site reçoit un port local libre (à partir de 3000) vers lequel Nginx transmet les requêtes, et le script de déploiement installe les paquets et exécute `npm run build`. Vimonto Deploy ajoute aussi le processus qui fait tourner votre application sur ce port, et le premier déploiement le démarre. Vous le trouvez sous [Processus](https://ops.vimonto.com/docs/fr/sites/queues-and-scheduler#faire-tourner-une-application-nodejs).

### Puis-je répartir un site sur plusieurs serveurs ?

Oui, avec un serveur load balancer placé devant deux serveurs d'application ou plus, qui font chacun tourner le même site. Consultez [répartition de charge](https://ops.vimonto.com/docs/fr/sites/load-balancing).

### Puis-je changer de framework plus tard ?

Non, le preset est choisi à la création du site. La version de PHP, le répertoire web, le port Node.js et les déploiements sans interruption peuvent être modifiés dans les [paramètres du site](https://ops.vimonto.com/docs/fr/sites/site-settings), et le script de déploiement sur la page [Déploiements](https://ops.vimonto.com/docs/fr/sites/deployments).

### Puis-je copier un site existant ?

Oui. Dans les **Paramètres** du site, cliquez sur **Cloner le site** pour créer un nouveau site avec le même dépôt, les mêmes réglages de build, le même script de déploiement et les mêmes règles, sur le même serveur ou sur un autre. Voir [cloner un site](https://ops.vimonto.com/docs/fr/sites/site-settings#cloner-un-site).