Stack d'auto-hébergement pour petit VPS : ce qui tient en 2 Go et 4 Go de RAM

En bref : un VPS de 2 Go fait tourner sans peine un socle auto-hébergé composé de Caddy (reverse proxy HTTPS), Vaultwarden (mots de passe), Uptime Kuma (supervision) et Forgejo (git) sous Docker Compose, pour environ 0,6 à 1 Go de RAM. Ajoutez Nextcloud et il vous faut 4 Go ; choisissez des outils plus légers comme Syncthing ou File Browser et 2 Go suffisent toujours.

Ce guide fournit un fichier Compose fonctionnel, un budget RAM par service, et les deux points que la plupart des installations auto-hébergées négligent jusqu'à ce qu'il soit trop tard : des sauvegardes hors site et une surface réseau verrouillée. Les commandes supposent Debian 12/13 ou Ubuntu 24.04 avec Docker Engine et le plugin Compose installés depuis le dépôt officiel de Docker.

Budget RAM par service

Les chiffres correspondent à la mémoire résidente typique, au repos ou en usage léger, pour un à cinq utilisateurs avec SQLite lorsque c'est possible. Les pics lors des mises à jour, des clones git de gros dépôts ou des aperçus Nextcloud peuvent être plus élevés : gardez au moins 20 % de marge et ajoutez un fichier swap de 1 à 2 Go.

Choisir la taille du VPS

Le socle (Caddy, Vaultwarden, Uptime Kuma, Forgejo) plus le système de base tourne autour de 0,6 à 1 Go, ce qui tient sur un serveur 2 vCPU / 2 Go avec de la place pour Syncthing et Radicale. Nextcloud avec MariaDB et Redis porte le total à environ 1,5 à 2,2 Go : 4 Go est donc le minimum réaliste si vous voulez la suite complète plus tout le reste. Le disque compte aussi : les dépôts Forgejo et les fichiers synchronisés grossissent, tandis que les services eux-mêmes n'ont besoin que de quelques Go.

Chez NoctisNode, l'offre Pulse (2 vCPU, 2 Go de RAM, 40 Go NVMe, $10 pour 28 jours) accueille le socle, et Umbra (4 vCPU, 4 Go, 60 Go NVMe, $15 pour 28 jours) le socle plus Nextcloud. Les deux sont en KVM avec accès root complet et une IPv4 dédiée, et peuvent être payées en Monero ou autres cryptos. Rien dans ce guide ne dépend de l'hébergeur.

Fichier Docker Compose

Seul Caddy publie des ports web ; les applications ne sont joignables que via le réseau Compose interne. Forgejo publie aussi le port 2222 pour git en SSH, afin que l'OpenSSH de l'hôte reste sur son propre port. Définissez `FORGEJO_TAG` dans un fichier `.env` avec la version majeure actuelle de Forgejo et remplacez les domaines d'exemple par vos propres enregistrements DNS.

# /srv/stack/compose.yaml
services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy/data:/data
      - ./caddy/config:/config

  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"   # set to "false" after creating your account
    volumes:
      - ./vaultwarden:/data

  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - ./uptime-kuma:/app/data

  forgejo:
    image: codeberg.org/forgejo/forgejo:${FORGEJO_TAG}
    restart: unless-stopped
    environment:
      USER_UID: "1000"
      USER_GID: "1000"
      FORGEJO__service__DISABLE_REGISTRATION: "true"
    volumes:
      - ./forgejo:/data
    ports:
      - "2222:22"

# /srv/stack/Caddyfile
# vault.example.com {
#     reverse_proxy vaultwarden:80
# }
# status.example.com {
#     reverse_proxy uptime-kuma:3001
# }
# git.example.com {
#     reverse_proxy forgejo:3000
# }

Démarrer la stack

1. 01.Pointez des enregistrements A (et AAAA) pour `vault`, `status` et `git` vers l'IP du serveur, afin que Caddy puisse obtenir les certificats au premier démarrage.
2. 02.Créez `/srv/stack`, placez-y `compose.yaml`, `Caddyfile` et `.env`, puis lancez `docker compose up -d`.
3. 03.Ouvrez l'URL de Forgejo et terminez l'installateur ; le premier compte créé par ce biais devient administrateur, puisque l'inscription publique est désactivée.
4. 04.Créez votre compte Vaultwarden, puis définissez `SIGNUPS_ALLOWED` à `"false"` et relancez `docker compose up -d`. Laissez le panneau d'administration désactivé, sauf si vous définissez un `ADMIN_TOKEN` haché avec Argon2.
5. 05.Créez l'administrateur Uptime Kuma juste après le démarrage, car la page de configuration est ouverte à tous tant que ce n'est pas fait.
6. 06.Ajoutez des sondes pour chaque service et pour l'expiration des certificats, idéalement depuis un second emplacement, car une sonde sur le même serveur ne peut pas signaler sa propre panne.

Note · Caddy gère automatiquement le HTTPS. Pour les en-têtes, les limites de débit et un routage plus complexe, voir le guide reverse proxy Caddy.

Des sauvegardes qui se restaurent vraiment

Tout ce qui mérite d'être conservé se trouve sous `/srv/stack` : bases SQLite, dépôts Forgejo, certificats Caddy et votre configuration. Ne comptez pas sur les snapshots de l'hébergeur ; gardez votre propre copie chiffrée hors site avec restic, comme décrit dans le guide des sauvegardes restic.

Des fichiers SQLite copiés pendant qu'un service écrit peuvent être incohérents. Sur un petit serveur, l'approche sûre la plus simple consiste à arrêter la stack pendant la minute que dure une sauvegarde. Si vous ajoutez Nextcloud avec MariaDB, exportez la base avec `mariadb-dump` avant le passage de restic. Testez au moins une fois une restauration dans un répertoire temporaire ; une sauvegarde jamais restaurée n'est qu'une supposition.

#!/bin/sh
# /usr/local/sbin/stack-backup (run nightly from cron or a systemd timer)
# needs RESTIC_REPOSITORY and RESTIC_PASSWORD_FILE in the environment
cd /srv/stack || exit 1
docker compose stop
rc=0
restic backup /srv/stack --tag stack || rc=$?
docker compose start
[ "$rc" -eq 0 ] || exit "$rc"
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Bases de la sécurité

• ▹SSH : clés uniquement, pas de connexion root par mot de passe, éventuellement un port non standard ; voir [le guide de durcissement SSH](/guides/ssh-hardening).
• ▹Mise en garde sur le pare-feu : les ports publiés par Docker contournent les règles `ufw`, car Docker écrit ses propres chaînes iptables/nftables. Ne publiez que ce qui doit être public (80, 443, 2222) et jamais les ports de bases de données ou d'administration.
• ▹Mises à jour : activez `unattended-upgrades` pour l'hôte, et lancez `docker compose pull && docker compose up -d` selon un calendrier que vous tenez réellement.
• ▹Inscriptions : laissez les inscriptions publiques désactivées dans Vaultwarden et Forgejo ; invitez plutôt les utilisateurs.
• ▹Chiffrement du disque : placez `/srv` sur une [racine chiffrée](/guides/luks-encrypted-root) pour qu'une image disque copiée ne révèle rien ; sur un serveur distant, utilisez le [déverrouillage LUKS à distance via SSH](/guides/luks-remote-unlock-ssh), et préférez le format LUKS2 expliqué dans [LUKS2 ou LUKS1](/guides/luks2-vs-luks1).
• ▹Secrets : `.env` et le répertoire de données de Vaultwarden ne doivent être lisibles que par root (`chmod 600`/`700`).

FAQ