Nextcloud transforme du matériel nu en cloud privé que vous contrôlez de bout en bout : sync de fichiers, calendriers, contacts et édition de documents, sans licence par siège et sans tiers qui tient les clés. Le faire tourner sur un serveur dédié donne à ces services le disque entier, le processeur entier et la carte réseau entière. Ce guide couvre le déploiement manuel sur Ubuntu 24.04 LTS, sur du matériel à partir de 9,99 €/mois.

Points clés à retenir

  • Vous emmènerez une distribution propre vers un serveur Nextcloud en marche, avec HTTPS et une configuration durcie.
  • Outils requis : un accès SSH, un domaine pointant vers votre IP publique, et les credentials root et l'adresse IP que Kimsufi envoie au provisioning.
  • Temps estimé : 60 à 90 minutes, l'essentiel étant passé à attendre les téléchargements de paquets.
  • Niveau : intermédiaire. Un confort avec la ligne de commande Linux est supposé.
  • L'hôte Nextcloud terminé fait tourner MariaDB, PHP 8.3, un certificat Let's Encrypt et une protection brute-force.

Pourquoi choisir un serveur dédié pour Nextcloud ?

La suite est liée aux I/O avant toute autre chose. La génération de miniatures, la recherche full-text et les vérifications delta du client de sync martèlent toutes le même disque, et sur une infrastructure partagée ce disque est partagé aussi.

Pas de voisins bruyants. Le bare metal assigne l'unité entière à un seul tenant. Le débit de stockage ne s'effondre pas parce qu'un autre client a lancé un job de sauvegarde, qui est le mode d'échec standard sur une machine virtuelle.

Accès root complet. Vous choisissez la distribution, la version de PHP, la couche de cache et le filesystem, et vous pouvez intégrer le logiciel de monitoring que vous faites déjà tourner. Aucun plafond imposé par le fournisseur sur la taille de transfert ou le temps d'exécution.

Coût prévisible. Les abonnements cloud facturent par téraoctet par mois. Le bare metal facture un tarif fixe quoi que vous stockiez, si bien que l'arithmétique est simple : un cloud privé auto-hébergé devient moins cher à mesure que vous gardez plus de données. Notre comparatif du stockage cloud open source oppose Nextcloud à Seafile et ownCloud, avec le seuil où le matériel bat un forfait de 2 To.

Souveraineté des données. Vous savez quel rack détient vos données et dans quelle juridiction il se siège, parce que vous avez choisi le data centre.

Prérequis : ce qu'il vous faut avant de commencer

  • Un serveur dédié Kimsufi avec au moins 8 Go de RAM. Le guidance de dimensionnement est dans le tableau ci-dessous.
  • Un domaine enregistré avec un enregistrement A pointant vers votre adresse IP. Let's Encrypt n'émettra pas de certificat pour une IP nue.
  • Un accès root par SSH, plus l'adresse IP et les identifiants envoyés par e-mail après le provisioning. Pointez l'enregistrement A vers cette IP avant de commencer, parce qu'une IP nue ne passera pas la validation.
  • Ubuntu 24.04 LTS, la base stable que la plupart des guides supposent. Debian 12 est l'autre distribution sûre ici, identique à deux noms de paquets près.
  • Environ 5 Go libres pour la source, séparés de ce que vous comptez stocker.
  • Une vue d'ensemble de la séquence : verrouiller le système d'exploitation, poser la pile, vérifier l'archive, câbler Apache et la base, puis exécuter l'installateur.

💡 Astuce Il existe aussi un snap et une image Docker all-in-one. La route snap promet une installation Nextcloud facile en une instruction et la livre, mais le sandbox du snap restreint où les données peuvent vivre et quel réglage PHP vous pouvez changer, et la même limite s'applique aux images appliance vendues sur du matériel single-board. Sur du matériel que vous possédez en propre, un build manuel vous donne le contrôle qui rend le matériel payant.

Étape 1 : provisionner votre serveur dédié Kimsufi

Commandez la boîte et choisissez la distribution dans le même flux. Le provisioning est automatisé et se termine habituellement en quelques minutes. Accordez le matériel au nombre de personnes qui l'utiliseront :

