Configuration VPS requise pour Kamal : RAM, CPU, stockage

Kamal est un outil de déploiement qui tourne sur votre propre machine ou sur votre runner CI, pas sur le serveur. La question de la « configuration VPS requise pour Kamal » porte donc en réalité sur la machine vers laquelle Kamal déploie : elle doit faire tourner vos conteneurs applicatifs, kamal-proxy, les accessoires déclarés et quelques jours d’anciennes images conservées pour les rollbacks.

Le coût en ressources de Kamal sur l’hôte est nul. Dimensionnez tout le reste.

Ce qui consomme des ressources sur l’hôte

Après kamal setup, le serveur fait tourner trois choses :

• kamal-proxy, un petit proxy HTTP en Go qui occupe les ports 80 et 443
• vos conteneurs applicatifs, un jeu par rôle dans config/deploy.yml
• les accessoires — Postgres, Redis ou tout ce que vous avez déclaré

Seuls les deux derniers comptent pour le dimensionnement. kamal-proxy est un binaire statique unique dont l’empreinte disparaît face à n’importe quelle application réelle.

La mémoire

Le chiffre qui surprend n’est pas la consommation en régime établi, c’est le recouvrement de déploiement. Kamal démarre le nouveau conteneur pendant que l’ancien sert encore le trafic, et n’arrête l’ancien qu’une fois le contrôle de santé passé. Le pic correspond donc à votre consommation habituelle plus, grosso modo, une copie supplémentaire du conteneur applicatif.

• Minimum pratique : 2 Go, pour une petite application sans base de données séparée
• Confortable : 4 Go, ce qui couvre une application web classique avec Postgres et le recouvrement
• Ajoutez du swap sur les hôtes à 4 Go. Un hôte qui commence à swapper en plein déploiement peut devenir assez lent pour manquer la fenêtre du contrôle de santé, et le déploiement revient alors en arrière sans raison apparente.

Si vous faites tourner Postgres comme accessoire Kamal plutôt qu’en service managé, dimensionnez explicitement pour lui : ce n’est pas Kamal, c’est la base qui sera le plus gros consommateur de la machine.

Le processeur

Deux vCPU constituent le plancher raisonnable, pour une raison qui n’a rien à voir avec la charge courante : pendant un déploiement, l’hôte tire une image, démarre un conteneur, exécute des contrôles de santé et sert le trafic depuis l’ancien conteneur, tout cela en même temps. Sur un seul vCPU, cette concurrence étire la fenêtre de déploiement.

• Minimum : 1 vCPU, viable pour une application peu sollicitée si vous acceptez des déploiements plus lents
• Recommandé : 2 vCPU
• Construire les images sur le VPS lui-même est le seul cas qui demande réellement davantage. Si votre portable est en arm64 et que le VPS est votre unique machine amd64, une construction utilisera tous les cœurs que vous lui donnerez.

Le stockage

C’est ici que le comportement de Kamal change vraiment les chiffres. Kamal conserve les anciens conteneurs et images sur le serveur pour que kamal rollback relance une version précédente sans repasser par le registre, et les purge au bout de trois jours par défaut.

Le disque doit donc contenir :

• Les données et volumes propres à votre application
• L’image actuelle plus environ trois jours de versions antérieures
• Les couches de base partagées, stockées une seule fois quel que soit le nombre de versions conservées

Une image de 1 Go déployée quelques fois par jour tient sans problème sur 40 Go NVMe. Une image de 3 Go remplit un disque de 25 Go en une semaine. Le mode de défaillance mérite d’être connu : un disque plein casse le déploiement suivant, pas celui qui l’a rempli, si bien que la cause et le symptôme sont séparés de plusieurs jours.

Si vous déployez souvent, kamal prune all vide l’arriéré à la demande plutôt que d’attendre la fenêtre de trois jours.

Hébergeurs VPS et tarifs

Pour un panorama complet, consultez le comparatif VPS.

DigitalOcean est l’entrée en matière la plus simple, parce que Kamal ne gère délibérément l’hôte que jusqu’à Docker — les règles de pare-feu, le swap et les mises à jour automatiques restent à votre charge, et la documentation de DigitalOcean couvre les trois. Hetzner vous donne plus de RAM et de disque par euro si cette configuration ne vous fait pas peur.

Conseils pratiques

• N’ouvrez que les ports 22, 80 et 443. kamal-proxy termine TLS lui-même, rien d’autre n’a besoin d’être joignable.
• Vérifiez kamal app containers avant de compter sur un rollback : la cible doit encore être sur le disque.
• Surveillez l’espace disque libre avec la même alerte que la mémoire. C’est la panne qui arrive sans bruit.
• Déployer une seconde application sur le même hôte est possible avec Kamal 2 — kamal-proxy route par nom d’hôte — mais cela double le nombre de conteneurs et l’historique d’images : dimensionnez le disque pour les deux.

Conclusion

Pour la plupart des déploiements d’une seule application, 2 vCPU, 4 Go de RAM et 40 Go de SSD ou NVMe laissent de la place à l’application, sa base de données, le recouvrement de déploiement et trois jours d’images de rollback. Augmentez le disque avant d’augmenter la mémoire : la pression mémoire se signale d’elle-même, l’accumulation d’images non. Pour d’autres options, explorez notre comparatif VPS.