VPS Cloud

Avec un hébergement mutualisé, les ressources sont partagées entre plusieurs clients. Un VPS vous offre des ressources dédiées (vCPU, RAM, SSD), un accès root et une isolation complète — plus de performances et de contrôle.

Oui, tous nos VPS Linux incluent un accès root complet via SSH. Vous installez ce que vous voulez, configurez votre stack librement, et gérez les permissions selon vos besoins.

3 configurations, toutes avec accès root et IPv4 dédiée : VPS Start (2 vCPU, 4 GB RAM, 50 GB SSD — 99 DH/mois), VPS Power (4 vCPU, 8 GB RAM, 100 GB SSD — 299 DH/mois) et VPS Business (8 vCPU, 16 GB RAM, 200 GB SSD — 499 DH/mois). Le détail à jour figure sur la page VPS Cloud.

Oui. Chaque VPS reçoit une adresse gratuite de la forme vps-xxxxxxx.servorbit-dns.com, incluse et active dès la mise en service. Elle masque l'IP publique et vous sert à tout — vous connecter en SSH, publier une application ou communiquer un accès — sans posséder de domaine. Vous la retrouvez dans la console de votre VPS (espace client → VPS → Gérer). Enregistrez ou transférez votre propre domaine quand vous le souhaitez : votre adresse de marque reste disponible en parallèle.

Oui, sous réserve des conditions d'utilisation. Vous pouvez installer Node.js, Python, Docker, Nginx, Apache, ou tout autre logiciel compatible avec votre distribution Linux.

Vous choisissez votre distribution Linux à la commande (Ubuntu, Debian, et autres distributions courantes). Vous pouvez réinstaller le système quand vous le souhaitez.

Un template est un environnement préconfiguré (par exemple Open WebUI, n8n, Coolify) installé automatiquement à la création du VPS, pour démarrer sans configuration manuelle.

Par défaut, le VPS est non managé : vous en avez le contrôle total. Une prestation d'administration VPS est disponible en option si vous préférez nous la confier.

Oui, chaque VPS est livré avec une adresse IPv4 dédiée, incluse dans le prix. Une IPv6 est disponible sur demande.

Non. À la commande d'un VPS, vous choisissez librement son adresse — sans jamais bloquer le paiement. Trois options : garder le sous-domaine gratuit servorbit-dns.com (proposé par défaut, rien à acheter), utiliser un nom de domaine que vous possédez déjà sur votre compte (nous le rattachons au serveur dès sa mise en service), ou en enregistrer un nouveau au passage. Vous pouvez aussi démarrer sur le sous-domaine gratuit et rattacher un domaine plus tard, à tout moment.

VPS Power inclut les snapshots. VPS Business inclut snapshots et backups automatiques. Vous pouvez aussi configurer vos propres sauvegardes (rsync, borgbackup, etc.).

Oui. Depuis votre espace client, ajoutez des options (vCPU, RAM, espace disque, IP supplémentaire) à la volée : la différence est facturée au prorata du temps restant et les ressources sont appliquées au paiement, sans perte de données.

En partie. Depuis l'espace client, vous pouvez retirer les options récupérables — vCPU, RAM, sauvegarde, snapshots — et libérer une IP supplémentaire : la réduction est immédiate et la part non consommée vous est restituée au prorata (avoir). L'IP principale et l'espace disque ne peuvent pas être réduits (le disque ne se rétrécit pas sans risque) — pour ces cas, contactez le support.

Oui. Les plans VPS Power et VPS Business sont recommandés pour la production selon la charge attendue (trafic, conteneurs, bases de données).

Oui. Sur le configurateur VPS Cloud, après avoir choisi le plan et la distribution, réglez le « Nombre de VPS » avant de continuer : nous créons autant de serveurs indépendants — chacun avec sa propre machine, son IP et ses accès — réglés en une seule commande. Vous pouvez ensuite les gérer séparément depuis votre espace client.

Évitez-le : pendant une installation 1-clic, votre serveur est momentanément gelé et les actions de gestion sont suspendues. Si vous le redémarrez ou vous y connectez (console / SSH root) à ce moment-là, vous risquez d'interrompre l'installation. Aucune crainte toutefois pour vos données : nous prenons une sauvegarde (snapshot) juste avant de commencer, et en cas d'interruption votre serveur est automatiquement restauré à son état d'avant l'installation. Attendez simplement la fin de l'opération (la page se met à jour toute seule).

En un clic depuis votre espace client : dans la console de votre VPS, la section « Domaines rattachés » (ou l'onglet DNS d'un domaine, « Rattacher à un VPS ») fait pointer le domaine vers l'IP du serveur — nous créons automatiquement les enregistrements A (racine et www) et configurons le reverse-proxy. Le domaine doit appartenir au même compte et le VPS être actif avec une IP attribuée. Vous pouvez aussi commander ou transférer un domaine directement pour ce VPS : le pointage se fera dès son activation.

L'adresse gratuite `vps-xxxxxxx.servorbit-dns.com` est parfaite pour démarrer : elle masque l'IP et publie vos apps en HTTPS. Mais un nom de domaine à vous porte votre marque, fiabilise vos e-mails professionnels (vous maîtrisez SPF, DKIM et DMARC sur votre propre domaine) et rassure vos visiteurs. Vous le rattachez en un clic depuis l'espace client — DNS managé et certificat HTTPS inclus — et l'adresse gratuite continue de fonctionner pendant la transition.

Oui. À l'installation d'une application (espace client → VPS → Gérer → Applications), vous choisissez son adresse web — un sous-domaine (par ex. dolibarr.monsite.tld) ou un chemin (monsite.tld/dolibarr) — sur l'un de vos domaines. Nous créons l'enregistrement DNS automatiquement si votre domaine utilise notre DNS managé (sinon nous vous indiquons l'enregistrement à créer chez votre fournisseur), puis nous posons un reverse-proxy et un certificat HTTPS (Let's Encrypt) renouvelé automatiquement. Pas encore de domaine ? Publiez l'application sur votre sous-domaine gratuit (de la forme dolibarr.vps-xxxxxxx.servorbit-dns.com, HTTPS inclus, rien à configurer), ou enregistrez / transférez votre propre domaine directement depuis le formulaire. Les applications réseau de type VPN (OpenVPN, WireGuard) font exception : elles s'installent sans domaine web et s'utilisent via l'adresse du serveur (son IP ou son adresse ServOrbit).