UtilisateursGamme suggéréeProfil
1 à 5Serveur dédié Kimsufi KS-2Cloud personnel, backup photos, partage de fichiers léger
5 à 25Serveur dédié Kimsufi KS-3Petite équipe, Nextcloud Office, sync de calendrier
25 à 100Serveur dédié Kimsufi KS-4Organisation entière, usage concurrentiel lourd

Attachez votre clé publique SSH, choisissez la distribution et confirmez. Quand l'e-mail de bienvenue arrive, connectez-vous et vérifiez que l'interface est montée sur l'IP attendue :

bash
ssh root@YOUR_SERVER_IP
ip -4 addr show

✅ Résultat attendu Un shell root sur un système Ubuntu propre, montrant l'IP publique vers laquelle vous pointerez le domaine, et la route que la boîte emprunte pour joindre Internet.

Étape 2 : sécuriser le serveur (pare-feu, SSH, Fail2Ban)

Durcissez l'hôte avant que quoi que ce soit écoute sur le port 443. Chaque instruction ci-dessous s'exécute par SSH en root. Mettez à jour, puis tirez l'outillage de sécurité :

bash
sudo apt update && sudo apt upgrade -y
sudo apt install -y ufw fail2ban

Ouvrez seulement ce dont Nextcloud a besoin, et ajoutez la règle SSH d'abord :

bash
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable

Désactivez la connexion par mot de passe et le SSH root dans /etc/ssh/sshd_config (PermitRootLogin no, PasswordAuthentication no), puis redémarrez le service. Démarrez la jail qui surveille les connexions échouées et bannit l'IP fautive :

bash
sudo systemctl restart ssh
sudo systemctl enable --now fail2ban

Notre guide pare-feu du serveur dédié couvre en profondeur le design des règles, la journalisation et la politique par port.

⚠️ Attention Ouvrez une seconde fenêtre de terminal et confirmez que vous pouvez encore vous connecter avant de fermer la première session. Un pare-feu activé sans règle SSH vous verrouille hors de la boîte.

Étape 3 : installer les paquets requis (Apache/Nginx, PHP, MariaDB)

La pile est un serveur web, PHP 8.3 et une base de données relationnelle. Tirez tout avec une seule commande :

bash
sudo apt install -y apache2 mariadb-server libapache2-mod-php8.3 \
  php8.3 php8.3-{gd,mysql,curl,mbstring,intl,gmp,bcmath,xml,imagick,zip} \
  php8.3-apcu redis-server certbot python3-certbot-apache unzip wget

Vous préférez Nginx ? Échangez apache2 et libapache2-mod-php8.3 contre nginx et php8.3-fpm. Sur toute distribution à base Debian le reste de la liste de paquets est identique ; sur une distribution RPM les noms diffèrent mais l'ensemble non.

Sécurisez le moteur de base de données, puis confirmez que les deux services démarrent au boot :

bash
sudo mysql_secure_installation
sudo systemctl enable --now apache2 mariadb

💡 Astuce APCu et Redis sont dans cette liste de paquets délibérément. Un memory cache silencie l'avertissement de configuration, et le file locking à travers Redis empêche deux clients de sync de corrompre le même document.

Étape 4 : télécharger et vérifier le paquet Nextcloud

Ne déployez jamais une archive que vous n'avez pas vérifiée. Récupérez la release stable, sa signature et la clé de signature du projet depuis un keyserver :

bash
cd /tmp
wget https://download.nextcloud.com/server/releases/latest.zip
wget https://download.nextcloud.com/server/releases/latest.zip.asc
gpg --keyserver keys.openpgp.org --recv-keys D75899B9A724937A
gpg --verify latest.zip.asc latest.zip

Si ce keyserver est injoignable, utilisez un second keyserver ou importez la clé manuellement. Le manuel d'administration liste les sources alternatives, et la fingerprint y est publiée aussi, si bien que vous pouvez la vérifier à la main contre ce que gpg rapporte. Une bonne signature est la seule preuve que le paquet a quitté le projet sans falsification.

