Deploy+

Deploy+.
Du push à la production.

Connectez vos dépôts GitHub, GitLab, Bitbucket ou Gitea à l'hébergement et oubliez la dernière étape : chaque push publie une nouvelle version sans interruption, avec vos commandes de build, et revenir en arrière tient en un clic.
Voir les offres Lire le guide
tuproyecto/web · main Deploy+
  1. 01 Push
  2. 02 Build
  3. 03 Publier
  4. 04 En ligne

en attente de changements…

Versions

Chaque version est conservée : revenir en arrière tient en un clic, sans coupure.

Un git push

et le déploiement démarre tout seul, sans passer par le panneau

Sans interruption

la nouvelle version est publiée en changeant un lien

Rollback en quelques secondes

vous revenez à n'importe quelle version précédente depuis l'historique

Gratuit

inclus dans toutes les offres d'hébergement

Fonctionne avec votre Git, où qu'il soit

Comment créer le jeton dans chacun →
GitHub github.com · webhook et signature GitLab gitlab.com ou votre propre instance Bitbucket bitbucket.org · webhook et signature Gitea / Forgejo Codeberg ou votre propre installation Autre serveur Git n'importe quel dépôt en HTTPS

Comment ça marche

Quatre étapes, et vous n'y touchez plus.

Votre code est déjà versionné. Il manquait la dernière étape : le mettre en production sans envoyer de fichiers à la main ni croiser les doigts.

Connecter

Votre dépôt, où qu'il soit

GitHub, GitLab, Bitbucket, Gitea ou tout Git en HTTPS, public ou privé, avec un jeton en lecture seule. Avant de continuer, le panneau interroge l'API et vous montre le dépôt, ses branches et ce qu'il y a actuellement dans le dossier de destination.
https:// jeton en lecture seule accès vérifié

aussi sur les comptes d'une offre Multi-comptes

Cinq fournisseurs, une destination

en HTTPS
Deploy+

Push

Faites un push et le déploiement démarre tout seul

Nous créons le webhook lors de la connexion du dépôt, et chaque notification arrive signée. Si vous préférez décider vous-même du moment, lancez-le d'un clic ou depuis votre intégration continue avec le lien de déploiement.
L'habituel
Envoyer des fichiers à la main et croiser les doigts
Ici
Un push, et GitHub prévient le serveur

Du push au déploiement

webhook signé
Un push sur la branche prévient par webhook et le déploiement démarre tout seul GITHUB · PUSH main · a91f3c2 fix: checkout avec coupon POST · HMAC HOSTSUAR · DEPLOY+ signature vérifiée branche main : est déployée deploy #48 en cours
Notification signée · deploy #48 en file d'attente

Publier

Déploiement atomique, sans coupure

Chaque version est clonée dans son dossier, votre .env et vos dossiers partagés sont liés et votre script s'exécute. Ce n'est que si tout s'est bien passé qu'elle est publiée : un lien change, et la précédente est toujours là.

0 s

d'interruption : la nouvelle version est publiée en changeant un lien

Déploiement atomique

~/deploy/tienda/

releases/

├─ 20260904-1830 · publiée

└─ 20260905-1012 · clonage et exécution du script…

shared/

├─ .env → lié dans chaque version

└─ storage/ → lié dans chaque version

current → releases/20260904-1830

Préparation de la nouvelle version ; la précédente reste en ligne

Revenir en arrière

Rollback en un clic, depuis l'historique

Date, auteur du lancement, commit, durée et journal complet de chaque déploiement. Les dernières versions restent sur le serveur : revenir à l'une d'elles prend quelques secondes, car il n'y a rien à cloner.

5 versions

conservées par défaut ; vous décidez combien

Lire le guide complet

Historique des déploiements

5 versions enregistrées
DateDéclencheurTemps
aujourd'hui 10:12 · a91f3c2 Push 38 s
hier 18:30 · e07b9d4 Manuel 41 s
hier 11:05 · 4c1d8e7 Rollback 2 s
lun. 09:48 · 4c1d8e7 Push 35 s