Oui, depuis la console de votre VPS (Réseau & sécurité → Reverse DNS). Le PTR est indispensable pour envoyer des e-mails depuis le serveur : il doit correspondre au nom annoncé par votre serveur mail. Si vous n'avez pas de domaine à vous, vous pouvez y placer votre adresse ServOrbit gratuite en un clic — elle pointe déjà vers l'IP du serveur, ce qui donne un reverse DNS « confirmé » attendu par les services de messagerie.

Oui. Depuis l'espace client → VPS → Gérer → Applications, chaque application installée propose un bouton « Désinstaller ». Vous choisissez de conserver les données (par défaut : seuls les conteneurs sont retirés, une réinstallation les retrouve) ou de les supprimer définitivement. Comme pour l'installation, l'opération est confirmée par un code de sécurité, votre serveur est momentanément injoignable, et une sauvegarde (snapshot) est prise avant de commencer : en cas de problème, le serveur est restauré à l'identique. Une fois terminée, le port et les ressources qu'occupait l'application sont de nouveau disponibles. Note : une application requise par une autre application installée ne peut pas être retirée tant que cette dernière est présente.

Oui, grâce à K3s, une distribution Kubernetes légère certifiée CNCF, il est possible de déployer un cluster fonctionnel sur un VPS disposant d'un seul vCPU et de 2 Go de RAM. K3s regroupe tous les composants du control plane dans un seul binaire de 60 Mo et remplace etcd par SQLite, réduisant considérablement l'empreinte mémoire. Il reste entièrement compatible avec `kubectl` et Helm, ce qui vous permet d'utiliser l'écosystème Kubernetes habituel sans surcoût d'infrastructure.

Oui. Woodpecker CI (serveur + agent) consomme moins de 50 Mo de RAM au repos, et Forgejo tourne confortablement dans 300 à 500 Mo. Un VPS avec 2 Go de RAM est suffisant pour une utilisation courante (quelques dépôts, pipelines courts). Pour des builds plus intensifs (compilation, tests parallèles), un VPS 4 Go est recommandé. Chaque étape de pipeline s'exécute dans un conteneur Docker isolé : Docker doit être installé et le démon actif.

Oui. Chaque dépôt GitHub publie un flux Atom de ses releases à l'adresse `https://github.com/<owner>/<repo>/releases.atom`. Ajoutez ces URL dans FreshRSS, créez une règle de marquage automatique sur les mots-clés « security » ou « breaking change », et activez le webhook ntfy ou un webhook email dans les paramètres. FreshRSS rafraîchit les flux toutes les 20 minutes côté serveur — vous recevez une notification mobile dès qu'un mainteneur publie une alerte, sans ouvrir aucune application.

Dans FreshRSS, allez dans Paramètres → Authentification → Accès à l'API GReader, activez l'API et notez l'URL de l'endpoint (format `http://ip-ou-domaine:8080`). Dans Reeder 5, ajoutez un compte de type « FreshRSS » (ou « Fever » selon la version) et entrez cet URL avec votre nom d'utilisateur et mot de passe FreshRSS. Dans NetNewsWire, sélectionnez « FreshRSS » dans les comptes et procédez de même. Les flux et les états de lecture (lu/non lu, étoile) se synchronisent automatiquement. Recommandation : activez HTTPS via un reverse proxy nginx pour que vos identifiants ne transitent pas en clair sur internet.

FreshRSS consomme moins de 128 Mo de RAM au repos. Un VPS 512 Mo est largement suffisant pour un usage personnel ou pour une petite équipe de 5 à 10 utilisateurs avec 200 à 500 flux chacun. Pour plus de 10 utilisateurs simultanés ou des milliers de flux, un VPS 1 Go est recommandé. FreshRSS peut cohabiter sans problème avec d'autres applications sur le même VPS — il n'occupe qu'un seul conteneur Docker et sa base SQLite ne dépasse pas quelques mégaoctets même après des mois d'utilisation intensive.

Oui. FreshRSS supporte l'import et l'export OPML, le format standard d'échange des listes d'abonnements RSS. Dans Feedly ou votre lecteur actuel, exportez vos abonnements en OPML (fichier `.xml` ou `.opml`). Dans FreshRSS, allez dans Paramètres → Abonnements → Importer/Exporter, sélectionnez votre fichier OPML et validez. Tous vos flux apparaissent immédiatement avec leurs dossiers et catégories d'origine. Le processus prend moins d'une minute, quelle que soit la taille de votre liste.

FreshRSS sert du HTTP sur le port 80 (exposé sur 8080 côté hôte). Pour HTTPS, configurez nginx en reverse proxy devant ce port avec un certificat Let's Encrypt — ou activez `requireDomain: true` dans le marketplace ServOrbit pour que le VPS soit configuré automatiquement avec un vhost nginx + HTTPS. Une fois en HTTPS, les applications mobiles comme Reeder ou FeedMe peuvent se connecter à `https://rss.votre-domaine.com` de façon sécurisée depuis n'importe quel réseau.

Oui, depuis 2026 les modèles quantifiés 3B à 7B (format Q4_K_M) tournent correctement sur CPU moderne avec support AVX-512, à une vitesse de 8 à 12 tokens par seconde — suffisant pour un usage API à faible trafic (moins de 5 requêtes par minute). Nous recommandons un VPS avec 8 à 16 Go de RAM et des modèles comme Phi-3-mini, Llama 3.2 3B ou Qwen2.5-7B, déployés via Ollama. Retrouvez Ollama directement dans notre <a href="/marketplace">Marketplace applicative</a> pour une installation en un clic.