Décompressez la source et remettez la possession à l'utilisateur web, qui ne peut pas autrement écrire dans l'arbre :

bash
sudo unzip latest.zip -d /var/www/
sudo chown -R www-data:www-data /var/www/nextcloud

Étape 5 : configurer le serveur web et les réglages PHP

Créez un virtual host dans /etc/apache2/sites-available/nc.conf pour qu'Apache le serve sur votre domaine :

apache
<VirtualHost *:80>
  DocumentRoot /var/www/nextcloud
  ServerName cloud.example.com
  <Directory /var/www/nextcloud>
    Require all granted
    AllowOverride All
    Options FollowSymlinks MultiViews
  </Directory>
</VirtualHost>

Activez le site et les modules dont il dépend :

bash
sudo a2ensite nc.conf
sudo a2enmod rewrite headers env dir mime
sudo systemctl reload apache2

Puis relevez les limites PHP dans /etc/php/8.3/apache2/php.ini, parce que les défauts rejettent tout upload au-dessus de 2 Mo :

bash
memory_limit = 1G
upload_max_filesize = 16G
post_max_size = 16G
max_execution_time = 3600

💡 Astuce Posez opcache.memory_consumption=128 dans ce même ini. Ce seul réglage est le changement de performance le moins cher disponible n'importe où.

Étape 6 : mettre en place la base de données et créer un utilisateur Nextcloud

L'application a besoin de son propre schéma et de son propre compte. Ouvrez le shell de la base avec sudo mysql -u root -p, puis n'accordez rien de plus large que requis :

sql
CREATE DATABASE nc_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'nc_admin'@'localhost' IDENTIFIED BY 'a-long-random-password';
GRANT ALL PRIVILEGES ON nc_db.* TO 'nc_admin'@'localhost';
FLUSH PRIVILEGES;
EXIT;

✅ Résultat attendu SHOW DATABASES; liste le nouveau schéma, et le compte se connecte sans droits root.

Étape 7 : exécuter l'installateur web et terminer l'installation

Pointez un navigateur vers http://cloud.example.com. L'installateur web demande quatre choses : un nom d'administrateur, un mot de passe, un répertoire de données et les credentials de base de données de la section précédente.

Gardez le répertoire de données hors de la racine web pour qu'aucun fichier ne puisse jamais être servi directement :

bash
sudo mkdir -p /var/nc-data && sudo chown -R www-data:www-data /var/nc-data

Soumettez le formulaire et l'installateur écrit config.php, construit le schéma et vous connecte. L'outil occ fait le même travail en mode non supervisé, qui est l'option à prendre pour scripter une reconstruction ou une instance de développement.

✅ Résultat attendu Le dashboard charge et l'app Files est prête à l'emploi.

Optionnel : activer HTTPS avec Let's Encrypt

Servir un cloud en HTTP simple expose chaque token de session sur le câble. Certbot, tiré plus tôt avec le reste de la pile, émet et renouvelle un certificat gratuit :

bash
sudo certbot --apache -d cloud.example.com

Certbot réécrit ce vhost, redirige le port 80 vers le 443 et dépose un timer de renouvellement sous /etc/letsencrypt. Confirmez l'automatisation avec certbot renew --dry-run avant d'oublier qu'elle existe. Ajoutez le domaine à trusted_domains dans config.php si l'installateur ne l'a pas fait, sinon la requête est refusée. Sauvegardez /etc/letsencrypt avec tout le reste.

Optionnel : configurer un reverse proxy pour une meilleure performance

Un reverse proxy termine le TLS, met en cache les assets statiques et laisse une boîte faire tourner plusieurs services derrière une IP publique. Nginx est le choix habituel, et le même reverse proxy est là où le trafic WebDAV se termine proprement, puisque les clients de sync et les disques montés partagent un endpoint.

Déclarez le proxy, sinon chaque client apparaît venir de 127.0.0.1 et la protection brute-force bannit votre propre IP :

bash
'trusted_proxies' => ['127.0.0.1'],
'overwriteprotocol' => 'https',

Post-installation : tuning, backup et monitoring

Jobs de fond. Passez d'AJAX au cron système dans le panneau d'administration, puis attachez le job à l'utilisateur web :

