Natif ou conteneur — lequel choisir ?

Le mode natif exécute ton application web directement sur l’hôte avec systemd — rapide, peu gourmand en RAM, environnement d’exécution partagé. Le mode conteneur l’exécute dans Docker — version d’environnement propre à chaque appli, avec ~30–100 Mo de RAM en plus.

Dernière mise à jour 24 mai 2026

Pertinent uniquement si tu déploies une application web (Node, Python, Go). Les sites statiques et WordPress n’affichent pas ce choix.

Quand tu déploies une application web, la section Avancé de la fenêtre de déploiement propose un bouton à bascule : Déployer comme processus natif ou Conteneur. Dans les deux cas, ton appli est mise en ligne derrière avec le HTTPS de — la différence se situe dans la façon dont ton code s’exécute en dessous.

Ce que tu choisis

Le bouton « Déployer comme » dans la section Avancé de la fenêtre de déploiement

Processus natif — Server Manager installe l’environnement d’exécution une seule fois sur l’hôte (Node 22 LTS, Python 3 + venv, ou Go), puis exécute ton appli directement sous comme service dédié.
Conteneur — Server Manager crée une image Docker pour ton appli avec la version d’environnement que tu choisis, puis l’exécute comme conteneur derrière Caddy sur l’hôte.

Dans les deux cas : même domaine, même HTTPS, même bouton pour récupérer la dernière version depuis Git, même accès à ton code depuis l’onglet Fichiers.

Fonctionnement du mode natif

Ton appli se trouve dans /opt/<appName>/ et s’exécute comme unité appelée <appName>.service. L’environnement d’exécution (Node, Python, Go) est installé une seule fois au niveau du système d’exploitation et partagé par toutes les applications web natives du serveur.

Déploiement natif — trois applis sous systemd, partageant toutes une installation Node et une installation Python sur l’hôte

Fichiers dans /opt/<appName>/
Service géré par systemd — sudo systemctl status <appName> fonctionne comme prévu
Logs capturés par journald, affichés dans l’onglet Logs
Environnement d’exécution une installation Node 22, une installation Python 3 et une installation Go sur l’hôte — toutes les applis natives les partagent

Fonctionnement du mode conteneur

Ton appli s’exécute dans son propre conteneur Docker. Le fichier compose se trouve dans /opt/<appName>/docker-compose.yml, et Caddy sur l’hôte sert de frontal en faisant un proxy inverse de ton domaine vers le port interne du conteneur.

Déploiement en conteneur — trois applis, chacune dans son propre conteneur Docker avec sa version d’environnement épinglée

Fichiers dans /opt/<appName>/ — ton code source, plus un Dockerfile et un docker-compose.yml générés par Server Manager
Service géré par Docker — sudo docker compose -f /opt/<appName>/docker-compose.yml ps affiche l’état
Logs capturés par Docker, affichés dans l’onglet Logs
Environnement d’exécution chaque appli épingle sa propre version — Node 18, Node 22, Python 3.11, Python 3.13 peuvent tous coexister

Lequel choisir ?

La plupart des applis devraient commencer en natif. Choisis le conteneur uniquement si tu as une raison précise.

Si…	Choisis
Tu as une seule appli sur le serveur et l’épinglage de version ne t’importe pas	Natif
Tu veux le minimum de surcoût en RAM (important sur les serveurs de 1 Go / 2 Go)	Natif
Tu veux les déploiements les plus rapides (pas de création d’image)	Natif
Tu as deux applis avec des versions d’environnement différentes (par exemple Node 18 + Node 22)	Conteneur au moins pour celle qui fait exception
Tu veux une isolation stricte entre les applis (par exemple si l’une contient du code tiers auquel tu ne fais pas totalement confiance)	Conteneur
Ton appli apporte une dépendance complexe hors environnement d’exécution (version précise du client Postgres, build ImageMagick, etc.)	Conteneur (tout est inclus dans l’image)
Tu prévois de déplacer cette appli vers un autre hôte plus tard	Conteneur (l’image est portable ; les déploiements natifs dépendent de l’environnement installé sur l’hôte)

Le compromis en chiffres (approximatifs) :

Natif : ~50–200 Mo RSS par appli (juste l’appli + l’interpréteur). Premier déploiement : 10–30 s.
Conteneur : ~50–200 Mo RSS pour l’appli + ~30–100 Mo de surcoût Docker par conteneur. Premier déploiement : 1–3 min (création de l’image).

Sur un serveur de 2 Go peu sollicité, tu peux faire tourner 5–8 applications web natives + Caddy + une petite base de données. Avec des conteneurs, ce nombre tombe à ~4–6.

Changer plus tard

Le mode est propre à l’appli : il n’y a pas de bouton dans le panneau du service pour passer une appli native en conteneur, ou l’inverse.

Pour changer, redéploie l’appli depuis la fenêtre modale et choisis l’autre option :

Ouvre Actions → Déployer depuis mon ordinateur (ou Déployer une application web depuis un dépôt git)
Dépose ton code ou colle l’URL du dépôt
Déplie Avancé → change le bouton Déployer comme
Clique sur Déployer — l’appli existante est remplacée avec le nouveau mode

Le code reste sur le disque (les règles .helm-keep de Plusieurs sites sur le même serveur s’appliquent aussi aux redéploiements en conteneur). Ton domaine continue de pointer au même endroit. L’interruption correspond à la durée d’un redéploiement normal — généralement moins d’une minute.