# Git Deploy

> Reliez votre serveur à un dépôt GitHub, GitLab, Gitea ou Forgejo et déployez automatiquement à chaque push, release ou tag, avec chemins protégés, redémarrages, vérifications CI et retour arrière en un clic.

L'onglet **Git Deploy** du Portail relie votre serveur à un dépôt Git sur **GitHub**, **GitLab**, **Gitea** ou **Forgejo**. Ses fichiers sont copiés sur votre serveur automatiquement — à chaque push, lorsque vous publiez une release, lorsque vous poussez un tag, ou d'un simple clic. Si vous le souhaitez, votre serveur est arrêté proprement avant le déploiement, puis redémarré ensuite.

En bref : poussez votre code, et quelques secondes plus tard il tourne sur votre serveur. Plus besoin de téléverser via SFTP, de décompresser des fichiers ZIP dans le gestionnaire de fichiers, ni d'oublier de redémarrer.

## Ce que vous allez apprendre

- Comment connecter un dépôt, avec l'app GitHub Daki Git Deploy ou avec un token d'accès
- Quand un déploiement a lieu et comment en lancer un vous-même
- Comment protéger mondes, bases de données et fichiers `.env` grâce aux chemins protégés
- Comment fonctionnent les redémarrages, l'historique des déploiements, les retours arrière et le statut dans votre dépôt
- Comment donner les bonnes permissions à votre équipe

---

## Pour qui