bash
sudo crontab -u www-data -e
*/5 * * * * php -f /var/www/nextcloud/cron.php

Backup. Trois choses doivent être capturées ensemble : le répertoire de données, un dump de base de données et config.php. Un instantané de l'un d'eux seul ne se restaurera pas. Testez une restauration chaque trimestre pour vous assurer que les copies sont utilisables avant qu'un incident de production ne force la question. Les scripts rsync et Borg des sauvegardes serveur automatisées prennent en charge les trois via une tâche cron nocturne.

Monitoring. L'app Serverinfo vous donne une vue unique de CPU, mémoire et espace libre, exposée en JSON que n'importe quel outil de monitoring peut sonder. Le panneau d'admin garde une vue correspondante par utilisateur et par device. Surveillez l'espace disque avant tout, parce que la performance se dégrade sévèrement quand le volume de données se remplit. Ce que vous utilisez déjà pour monitorer Linux gérera celui-ci aussi.

Maintenance. Exécutez occ maintenance:repair après chaque mise à niveau et gardez une fenêtre par mois pour les patchs du système d'exploitation.

Problèmes courants et comment les dépanner

SymptômeCause probableCorrectif
"Accès via un domaine non confiance"Manquant dans la configurationAjoutez-le à trusteddomains
Upload stoppe à 2 MoDéfauts PHP toujours actifsRelevez uploadmaxfilesize et postmaxsize, rechargez Apache
"Internal Server Error" après l'installationModule PHP manquant ou possession erronéeLisez /var/log/apache2/error.log, relancez le chown
Client de sync bloqué sur "Connexion"Port 443 fermé ou certificat invalideVérifiez ufw status et certbot certificates en root
Vue lente, forte charge sous accès concurrentPas de memory cache configuréActivez APCu, posez memcache.local
Fail2Ban bannit de vrais utilisateursReverse proxy non déclaréPosez trustedproxies pour que l'IP client, et non l'IP du proxy, soit loggée

Scaling de Nextcloud sur un serveur dédié : ajouter RAM, stockage et CPU

Scaler une plateforme auto-hébergée signifie savoir quelle ressource s'épuise la première.

La RAM d'abord. Les workers PHP-FPM, le cache APCu et le buffer pool de la base tirent tous sur la mémoire. Sous 8 Go, les uploads concurrents font la file.

Puis le stockage. Les bibliothèques de photos et de vidéos croissent plus vite que tout autre type de données. Passé 70% rempli, passez à une machine riche en stockage comme le serveur dédié Kimsufi KS-C plutôt que de vous battre pour l'espace.

Puis le CPU. La génération de vignettes, le chiffrement et l'indexation full-text sont du travail de processeur, et ce sont les jobs précis qui rendent une instance de production lente. Quelque chose comme le serveur dédié Kimsufi KS-7 absorbe cette charge sans ralentir l'usage interactif.

Stockage externe. Vous pouvez monter un bucket S3, un partage SMB ou une seconde boîte, et l'intégrer comme s'il était local. C'est ainsi que vous étendez la capacité sans migrer l'instance, et vous pouvez toujours partager des liens de fichiers qui pointent vers des données vivant ailleurs, ou partager l'accès fichiers avec un groupe qui n'a aucun compte du tout.

Bonnes pratiques de sécurité : 2FA, protection brute-force et mises à jour

Authentification à deux facteurs. Activez l'app Nextcloud TOTP et appliquez-la par groupe à travers l'organisation. Chaque utilisateur enregistre un périphérique, et un mot de passe volé seul cesse de suffire. La liste de sessions montre chaque appareil actuellement connecté, et révoquer l'un prend un clic depuis la même vue.

Protection brute-force. Activée par défaut. Elle limite les échecs répétés par IP, et Fail2Ban ajoute un bannissement au niveau pare-feu sur la même IP par-dessus le délai au niveau application.

Chiffrement côté serveur. Utile pour le stockage externe que vous ne contrôlez pas, où il protège les données au repos sur le disque de quelqu'un d'autre. Il coûte en performance et complique la récupération, donc allumez cette option délibérément.

