Aller au contenu
Deploy
Parcourir la documentation

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.

Voir en Markdown Mis à jour le 7 octobre 2026

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
Création d'un site Laravel

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, 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
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). 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 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. 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.

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.

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

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

Consultez domaines et SSL 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.

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.

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.
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. Consultez déploiements 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.

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.

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 ?

Les sites d'un serveur avec leurs domaines et leurs derniers déploiements
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.

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.

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, et le script de déploiement sur la page Déploiements.

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.