Docs / Concepts de base / Apps et services

Apps et services

Une application est la configuration que vous gérez ; les conteneurs qu'elle fait tourner sont les services. Cette page explique leur relation, les réglages d'une application et ce que sh0 fait par défaut.

Applications et services

Application : la configuration persistante. Sa source, ses réglages, ses variables d'environnement, ses domaines et ses limites de ressources survivent à chaque déploiement.
Service : un conteneur créé par un déploiement, nommé sh0-<préfixe-id-stack>-<app>-<préfixe-id-déploiement>. Chaque déploiement en crée un nouveau ; le conteneur précédent n'est arrêté et supprimé qu'une fois le nouveau sain et routé.

Statut d'une application

Une application affiche l'un de ces statuts :

État	Signification
inactive	Créée, jamais déployée.
building	Un déploiement construit l'image ou démarre le conteneur.
running	Le conteneur a passé son contrôle de santé et reçoit le trafic.
stopped	Arrêtée par un utilisateur (`sh0 stop` ou le tableau de bord).
failed	Le dernier déploiement a échoué. Un conteneur d'un déploiement antérieur encore en marche continue de servir.

Créer une application

Dans un stack, Ajouter une app ouvre la page Déployer avec le stack présélectionné. Une application peut venir d'une image Docker, d'un dépôt Git, d'une archive envoyée, d'un Dockerfile, d'un fichier Docker Compose, d'un modèle de framework ou du catalogue de gabarits. Depuis un terminal, sh0 push envoie le répertoire courant et le déploie.

Réglages d'une application

L'onglet Paramètres de l'application porte ces champs, enregistrés avec Enregistrer les modifications :

Champ	Description
Nom de l'application	Identifiant de l'application ; aussi son nom d'hôte dans le stack (`<nom>` et `<nom>.internal`).
URL du dépôt, Branche	Pour une application Git : le dépôt et la branche à déployer.
Chemin de build, Dockerfile	Sous-répertoire à construire et Dockerfile à utiliser. Sans Dockerfile, sh0 détecte la pile technique et en génère un.
Port	Port d'écoute de l'application dans le conteneur ; le trafic public y est acheminé.
Répliques, Ordre de démarrage, Projet	Nombre de conteneurs, rang lors du déploiement du stack entier, et stack auquel appartient l'application.

Il n'y a pas de champ de commande de build ni de démarrage : c'est le Dockerfile qui décide. Les arguments de build sont des variables d'environnement marquées « build », voir Variables d'environnement.

Limites de ressources

Chaque conteneur d'application a une limite CPU et mémoire, sur toute installation, avec ou sans licence :

Champ	Par défaut	Valeurs admises
CPU	La moitié des cœurs de l'hôte, au moins 0,5	`cpu_limit` en millicœurs (1000 = un cœur), de 100 au nombre de cœurs de l'hôte
Mémoire	512 Mo	`memory_limit` en Mo, de 64 à la mémoire de l'hôte

Modifiez-les dans l'onglet Mise à l'échelle de l'application, sous Limites de ressources, puis Enregistrer la configuration. Dans l'API, les deux valeurs sont des entiers et 0 remet la valeur par défaut. Une chaîne comme "512m" est refusée en 422.

Terminal

$ curl -s -X PUT https://panel.example.com/api/v1/apps/e17d4314-ff61-485a-a509-58b3974c1eee/resources \
    -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
    -d '{"cpu_limit":500,"memory_limit":256}'
{"data":{"app_id":"e17d4314-ff61-485a-a509-58b3974c1eee","autoscale_cpu_threshold":80,"autoscale_enabled":false,"autoscale_memory_threshold":80,"cooldown_seconds":300,"cpu_limit":500,"created_at":"2026-10-02 02:52:11","current_replicas":1,"id":"64433fb7-a676-4257-8c78-474d2fb961fd","last_scale_at":null,"lb_policy":"round_robin","max_replicas":1,"memory_limit":256,"min_replicas":1,"updated_at":"2026-10-02 03:04:09"}}

Les nouvelles limites s'appliquent au déploiement suivant ; d'ici là, le conteneur en cours garde les anciennes. Relevé sur une application de test : avant redéploiement, le conteneur avait encore 512 Mo et 2 cœurs (hôte à 4 cœurs), après, 256 Mo et 0,5 cœur :

Terminal

$ docker inspect <container> --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}'
536870912 2000000000
$ sh0 deploy my-api
[*] Deploying my-api...
  Deployment ID: 9b98d35b-0751-490e-88e8-f089fb0a6007
  Status:        queued
$ docker inspect <new-container> --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}'
268435456 500000000

Warning

Un conteneur qui dépasse sa limite mémoire est tué par le noyau (OOMKilled). Si cela arrive pendant un déploiement, celui-ci échoue aussitôt au lieu d'attendre la fin du délai du contrôle de santé. Relevez la limite ou réduisez la consommation de l'application.

Politique de redémarrage

Chaque conteneur d'application tourne avec la politique Docker unless-stopped : Docker le relance après un plantage ou un redémarrage de l'hôte, sauf si vous l'avez arrêté. La politique n'est pas réglable.

Contrôle de santé au déploiement

Avant d'envoyer du trafic vers un nouveau conteneur, sh0 attend qu'il soit sain, jusqu'à 300 secondes. Le contrôle est choisi automatiquement et n'a pas de réglages :

Si l'image définit un HEALTHCHECK Docker, sh0 l'utilise.
Sinon, pour une application web, une connexion TCP au port de l'application doit réussir. Il n'y a pas de contrôle sur un chemin HTTP.
Un worker (sans port) est sain dès qu'il est resté en marche 15 secondes sans redémarrer.

Note

Une boucle de plantages ou un arrêt pour manque de mémoire fait échouer le déploiement immédiatement. Quand un déploiement échoue, le conteneur précédent n'est pas arrêté et continue de servir le trafic.

Stacks

Domaines et SSL