📍 Article principal du sujet : Incus 6 LTS — gérer conteneurs système et VMs Linux pour PME ouest-africaine
Pour la vue d’ensemble, lisez d’abord l’article principal qui pose le contexte d’Incus.
Nextcloud joue un rôle particulier dans l’écosystème open source : c’est l’alternative crédible à Google Drive, Microsoft 365 et Dropbox dont les PME ouest-africaines ont besoin pour rester maîtres de leurs données sans renoncer aux fonctionnalités modernes (édition collaborative, calendrier, contacts, visio Talk, partage externe). L’auto-hébergement sur un Hostinger Cloud VPS dans un conteneur Incus dédié rend le déploiement réversible, isolé et facile à sauvegarder. Ce tutoriel monte une instance Nextcloud production-ready en moins d’une heure, avec PostgreSQL, Redis, HTTPS automatique et stockage objet pour les fichiers volumineux.
Le scénario typique : une PME de Dakar avec dix collaborateurs qui veut un cloud privé pour partager devis, factures et photos client, sans payer 8 USD par utilisateur par mois à Microsoft 365. Sur un VPS 4 Go RAM à 5 USD/mois, l’instance Nextcloud héberge confortablement quinze à vingt utilisateurs avec des dizaines de gigaoctets de fichiers — soit un coût par utilisateur de 0,30 USD au lieu de 8 USD. La rentabilité tient à elle seule la conversation.
Pourquoi Nextcloud dans Incus plutôt qu’avec snap ou Docker
Nextcloud est livré officiellement sous trois formats : archive ZIP à déployer manuellement, paquet snap tout-en-un, et image Docker officielle. Chacun a ses limites pour un usage PME : le snap est un système d’exploitation alternatif dans votre OS, lourd et difficile à personnaliser ; le Docker officiel multiplie les conteneurs (app, db, redis, cron, push) à orchestrer ; l’archive ZIP demande de configurer Apache, PHP, base de données et certificats à la main.
Un conteneur Incus système permet de retrouver le confort d’une installation classique (un seul conteneur, systemd, services normaux) avec l’isolation d’un Docker. Mises à jour, sauvegardes, migration vers un autre VPS deviennent triviales — exporter le conteneur en un fichier .tar.gz et l’importer ailleurs suffit à déménager toute l’instance.
Prérequis
- VPS Linux 64 bits, 4 Go de RAM minimum, 80 Go SSD — Ubuntu 24.04 LTS recommandé sur l’hôte
- Incus 6 LTS opérationnel — voir Installer Incus avec Zabbly
- Caddy installé sur l’hôte pour le reverse-proxy HTTPS
- Un nom de domaine pointant vers l’IP publique du VPS (ex :
cloud.exemple.org) - Niveau attendu : confortable Linux, notion de bases de données et de reverse-proxy
- Temps estimé : 60 minutes pour une instance complète
Pour reproduire, Hostinger Cloud VPS à 4 Go RAM et 80 Go SSD (autour de 5-6 USD/mois) est dimensionné pour vingt utilisateurs Nextcloud actifs avec quelques dizaines de gigaoctets de stockage. Pour un parc plus large ou des fichiers volumineux, on monte sur 8 Go RAM et on délègue le stockage à un bucket S3-compatible externe.
Étape 1 — Créer un conteneur dédié Nextcloud
On lance un conteneur Debian 12 avec un profil dimensionné pour la charge. Les ressources recommandées : 1 vCPU, 1,5 Go RAM, 30 Go disque. Le quota disque sera complété par un bucket S3 pour les fichiers utilisateurs au-delà d’un certain seuil.
incus profile create nextcloud
incus profile edit nextcloud
config:
limits.cpu.allowance: 100%
limits.memory: 1.5GB
limits.memory.swap: false
limits.processes: 800
security.idmap.isolated: true
description: Profil Nextcloud auto-hebergé
devices:
eth0:
name: eth0
network: incusbr0
type: nic
root:
path: /
pool: default
size: 30GB
type: disk
name: nextcloud
used_by: []
incus launch images:debian/12 nextcloud-srv -p nextcloud
incus shell nextcloud-srv
À l’intérieur du conteneur, on installe la pile attendue : Apache, PHP 8.2 avec extensions, PostgreSQL et Redis. Apache reste un meilleur choix que Nginx pour Nextcloud à cette taille — la configuration .htaccess est plus simple à exploiter pour les administrateurs débutants, et les performances sont équivalentes en dessous de cinquante utilisateurs concurrents.
apt update && apt upgrade -y
apt install -y apache2 libapache2-mod-php php php-cli php-pgsql php-curl \
php-gd php-mbstring php-xml php-zip php-imagick php-intl php-bcmath \
php-gmp php-redis php-apcu postgresql redis-server unzip wget
Étape 2 — Configurer PostgreSQL
PostgreSQL est préféré à MariaDB pour Nextcloud en production : meilleur comportement sous charge concurrente, meilleur support des transactions complexes utilisées par les apps Nextcloud (Talk, Calendar). On crée la base et l’utilisateur dédiés en quelques commandes.
systemctl enable --now postgresql
sudo -u postgres psql <<EOF
CREATE USER nextcloud WITH PASSWORD 'mot-de-passe-fort-genere';
CREATE DATABASE nextcloud OWNER nextcloud TEMPLATE template0 ENCODING 'UTF8';
\q
EOF
Le mot de passe doit être généré aléatoirement (openssl rand -base64 24) et conservé dans votre gestionnaire de secrets. Vérifiez la connexion avant de poursuivre :
PGPASSWORD='mot-de-passe' psql -h localhost -U nextcloud -d nextcloud -c '\conninfo'
# You are connected to database "nextcloud" as user "nextcloud" on host "localhost"
Étape 3 — Télécharger et installer Nextcloud
cd /var/www
wget https://download.nextcloud.com/server/releases/latest.zip
unzip latest.zip
chown -R www-data:www-data /var/www/nextcloud
rm latest.zip
L’archive officielle pèse 200 à 250 Mo selon la version. À ce stade, on a les fichiers, on n’a pas encore initialisé l’instance. Cette initialisation se fera via l’occ (l’outil CLI de Nextcloud) plutôt que par l’interface web — c’est plus reproductible et scriptable.
cd /var/www/nextcloud
sudo -u www-data php occ maintenance:install \
--database=pgsql --database-name=nextcloud \
--database-user=nextcloud --database-pass='mot-de-passe-fort-genere' \
--admin-user=admin --admin-pass='mot-de-passe-admin' \
--data-dir=/var/www/nextcloud/data
L’install prend une à deux minutes selon la performance disque. Si elle réussit, vous voyez Nextcloud was successfully installed. Sinon, le message d’erreur est généralement explicite (PostgreSQL pas démarré, mauvais mot de passe, extension PHP manquante).
Étape 4 — Configurer Apache et le domaine de confiance
cat <<'EOF' > /etc/apache2/sites-available/nextcloud.conf
<VirtualHost *:80>
DocumentRoot /var/www/nextcloud
ServerName _
<Directory /var/www/nextcloud/>
Require all granted
AllowOverride All
Options FollowSymLinks MultiViews
<IfModule mod_dav.c>
Dav off
</IfModule>
</Directory>
</VirtualHost>
EOF
a2enmod rewrite headers env dir mime
a2ensite nextcloud
a2dissite 000-default
systemctl reload apache2
Nextcloud refuse par défaut les requêtes provenant de domaines non listés dans trusted_domains. On ajoute le domaine public (qui sera proxifié par Caddy) à cette liste :
sudo -u www-data php occ config:system:set trusted_domains 1 --value=cloud.exemple.org
sudo -u www-data php occ config:system:set overwrite.cli.url --value=https://cloud.exemple.org
sudo -u www-data php occ config:system:set overwriteprotocol --value=https
Le overwriteprotocol https est crucial : sans lui, Nextcloud génère des liens en http:// en interne et provoque les fameux mixed-content warnings dans le navigateur. On sort du conteneur (exit) et on configure Caddy sur l’hôte.
Étape 5 — Caddy sur l’hôte avec HTTPS automatique
# Sur l'hôte, récupérer l'IP du conteneur
incus list -c n4 nextcloud-srv --format csv
# nextcloud-srv,10.124.10.51 (eth0)
cat <<'EOF' >> /etc/caddy/Caddyfile
cloud.exemple.org {
reverse_proxy 10.124.10.51:80
encode gzip
request_body {
max_size 16GB
}
header {
Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
}
}
EOF
systemctl reload caddy
La directive request_body max_size 16GB autorise l’upload de gros fichiers (16 Go par défaut, à ajuster). HSTS est ajouté pour empêcher les downgrade attacks. Caddy demande automatiquement un certificat Let’s Encrypt et l’applique en moins d’une minute.
Étape 6 — Activer le cache Redis et APCu
Sans cache, Nextcloud est lent dès le second utilisateur connecté. Avec Redis pour le verrouillage de fichiers et APCu pour le cache mémoire, l’expérience devient fluide même à dix utilisateurs concurrents. La configuration tient en quelques lignes :
incus shell nextcloud-srv
systemctl enable --now redis-server
sudo -u www-data php /var/www/nextcloud/occ config:system:set memcache.local --value='\OC\Memcache\APCu'
sudo -u www-data php /var/www/nextcloud/occ config:system:set memcache.distributed --value='\OC\Memcache\Redis'
sudo -u www-data php /var/www/nextcloud/occ config:system:set memcache.locking --value='\OC\Memcache\Redis'
sudo -u www-data php /var/www/nextcloud/occ config:system:set redis host --value=127.0.0.1
sudo -u www-data php /var/www/nextcloud/occ config:system:set redis port --value=6379
L’effet est immédiat et mesurable : la page d’accueil passe de 800 ms à 150 ms en moyenne, et les opérations de partage répondent quasi instantanément. La consommation mémoire augmente de 50 Mo environ pour Redis, négligeable.
Étape 7 — Cron Nextcloud propre via systemd
Nextcloud exécute des tâches en arrière-plan (suppression de fichiers expirés, indexation, push notifications). Par défaut le cron se déclenche à chaque page chargée (mode AJAX), ce qui ralentit l’expérience. On bascule en mode cron via systemd timer :
cat <<'EOF' > /etc/systemd/system/nextcloud-cron.service
[Unit]
Description=Nextcloud cron.php job
[Service]
User=www-data
ExecStart=/usr/bin/php -f /var/www/nextcloud/cron.php
EOF
cat <<'EOF' > /etc/systemd/system/nextcloud-cron.timer
[Unit]
Description=Run Nextcloud cron.php every 5 minutes
[Timer]
OnBootSec=5min
OnUnitActiveSec=5min
Unit=nextcloud-cron.service
[Install]
WantedBy=timers.target
EOF
systemctl daemon-reload
systemctl enable --now nextcloud-cron.timer
sudo -u www-data php /var/www/nextcloud/occ background:cron
exit
À ce stade, Nextcloud est complet et fonctionnel. Vous pouvez vous connecter sur https://cloud.exemple.org, créer des comptes utilisateurs, installer les apps souhaitées (Talk pour la visio, Deck pour la gestion de tâches, Calendar, Contacts) depuis le menu administrateur.
Étape 8 — Externaliser les fichiers vers S3 pour scaler
Le quota disque du conteneur (30 Go) tient pour vingt utilisateurs avec usage modéré. Pour aller au-delà sans gonfler le VPS, on externalise les fichiers utilisateurs vers un bucket S3-compatible. Bunny Storage, Wasabi ou un MinIO auto-hébergé conviennent — le bucket S3 d’AWS est aussi possible mais nettement plus cher.
incus shell nextcloud-srv
sudo -u www-data php occ config:system:set objectstore class --value='\OC\Files\ObjectStore\S3'
sudo -u www-data php occ config:system:set objectstore arguments bucket --value=nextcloud-pme
sudo -u www-data php occ config:system:set objectstore arguments key --value=ACCESS_KEY
sudo -u www-data php occ config:system:set objectstore arguments secret --value=SECRET_KEY
sudo -u www-data php occ config:system:set objectstore arguments hostname --value=storage.bunnycdn.com
sudo -u www-data php occ config:system:set objectstore arguments port --value=443
sudo -u www-data php occ config:system:set objectstore arguments use_ssl --value=true
À partir de cette config, les fichiers uploadés ne sont plus stockés sur le disque local du conteneur mais directement sur le bucket. Le coût change de nature : 5 USD par téraoctet stocké chez Bunny, contre l’achat d’un disque de VPS dédié. Pour une PME qui passe de 50 Go à 500 Go en deux ans, l’économie est concrète.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Untrusted domain au login | Domaine pas dans trusted_domains |
occ config:system:set trusted_domains 1 --value=cloud.exemple.org |
| Upload de fichiers gros bloque à 2 Mo | upload_max_filesize PHP par défaut |
Modifier /etc/php/8.2/apache2/php.ini : upload_max_filesize 16G, post_max_size 16G, memory_limit 512M |
| Avertissement strict-transport-security manquant | HSTS pas activé côté reverse-proxy | Ajouter le header dans Caddy comme montré étape 5 |
| Mode maintenance bloqué après update plantée | Update interrompue | occ maintenance:mode --off puis occ upgrade |
| Performances dégradées après quelques mois | Tables PostgreSQL non vacuumées | Activer autovacuum (par défaut) et lancer occ db:add-missing-indices |
Adaptation au contexte ouest-africain
Pour une PME de 10 personnes à Dakar, le calcul mensuel est radical : 5 USD pour le VPS Hostinger 4 Go, 0 USD si on reste sur le stockage local sous 30 Go, soit 500 FCFA par utilisateur et par mois pour un cloud privé complet (fichiers, calendrier, contacts, partage externe). À comparer aux 4 800 FCFA mensuels par utilisateur de Microsoft 365 Business Standard. Sur 10 collaborateurs, le différentiel atteint 50 000 FCFA mensuels — soit 600 000 FCFA d’économie annuelle pour une fonctionnalité équivalente.
L’argument souveraineté joue aussi : les données restent sur un serveur que l’entreprise contrôle, ne transitent pas par les datacenters américains, et le RGPD-équivalent local devient plus facile à respecter pour les structures qui traitent des données personnelles (cabinets juridiques, médecins, ONG).
Côté connectivité, Nextcloud comprend très bien la bande passante limitée. Le client desktop synchronise par delta-blocs (n’envoie que ce qui a changé), supporte la pause à la demande, et les apps mobiles offrent un mode upload uniquement sur Wi-Fi qui évite les surconsommations de data sur les forfaits Orange/MTN/Free. Pour un freelance qui voyage entre Dakar et Saint-Louis, la synchro reprend là où elle en était au prochain branchement, sans casser les conflits.
Tutoriels frères
- Héberger 100 conteneurs Incus sur un seul VPS — pour comprendre la dimension capacité multi-services.
- WordPress multisite — un conteneur Incus par client — modèle similaire pour l’hébergement de sites.
- Backup distant S3 d’instances Incus — pour sauvegarder Nextcloud hors site.
Pour aller plus loin
- 🔝 Retour à l’article principal sur Incus
- Documentation officielle Nextcloud
- Configuration stockage primaire S3
- Pour pratiquer : Hostinger Cloud VPS 4 Go RAM en français
FAQ
PostgreSQL ou MariaDB ?
PostgreSQL pour la production, MariaDB pour les déploiements simples. Au-delà de cinq utilisateurs concurrents, PostgreSQL gère mieux les locks et la fragmentation des tables.
Combien d’utilisateurs sur un VPS 4 Go ?
Vingt utilisateurs actifs en usage bureautique standard. Au-delà, passer sur 8 Go RAM ou cluster Incus 3 nœuds avec PostgreSQL en haute dispo.
Comment activer Talk pour la visio ?
Depuis le panneau admin, Apps → installer Talk. Pour les appels au-delà de quatre participants, déployer un serveur signaling externe (Janus ou nextcloud-spreed-signaling) — un autre conteneur Incus dédié fait l’affaire.
Sauvegarde recommandée ?incus snapshot quotidien + incus export hebdomadaire vers S3 distant. Pour les fichiers stockés en S3, un versionning bucket-side suffit (Bunny et Wasabi le proposent).
Le client desktop fonctionne-t-il sous Windows et macOS ?
Oui, clients officiels disponibles pour Windows, macOS, Linux, iOS et Android. La synchro est multi-plateforme et stable.