hier 18:30 · e07b9d4

la version reste sur le serveur

Revenir à cette version

Assistant

Il sait de quel projet il s'agit et le prépare.

Vous choisissez le type de projet et l'assistant propose la racine web, le script, les dossiers partagés et la nécessité ou non d'une base de données. Ensuite, vous ajustez vous-même.

  • PHP

    Laravel

    Composer, caches optimisés et publication depuis public.

    Racine web
    public/
    Partagé
    storage
    Base de données
    la prépare
    Assets avec Node
    si vous la cochez

  • PHP

    Symfony

    Composer, environnement prod et publication depuis public.

    Racine web
    public/
    Partagé
    var/log
    Base de données
    la prépare
    Assets avec Node
    si vous la cochez

  • PHP

    WordPress

    Base de données, wp-config.php et fichiers envoyés persistants.

    Racine web
    racine
    Partagé
    wp-content/uploads, wp-config.php
    Base de données
    la prépare
    Assets avec Node
    si vous la cochez

  • PHP

    PHP / Composer

    Une base propre pour les applications PHP avec Composer.

    Racine web
    racine
    Partagé
    —
    Base de données
    la prépare
    Assets avec Node
    si vous la cochez

  • Statique

    Frontend compilé

    Compile avec Node et publie le résultat de dist.

    Racine web
    dist/
    Partagé
    —
    Base de données
    pas nécessaire
    Assets avec Node
    toujours

  • Statique

    HTML statique

    Publie le dépôt tel quel, sans rien installer.

    Racine web
    racine
    Partagé
    —
    Base de données
    pas nécessaire
    Assets avec Node
    —

  • Sur mesure

    Autre projet

    Pas de suppositions : vous choisissez la racine, le script et la persistance.

    Racine web
    racine
    Partagé
    —
    Base de données
    la prépare
    Assets avec Node
    si vous la cochez

Ce qui est inclus

Ce qu'il faut pour déployer sérieusement.

Cinq décisions du moteur qu'on ne voit pas dans un « déploiement depuis Git » ordinaire, et que vous remarquerez le jour où quelque chose échouera.

Script et Node

Vos commandes, sur chaque version, avec Node si nécessaire

Composer, npm, artisan… commande par commande ou sous forme de script Bash complet, avec le commit, les chemins et votre .env comme variables. S'il utilise Node et que le compte ne l'a pas, il est installé avant.
Composer npm ci artisan Node via NVM

si une commande échoue, la version précédente reste en ligne

Script de déploiement

modèle · Laravel
Laravel Symfony WordPress PHP Node / Vite Aucune

composer install --no-dev --prefer-dist --optimize-autoloader

npm ci && npm run build # Node installé via NVM s'il manque

php artisan migrate --force # facultatif : le rollback n'annule pas les données

php artisan config:cache && php artisan route:cache

Si une commande échoue, le déploiement s'arrête et la version précédente reste en ligne.

Base de données

La base de données, créée à la connexion

Cochez « préparer aussi la base de données » et Deploy+ crée une base MySQL vide, un utilisateur dédié et écrit la connexion dans votre .env ou wp-config.php. Le mot de passe n'est enregistré nulle part.

MySQL

base, utilisateur et fichier en une seule opération

Base de données · à la connexion

prête
  • Base MySQL vide mi_app
  • Utilisateur dédié avec tous les privilèges mi_app_usr
  • Connexion écrite dans .env sans rien toucher à la main

DB_DATABASE=mi_app

DB_USERNAME=mi_app_usr

DB_PASSWORD=•••••••••••• # n'est pas enregistré dans le panneau

Configuration

Le .env et les fichiers envoyés survivent à chaque version

Le .env est conservé automatiquement et vous le modifiez depuis le panneau. Les chemins que vous cochez, comme storage ou uploads, se trouvent dans shared et sont liés à chaque nouvelle version. Le profil du projet propose déjà les siens.
L'habituel
Fichiers envoyés et .env dans le code, à la merci de chaque déploiement
Ici
En dehors du code : ni un déploiement ni un rollback n'y touchent