- **Développeurs de bots Discord et d'apps Node.js, Python ou Java** dont le code est déjà sur GitHub ou GitLab.
- **Réseaux Minecraft et équipes de serveurs de jeu** qui gardent plugins, configurations ou datapacks dans un dépôt et veulent que les changements se déploient de façon traçable.
- **Équipes :** plusieurs personnes travaillent sur le dépôt, le serveur est toujours à jour, et les permissions des sous-utilisateurs décident précisément qui peut déployer.
- **Projets basés sur les releases :** seules les versions publiées (par exemple un `.jar` finalisé issu d'une release) arrivent sur le serveur, et non chaque travail en cours.

---

## Avant de commencer

- Un serveur dans le Portail qui affiche l'onglet **Git Deploy**. Il se trouve dans la navigation du serveur, sous **Essentials**, juste après **Files** par défaut.
- Un dépôt sur GitHub (github.com), GitLab (gitlab.com ou votre propre instance, sous-groupes comme `group/subgroup/project` inclus), Gitea ou Forgejo (par exemple Codeberg ou votre propre instance). Les dépôts publics comme privés fonctionnent.

> **Remarque:** Daki détermine selon le type de serveur (egg) si l'onglet est affiché. Si vous ne voyez pas **Git Deploy**, il n'est pas activé pour le type de votre serveur.

> **Info:** Ce guide utilise les libellés anglais de l'onglet Git Deploy. L'onglet est disponible en 19 langues et suit la langue choisie dans le Portail — les boutons se trouvent au même endroit dans chaque langue.

---

## Démarrage rapide avec GitHub (recommandé)

La méthode la plus rapide : connectez-vous avec **Daki Git Deploy**, l'app GitHub officielle de Daki Hosting. Vous vous connectez sur GitHub et choisissez vos dépôts — **aucun token ni aucun webhook** n'est nécessaire.

**Étape 1: Ouvrir l'onglet Git Deploy**

Dans le Portail, ouvrez votre serveur et rendez-vous dans l'onglet **Git Deploy**. Sous **Git service**, choisissez **GitHub**.

**Étape 2: Connecter votre compte GitHub**

Dans l'encadré **GitHub access**, cliquez sur **Connect with GitHub**. Connectez-vous sur GitHub et autorisez l'app.

La première fois, GitHub vous amène ensuite directement au choix des dépôts auxquels l'app peut accéder (**All repositories** ou uniquement les dépôts sélectionnés) — en une seule étape au lieu de deux. Ensuite, vous revenez dans le Portail, et l'encadré **GitHub access** affiche **Connected via Daki Git Deploy as** suivi de votre nom GitHub. L'encadré **Webhook** confirme qu'il n'y a rien à configurer : les push et les releases arrivent par l'app toutes seules.

**Étape 3: Choisir votre dépôt et votre branche**

Cliquez sur **Choose from my repositories** et sélectionnez votre dépôt, ou collez son URL web ou de clonage, ou saisissez le chemin. Cliquez sur **Load branches** et choisissez la branche à déployer. Laissez le champ de branche vide pour utiliser la branche par défaut du dépôt.

**Étape 4: Choisir quand et comment déployer**

Sous **When to deploy**, choisissez un mode (par exemple **Every push**). Définissez ensuite le dossier cible, vos [chemins protégés](#protected-paths) et le [comportement au redémarrage](#restart-behavior).

**Étape 5: Enregistrer**

Cliquez sur **Save settings** dans la barre en bas. C'est tout : l'en-tête de l'onglet affiche **Automatic deploys on**, et votre prochain push sera déployé automatiquement. Pour déployer tout de suite, cliquez sur **Deploy now** en haut à droite.

- **Autoriser un autre dépôt :** **Choose repositories on GitHub** rouvre la sélection des dépôts sur GitHub, où vous choisissez les dépôts auxquels Daki Git Deploy peut accéder.
- **Supprimer la connexion :** cliquez sur **Disconnect**. Le serveur ne déploie alors plus depuis les dépôts privés.

> **Astuce:** Vous n'avez jamais rien à renouveler. Pour chaque déploiement, le Portail récupère auprès de GitHub une clé fraîche et à courte durée de vie (valide 1 heure), qui n'atteint que le dépôt de votre serveur. Cela se fait en arrière-plan.

---

## Démarrage rapide avec un token d'accès

Pour **GitLab**, **Gitea** et **Forgejo** — et pour GitHub si vous le préférez — vous enregistrez un token d'accès personnel. Les dépôts publics fonctionnent sans aucun token.

**Étape 1: Choisir le service Git**

Ouvrez votre serveur → **Git Deploy** et choisissez le **Git service**. Pour votre propre instance GitLab, Gitea ou Forgejo, saisissez l'URL du serveur (par exemple `https://codeberg.org` ou `https://git.example.com`). Pour gitlab.com, laissez ce champ vide.

**Étape 2: Saisir le dépôt**

Saisissez le dépôt sous forme de chemin (`owner/name`) ou collez simplement son URL web ou de clonage. Pour un dépôt **public**, c'est tout ce qu'il faut — sans token, la zone d'accès affiche **No token – public repositories only**.

**Étape 3: Enregistrer un token pour les dépôts privés**

Avec GitHub, cliquez d'abord sur **Use an own access token instead** dans la zone **GitHub access**. Puis créez un token chez votre fournisseur Git — le lien **Create a token on …** du Portail vous mène directement à la bonne page — et enregistrez-le sous **Personal access token**. Le Portail vérifie le token immédiatement. Voir [Permissions du token](#token-permissions) pour les droits nécessaires.

**Étape 4: Choisir vos paramètres et enregistrer**

Choisissez quand déployer, le dossier cible, les chemins protégés et le comportement au redémarrage, puis cliquez sur **Save settings**.

**Étape 5: Ajouter le webhook**

L'encadré **Webhook** affiche la **Payload URL** et le **Secret**, chacun avec un bouton de copie. Ajoutez-les à votre dépôt comme décrit dans [Configurer le webhook](#set-up-the-webhook). Sous l'encadré, **Last delivery** indique ensuite si le webhook arrive.

**Étape 6: Activer les déploiements automatiques**

Activez **Automatic deploys active**.

### Permissions du token

| Fournisseur | Type de token | Droits pour les déploiements | Également nécessaire pour le statut dans votre dépôt |
| :--- | :--- | :--- | :--- |
| GitHub | Token à permissions fines, uniquement pour ce dépôt | *Contents: Read-only* (pour **Wait for CI checks**, également *Actions: Read-only*) | *Commit statuses* et *Deployments* : *Read and write* |
| GitLab | Token d'accès personnel, de projet ou de groupe | `read_api` + `read_repository` | `api` à la place de `read_api`, rôle Developer |
| Gitea / Forgejo | Settings → Applications | `repository: Read`, `user: Read` | `repository: Read and Write` |

Si seule l'autorisation d'écriture pour le statut manque, votre serveur est tout de même déployé — le journal de déploiement affiche une remarque.

### Configurer le webhook

**GitHub**

Dans votre dépôt, allez dans **Settings → Webhooks → Add webhook** :

1. Collez la **Payload URL** et le **Secret** depuis le Portail.
2. Définissez le content type sur `application/json`.
3. Dans les événements, choisissez **Just the push event**. En mode release, choisissez plutôt **Releases**.

**GitLab**

Dans votre projet, allez dans **Settings → Webhooks** :

1. Collez la **Payload URL** comme URL et le **Secret** sous **Secret token**.
2. Dans les déclencheurs, sélectionnez **Push events**. En mode tag, sélectionnez **Tag push events** ; en mode release, **Releases events**.

**Gitea / Forgejo**

Dans votre dépôt, allez dans **Settings → Webhooks → Add webhook** et choisissez Gitea ou Forgejo :

1. Collez la **Payload URL**, définissez le content type sur `application/json` et saisissez le **Secret**.
2. Choisissez **Push events**, ou en mode release **Custom events → Release**.

> **Astuce:** Votre fournisseur Git ne peut pas joindre le Portail, par exemple parce que votre instance Gitea tourne sur votre réseau domestique ? Choisissez plutôt un intervalle sous **Also check … for updates** (par exemple **Also check Gitea for updates**). La première vérification déploie une fois l'état actuel.

---

## Quand un déploiement a lieu

Sous **When to deploy**, choisissez l'un des quatre modes :

| Mode | Ce qui est déployé |
| :--- | :--- |
| **Manual** | Uniquement lorsqu'une personne clique sur **Deploy now**. |
| **Every push** | Chaque push vers la branche choisie. |
| **Releases** | Uniquement lorsqu'une release est publiée. Déployez soit le **source code** de la release, soit un **release file** (par exemple `*.jar`) — éventuellement enregistré sous un nom fixe (par exemple `server.jar`) et éventuellement extrait s'il s'agit d'un `.zip`. Les pré-releases peuvent être incluses ou exclues. |
| **Tags** | Lorsqu'un tag correspondant à un motif est poussé, par exemple `v*`. |

### Déclencheurs

- **Webhook :** votre fournisseur Git signale les changements immédiatement, et le déploiement démarre en quelques secondes. Avec l'app GitHub, cela se fait automatiquement, sans webhook de votre part.
- **Vérifications de mises à jour (polling) :** facultatives, pour les cas où votre fournisseur Git ne peut pas joindre le Portail. Intervalles de 5 minutes à 1 jour.
- **Deploy now :** à tout moment, d'un simple clic. En mode release, vous pouvez choisir une release précise.
- **Ignorer un push :** mettez `[skip deploy]` dans le message de commit et ce push n'est pas déployé. `[deploy skip]` et `[no deploy]` fonctionnent aussi.

### Attendre les vérifications CI

Lorsque **Wait for CI checks** est activé (uniquement en mode **Every push**), un commit n'est déployé qu'une fois que sa CI est au vert — GitHub Actions, GitLab CI et Gitea/Forgejo Actions sont pris en charge. Si la CI échoue, le déploiement est ignoré.

---

## Tous les paramètres expliqués

| Section | Paramètre | Ce qu'il fait |
| :--- | :--- | :--- |
| Dépôt | **Git service** | GitHub, GitLab, Gitea ou Forgejo |
| Dépôt | **Server URL** | Uniquement pour les instances auto-hébergées ; doit être accessible depuis Internet |
| Dépôt | **Repository** | `owner/name` ou une URL ; **Choose from my repositories** affiche une liste |
| Dépôt | **Branch** | Vide = branche par défaut ; **Load branches** affiche une liste |
| Quand déployer | **Manual** / **Every push** / **Releases** / **Tags** | Voir [Quand un déploiement a lieu](#when-a-deploy-runs) |
| Quand déployer | **Wait for CI checks** | Uniquement avec **Every push** |
| Quand déployer | **Include pre-releases**, **What to deploy** (**Source code** / **Release file**), **Save as**, **Extract .zip files instead of uploading them** | Uniquement avec **Releases** |
| Quand déployer | **Tag pattern** | Uniquement avec **Tags**, par exemple `v*` ; vide = chaque tag |
| Quand déployer | **Also check … for updates** (selon le nom de votre service Git, par exemple **Also check GitHub for updates**) | Polling : **Never (webhook only)**, 5/10/15/30 min, 1/3/6/12/24 h |
| Quand déployer | **Automatic deploys active** | Désactivé, met en pause le webhook et le polling ; **Deploy now** continue de fonctionner |
| Quand déployer | **Show deploys in the repository** | Statut sur le commit, voir [Statut dans votre dépôt](#status-in-your-repository) |
| Fichiers | **Folder in the repository** | Ne déployer qu'un sous-dossier, par exemple `dist` ; vide = tout |
| Fichiers | **Target folder on the server** | Destination des fichiers ; `/` = le dossier principal de votre serveur |
| Fichiers | **Protected paths** | Une règle par ligne, voir [Chemins protégés](#protected-paths) |
| Fichiers | **Remove files that were deleted from the repository** | Nettoyage facultatif, voir ci-dessous |
| Redémarrage | **Restart if running** / **Always start** / **Do not restart** | Voir [Comportement au redémarrage](#restart-behavior) |
| Redémarrage | **If the server does not stop** | Arrêt immédiat, ou après 5 s, 10 s (par défaut : **Kill after 10 seconds**), 15 s, 30 s, 1 min, 2 min ou 5 min |

Les modifications ne prennent effet qu'après un clic sur **Save settings**. Tant que quelque chose n'est pas enregistré, une barre en bas affiche **Discard** et **Save settings**, et **Deploy now** est verrouillé.

**Remove files that were deleted from the repository** ne supprime que les fichiers qu'un déploiement précédent a écrits lui-même — jamais les chemins protégés, ni les fichiers que vous avez créés vous-même. Les dossiers vides restent en place.

---

## Chemins protégés

Les fichiers et dossiers listés sous **Protected paths** ne sont **jamais écrasés ni supprimés** par un déploiement. S'ils n'existent pas encore, ils sont créés une seule fois. Idéal pour les mondes de jeu, les bases de données et les mots de passe.

Écrivez une règle par ligne, par rapport au dossier cible. Les lignes vides et les lignes commençant par `#` sont ignorées. `*` ne correspond jamais au-delà d'un `/`.

| Règle | Protège |
| :--- | :--- |
| `world/` | Chaque dossier nommé `world`, à n'importe quelle profondeur |
| `/world/` | Uniquement `world` directement dans le dossier cible |
| `*.db` | Chaque fichier se terminant par `.db`, partout |
| `.env` | Chaque fichier nommé `.env`, partout |
| `/config.yml` | Uniquement `config.yml` directement dans le dossier cible |
| `plugins/*/config.yml` | `config.yml` dans chaque sous-dossier direct de `plugins` |

Exemples typiques :

**Minecraft**

```

world/

world_nether/

world_the_end/

plugins/*/config.yml

whitelist.json

ops.json

banned-*.json

```

**Bot Discord / Node.js**

```

.env

*.db

*.sqlite

node_modules/

data/

```

**Python**

```

.env

*.db

venv/

```

---

## Comportement au redémarrage

| Option | Ce qui se passe |
| :--- | :--- |
| **Restart if running** | Le serveur est arrêté avant l'écriture des fichiers et redémarré ensuite. Un serveur éteint reste éteint. |
| **Always start** | Comme ci-dessus, et un serveur éteint est démarré après le déploiement. |
| **Do not restart** | Les fichiers sont remplacés pendant que le serveur continue de tourner. |

**If the server does not stop:** certains programmes, en particulier les apps Node.js, ignorent le signal d'arrêt. Le serveur est alors arrêté de force après le délai choisi (immédiatement, de 5 secondes à 5 minutes ; **Kill after 10 seconds** par défaut) pour que le déploiement ne reste pas bloqué. L'arrêt forcé immédiat est le plus rapide, mais ne laisse aucun délai au serveur pour enregistrer ses données.

> **Remarque:** Deux filets de sécurité : si le serveur ne s'éteint pas du tout, **aucun fichier n'est modifié**. Si le déploiement échoue après l'arrêt du serveur, le serveur est **redémarré**.

---

## Déroulement d'un déploiement

1. Un déclencheur (push, release, tag, vérification de mise à jour ou bouton) crée un déploiement.
2. Si **Wait for CI checks** est activé, il attend que les vérifications CI soient au vert (**Waiting**).
3. Le **Portail** télécharge l'archive depuis votre fournisseur Git. Vos identifiants ne quittent jamais le Portail et n'arrivent jamais sur votre serveur.
4. L'archive est préparée : seul le dossier choisi est conservé, les chemins protégés sont filtrés et les contenus non sûrs, comme les liens symboliques, sont écartés.
5. Selon vos paramètres, le serveur est arrêté (et arrêté de force après le délai choisi si nécessaire).
6. Les fichiers sont écrits dans le dossier cible ; éventuellement, les fichiers supprimés sont retirés.
7. Selon vos paramètres, le serveur est redémarré.
8. Le résultat et le journal complet apparaissent dans l'historique — et, si c'est activé, sous forme de statut sur le commit.

Un déploiement prend généralement **10 à 40 secondes**, auquel s'ajoute le temps nécessaire à l'arrêt de votre serveur.

---

## Historique, journaux et rollback

La liste **Deployments** en bas de l'onglet affiche chaque déploiement avec son statut, sa branche et son commit (par exemple `main @ 75cd0a1`), son numéro, son déclencheur, la personne qui l'a lancé, l'heure et le message du commit. L'en-tête de l'onglet indique quand le serveur a été déployé pour la dernière fois.

| Statut | Signification |
| :--- | :--- |
| **Waiting** | Attente des vérifications CI |
| **Scheduled** | En file d'attente, démarre sous peu |
| **Running** | Le déploiement est en cours |
| **Deployed** | Terminé avec succès |
| **Failed** | Une erreur s'est produite — le journal indique laquelle |
| **Skipped** | Non déployé, par exemple parce que la CI a échoué ou que le commit contient `[skip deploy]` |
| **Cancelled** | Annulé avant son démarrage |

- **Journal :** chaque déploiement dispose d'un journal en direct, qui se met à jour pendant son exécution. **Hide log** le referme.
- **Rollback en un clic :** cliquez sur **Deploy again** sur un déploiement antérieur pour redéployer cet état une fois de plus.
- **Annuler :** les déploiements en attente ou planifiés peuvent être annulés.

Plusieurs serveurs peuvent déployer en même temps, mais chaque serveur n'exécute qu'un seul déploiement à la fois. Un nouveau déclencheur remplace un déploiement plus ancien encore en attente.

---

## Statut dans votre dépôt

Lorsque **Show deploys in the repository** est activé, votre commit affiche un statut **Daki Hosting / *le nom de votre serveur*** : jaune pendant le déploiement, puis une coche verte ou une croix rouge, avec un lien vers l'onglet Git Deploy.

- Sur GitHub, un déploiement apparaît aussi sous **Deployments**, avec le nom de votre serveur comme environnement.
- Avec l'app GitHub, le statut est écrit par **Daki Git Deploy** et affiche son logo ; rien d'autre à configurer. Avec un token, il affiche l'image du compte auquel appartient le token, et le token a besoin des permissions d'écriture (voir [Permissions du token](#token-permissions)).
- Vous pouvez le désactiver serveur par serveur. Seuls le statut et le lien sont publics — aucun journal ni détail d'erreur.

---

## Équipes et permissions des sous-utilisateurs

Les [sous-utilisateurs](https://daki.cc/fr/wiki/guides/subusers) disposent de leur propre groupe de permissions **Git Deploy** :

| Permission | Autorise |
| :--- | :--- |
| **view** (`github.read`) | Voir les paramètres, l'adresse du webhook et l'historique avec les journaux |
| **deploy** (`github.deploy`) | **Deploy now**, **Deploy again** et l'annulation des déploiements |
| **change settings** (`github.update`) | Dépôt, accès, webhook et tous les paramètres |

Les sous-utilisateurs n'ont **aucun** accès à Git Deploy par défaut — c'est vous qui décidez qui obtient quelle permission. Le propriétaire du serveur peut toujours tout faire.

---

## Sécurité

- Les tokens et secrets sont stockés **chiffrés** et ne sont **jamais envoyés à votre navigateur**.
- Avec l'app GitHub, aucun token de longue durée à vous n'est utilisé pour les déploiements : chaque déploiement utilise une clé à courte durée de vie (1 heure) qui n'atteint **que le dépôt de votre serveur**.
- Vos propres accès GitHub déterminent les dépôts que vous pouvez connecter. Personne ne peut faire venir sur son serveur les dépôts d'une autre personne.
- Les webhooks sont **signés** avec un secret propre à chaque serveur. Les envois avec un mauvais secret ou pour un autre dépôt sont rejetés.
- Seule la personne qui a enregistré le token peut modifier le dépôt, ainsi les sous-utilisateurs ne peuvent pas utiliser le token du propriétaire pour charger d'autres dépôts privés.
- Si vous changez le **Git service** ou l'URL du serveur, le token enregistré est supprimé automatiquement à l'enregistrement.
- Les chemins protégés ne sont jamais écrasés, et **Remove files that were deleted from the repository** ne supprime que ce qu'Git Deploy a écrit lui-même.
- Le statut public dans votre dépôt ne contient ni journal ni détail d'erreur.

---

## Limites connues

- Un dépôt et un accès par serveur.
- Chaque serveur n'exécute qu'un déploiement à la fois.
- Le statut dans votre dépôt n'apparaît qu'une fois le déploiement réellement démarré, et non pendant l'attente de la CI.
- Les fichiers de release ne sont extraits que s'il s'agit de fichiers `.zip` ; un `.tar.gz` est téléversé comme fichier.
- Les dossiers vides restent en place après **Remove files that were deleted from the repository**.
- Les liens symboliques du dépôt ne sont pas déployés.
- GitLab n'a pas de pré-releases ; une release datée dans le futur compte comme pré-release.
- GitLab : les fichiers de release téléversés dans le projet (`/uploads/…`) ne peuvent pas être téléchargés avec un token depuis des projets privés ; les liens vers le registre de paquets fonctionnent.
- **Connect with GitHub** n'est disponible que pour GitHub ; GitLab, Gitea et Forgejo utilisent un token.

---

## FAQ et dépannage

**Dois-je renouveler mon token régulièrement ?**

Pas avec l'app GitHub : le Portail récupère automatiquement une clé fraîche pour chaque déploiement. Un token personnel reste valide aussi longtemps que vous l'avez défini lors de sa création chez votre fournisseur Git ; à expiration, enregistrez simplement un nouveau token.

**Mon dépôt n'apparaît pas dans la liste (app GitHub)**

Cliquez sur **Choose repositories on GitHub** et autorisez l'app à accéder au dépôt.

**Le déploiement reste sur Scheduled**

Patientez un instant. Si la situation persiste plus de quelques minutes, veuillez [contacter le support](https://daki.cc/fr/wiki/guides/support).

**Le webhook n'arrive pas, ou GitHub affiche l'erreur 401**

Le secret ne correspond pas. Copiez le secret depuis le Portail et saisissez-le à nouveau dans le webhook. **New secret** en crée un nouveau — modifiez-le ensuite aussi chez votre fournisseur Git.

**Pourquoi mon déploiement a-t-il été ignoré ?**

Raisons possibles : les vérifications CI ont échoué, le message de commit contient `[skip deploy]`, ou un déclencheur plus récent a remplacé un déploiement encore en attente. La raison est affichée dans la ligne du déploiement.

**Je ne vois aucun statut sur mon commit**

**Show deploys in the repository** doit être activé. Avec un token, celui-ci a aussi besoin des permissions d'écriture (voir [Permissions du token](#token-permissions)) — le journal de déploiement indique la raison.

**Le déploiement échoue avec « The node rejected the request »**

Le type de votre serveur n'autorise pas certains fichiers, ou le disque est plein. Le journal affiche les détails.

**L'URL de mon instance Gitea est refusée**

Les instances auto-hébergées doivent être accessibles depuis Internet. Les adresses d'un réseau domestique, comme `192.168.x.x`, ne fonctionnent pas.

**Comment faire un rollback ?**

Dans l'historique, cliquez sur **Deploy again** sur le déploiement antérieur auquel vous voulez revenir.

**Mon monde de jeu ou ma base de données seront-ils écrasés ?**

Non, s'ils sont listés sous **Protected paths** (par exemple `world/` ou `*.db`).

**Qui dans mon équipe peut déployer ?**

Seules les personnes disposant de la permission **deploy** dans le groupe **Git Deploy** des paramètres de sous-utilisateurs du serveur. Le propriétaire du serveur peut toujours tout faire.

---

## Étapes suivantes

- [Subusers](https://daki.cc/fr/wiki/guides/subusers) — Donnez accès à votre équipe et décidez qui peut déployer.
- [Variables d'environnement](https://daki.cc/fr/wiki/guides/environment-variables) — Gardez tokens et mots de passe hors de votre dépôt.
- [Paramètres de démarrage](https://daki.cc/fr/wiki/guides/startup-settings) — Définissez la commande de démarrage avec laquelle tourne votre code déployé.
- [Sauvegardes](https://daki.cc/fr/wiki/guides/backups) — Enregistrez des sauvegardes automatiques de votre serveur sur Google Drive.

---
Source: https://daki.cc/fr/wiki/guides/git-deploy