Que peut faire un serveur KVM 1 cœur 1 Go ? Le guide ultime pour en tirer le maximum

Chaque Black Friday, les forums regorgent d'offres « 1 cœur, 1 Go, abonnement annuel moins cher qu'un café ». Certains VPS restent inutilisés ; d'autres hébergent blog, reverse proxy, WireGuard, flux RSS et tâches cron — sur la même machine. L'écart vient rarement du matériel, mais de la maîtrise d'un petit VPS : remplacer la pile par défaut par des composants légers, puis ajuster le noyau pour que chaque mégaoctet et chaque changement de contexte compte.

Cet article ne parle pas d'acheter une machine plus grosse. Il répond à une question : pour l'hébergement et les services sur 1 cœur et 1 Go, où est la limite, et comment la trouver ?

Comprendre les limites : que peut faire 1 cœur / 1 Go

Un vCPU en KVM signifie en général pas de cœur physique dédié — la capacité en rafale est limitée. Un gigaoctet de RAM doit être partagé entre le système, les caches, les applications et les connexions. Ce n'est pas « impossible », c'est une chose bien faite ; le reste se fusionne ou s'externalise.

Budget mémoire : chaque Mo a un rôle

Sur Debian 12 minimal avec SSH seul, le système occupe environ 150–200 Mo. Le « vrai budget » pour les apps tourne souvent autour de 400 Mo — hors cache et pics de connexion.

• Système + systemd + sshd : ~150–180 Mo ; désactiver les units inutiles économise 30–50 Mo.
• Reverse proxy web (Caddy / nginx) : ~15–40 Mo ; nginx est plus léger en mode statique pur.
• Runtime applicatif : binaires Go souvent 10–30 Mo ; un processus Node.js vide démarre à 50 Mo+ — prudence sur mini VPS.
• Base de données : SQLite quasi nulle en résident ; MySQL 8 avec défauts avale facilement 400 Mo.
• Swap / zram : prévoir 512 Mo–1 Go de mémoire virtuelle en tampon, sans la traiter comme de la vraie RAM.

⚠️ Conseil pratique : dans free -h, regardez available, pas seulement free. Linux utilise la RAM libre en cache ; available indique ce que les apps peuvent réellement demander.

Héberger sur 1 cœur / 1 Go : alternatives légères

La pile LAMP/LNMP classique est un tueur de mémoire sur un petit VPS. Cette combinaison a tenu la route pour des sites personnels à quelques milliers de pages vues par jour :

Pour du contenu dynamique, privilégiez un binaire Go unique (PocketBase, outils type miniBlog) ou Python FastAPI + SQLite, avec les workers limités à 1.

Configuration Caddy statique prête à copier

example.com {
    root * /var/www/site
    file_server
    encode gzip zstd
    header Cache-Control "public, max-age=3600"
}

Mémoire totale souvent < 30 Mo, renouvellement HTTPS automatique, pas de daemon certbot. Build en local ou en CI ; le VPS ne sert que les fichiers — la voie la plus fiable pour 1 cœur / 1 Go.

Optimisation KVM : réglages noyau et système

Les performances réseau et I/O dépendent beaucoup de l'hôte, mais la VM guest offre encore une marge de réglage. Ces paramètres fonctionnent sur la plupart des petits VPS Debian / Ubuntu :

1. Activer le contrôle de congestion BBR

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_fastopen = 3

Sur des liaisons transocéaniques, BBR remplit souvent mieux la bande passante que cubic et paraît plus réactif.

2. zram plutôt qu'une partition swap classique

Le swap disque sur VPS a une latence I/O élevée et peut bloquer toute la machine. zram compresse la RAM pour simuler du swap et gère mieux les petits pics :

apt install zram-tools
# /etc/default/zramswap 中设置：
# ALGO=lz4
# PERCENT=50

3. Baisser swappiness pour protéger les données chaudes

vm.swappiness = 10
vm.vfs_cache_pressure = 50

4. Connexions et descripteurs de fichiers

net.core.somaxconn = 1024
net.ipv4.tcp_max_syn_backlog = 2048
fs.file-max = 65535

5. Élaguer les services systemd

Auditez et désactivez l'inutile. Candidats fréquents : bluetooth, avahi-daemon, ModemManager, agents de monitoring du panneau si vous surveillez déjà de l'extérieur.

Idées pour petit VPS : sept usages fiables

Traitez 1 cœur / 1 Go comme un nœud edge dédié, pas un mini datacenter. Il peut tenir la route pour :

1. Blog personnel / documentation technique : Hugo + Caddy ; build local, déploiement rsync.
2. Entrée reverse proxy : Cloudflare devant, origine sur le LAN ou stockage objet derrière.
3. Saut WireGuard : mailler 3–5 appareils ; charge CPU minimale.
4. Webhook / écoute bot : Telegram, Slack ou bots maison en un seul processus Go ou Python.
5. DNS ou AdGuard Home : limiter la taille des logs de requêtes et faire tourner la rotation.
6. Sonde de disponibilité légère : Uptime Kuma ou cron curl vers un tableau de bord externe.
7. Miroir Git privé : git daemon ou Gitea mode minimal ; dépôts dans la zone basse Go.

Inférence IA, builds lourds et pipelines de scan sécurité dépassent un mini VPS — il faut une vraie machine de dev. Pour évaluer les outils de revue de code, voir Comment utiliser /security-review dans GitHub Copilot App et exécuter le travail lourd en local ou sur un Mac cloud.

Lignes rouges : à ne pas faire sur un mini VPS

• Elasticsearch / ClickHouse : minimum RAM officiel bien au-delà de 1 Go ; OOM au démarrage.
• MySQL 8 avec réglages par défaut : sauf innodb_buffer_pool_size à 64M et requêtes très lentes.
• Panneau one-click + LNMP : panneau + Nginx + MySQL + PHP dépasse facilement 800 Mo résidents.
• Kubernetes (k3s nœud unique) : plan de contrôle non conçu pour ces specs.
• Stacks Docker Compose multi-services : dockerd plus plusieurs services fragmentent la mémoire.
• VPS en NAS 24/7 pour torrents : I/O disque et RAM souffrent ; plafonds bande passante fréquents.

Surveillance et dépannage : cinq minutes avant l'OOM

Pas de marge sur un mini VPS — la surveillance doit être légère, précise et alertante :

• node_exporter : complet mais ~20 Mo ; mieux avec un peu de réserve.
• glances : convivial en terminal ; glances -w pour une vue web simple.
• Script maison : cron toutes les 5 minutes sur MemAvailable ; alerte Telegram sous 80 Mo.
• Rotation des logs : configurer logrotate — access.log plein plus fréquent que l'OOM.

En charge : surveillez load average (éviter > 1.5 durable sur 1 cœur), MemAvailable (> 100 Mo), iowait (pic quand le swap sature).

Quand passer à une machine plus grande ?

Ces signaux indiquent que le petit VPS a atteint sa limite :

• Plus d'un OOM par semaine malgré toutes les optimisations de cet article.
• Web + base + tâches de fond simultanés, rien à externaliser.
• UV quotidiennes stables au-delà de 10 000, CPU origine saturée malgré le CDN.
• Le travail passe de « héberger un site » à « compiler, tester, inférence IA » — Mac cloud ou VPS plus grand.

Pour le choix de modèle et l'architecture proxy — travail gourmand en calcul — voir Gemini 4 vaut-il la peine d'attendre ? Choisir son modèle en 2026 et lancer l'inférence dans un environnement plus spacieux.