Partagé entre les versions

~/deploy/tienda/

shared/ → releases/20260905-1012/

.envmodifiable

storage/du profil

public/uploads/la vôtre

Liées dans chaque nouvelle version ; un rollback n'y touche pas non plus.

Console

Console en direct et commandes sur ce qui est publié

Pendant le déploiement, vous voyez chaque étape avec sa durée et, en cas d'échec, les dernières lignes. Ensuite, une commande quand vous en avez besoin sur la version publiée, sans ouvrir de terminal.

6 étapes

connecter, cloner, partagés, script, activer, nettoyer

Exécuter une commande

sur current · max. 2 min
$php artisan queue:restart Exécuter

~/deploy/tienda/current

$ php artisan queue:restart

Broadcasting queue restart signal.

✓ terminé en 0,4 s

Sécurité

Un jeton avec le strict minimum, chiffré et hors du journal

Lire le dépôt et, si vous voulez que nous créions le webhook, gérer les webhooks. Rien de plus. Chaque notification de push est vérifiée avec la signature du fournisseur.
lecture seule chiffré signature HMAC

révoquez-le quand vous voulez : seul le déploiement cesse de fonctionner

Autorisations du jeton

le strict minimum, et chiffré
FournisseurClonerWebhook
GitHubcontents + metadata · read+ webhooks
GitLabread_repository+ api
Bitbucketrepositories · read+ webhooks
Gitea / Forgejolecture+ webhooks
Autre Gitutilisateur + jeton—

Chiffré, uniquement pour cloner, jamais dans le journal.

Tout cela est inclus dans toutes les offres d'hébergement et dans les comptes d'une offre Multi-comptes, sans frais.

Lire le guide complet →

Questions

Avant de connecter le premier dépôt.

Dans quelles offres Deploy+ est-il inclus ?

Dans toutes les offres d'hébergement, sans coût supplémentaire. L'outil se trouve dans l'espace client, parmi les options de votre service d'hébergement.

Fonctionne-t-il avec des dépôts privés ?

Oui, avec les dépôts publics comme privés. Dans les deux cas, il faut un jeton d'accès GitHub : créez-en un fine-grained, limité au dépôt que vous allez déployer, avec les permissions Contents: Read-only et Metadata: Read-only. Nous n'avons besoin d'aucun droit d'écriture sur votre code.

Mon site est-il coupé pendant le déploiement ?

Non. Chaque déploiement est cloné dans une nouvelle version, les fichiers partagés sont liés et vos scripts sont exécutés avant la mise en ligne : ce n'est que lorsque tout s'est bien passé que le lien symbolique current est basculé vers la nouvelle version, et ce changement est instantané. Si un script échoue, le déploiement s'arrête et la version précédente reste en ligne.

Comment revenir à la version précédente en cas de problème ?

Depuis l'historique, avec le bouton Rollback sur n'importe quel déploiement antérieur. Cela prend quelques secondes, car rien n'est cloné : seule change la version vers laquelle pointe current. Par défaut, les 5 dernières versions sont conservées, et vous pouvez régler le nombre de versions à garder.

Puis-je exécuter composer, npm ou des commandes artisan ?

Oui. Chaque dépôt dispose d'un éditeur de scripts où vous définissez les commandes exécutées sur chaque version avant sa mise en ligne : composer install --no-dev, npm run build, php artisan config:cache… Le système filtre les commandes dangereuses. Pour utiliser Node.js et npm, installez-les d'abord depuis le gestionnaire de paquets de cPanel.

Que deviennent le .env et les dossiers d'upload ?

Ils ne sont pas perdus d'un déploiement à l'autre. Le .env est détecté et préservé automatiquement, et vous pouvez ajouter les chemins de votre choix (storage/app, uploads…) comme fichiers partagés : ils sont conservés à part et liés dans chaque nouvelle version.

Votre prochain push, déjà déployé.

Deploy+ est inclus dans toutes les offres d'hébergement, parmi les options de votre service. Si vous venez d'un autre fournisseur, nous vous aidons à le mettre en place.
Voir les offres Contacter