MCP (Model Context Protocol) est un protocole open source standardisé par Anthropic et adopté par OpenAI, Google et Microsoft, qui permet aux agents IA d'interagir de façon uniforme avec des outils externes — bases de données, fichiers, APIs — sans envoyer vos données vers des services cloud tiers. Un serveur MCP se déploie sur un VPS standard (1 Go de RAM minimum, avec Docker ou Node.js) et expose une API HTTP à laquelle se connectent des clients comme Claude Desktop, Open WebUI ou n8n. Retrouvez nos offres VPS adaptées sur la <a href="/vps-cloud">page VPS ServOrbit</a> ou contactez-nous via [email protected] pour un accompagnement.

Non. Depuis votre espace client (VPS → Avancé → Réinstaller l'OS), vous choisissez une distribution récente parmi celles proposées et le serveur est reconstruit en conservant son adresse IP publique ; de nouveaux identifiants vous sont envoyés par e-mail. L'opération efface intégralement le disque : sauvegardez vos données, vos volumes et vos fichiers de configuration avant de la lancer, puis redéployez vos applications sur le système neuf. Elle est protégée par une confirmation forte (saisie exacte du nom du serveur) ; en cas de doute sur l'ordre des opérations, ouvrez un ticket avant de commencer.

Parce que la console est un accès écran direct au serveur : elle ne passe ni par le réseau, ni par SSH, ni par le pare-feu — l'ouvrir revient à s'asseoir devant la machine. Nous la protégeons donc comme les autres opérations sensibles (réinitialisation du mot de passe administrateur, réinstallation, mode secours, restauration) : votre mot de passe de compte plus un code à 6 chiffres envoyé par e-mail. Une fois confirmée, la console reste ouverte 15 minutes : vous pouvez vous reconnecter autant de fois qu'il le faut pendant un dépannage sans redemander de code. Passé ce délai, une nouvelle confirmation est demandée.

Tout dépend de votre profil. Caddy est le choix idéal pour commencer : configuration en quelques lignes, certificats Let's Encrypt automatiques et zéro dépendance externe. Traefik convient aux environnements Docker multi-conteneurs : il détecte les services via les labels Docker et gère les certificats de façon native, mais exige un fichier de configuration plus complet. Nginx Proxy Manager offre une interface graphique web qui plaît aux utilisateurs non techniques. Si vous gérez moins de cinq services et que vous voulez aller vite, choisissez Caddy. Si vous opérez un cluster de dizaines de conteneurs avec des règles de routage complexes, préférez Traefik.

Oui. Ces plateformes PaaS open source fonctionnent sur tout VPS Linux avec accès root, et tous les plans ServOrbit incluent cet accès. Le plan VPS Power (4 vCPU, 8 GB de RAM) ou supérieur est recommandé, car ces outils consomment de la mémoire avant même vos applications. La Marketplace ServOrbit propose également des templates prêts à déployer pour plusieurs de ces solutions.

Activez le module de sécurité X-Pack (inclus depuis Elasticsearch 8) et créez un utilisateur dédié avec mot de passe : par défaut, sans authentification, n'importe qui sur le réseau peut lire vos index. Pour éviter les erreurs Out-Of-Memory, configurez la JVM heap à la moitié de la RAM disponible (par exemple `-Xms1g -Xmx1g` sur un VPS 2 Go) et activez `bootstrap.memory_lock: true` pour empêcher le swap. Un VPS à partir de 299 DH/mois offre 8 GB de RAM, ce qui couvre une instance de développement légère ; pour la production, prévoyez 4 Go minimum.

Avant toute mise à jour majeure de Docker, prenez un snapshot de votre VPS (disponible sur les plans VPS Power et VPS Business) pour disposer d'un point de restauration immédiat. Consultez les release notes de la version cible pour identifier les options supprimées ou les changements de comportement réseau, puis testez la mise à jour sur un VPS de qualification avec la même stack avant de l'appliquer en production. Notre article sur la migration vers Docker v29 liste les vérifications spécifiques à cette version.

Depuis votre VPS, les commandes `top`, `htop` ou `vmstat` vous donnent un aperçu instantané de la RAM et du CPU. Pour une supervision continue avec historique et alertes, vous pouvez déployer une stack légère comme Netdata (installation en une ligne) ou une stack Prometheus + Grafana, disponibles en templates depuis la Marketplace ServOrbit. Ces solutions vous permettent d'être alerté automatiquement en cas de pic de charge avant toute saturation.

Oui, un VPS peut héberger plusieurs services simultanément, à condition que les ressources allouées couvrent l'ensemble des besoins. Mattermost seul consomme en moyenne 500 Mo de RAM en charge légère. Si vous ajoutez d'autres services (proxy inverse, base de données, outil de monitoring), prévoyez au moins 2 Go de RAM disponibles, idéalement 4 Go pour rester à l'aise. L'isolation par conteneurs Docker facilite la cohabitation des applications et simplifie leur gestion. Un reverse proxy comme Nginx ou Caddy permet de faire pointer plusieurs domaines ou sous-domaines vers les bons ports. La montée en charge reste possible à tout moment via l'espace client ServOrbit.

Le dimensionnement dépend du nombre et de la nature des outils déployés. À titre indicatif : Mattermost nécessite environ 500 Mo à 1 Go, Forgejo tourne confortablement avec 512 Mo, Nextcloud requiert 1 Go minimum, et chaque base de données PostgreSQL ou MariaDB ajoute 256 à 512 Mo selon la charge. Pour deux à trois outils en parallèle, un VPS avec 4 Go de RAM constitue un bon point de départ. Si votre équipe grandit ou si vous ajoutez des intégrations tierces, 8 Go offrent une marge de manœuvre appréciable. Comptez également de l'espace disque SSD pour les volumes persistants, les logs et les sauvegardes. Les offres VPS ServOrbit commencent à 99 DH/mois et sont évolutives à la demande.

Firefly III est une application PHP/Laravel légère qui tourne confortablement sur des VPS modestes. **Configuration minimale** : 1 Go de RAM, 1 vCPU, 10 Go de stockage SSD. Cette configuration est suffisante pour un usage personnel ou une petite équipe (moins de 5 utilisateurs). **Configuration recommandée pour un usage professionnel** : 2 Go de RAM, 2 vCPU, 20 Go SSD. Cette configuration vous donne de la marge pour le Data Importer (application secondaire pour l'import de relevés bancaires) et les pics de charge lors des imports de fichiers CSV volumineux. **Système d'exploitation recommandé** : Ubuntu 22.04 LTS ou Debian 12. **Logiciel requis** : Docker Engine ≥ 24 et Docker Compose V2 — Firefly III s'installe exclusivement via Docker dans la documentation officielle. Nos VPS démarrent à partir de 99 DH/mois. Les instantanés sont disponibles à partir de l'offre VPS Power, et la sauvegarde quotidienne sur VPS Business — à prévoir pour sécuriser vos données financières.

Pour héberger ‎Ollama avec un modèle de code (‎Continue.dev, ‎Tabby), la configuration minimale dépend du modèle cible. Pour un modèle 7‎B en quantification 4-bit (ex. ‎Qwen2.5-‎Coder-7B-‎Q4, ~4 ‎Go ‎VRAM/‎RAM) : un ‎VPS avec 8 ‎Go de ‎RAM et 4 ‎vCPU est suffisant, en inférence ‎CPU uniquement. Pour un modèle 13‎B : prévoir 16 ‎Go de ‎RAM. L'inférence ‎CPU est fonctionnelle mais plus lente que ‎GPU — comptez 5 à 15 tokens/seconde selon le modèle et le processeur. Le disque est critique : un modèle 7‎B occupe 4 à 5 ‎Go. ‎Ollama est disponible en template ‎VPS sur la Marketplace ‎ServOrbit avec l'‎API compatible ‎OpenAI activée par défaut.

Oui, Actual Budget et Firefly III sont tous deux disponibles comme templates VPS dans la Marketplace ServOrbit : vous pouvez déployer l'un ou l'autre en quelques minutes sur un VPS avec accès root. La migration de vos données Firefly III vers Actual Budget se fait manuellement via les exports CSV de Firefly et l'import natif d'Actual ; prévoyez une sauvegarde complète avant de basculer. Consultez la page /marketplace pour déployer la solution adaptée à votre usage.

Authentik peut jouer le rôle de fournisseur d'identité centralisé via le mécanisme de forward authentication : votre reverse proxy (Nginx, Traefik, Caddy) interroge Authentik avant de transmettre chaque requête à l'application cible, bloquant tout accès non authentifié. Chaque application est déclarée comme un Provider dans Authentik avec son domaine propre ; une seule authentification donne ensuite accès à l'ensemble des services protégés (SSO). Authentik est disponible comme template VPS dans la Marketplace ServOrbit.

Le conteneur `immich-machine-learning` partage le réseau interne Docker avec les autres services Immich ; vérifiez d'abord qu'il est bien sur le même réseau (`docker network inspect immich_default`) et que le service est démarré (`docker compose ps`). Si le conteneur redémarre en boucle, consultez ses logs avec `docker compose logs immich-machine-learning` : un arrêt OOM (Out Of Memory) se lit comme `Killed` — dans ce cas, votre VPS manque de RAM et il faut soit réduire le nombre de modèles chargés, soit passer à un plan supérieur. Sur un VPS ServOrbit, vous pouvez ajuster vos ressources à tout moment depuis l'espace client.

Techniquement oui, mais les besoins sont très différents : Plane nécessite un minimum de 2 vCPU et 4 Go de RAM (Django, Celery, PostgreSQL 16, Redis, RabbitMQ et MinIO), tandis que Vikunja est bien plus léger (moins de 256 Mo au repos). Héberger les deux sur un seul VPS est envisageable à partir de 6 à 8 Go de RAM, en veillant à séparer leurs bases de données et leurs réseaux Docker. Si votre équipe grandit, il est plus simple de migrer chaque outil vers son propre VPS ; cette opération reste non destructive car toutes les données vivent dans des volumes Docker.

Le problème le plus fréquent est que le conteneur de base de données est « running » (processus démarré) mais pas encore « healthy » (prêt à accepter des connexions) : le serveur PostgreSQL ou MySQL met quelques secondes à initialiser. La solution est d'utiliser `depends_on` avec une condition `service_healthy` dans votre `compose.yaml`, couplée à un `healthcheck` sur le conteneur de base de données (`pg_isready -U user` pour PostgreSQL). Sans healthcheck, Docker considère le service prêt dès que le processus est lancé, et votre application tente de se connecter avant que la base ne soit accessible.

Oui. Le template installe PHP 8.3-FPM, Nginx, PostgreSQL 16, Redis, Supervisor et Composer sur Ubuntu 24.04. Il configure l'environnement serveur, pas votre application : clonez votre dépôt, créez votre `.env.local`, exécutez `composer install --no-dev --optimize-autoloader`, appliquez vos migrations et Nginx est prêt à proxifier vers PHP-FPM. Tout projet Symfony 5, 6 ou 7 fonctionne sur cette base.

Le template installe `php8.3-opcache` et active OPcache par défaut dans `php.ini`. Pour activer le preloading de Symfony, ajoutez dans `/etc/php/8.3/fpm/php.ini` : `opcache.preload=/var/www/votre-app/var/cache/prod/App_KernelProdContainer.preload.php` et `opcache.preload_user=www-data`, puis rechargez PHP-FPM avec `systemctl reload php8.3-fpm`. Le conteneur de services de Symfony est alors chargé en mémoire au démarrage de PHP-FPM, ce qui réduit sensiblement la latence en production.

Non. Le template cible l'environnement de production : PHP 8.3-FPM, Nginx, PostgreSQL 16, Redis et Supervisor. Symfony CLI est un outil de développement local — il n'est pas installé sur le serveur de production. Pour les déploiements continus, utilisez un pipeline Git (GitHub Actions, GitLab CI) qui exécute `composer install`, `cache:clear` et les migrations sur le serveur via SSH.

Supervisor est préconfiguré sur le template. Créez `/etc/supervisor/conf.d/symfony-messenger.conf` avec la directive `command=php /var/www/votre-app/bin/console messenger:consume async --time-limit=3600` et `autorestart=true`. Rechargez Supervisor avec `supervisorctl reread && supervisorctl update`. Après chaque déploiement, exécutez `php bin/console messenger:stop-workers` pour forcer les workers à s'arrêter proprement : Supervisor les relancera immédiatement avec le nouveau code.

Les deux templates installent la même chaîne PHP (PHP 8.3-FPM, Nginx, PostgreSQL, Redis, Supervisor, Composer) sur Ubuntu 24.04. La différence est dans les extensions PHP : Symfony Stack ajoute `php8.3-intl` (requis pour le composant Translation et les locales) et `php8.3-opcache` explicitement (pour le preloading). Laravel Stack inclut `php8.3-zip` et fonctionne sans `intl` sur la plupart des applications. Choisissez le template correspondant à votre framework : les deux coexistent sans conflit sur le même VPS.

Oui. Le template installe Node.js LTS, PM2 et Nginx. Pour un site statique (`output: 'static'`), buildez votre projet Astro en local, transférez le dossier `dist/` sur le VPS et configurez Nginx pour le servir. Aucun processus Node n'est nécessaire en production — Nginx sert directement les fichiers statiques avec une empreinte mémoire minimale.

Astro Stack installe Node.js LTS, PM2 et Nginx sans PostgreSQL — adapté aux projets Astro en mode statique (SSG) ou SSR. Next.js Stack ajoute PostgreSQL pour les applications full-stack nécessitant une base de données. Astro est souvent plus léger : son mode statique ne nécessite aucun processus Node en production, contrairement à Next.js qui est toujours SSR.

Oui. Installez l'adaptateur `@astrojs/node`, configurez `output: 'server'` et `adapter: node({ mode: 'standalone' })` dans `astro.config.mjs`. Après le build, lancez le serveur avec `pm2 start dist/server/entry.mjs --name astro` et proxifiez Nginx vers `http://localhost:4321`. PM2 gère le redémarrage automatique et les mises à jour sans coupure.

Oui. Nginx prend en charge plusieurs vhosts sur le même serveur. Chaque site statique Astro pointe vers son propre dossier `dist/` ; chaque site SSR utilise un port PM2 différent (ex. 4321, 4322). Une seule installation de Node.js et Nginx est suffisante pour l'ensemble. Prévoyez suffisamment de RAM si vous cumulez plusieurs processus Node en mode SSR.

1 Go de RAM suffit pour un site Astro entièrement statique : Nginx consomme très peu de ressources en servant des fichiers. Pour le mode SSR avec un processus Node et PM2, prévoyez au moins 2 Go. Si vous cumulez plusieurs sites SSR sur le même VPS, ajoutez environ 100 à 200 Mo par processus Node supplémentaire.

La solution de référence est Patroni, un orchestrateur qui gère la promotion automatique d'un secondaire en primaire en cas de défaillance, avec etcd ou Consul comme stockage distribué du consensus. Il faut au minimum trois nœuds : un primaire, un réplica et un nœud de quorum (ou utiliser un cluster etcd séparé). Patroni est accompagné de HAProxy ou pgBouncer côté applicatif pour rediriger les connexions vers le nouveau primaire sans modifier le code. Un VPS avec au moins 2 Go de RAM par nœud est recommandé pour un cluster PostgreSQL en production.

Les deux templates installent Node.js LTS, PM2 et Nginx. SvelteKit Stack est conçu pour des applications web réactives avec actions de formulaire, `load` côté serveur et fonctionnalités temps réel (WebSockets, SSE). Astro Stack cible les sites de contenu et le rendu hybride : Astro n'envoie aucun JavaScript par défaut et fait tourner un processus Node plus léger pour les pages SSR. Si vous créez une app avec formulaires, sessions et logic serveur, préférez SvelteKit ; si vous créez un blog ou un site vitrine, préférez Astro.

Oui. Configurez `@sveltejs/adapter-static` dans `svelte.config.js`, buildez votre projet avec `npm run build`, et transférez le dossier `build/` sur le VPS. Nginx servira les fichiers statiques directement — aucun processus Node ne tourne en production, ce qui réduit la consommation mémoire au minimum.

SvelteKit utilise `ORIGIN` pour valider les requêtes d'actions de formulaire et se protéger contre les attaques CSRF. Si cette variable ne correspond pas à l'URL réelle de votre site, SvelteKit rejette les soumissions de formulaire avec une erreur 403. Définissez-la via PM2 ou le fichier ecosystem config : `ORIGIN=https://votredomaine.com pm2 start build/index.js`.

Oui. Lancez chaque application comme un processus PM2 distinct en lui assignant un port interne différent (3000, 3001, 3002…). Configurez ensuite Nginx avec des blocs `server {}` séparés ou des règles `location` pour router les requêtes selon le nom de domaine vers le bon port. Chaque app garde ses propres logs et variables d'environnement dans PM2.

PM2 surveille votre processus Node et le relance automatiquement en cas de crash ou de dépassement du seuil de mémoire configuré. Pour les mises à jour sans coupure, utilisez `pm2 reload svelte-app` — PM2 lance une nouvelle instance, attend qu'elle soit prête, puis coupe l'ancienne. Pour rendre PM2 persistant au redémarrage du serveur, exécutez `pm2 startup` pour générer le script systemd, puis `pm2 save` pour sauvegarder la liste des processus.

Jellyfin en Direct Play (lecture du fichier tel quel) fonctionne avec 1 vCPU et 1 Go de RAM. Mais si vos clients ne supportent pas le format source et que le transcodage logiciel est nécessaire, le CPU devient le facteur limitant : chaque flux transcodé en H.264 1080p consomme entre 1 et 2 vCPU selon le codec source. Pour 2 à 4 utilisateurs simultanés avec transcodage, le plan VPS Power (4 vCPU, 8 GB de RAM) est le minimum recommandé ; au-delà, privilégiez un VPS avec plus de vCPU ou explorez les offres serveurs dédiés sur la page /serveurs-dedies.

Oui — OpenTofu (fork open-source de Terraform, CNCF) permet de versionner la configuration de votre flotte en HCL et de l'appliquer via tofu plan/apply. Notre guide opentofu-terraform-vps-automatiser-infrastructure couvre le provider Docker pour piloter les conteneurs directement sur VPS.

AnythingLLM seul (LLM externe via API) : 2 vCPU / 2 Go RAM suffisent. Avec embedding local (nomic-embed-text via Ollama) : 2 vCPU / 4 Go RAM minimum. Avec LLM local (Mistral 7B en Q4 via Ollama) : 4 vCPU / 8 Go RAM recommandé — la quantisation Q4 divise par environ 2 l'empreinte mémoire.

Un serveur e-mail de base pour un ou deux domaines avec quelques dizaines d'utilisateurs tourne sur 1 vCPU et 1 Go de RAM, mais 2 Go sont recommandés dès que vous activez le filtrage anti-spam (rspamd, SpamAssassin) ou le full-text search. Stalwart est un binaire Go particulièrement économe : il démarre sous 50 Mo de RAM au repos. Prévoyez un SSD d'au moins 20 Go pour commencer et ajoutez selon la rétention des boîtes. Le plan VPS Power (8 GB, 299 DH/mois) convient à la plupart des configurations en production. Pensez également à configurer un reverse DNS (PTR) et des enregistrements SPF/DKIM/DMARC pour assurer la délivrabilité.

Oui, en isolant chaque service dans son propre conteneur Docker et en leur attribuant des ports ou sous-domaines distincts. Prévoyez au minimum 4 Go de RAM pour les deux instances actives en même temps, et vérifiez que votre VPS supporte cette charge via les métriques de l'espace client. Une fois votre choix fait, arrêtez et supprimez l'instance non retenue pour libérer les ressources. Consultez nos templates Marketplace pour déployer chaque solution en quelques clics.

Le dimensionnement dépend du type d'application et du trafic attendu : **Application légère (< 100 req/min)** : 1 vCPU / 1 Go RAM. Suffisant pour une API REST en Node.js ou Flask avec une petite base de données. **Application moyenne (100–1 000 req/min)** : 2 vCPU / 2–4 Go RAM. Recommandé pour un backend Express ou FastAPI avec PostgreSQL, incluant Redis pour le cache. **Application lourde (> 1 000 req/min ou ML)** : 4+ vCPU / 8+ Go RAM. Les workers de traitement (Celery, BullMQ), les modèles ML ou les opérations de génération de rapports sont très gourmands. **Règle empirique** : commencez avec 2 vCPU / 4 Go RAM et monitorez. Il est toujours possible de redimensionner à la hausse. Préférez plus de RAM plutôt que plus de CPU pour la plupart des applications web — le swapping tue les performances plus sûrement qu'un CPU limité.

Les premières minutes après la création d'un VPS sont critiques. Voici les étapes prioritaires : **1. Mettre à jour le système** — `apt update && apt upgrade -y` **2. Créer un utilisateur non-root avec sudo** — `adduser monuser && usermod -aG sudo monuser` **3. Configurer l'authentification par clé SSH** — depuis votre machine locale, `ssh-copy-id monuser@ip-du-serveur`, puis dans `/etc/ssh/sshd_config` : `PasswordAuthentication no` et `PermitRootLogin no`. **4. Configurer le pare-feu** — `ufw default deny incoming`, puis `ufw allow ssh`, `ufw allow 80`, `ufw allow 443` et enfin `ufw enable`. **5. Activer fail2ban** — `apt install fail2ban` Ces cinq étapes couvrent l'essentiel. Des guides détaillés sont disponibles dans la base de connaissances ServOrbit.

Kamal (anciennement MRSK) orchestre vos déploiements via SSH et Docker directement depuis votre machine locale vers votre VPS ServOrbit : il suffit de configurer `config/deploy.yml` avec l'IP de votre serveur, vos identifiants de registre Docker et votre image. ServOrbit fournit des VPS avec Docker pré-installable (Debian/Ubuntu) et un accès SSH root ; assurez-vous d'ouvrir le port 80/443 dans votre pare-feu et de configurer votre DNS avant le premier déploiement. Kamal gère nativement le rolling update et le rollback, ce qui rend les mises à jour sans interruption de service possibles dès la première configuration.

Oui. GlitchTip est disponible dans le marketplace ServOrbit en mode compose : PostgreSQL + Redis + le conteneur GlitchTip tout-en-un démarrent en une seule commande. L'option `GLITCHTIP_EMBED_WORKER=true` fusionne le worker Celery dans le conteneur web, ce qui évite un quatrième service. Il faut un nom de domaine (le FQDN est utilisé pour les liens dans les e-mails et les tokens OAuth) : vous pouvez utiliser le sous-domaine gratuit inclus avec votre VPS ou rattacher votre propre domaine. Le premier compte est créé depuis l'interface à `https://<domaine>/register`.

Oui, GlitchTip implémente entièrement l'API d'ingestion d'événements de Sentry et est compatible avec tous les SDK officiels : Python (sentry-sdk), JavaScript (@sentry/browser, @sentry/node), PHP, Ruby, Go, Java, .NET, iOS et Android. Pour migrer, il suffit de remplacer l'URL du DSN dans vos variables d'environnement par celle de votre instance GlitchTip ; aucune modification du code source n'est nécessaire. Vos groupes d'erreurs, alertes et intégrations continuent de fonctionner comme avec Sentry Cloud.

GlitchTip exige au minimum 512 Mo de RAM pour le conteneur web Python, PostgreSQL et Redis. Un VPS avec 1 Go de RAM convient pour un projet unique avec un trafic modéré. Pour plusieurs projets ou un volume élevé d'événements d'erreur, 2 Go de RAM sont recommandés. Le disque dépend du volume d'événements stockés : commencez avec 10 Go et surveillez la taille de PostgreSQL. Les migrations de base de données s'exécutent automatiquement au démarrage du conteneur web, sans intervention manuelle.

GlitchTip inclut un module de monitoring de disponibilité intégré. Dans l'interface, allez dans **Monitor → Create Monitor**, entrez l'URL à surveiller, le type de vérification (HTTP/HTTPS ou ping), l'intervalle (minimum 1 minute) et le nombre d'échecs consécutifs avant alerte. Vous pouvez configurer des notifications par e-mail, Slack ou webhook. GlitchTip enregistre l'historique des incidents et affiche le temps de disponibilité sur un tableau de bord dédié. Le monitoring de disponibilité fonctionne depuis le serveur GlitchTip lui-même — il doit avoir accès réseau aux URLs surveillées.

**Sauvegarde** : la seule donnée persistante est le volume PostgreSQL (`glitchtip-db`). Planifiez un `pg_dump` quotidien avec `docker compose exec db pg_dump -U $DB_USER glitchtip > backup.sql` et copiez le fichier hors du serveur (rsync, Backblaze B2, etc.). **Mise à jour** : `docker compose pull && docker compose up -d`. GlitchTip applique les migrations Django automatiquement au démarrage. Aucun downtime prolongé n'est nécessaire — le conteneur redémarre en moins de 60 secondes en règle générale. Consultez les notes de version sur gitlab.com/glitchtip avant toute mise à jour majeure.

Plane CE lance plusieurs services Docker (app, worker, beat, migrator, PostgreSQL, Redis, MinIO, RabbitMQ) — prévoir au minimum 4 vCPU et 8 Go de RAM pour une utilisation fluide. Le stockage MinIO pour les pièces jointes nécessite un volume séparé dimensionné selon vos besoins. Pour moins de 15 utilisateurs, un VPS 4 vCPU / 8 Go avec 40 Go SSD constitue une base solide.

Non. Audiobookshelf fonctionne sans domaine via un tunnel SSH : `ssh -L 13378:127.0.0.1:<port> root@<ip-vps>` puis `http://localhost:13378`. Pour un accès permanent depuis l'app iOS ou Android sans tunnel, rattachez un domaine depuis votre espace client ServOrbit — nginx proxifie vers le conteneur en HTTPS — ou utilisez le sous-domaine gratuit `{app}.{dns_slug}.servorbit-dns.com` inclus avec chaque VPS.

Oui. Les deux applications (iOS et Android) sont gratuites, entièrement open source sous licence GPL-3.0 et maintenues par la communauté Audiobookshelf. Elles permettent l'écoute hors ligne, la synchronisation de la progression au chapitre près, et la gestion des marque-pages et playlists — sans aucun compte cloud tiers requis.

Audiobookshelf supporte : MP3, M4A, M4B (avec marques de chapitres), AAC, OGG, FLAC, WAV, OPUS, AIFF et WMA. Les chapitres M4B sont affichés dans le lecteur avec leur titre et durée. Pour les fichiers Audible AAX protégés par DRM, vous devez d'abord les convertir en format DRM-free avec un outil tiers avant de les importer.

Oui. Audiobookshelf gère plusieurs comptes utilisateurs sur la même instance. Chaque compte dispose de sa propre progression d'écoute, de ses marque-pages, de ses playlists et de ses notes. Les permissions peuvent être définies par bibliothèque (Livres, Podcasts), ce qui permet de contrôler précisément qui accède à quoi.

Audiobookshelf sépare les données en quatre volumes Docker : `/audiobooks` et `/podcasts` contiennent vos fichiers audio (jamais modifiés par le serveur), `/config` la base de données SQLite avec la progression et les marque-pages, et `/metadata` les couvertures et données d'indexation. Sauvegardez `/config` et `/metadata` via SFTP ou `rsync`. La fonction Backup intégrée (Settings → Backups) exporte également un fichier ZIP avec toutes les métadonnées — pratique pour migrer vers une autre instance ou VPS.

Les trois sont disponibles en template au Marketplace ServOrbit.com, mais leurs usages divergent. Open WebUI est idéal si vous voulez faire tourner des modèles locaux (Llama, Mistral) via Ollama, sans envoyer de requêtes à l'extérieur. LibreChat convient à une équipe qui veut un environnement de chat multi-modèles (OpenAI, Anthropic, API locale) avec gestion des utilisateurs et SSO. Dify cible la création d'agents et de workflows IA plutôt qu'un chat généraliste. Consultez la page Marketplace pour les prérequis RAM de chaque template.

Wallos est un gestionnaire d'abonnements open source (GPL-3.0) self-hosted. Il vous permet de centraliser tous vos abonnements récurrents — logiciels, services cloud, licences, abonnements streaming — et de visualiser leur coût réel dans une devise de référence unique. Wallos s'installe en un seul conteneur Docker sur votre VPS, sans base de données externe.

Non. Wallos fonctionne sans nom de domaine via un tunnel SSH : `ssh -L 8080:127.0.0.1:<port> root@<ip-vps>` puis `http://localhost:8080`. Pour un accès depuis n'importe quel navigateur ou appareil, rattachez un domaine depuis votre espace client ServOrbit — nginx proxifie le conteneur en HTTPS — ou utilisez le sous-domaine gratuit `{app}.{dns_slug}.servorbit-dns.com` inclus avec chaque VPS.

Wallos affiche un écran de configuration au premier lancement. Saisissez un nom d'utilisateur, une adresse e-mail et un mot de passe pour créer votre compte administrateur — aucun identifiant n'est pré-généré. Après cette première connexion, vous pouvez inviter d'autres utilisateurs depuis Paramètres → Utilisateurs et brancher un fournisseur OIDC si vous le souhaitez.

Wallos prend en charge plus de 170 devises, dont le dirham marocain (MAD), l'euro (EUR), le dollar américain (USD) et le riyal saoudien (SAR). Dans Paramètres → Devise, choisissez votre devise de référence ; Wallos récupère automatiquement les taux de change et convertit chaque abonnement pour que vos totaux soient toujours affichés dans une seule unité monétaire.

Toutes les données Wallos résident dans deux volumes Docker : `wallos_db` (base de données SQLite avec la liste de vos abonnements) et `wallos_logos` (logos importés). Sauvegardez ces volumes par SFTP ou `rsync`. Wallos propose également un export CSV depuis l'interface (Paramètres → Import/Export) — utile pour une sauvegarde lisible ou une migration vers une autre instance ou un autre hébergeur.

Comptez quelques minutes : la machine est clonée, démarrée puis configurée automatiquement. Dès votre paiement, le serveur apparaît dans votre espace client avec la mention « mise en service en cours » — vous n'avez rien à faire, et surtout rien à recommander. Vous recevez un e-mail avec vos accès dès qu'il est prêt. Si l'attente dépasse une heure, contactez le support avec votre numéro de commande.

Prometheus collecte les métriques de vos applications et de l'OS via des exporters (Node Exporter, cAdvisor), Loki centralise les logs Docker, et Grafana visualise le tout dans des tableaux de bord. Sur un VPS ServOrbit 8 GB est le minimum recommandé pour faire tourner les trois outils en parallèle avec un volume de données raisonnable. Déployez la stack via Docker Compose avec des volumes persistants pour les données Prometheus et Loki, et protégez Grafana avec un reverse proxy HTTPS. La Marketplace ServOrbit propose des templates préconfigurés pour vous faire gagner du temps.

L'approche recommandée est de combiner Restic (sauvegarde chiffrée et dédupliquée) avec un timer systemd plutôt qu'une cron, car systemd journalise les exécutions et peut notifier en cas d'échec. Créez un fichier `.service` qui exporte les variables d'environnement Restic (endpoint S3, clés d'accès, mot de passe du dépôt) et lance `restic backup /var/www /var/lib/mysql-files`, puis un `.timer` qui le déclenche quotidiennement. Activez le rattrapage avec `OnCalendar=daily` et `Persistent=true` (pour rejouer une exécution manquée). Notre support peut vous orienter vers un guide d'initialisation du dépôt adapté à votre plan VPS.

Une instance n8n seule tourne confortablement avec 1 Go de RAM, mais en production avec une base de données PostgreSQL et quelques workflows actifs, il est recommandé de partir sur 2 Go minimum. Si vous combinez n8n avec d'autres services Docker (Redis, un reverse proxy, une app métier), prévoyez 4 Go pour éviter les ralentissements lors des pics d'exécution. Les VPS ServOrbit à partir de 99 DH/mois incluent un SSD NVMe et sont dimensionnés pour ce type de charge ; la migration vers un plan supérieur reste possible à tout moment depuis l'espace client.

Créez un réseau Docker partagé (`docker network create proxy`) et rattachez vos conteneurs à ce réseau. Dans Nginx, déclarez un bloc `server` par application avec la directive `proxy_pass` pointant vers le nom du conteneur et son port interne (ex. `http://app1:3000`). Utilisez des noms de domaine distincts ou des sous-domaines pour différencier les applications, et activez HTTPS avec Certbot (`certbot --nginx -d monapp.exemple.com`). Une alternative simple est Nginx Proxy Manager, disponible dans la marketplace ServOrbit, qui propose une interface graphique pour gérer vos reverse proxies sans éditer de fichiers de configuration manuellement.

Oui, les trois composants cohabitent bien sur un même serveur via Docker Compose. Prévoyez au minimum 8 Go de RAM pour des modèles légers (7B) et un stockage suffisant pour les poids du modèle (entre 4 et 10 Go selon le modèle). Le plan VPS Power est un bon point de départ pour cette combinaison. Consultez notre guide sur la construction d'une stack IA open source sur VPS pour les détails de configuration.

Pour un réseau WordPress Multisite de moins de dix sites à trafic modéré, nous recommandons au minimum 2 vCPU et 4 Go de RAM. Au-delà de vingt sites actifs ou avec un plugin de cache PHP opcode (OPcache), 4 vCPU et 8 Go de RAM offrent plus de confort. Le mode Multisite concentre plusieurs WordPress sur une seule installation MySQL : un pic de trafic simultané sur plusieurs sous-sites sollicite PHP-FPM plus intensément qu'une instance seule. Voir notre guide WordPress Multisite sur VPS pour la configuration complète avec wildcard DNS et nginx.

Dans votre zone DNS Cloudflare (ou dans le gestionnaire DNS de ServOrbit), ajoutez un enregistrement A wildcard *.votredomaine.com pointant vers l'adresse IPv4 de votre VPS. Sur nginx, configurez un bloc server_name *.votredomaine.com et activez l'option ALLOW_MULTISITE dans wp-config.php. Chaque nouveau sous-site créé dans WordPress est automatiquement résolu sans toucher au DNS. Si vous utilisez Cloudflare, activez le proxy sur l'enregistrement wildcard pour bénéficier du cache et de la protection. Voir notre guide WordPress Multisite sur VPS pour la configuration nginx complète.

Les deux options sont disponibles sur un VPS ServOrbit (Ubuntu/Debian avec accès root). Un cron job est plus rapide à mettre en place pour une tâche simple : une ligne dans crontab suffit. Un timer systemd offre davantage de contrôle : journalisation native (journalctl), gestion des dépendances, redémarrage automatique en cas d'échec et déclencheurs plus précis (à l'heure, au démarrage, après un délai). Pour des scripts de sauvegarde ou des jobs de synchronisation en production, nous recommandons systemd timers : chaque exécution est tracée et les erreurs sont remontées sans configuration supplémentaire. La configuration se fait directement en SSH sur votre VPS.