Mises à jour. Appliquez chaque patch release par le gestionnaire de paquets ou l'updater intégré, et ne sautez jamais une version majeure : le chemin de migration attend chaque étape dans l'ordre. Suivez l'instruction de mise à niveau publiée avec chaque release plutôt que d'improviser.

Scan de sécurité. Exécutez le scanner officiel contre le domaine. Il note la configuration TLS, les en-têtes de réponse et la version que vous exposez, puis vous dit quels réglages doivent encore protéger la route de login. Le chapitre durcissement du manuel explique chaque découverte.

Conclusion

Vous avez maintenant un serveur Nextcloud sur du matériel que vous contrôlez : un paquet source vérifié, un système d'exploitation durci, un back end MariaDB, des réglages PHP calibrés et un certificat valide. Tout ce qui est au-dessus de cette ligne est là où le travail intéressant commence, que ce soit connecter un client desktop, ajouter un client mobile pour le backup photos, monter du stockage externe ou choisir une app Nextcloud du store pour étendre ce qui est livré par défaut. Gardez le cron job tournant et les sauvegardes vérifiées, et la plateforme se porte elle-même.

Déployez votre serveur Nextcloud dès aujourd'hui Commencez avec les serveurs dédiés Kimsufi à partir de 9,99 €/mois. Accès root, trafic illimité, protection DDoS intégrée.

FAQ

Puis-je héberger mon propre serveur Nextcloud ?

Oui, et c'est le modèle de déploiement prévu. C'est un logiciel open source que vous pouvez déployer sur tout matériel que vous contrôlez, d'un périphérique single-board à un châssis rack. Le bare metal est le juste milieu pratique : toujours allumé, sur un réseau de qualité entreprise, sans couche de machine virtuelle entre l'application et le disque, et avec assez de CPU et de disque pour soutenir une équipe entière. Vous fournissez le matériel, l'enregistrement DNS et l'entretien, et vous maintenez Nextcloud sur votre propre agenda. Aucune fonctionnalité n'est réservée à l'offre managée d'un fournisseur.

Nextcloud est-il gratuit en auto-hébergé ?

Le paquet est gratuit et reste gratuit, publié sous AGPLv3 sans plafond d'utilisateurs ni barrière de fonctionnalités. Vos coûts sont la boîte et le domaine. Un abonnement Enterprise payant existe, et il achète le support vendeur et les mises à jour longues durées pour les grands déploiements, mais rien ici ne l'exige. Pour la plupart des instances auto-hébergées la facture mensuelle de matériel est le coût entier, et c'est tout l'argument de posséder la plateforme plutôt que de louer la capacité par téraoctet.

Quelle RAM faut-il pour un serveur Nextcloud ?

Comptez 128 Mo par processus PHP au minimum, 512 Mo comme valeur recommandée. En pratique, 4 Go font tourner une instance personnelle, 8 Go sont un plancher confortable pour une petite équipe, et 16 Go ou plus conviennent à une organisation avec des dizaines d'utilisateurs concurrents, Nextcloud Office et la recherche full-text en usage. Une organisation de cette taille devrait étendre la RAM avant d'ajouter du disque. Redis et APCu vivent tous deux en mémoire, donc prévoyez pour eux par-dessus. La RAM est la première chose à relire quand l'interface paraît lente sous charge.

Nextcloud peut-il servir de NAS ?

Fonctionnellement oui, avec une réserve sur l'endroit où siègent les disques. Vous obtenez la navigation de fichiers, le partage, le versioning et l'accès WebDAV, ce qui couvre ce que la plupart des gens veulent d'un NAS, plus l'intégration LDAP si l'organisation a déjà un annuaire. Ce n'est pas une couche de stockage propre : il siège au-dessus du filesystem que vous lui donnez. TrueNAS est construit autour de ZFS d'abord, et c'est pourquoi faire tourner Nextcloud sur TrueNAS est un pattern si courant : TrueNAS gère le pool ZFS et ses snapshots dessous, et l'intégration reste propre. Sur du bare metal la même division s'applique, avec le tableau RAID du fournisseur jouant le rôle que TrueNAS joue à la maison.