Marketplace

Choisissez un VPS Cloud puis sélectionnez le template souhaité : l'environnement est installé automatiquement et accessible depuis votre domaine.

La Marketplace est un catalogue de templates VPS : des applications open source préconfigurées que vous déployez sur votre VPS en quelques clics.

Non. Ce sont des logiciels open source que nous proposons sous forme de templates prêts à déployer. Vous payez le VPS qui les héberge, pas le logiciel.

Les applications proposées sont open source et gratuites. Votre seul coût est celui du VPS Cloud sur lequel elles tournent.

Le catalogue couvre l'IA, l'automatisation, les bases de données, les CMS, le déploiement et plus encore (143 solutions à ce jour). Il s'enrichit régulièrement.

Oui. Via le formulaire de contact, choisissez « Suggérer une solution » et indiquez l'application open source souhaitée ainsi que votre cas d'usage.

La configuration minimale d'une application s'entend sur un serveur libre. Or vos applications déjà installées consomment déjà une partie de la RAM, du CPU et du disque : nous vérifions donc la place réellement DISPONIBLE sur votre VPS (et non sa capacité totale) avant de lancer une nouvelle installation, pour éviter de saturer la machine. Si l'espace libre est insuffisant, augmentez les ressources depuis votre espace client (options vCPU / RAM / disque) puis relancez l'installation — ou désinstallez une application devenue inutile.

Pour garantir une installation qui fonctionne du premier coup, nous vérifions la compatibilité avec ce qui est déjà installé sur votre serveur. Une application apparaît bloquée dans trois cas : (1) « conflit de port » — elle a besoin du même port réseau qu'une application déjà présente (deux services ne peuvent pas écouter sur le même port d'un serveur) ; (2) « conflit » — c'est un rôle qui ne peut exister qu'en un exemplaire, par exemple deux reverse-proxies comme Caddy et HAProxy qui veulent tous deux gérer les ports 80/443 ; (3) « prérequis » — elle a besoin qu'une autre application soit installée d'abord. Dans chaque cas, le motif est affiché sous l'application. Pour la poser quand même : désinstallez l'application en conflit, installez d'abord le prérequis, ou utilisez un autre VPS.

Gitea est une plateforme Git open source et légère écrite en Go. L'auto-hébergement vous offre des dépôts privés illimités, un CI/CD intégré (Gitea Actions), un registre de paquets et des permissions d'équipe fines — le tout sur un VPS de 2 GB RAM, sans facturation au siège.

Gitea sert son interface web sur le port 3000 (relayé vers 80/443 via Caddy ou Nginx). Git par SSH est exposé sur le port 2222 pour éviter tout conflit avec le SSH de l'hôte VPS sur le port 22.

Oui. Activez Gitea Actions dans votre app.ini (`[actions] ENABLED = true`) et enregistrez un conteneur `act_runner` sur le même VPS. Gitea Actions est compatible avec la syntaxe YAML de GitHub Actions, de sorte que la plupart des workflows existants fonctionnent sans modification.

Utilisez `git clone ssh://git@<your-domain>:2222/<user>/<repo>.git`. Vous pouvez aussi ajouter un bloc Host dans `~/.ssh/config` pour définir Port 2222 de façon transparente, afin que les commandes Git standard fonctionnent sans préciser le port.

Gitea fonctionne confortablement sur un VPS doté de 1 vCPU et 2 GB RAM pour des équipes jusqu'à 20 utilisateurs. Ajoutez de la RAM si vous activez des runners Gitea Actions locaux qui compilent du code. Prévoyez au moins 20 GB de stockage SSD par volume de dépôt.

PocketBase est un backend-as-a-service (BaaS) open source écrit en Go. Il regroupe une base de données SQLite embarquée, une API REST et WebSocket en temps réel, une authentification intégrée (email/password, OAuth2, OTP) et un tableau de bord d'administration web dans un unique binaire — sans serveur de base de données externe ni fichiers de configuration.

PocketBase fonctionne avec 512 MB RAM pour des charges légères. Un VPS de 1–2 GB gère confortablement des milliers d'utilisateurs actifs par jour. N'augmentez les ressources que si vous traitez de très gros fichiers ou exécutez en parallèle des tâches de fond gourmandes en calcul.

PocketBase est bien plus léger (un seul binaire contre plus de 10 services Docker pour Supabase) et présente un coût VPS fixe, sans facturation à la lecture ou à l'écriture. Firebase et Supabase conviennent mieux à une montée en charge cloud infinie ; PocketBase convient mieux aux applications à coût prévisible, en dessous d'environ 1 M de requêtes par jour.

PocketBase prend en charge Google, GitHub, GitLab, Apple, Twitter/X, Facebook, Microsoft, Spotify, Kakao, Twitch et d'autres. Activez-les dans le tableau de bord d'administration, sous Settings → Auth Providers, en collant votre client ID et votre secret OAuth2.

Toutes les données résident dans le volume Docker `/pb/pb_data` — un fichier SQLite et les fichiers téléversés. Sauvegardez ce volume avec `docker run --rm -v pocketbase:/data alpine tar -czf - /data`. PocketBase expose aussi un endpoint de sauvegarde intégré, accessible depuis le tableau de bord d'administration.

Oui. PocketBase prend en charge les hooks JavaScript depuis la v0.17 : exécutez du code avant ou après les événements de création, de mise à jour, de suppression d'enregistrement ou d'authentification. Pour des cas d'usage avancés, intégrez PocketBase comme bibliothèque Go et ajoutez vos propres handlers HTTP ou tâches de fond.

Vaultwarden est une implémentation open source non officielle du serveur Bitwarden, écrite en Rust. Elle est 100 % compatible avec tous les clients Bitwarden officiels (extensions de navigateur, iOS, Android, bureau, CLI) et consomme moins de 50 MB RAM — ce qui la rend idéale pour l'auto-hébergement sur un petit VPS.

Oui. Les clients Bitwarden officiels refusent de se connecter à un serveur dépourvu d'un certificat TLS valide. Il vous faut un nom de domaine et un reverse proxy (Caddy, Nginx ou Traefik) avec un certificat Let's Encrypt. Caddy réduit cela à une seule ligne — il provisionne et renouvelle le certificat automatiquement à partir de votre Caddyfile.

Vaultwarden consomme moins de 50 MB RAM au repos. Un VPS de 512 MB suffit pour un usage personnel ou une petite équipe ; 1 GB est confortable pour une organisation de 20–50 utilisateurs. Il s'exécute facilement aux côtés d'autres services sans impacter les performances.

Oui. Exportez votre coffre depuis Bitwarden.com (Settings → Export Vault → JSON format) et importez-le dans le coffre web de Vaultwarden, sous Tools → Import Data. L'opération prend moins de deux minutes et conserve tous les mots de passe, dossiers, notes et identités.

Définissez la variable d'environnement `SIGNUPS_ALLOWED=false` sur le conteneur et redémarrez-le. Les nouvelles inscriptions seront rejetées. Vous pouvez toujours inviter des utilisateurs spécifiques via le panneau d'administration, que vous activez avec la variable d'environnement `ADMIN_TOKEN`.

Toutes les données résident dans le volume Docker `/data` : un fichier SQLite et les pièces jointes. Exécutez `docker run --rm -v vaultwarden:/data -v /backup:/out busybox tar czf /out/vaultwarden-backup.tar.gz /data` pour créer un instantané. Planifiez cela dans cron pour des sauvegardes quotidiennes automatiques.

Beszel est un hub de supervision de serveurs léger et open source (MIT). Vous déployez un seul hub et installez de petits agents sur chaque serveur à surveiller. Le hub agrège en temps réel les métriques de CPU, RAM, disque, bande passante et conteneurs Docker de tous vos serveurs dans un unique tableau de bord adossé à PocketBase.

Au repos, le hub consomme moins de 50 MB de RAM et tient sans problème sur un VPS de 512 MB aux côtés d'autres services. Les agents sont encore plus légers — quelques MB chacun. Vous pouvez superviser plus de 20 serveurs sans que le hub ne dépasse ~100 MB de RAM.

Non. Les agents Beszel établissent des connexions sortantes vers le hub — les serveurs surveillés n'ont besoin d'aucun port entrant ouvert. Il vous suffit que le port 8090 (ou le port de votre proxy HTTPS) soit accessible sur le serveur du hub lui-même.

Uptime Kuma est conçu pour les contrôles de disponibilité : une URL ou un port TCP est-il actif ou hors service ? Beszel est conçu pour la supervision des ressources : CPU, RAM, disque, bande passante et statistiques Docker par serveur. Ils sont complémentaires — utilisez Uptime Kuma pour les sondes externes en boîte noire et Beszel pour les métriques internes de tout votre parc.

Oui. Montez `/var/run/docker.sock` au lancement du conteneur de l'agent et Beszel découvre et suit automatiquement tous les conteneurs Docker de cet hôte — CPU, RAM et réseau par conteneur, sans exporter supplémentaire.

Beszel prend en charge email, Telegram, Slack, Discord, ntfy, PagerDuty et Pushover via ses paramètres de notification intégrés. Définissez un seuil sur n'importe quelle métrique (p. ex. disque > 80 %) et Beszel déclenche l'alerte lorsque le seuil est franchi, puis de nouveau lorsqu'il repasse en dessous.

Twenty est un CRM open source (AGPL-3.0) conçu comme une alternative auto-hébergée à Salesforce et HubSpot. Il propose des objets et champs personnalisables, des vues kanban et liste, une API GraphQL + REST, des notes et tâches intégrées, et un worker en arrière-plan pour les automatisations et les webhooks. Depuis la v2.1.0, il est prêt pour la production dans les déploiements auto-hébergés mono-locataires.

La pile Twenty complète (server + worker + PostgreSQL + Redis) consomme environ 1,2 GB de RAM au repos. Prévoyez 2 GB minimum et 4 GB recommandés pour laisser à PostgreSQL de la marge sous des requêtes concurrentes. Le server seul utilise à peu près 300–400 MB au repos.

Oui — Twenty est entièrement open source sous AGPL-3.0. L'auto-hébergement sur votre propre VPS est gratuit. Aucun frais par utilisateur, aucune facturation à l'usage et aucune fonctionnalité verrouillée derrière un plan payant dans l'édition auto-hébergée. Vous ne payez que le VPS.

HubSpot et Salesforce sont des produits SaaS cloud facturés par utilisateur, avec vos données stockées sur leur infrastructure. Twenty est auto-hébergé : toutes les données restent sur votre serveur, le coût est un forfait VPS fixe, et vous pouvez étendre le schéma, l'API et les automatisations sans approbation de l'éditeur ni restrictions de marketplace.

Oui — chaque objet de Twenty (contacts, entreprises, affaires, et tout objet personnalisé que vous définissez) est accessible via une API GraphQL entièrement documentée et une API REST. Les webhooks se déclenchent sur tout événement d'enregistrement. L'API est la surface d'intégration principale, pas une réflexion après coup.

Oui. Twenty prend en charge l'import CSV depuis les paramètres de l'espace de travail → Import. Exportez vos contacts et entreprises au format CSV depuis HubSpot, Pipedrive ou tout ancien CRM, puis importez-les dans l'objet Twenty correspondant. Les migrations plus complexes (affaires avec historique d'activité) peuvent nécessiter un court script API.

Qdrant est une base de données vectorielle open source écrite en Rust. Elle stocke des fragments de documents sous forme de vecteurs d'embedding et récupère les plus similaires en quelques millisecondes. Le RAG (Retrieval-Augmented Generation) s'en sert pour injecter du contexte pertinent dans chaque appel au LLM — afin que votre IA réponde à partir de faits au lieu d'halluciner. Une base de données relationnelle ou un index plein texte ne peut égaler la vitesse ni la précision de Qdrant sur cette tâche.

Au repos, Qdrant consomme environ 100–200 MB de RAM. La limite pratique est la taille de votre index : 1 million de vecteurs float32 à 1536 dimensions occupent environ 6 GB sans quantification, ou ~1,5 GB avec une quantification scalaire (int8). Pour la plupart des projets RAG de petite à moyenne taille, un VPS de 4 GB constitue un point de départ confortable.

Tout modèle qui produit des vecteurs float de taille fixe. Choix auto-hébergés populaires via Ollama : mxbai-embed-large (1024 dims), nomic-embed-text (768 dims). Via API : OpenAI text-embedding-3-small (1536 dims), Cohere Embed. LangChain, LlamaIndex, Haystack et les SDK officiels de Qdrant (Python, TypeScript, Go, Rust) disposent tous de connecteurs natifs.

Oui. Les deux se déploient dans un seul conteneur, sans conflit de port (Ollama sur 11434, Qdrant sur 6333/6334). Un VPS de 4 GB de RAM fait tourner les deux sans peine avec un modèle 7B Q4 chargé — vous offrant une pile RAG entièrement autonome et isolée du réseau : embedding avec Ollama, récupération avec Qdrant, génération avec Ollama, sans aucune API externe.

Oui. Qdrant est la principale alternative auto-hébergée à Pinecone. Il égale ou dépasse Pinecone en latence et en rappel sur les benchmarks, prend en charge le même écosystème de modèles d'embedding, et coûte un forfait VPS fixe au lieu d'une facturation par vecteur et par requête. La contrepartie : vous gérez l'infrastructure vous-même.

Redémarrez le conteneur en définissant la variable d'environnement QDRANT__SERVICE__API_KEY sur une chaîne aléatoire robuste. Toutes les requêtes REST et gRPC doivent alors inclure l'en-tête `api-key`. Placez Qdrant derrière Caddy ou Nginx pour le HTTPS. N'exposez jamais le port 6333 à Internet sans authentification.

Infisical est un gestionnaire de secrets open source (MIT, 27,6k étoiles) — une alternative auto-hébergée à Doppler et HashiCorp Vault. Il centralise les clés d'API, mots de passe de bases de données et certificats dans un seul coffre, synchronisés automatiquement vers vos applications et pipelines CI via des SDK et des intégrations natives. L'auto-hébergement garde vos identifiants les plus sensibles sur votre propre infrastructure avec des journaux d'audit complets, pour un coût VPS fixe au lieu d'une facturation SaaS par développeur.

La pile Infisical (app + PostgreSQL 14 + Redis) consomme environ 600–800 MB de RAM au repos et dépasse 1 GB en pointe sous des requêtes API concurrentes provenant de plusieurs applications. Prévoyez un VPS avec au moins 2 GB de RAM (4 GB recommandés pour les équipes dont plusieurs services récupèrent des secrets simultanément).

Oui. Infisical propose des intégrations CI/CD de premier ordre : GitHub Actions (action officielle sur le marketplace), GitLab CI (synchronisation native des variables), CircleCI et Jenkins. Vous ajoutez un service token comme secret de CI, puis l'intégration injecte les secrets du bon environnement directement dans chaque exécution du pipeline — aucun fichier .env, aucune rotation manuelle.

Oui. Installez le SDK Infisical (`npm install @infisical/sdk` ou `pip install infisical-python`) et récupérez les secrets au démarrage. Vous pouvez aussi utiliser le wrapper CLI : `infisical run -- node server.js` injecte les secrets comme variables d'environnement, de sorte que votre application les lit via `process.env` — sans intégration du SDK, et sans qu'aucun secret ne touche jamais le système de fichiers.

Oui. Infisical chiffre au repos chaque valeur de secret avec AES-256-GCM au moyen d'une `ENCRYPTION_KEY` que vous générez et contrôlez. En transit, toutes les communications se font en HTTPS. L'accès est régi par des politiques basées sur les rôles, des service tokens et des identités machine appliquant le principe du moindre privilège. Chaque lecture et écriture est consignée dans le journal d'audit. Le cœur MIT inclut toutes ces fonctionnalités de sécurité — aucune offre payante n'est requise.

Ils répondent à des problèmes différents : Vaultwarden est un gestionnaire de mots de passe personnel et d'équipe (compatible Bitwarden — identifiants de connexion humains, extensions de navigateur, applications mobiles). Infisical est un gestionnaire de secrets pour les machines et le code (clés API, URI de bases de données, tokens — consommés par programme par les applications et les pipelines CI/CD via des SDK ou la CLI). La plupart des équipes utilisent les deux : Vaultwarden pour les identifiants humains, Infisical pour les secrets applicatifs.

Dockge est un gestionnaire visuel open source (MIT) de stacks Docker Compose, créé par Louis Lam — le développeur à l'origine d'Uptime Kuma. Il vous permet de créer, modifier, démarrer, arrêter et surveiller toutes vos applications multi-conteneurs depuis une interface web épurée sur le port 5001, sans SSH ni ligne de commande. Il stocke chaque stack sous forme de fichier `compose.yaml` standard dans `/opt/stacks` sur votre hôte.

Dockge consomme au repos moins de 150 MB de RAM et tient sur n'importe quel VPS sans impacter les autres services qui y tournent. Il repose sur Node.js avec une base de données SQLite — aucune base de données ni cache externe à provisionner. Un VPS de 512 MB peut faire tourner Dockge confortablement aux côtés de plusieurs stacks gérées.

Oui. Placez vos fichiers `compose.yaml` existants dans des sous-répertoires sous `/opt/stacks` (par ex. `/opt/stacks/n8n/compose.yaml`) et Dockge les découvrira et les affichera automatiquement au prochain chargement. La convention de chemin est `<stacks-dir>/<stack-name>/compose.yaml` — toute stack respectant déjà cette disposition apparaît dans l'interface sans aucune étape d'import.

Ils couvrent des périmètres différents : Dockge est un pur gestionnaire de Compose — il vous permet de créer et de gérer des stacks sur le serveur même où il tourne. Coolify et Dokploy sont des plateformes PaaS complètes avec intégration Git, SSL automatique, promotion d'environnement et déploiements multi-serveurs. Utilisez Dockge quand vous voulez une interface légère pour vos stacks faites main ; utilisez Coolify ou Dokploy quand vous voulez du déploiement par git-push et du SSL automatisé prêts à l'emploi.

La console terminal intégrée a été désactivée par défaut en v1.5.0 à la suite d'un avis de sécurité (GHSA-7vx4-hf96-mqq6). Le reste de Dockge — gestion des stacks, streaming des logs, tableau de bord de statut — est pleinement fonctionnel sans la console. Ne l'activez pas sur une instance exposée publiquement. Si vous avez besoin d'un accès shell aux conteneurs, utilisez plutôt une session SSH dédiée.

Ouvrez la stack dans l'interface de Dockge, cliquez sur Update, puis sur Start. En coulisses, Dockge exécute `docker compose pull` suivi de `docker compose up -d`. Pour mettre à jour Dockge lui-même, modifiez son propre `compose.yaml` (dans `/opt/dockge` ou là où vous l'avez installé), changez le tag de l'image si nécessaire, puis lancez `docker compose up -d` depuis le terminal — ou utilisez une autre instance de Dockge pour le gérer.

Authelia est une passerelle d'authentification et d'autorisation open source (Apache 2.0). Elle se place devant vos applications comme point de terminaison forward-auth sur votre reverse proxy (Nginx, Caddy, Traefik). Chaque requête est vérifiée par rapport à votre politique : les utilisateurs non authentifiés sont redirigés vers le portail de connexion Authelia, où vous pouvez imposer un mot de passe, du TOTP, des passkeys ou n'importe quelle combinaison. Les applications elles-mêmes n'ont besoin d'aucune modification — Authelia les protège au niveau de l'infrastructure.

Oui. Les cookies de session d'Authelia doivent être limités à un domaine (`Domain=.yourdomain.com`), et les callbacks OIDC ainsi que les certificats Let's Encrypt exigent un FQDN résoluble publiquement en HTTPS. Authelia ne peut pas fonctionner correctement derrière une simple adresse IP. Lorsque vous déployez via ServOrbit, faites pointer un enregistrement A vers votre VPS et saisissez le domaine lors de la configuration — le reverse proxy et le certificat TLS sont configurés automatiquement.

Authelia lui-même consomme au repos moins de 30 MB de RAM. Ajoutez environ 20 MB pour le magasin de sessions Redis. Total : moins de 60 MB pour la pile d'authentification complète. Un VPS de 512 MB suffit pour un usage personnel ; 1 GB est confortable pour une équipe de 20 utilisateurs ou plus.

Oui. Authelia est un fournisseur OpenID Connect (OIDC) certifié. Enregistrez chaque application comme client OIDC dans `configuration.yml` — donnez-lui un client ID, un secret et une redirect URI. Configurez ensuite l'application pour utiliser Authelia comme fournisseur d'identité. Les utilisateurs s'authentifient une seule fois sur votre portail d'authentification et sont transférés silencieusement vers chaque application connectée sans avoir à ressaisir leurs identifiants.

Authelia prend en charge le TOTP (toute application d'authentification : Google Authenticator, Ente Auth, Aegis, Bitwarden Authenticator), WebAuthn/Passkeys (Touch ID, Face ID, YubiKey, toute clé matérielle FIDO2) et les notifications push Duo. Les utilisateurs peuvent enregistrer plusieurs méthodes et choisir au moment de la connexion. Le MFA est imposé par domaine, par groupe ou globalement selon vos règles de contrôle d'accès.

Actual Budget est une application de finances personnelles open source (MIT), local-first, fondée sur la budgétisation à base zéro (méthode des enveloppes). C'est une alternative auto-hébergée à YNAB — vous faites tourner un serveur Node.js léger sur votre propre VPS et synchronisez votre budget vers n'importe quel appareil grâce au chiffrement de bout en bout. Vos données financières ne quittent jamais votre infrastructure.

La méthodologie de budgétisation est identique : affectez chaque dollar à une enveloppe (catégorie) nommée avant de le dépenser. Les différences : Actual est sous licence MIT sans frais d'abonnement, vos données restent sur votre propre serveur, et le code source est entièrement auditable sur GitHub. YNAB dispose d'une application mobile native plus soignée ; Actual propose une PWA rapide et une communauté open source active.

Le serveur Node.js consomme au repos moins de 80 MB de RAM. Un VPS de 1 GB est largement suffisant pour plusieurs utilisateurs simultanés. Actual Budget est l'un des outils de finances auto-hébergés les plus économes en ressources qui soient.

Oui, via deux intégrations optionnelles : GoCardless pour les banques européennes (API d'open banking, sans partage d'identifiants) et SimpleFIN pour les banques nord-américaines. Si votre banque n'est pas prise en charge, vous pouvez importer des fichiers OFX, QFX, QIF ou CSV exportés depuis votre portail de banque en ligne. La saisie manuelle des transactions fonctionne aussi très bien pour garder l'œil sur votre trésorerie.

Oui. Toutes les données sont stockées dans un fichier SQLite sur votre VPS et synchronisées entre les appareils au moyen du chiffrement de bout en bout — le serveur ne manipule que du texte chiffré et ne lit jamais vos transactions ni vos soldes. Aucun service tiers n'a accès à vos relevés financiers.

Oui. Actual prend en charge l'import direct depuis YNAB 4 (export local) et nYNAB (export web). Vos catégories, comptes, montants budgétés et l'historique des transactions sont tous repris. La migration prend environ cinq minutes, directement depuis l'écran des paramètres d'Actual Budget.

Umami est un outil d'analytics web open-source (licence MIT) auto-hébergé qui mesure votre audience sans cookies ni collecte de données personnelles. Contrairement à Google Analytics 4, Umami ne nécessite pas de bannière de consentement (pas de cookies → pas d'obligation RGPD), le script de suivi fait moins de 2 Ko et est servi depuis votre propre domaine. Vos données restent sur votre VPS et ne transitent jamais par un serveur tiers.

Il n'y a aucune limite. Une seule instance Umami peut suivre un nombre illimité de sites web. Chaque site reçoit son propre identifiant de suivi et ses propres clés API, ce qui permet de délimiter les accès par site (utile pour les agences qui gèrent plusieurs clients). La consommation de ressources augmente légèrement avec le volume d'événements, mais 1 à 2 Go de RAM suffisent pour des dizaines de sites à trafic modéré.

Par défaut, le script est accessible à `/script.js` sur votre domaine. La plupart des bloqueurs de publicités ne ciblent pas les noms de fichiers génériques sur des domaines first-party, donc Umami passe généralement là où Google Analytics et Plausible sont bloqués. Si vous avez besoin d'une protection supplémentaire, définissez la variable d'environnement `TRACKER_SCRIPT_NAME` dans votre fichier Docker Compose pour renommer le script en quelque chose de neutre (ex. `u`), ce qui le rend pratiquement invisible aux listes de filtres.

Oui. Umami offre une API d'événements simple en JavaScript : appelez `umami.track(nomEvenement, données)` n'importe où dans votre code, par exemple `umami.track('clic_inscription', { plan: 'pro' })`. Les événements apparaissent dans le tableau de bord sous l'onglet Événements. Aucun gestionnaire de balises, aucun tag Google — juste un appel de fonction et vos propres données sur votre serveur.

Oui. La version open-source d'Umami (licence MIT) est entièrement gratuite, sans aucune limitation de fonctionnalités. Umami propose également une offre Cloud gérée payante sur umami.is, mais sur ServOrbit vous ne payez que le VPS — Umami lui-même ne coûte rien.

DocuSeal est une plateforme de signature électronique open-source (AGPL-3.0, 17 000+ étoiles GitHub, v3.1.4) qui permet de créer des modèles PDF, d'envoyer des demandes de signature à plusieurs parties et de collecter des signatures numériques juridiquement valables — le tout sur votre propre serveur. C'est une alternative auto-hébergée à DocuSign, Adobe Acrobat Sign et HelloSign.

Non. DocuSeal utilise SQLite par défaut — la base de données est un fichier unique stocké dans `/data/db.sqlite3` à l'intérieur du conteneur. Aucun serveur PostgreSQL, MySQL ou Redis n'est nécessaire. Le volume monté dans `/data` conserve tous les documents et la base de données à travers les redémarrages du conteneur.

DocuSeal fonctionne avec moins de 256 Mo de RAM en veille. Un VPS 1 Go est confortable pour une équipe traitant quelques dizaines de documents par mois. Pour un volume élevé ou plusieurs sessions de signature simultanées, un plan 2 Go est recommandé.

Non. Chaque signataire reçoit un lien unique (par e-mail si SMTP est configuré, ou partagé manuellement). Il ouvre le lien dans n'importe quel navigateur, remplit ses champs et soumet — sans inscription ni téléchargement d'application.

DocuSeal génère une piste d'audit contenant l'adresse e-mail, l'adresse IP et l'horodatage du signataire pour chaque signature, ainsi qu'un certificat d'achèvement. Cela satisfait les exigences de preuve pour les signatures électroniques simples au sens d'eIDAS (UE) et des lois équivalentes dans de nombreux pays. Pour les NDAs, contrats et formulaires de consentement courants, la piste d'audit de DocuSeal est suffisante.

Oui. Sans SMTP configuré, DocuSeal fonctionne entièrement — il suffit de copier les liens de signature depuis la page Soumissions et de les partager manuellement (par Slack, WhatsApp ou e-mail). L'application reste pleinement opérationnelle ; SMTP est recommandé pour automatiser les invitations, les rappels et les notifications de signature complétée.

Changedetection.io est un outil open-source (Apache 2.0) qui surveille n'importe quel site web et vous alerte dès qu'une page change — prix, stocks, appels d'offres, publications officielles. Il tourne sur votre VPS, sans frais par vérification.

Oui, via un second conteneur Playwright/Chromium optionnel. Changedetection.io s'y connecte pour rendu navigateur complet — idéal pour les compteurs de stock dynamiques, les SPA et les pages de paiement.

Plus de 80 canaux via la bibliothèque Apprise : email (SMTP), Telegram, Slack, Discord, ntfy, Gotify, Matrix, webhooks personnalisés et bien d'autres. Vous pouvez configurer plusieurs canaux par URL surveillée.

Oui. Utilisez un sélecteur CSS (ex. `.price`), une expression XPath ou un déclencheur par mot-clé (alerte uniquement si la page contient ou cesse de contenir un texte donné). Les filtres éliminent le bruit des menus, des publicités et des horodatages qui changent à chaque chargement.

Le conteneur principal consomme moins de 256 Mo en veille. Un VPS 1 Go suffit pour surveiller des centaines d'URLs. Avec le sidecar Playwright/Chromium pour les pages JS, prévoyez 2 Go au total.

Oui. Changedetection.io est open-source sous licence Apache 2.0 — aucune limite d'URLs, aucun frais par vérification, aucun compte cloud obligatoire. Vous payez uniquement le VPS qui l'héberge.

Memos est une application de notes open-source (MIT) légère : capturez vos idées, tenez un journal de bord ou partagez des notes avec votre équipe depuis votre VPS. Image Docker ~20 Mo, moins de 128 Mo de RAM, SQLite par défaut.

Memos consomme moins de 128 Mo de RAM au repos avec SQLite. Son image Docker de ~20 Mo est l'une des plus légères du catalogue — il peut cohabiter avec d'autres applications sur un VPS 1 Go sans impact perceptible.

Oui. Memos offre un rendu Markdown en temps réel dans la vue chronologique : gras, italique, blocs de code, cases à cocher, liens et images intégrées — tout est rendu à la frappe. Les captures d'écran collées directement sont également uploadées et intégrées.

Oui. Chaque note peut être basculée en mode « public » via l'icône de partage — elle obtient alors un lien accessible sans connexion. Le reste de l'instance demeure privé. Il est aussi possible de rendre l'intégralité de l'instance publique pour un micro-blog personnel.

Oui. Memos expose une API RESTful sur /api/v1/ avec authentification par jeton. Vous pouvez poster des notes depuis un script, un pipeline CI, un cron job ou un bot Telegram — utile pour les logs de standup automatiques ou les captures depuis d'autres outils.

Oui. Memos est sous licence MIT — gratuit à utiliser, modifier et auto-héberger. Aucun abonnement, aucune télémétrie, aucun compte cloud requis. Vous payez uniquement le VPS qui le fait tourner.

Chatwoot est une plateforme de support client omnicanal open-source (MIT, 34 000+ étoiles GitHub, v4.16.0) qui centralise le livechat, les e-mails, WhatsApp, Telegram, Facebook Messenger et les DMs Twitter/X dans une seule boîte de réception partagée. Auto-hébergée sur votre VPS, elle offre une alternative à Intercom et Zendesk sans frais par agent.

Oui. Chatwoot s'intègre avec l'API WhatsApp Business Cloud (Meta), Twilio WhatsApp et Telegram Bot API. Vous connectez chaque canal depuis le panneau Paramètres → Boîtes de réception. Les messages de ces canaux apparaissent dans la boîte de réception partagée aux côtés du livechat et des e-mails.

Créez une boîte de réception de type Site web dans Paramètres → Boîtes de réception. Chatwoot génère un snippet JavaScript de deux lignes. Collez-le dans le <head> de votre site : une bulle de chat personnalisable apparaît instantanément pour vos visiteurs. La couleur, le message de bienvenue et le nom d'équipe sont configurables depuis le tableau de bord.

Chatwoot tourne avec quatre conteneurs Docker (Rails + Sidekiq + PostgreSQL + Redis) qui consomment environ 1,2 Go de RAM au repos. Un VPS de 2 Go de RAM est le minimum pour la production ; 4 Go sont recommandés pour les équipes de plus de 10 agents ou avec un volume élevé de conversations.

Oui. Chatwoot exige un FRONTEND_URL valide (FQDN en HTTPS) pour que les redirections OAuth, les liens dans les e-mails et l'URL du script du widget livechat fonctionnent correctement. Sans domaine, ces fonctionnalités (intégrations e-mail, notifications, widget) ne fonctionneront pas de façon fiable.

Oui. Chatwoot Community Edition est un logiciel open-source sous licence MIT — gratuit à installer et à auto-héberger avec un nombre illimité d'agents. Vous payez uniquement le VPS qui l'héberge, pas la plateforme. Des fonctionnalités entreprise (SSO, journaux d'audit avancés, rôles personnalisés) sont disponibles dans les offres cloud payantes.

Vikunja est un gestionnaire de tâches et de projets open-source auto-hébergé (AGPL-3.0, 24 k+ étoiles, v2.4.0). Il propose des vues liste, Kanban et Gantt avec dépendances, des tâches récurrentes, une synchronisation CalDAV et une API REST complète — une alternative à Todoist, TickTick et Asana sans frais récurrents.

Vikunja consomme moins de 256 Mo de RAM au repos avec SQLite comme stockage par défaut. L'image Docker fait environ 80 Mo. Un VPS de 512 Mo peut faire tourner Vikunja avec un reverse proxy sans aucune surcharge — un plan de 1 Go offre une marge confortable.

Oui. Vikunja supporte la vue liste, les tableaux Kanban avec glisser-déposer et la vue Gantt avec dates de début/fin et dépendances entre tâches. Vous pouvez basculer entre les vues par projet sans migrer aucune donnée.

Oui. Vikunja expose un endpoint CalDAV/WebDAV sur `/dav/`. N'importe quel client CalDAV compatible — Thunderbird, DAVx⁵, Apple Reminders — peut se connecter avec vos identifiants Vikunja et synchroniser vos tâches nativement.

Oui. Vikunja embarque une API REST complète documentée avec une spec Swagger sur `/api/v1/docs`. Vous pouvez créer, mettre à jour et fermer des tâches via HTTP avec un token API — utile pour les pipelines CI qui ferment automatiquement les tâches au déploiement réussi.

Oui. Vikunja est un logiciel open-source sous licence AGPL-3.0 — gratuit à utiliser et à auto-héberger. Il n'y a pas de frais par siège, pas de plans d'abonnement et pas de télémétrie. Vous payez uniquement le VPS qui l'héberge.

Paperless-ngx est une application de gestion documentaire (GED) open-source auto-hébergée (AGPL-3.0, 43 k+ étoiles). Elle numérise vos documents, les OCRise automatiquement via Tesseract (français, anglais, arabe), les indexe en plein texte et les classe par correspondant, type et tags — le tout sur votre VPS, sans aucune donnée envoyée dans un cloud tiers.

Oui. L'image Docker intègre Tesseract avec les packs de langue complets. La variable `PAPERLESS_OCR_LANGUAGE=fra+eng` — préconfigurée dans la recette ServOrbit — active simultanément l'OCR en français, anglais et arabe sur chaque document. Les documents mixtes sont correctement traités dans les deux langues.

La stack complète (serveur web Django + PostgreSQL 16 + Redis 7) consomme environ 400 à 512 Mo de RAM au repos. Un VPS à 2 Go est recommandé pour un usage normal ; 4 Go pour des archives volumineuses (100 k+ documents) ou des OCR simultanés intensifs.

Ce sont deux outils complémentaires avec des usages différents. Stirling-PDF est une boîte à outils PDF (50+ opérations : fusionner, découper, compresser, convertir, signer…) — vous y traitez des fichiers PDF ponctuellement. Paperless-ngx est une GED archivistique : vous y versez vos documents une fois et elle les indexe, les classe et les rend cherchables à vie. Les deux fonctionnent très bien ensemble.

Oui. Paperless-ngx expose une REST API complète documentée sur `/api/` (Swagger). Vous pouvez lister, rechercher, télécharger, uploader et supprimer des documents via HTTP. Dans n8n, un nœud HTTP Request suffit pour déclencher l'ingestion d'une pièce jointe reçue par e-mail ou d'un PDF généré par un pipeline CI.

Oui. Paperless-ngx est un logiciel open-source sous licence AGPL-3.0 — gratuit à utiliser, modifier et auto-héberger. Aucun frais par document, aucune limite de stockage, aucun abonnement. Vous payez uniquement le VPS ServOrbit qui fait tourner la stack.

NocoBase est une plateforme no-code/low-code open-source (Apache-2.0, 23 k+ étoiles) qui vous permet de créer des outils internes, des CRM, des workflows de validation et des portails client sans écrire de code frontend. Le principe : vous définissez des collections (entités avec champs, relations et permissions), puis vous composez une interface avec des blocs glisser-déposer (tableaux, formulaires, Kanban, graphiques). Chaque collection génère automatiquement une REST API. Sur ServOrbit, NocoBase s'installe en deux conteneurs Docker (app + PostgreSQL 16) sur un VPS 2 Go de RAM.

NocoDB transforme n'importe quelle base de données en tableau collaboratif à la Airtable — l'accent est mis sur la visualisation de données existantes sous forme de grille, de galerie ou de Kanban simple. NocoBase est data-model-first : vous concevez des entités, des relations, des types de champs et des permissions, puis vous composez des interfaces complexes avec des blocs (formulaires multi-étapes, workflows, dashboards). NocoDB excelle pour explorer et modifier des données rapidement ; NocoBase est fait pour construire des applications métier structurées avec chaînes de validation, rôles granulaires et automatisations. Les deux sont au catalogue ServOrbit.

Oui. NocoBase est bien adapté à la construction d'un CRM sur mesure : créez des collections Contacts, Entreprises, Opportunités et Activités avec des relations entre elles. Ajoutez une vue Kanban pour le pipeline commercial, un formulaire de saisie de leads et des permissions différentes par équipe (commerciaux voient leurs propres opportunités, managers voient tout). Le moteur de workflow peut envoyer un e-mail automatique quand une opportunité change de statut ou programmer des relances. Tout reste sur votre VPS, exportable via CSV ou REST API à tout moment.

Non. NocoBase fonctionne sans domaine sur `http://ip-de-votre-vps:13000` pour un usage interne ou en test. Si vous souhaitez exposer votre instance sur internet avec HTTPS, pointez un sous-domaine vers votre VPS et ServOrbit posera automatiquement le reverse-proxy nginx + le certificat Let's Encrypt lors du déploiement depuis la Marketplace. Pour un usage strictement interne (équipe connectée en VPN ou réseau local), le port 13000 sans domaine suffit.

Oui. NocoBase dispose d'un gestionnaire de plugins intégré (accessible depuis Paramètres → Gestionnaire de plugins). Il offre plus de 80 plugins officiels : vues Kanban, Gantt, calendrier, graphiques, blocs carte, gestionnaire de fichiers, workflow visuels, import/export Excel, intégrations LDAP/SSO (Enterprise), audit logs, etc. Les plugins sont activables à la volée sans redémarrer le serveur. L'API de plugin est publique, ce qui permet à votre équipe de développer des extensions sur mesure si nécessaire.

Oui. NocoBase est un logiciel open-source sous licence Apache-2.0 — gratuit à utiliser, modifier et auto-héberger sans frais par utilisateur, sans limite de collections et sans télémétrie. Un plan Enterprise payant existe pour les équipes qui ont besoin de plugins premium (SSO SAML, audit logs avancés, marque blanche), mais la version Community couvre l'essentiel pour la grande majorité des usages. Vous payez uniquement le VPS ServOrbit qui fait tourner la stack.

Glance est un tableau de bord self-hosted léger (AGPL-3.0, ~35 k ⭐, Go). Il regroupe actualités Hacker News, flux RSS, stats VPS en direct (CPU, RAM, disque) et statut de vos conteneurs Docker sur une seule page — un seul fichier de configuration YAML, aucune base de données, moins de 25 Mo RAM.

Non. Glance est entièrement fonctionnel sur une adresse IP et un port (ex. http://95.x.x.x:8080). Un domaine et HTTPS ne sont pas obligatoires, mais recommandés pour la sécurité des cookies de session. Vous pouvez ajouter un reverse proxy Caddy devant Glance à tout moment.

Éditez le fichier /data/glance.yml dans le volume Docker de votre VPS. Chaque widget est un bloc YAML dans la section columns d'une page. Par exemple, ajoutez `- type: rss` avec une liste d'URLs pour des flux RSS, ou `- type: docker-containers` pour voir vos conteneurs. Redémarrez ensuite Glance (`docker compose restart glance`). La documentation officielle liste 30+ types de widgets.

Non. Glance est configuré avec une authentification intégrée (username/password). Tout visiteur est redirigé vers une page de connexion. Vous pouvez ajouter plusieurs utilisateurs dans la section auth.users du fichier glance.yml, ou placer Glance derrière un VPN pour une protection supplémentaire.

Oui. Ajoutez `- type: docker-containers` dans un column de votre glance.yml. Le playbook de provisioning ServOrbit monte déjà /var/run/docker.sock en lecture seule dans le conteneur Glance. Vous verrez le nom, l'image et le statut de chaque conteneur actif sur le VPS.

Glance idle sous 25 Mo de RAM, même avec plusieurs widgets actifs. Il s'agit d'un binaire Go statique sans base de données ni processus externe. Vous pouvez le faire tourner sur un VPS de 512 Mo aux côtés d'autres services (Dozzle, Uptime Kuma) sans saturer la mémoire.

Komodo est une plateforme GitOps open-source (GPL-3.0) pour gérer des stacks Docker et des pipelines de déploiement sur plusieurs serveurs depuis un tableau de bord unique. Il utilise une architecture Core/Periphery : le Core centralise la gestion, et des agents Periphery légers s'installent sur chaque serveur à piloter.

Dockge et Portainer sont des interfaces de gestion Docker mono-serveur. Komodo est conçu pour les flottes multi-serveurs : un Core unique gère un nombre illimité de serveurs via des agents Periphery. Il ajoute aussi des pipelines GitOps, des Procedures automatisées et un support Docker Swarm — des fonctionnalités absentes des deux autres.

Oui, un nom de domaine (ou sous-domaine) est requis car KOMODO_HOST doit pointer vers l'URL HTTPS publique de votre Core. Cette URL est utilisée pour la validation des signatures HMAC des webhooks et les callbacks OAuth. Le playbook ServOrbit configure automatiquement le TLS via certbot lors du déploiement.

Installez l'agent Periphery sur chaque nouveau serveur avec la commande Docker fournie dans la documentation Komodo (`docker run -d --restart=unless-stopped --network host -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/moghtech/komodo-periphery:2`), puis ajoutez-le dans l'interface Komodo via Servers → Add Server en renseignant son IP et le port 8120.

Oui. Configurez un webhook dans votre dépôt GitHub pointant vers `https://votre-domaine.com/api/webhook/komodo`. Dans Komodo, créez une Procedure avec les étapes de déploiement (pull image, restart stack, notification) et liez-la au webhook. Komodo vérifie la signature HMAC avant d'exécuter quoi que ce soit.

Le binaire Komodo Core (Rust) idle sous 256 Mo de RAM. La base FerretDB + PostgreSQL ajoute environ 200–300 Mo supplémentaires. Un VPS de 1 Go de RAM est suffisant pour le plan de contrôle seul. Les agents Periphery sont encore plus légers — moins de 50 Mo chacun.

Authelia est un proxy forward-auth léger qui ajoute le MFA devant vos apps sans les modifier — il n'a pas de console de gestion d'utilisateurs. Authentik est un fournisseur d'identité (IdP) complet avec son propre annuaire, une console d'administration, le SSO via OIDC/SAML/LDAP et un éditeur de flux visuel. Utilisez Authelia pour protéger rapidement des apps existantes ; utilisez Authentik quand vous avez besoin d'un vrai IdP avec gestion du cycle de vie des comptes.

Les conteneurs server et worker consomment ensemble ~300-400 Mo au repos. PostgreSQL 16 ajoute ~150 Mo. Un VPS de 1 Go est le strict minimum ; 2 Go est recommandé pour une utilisation confortable. Authentik a supprimé sa dépendance Redis depuis la v2025.10, donc pas de couche cache supplémentaire à provisionner.

Oui. Les callbacks OIDC, les assertions SAML et les cookies de session nécessitent HTTPS avec un FQDN valide et résolvable publiquement. ServOrbit provisionne automatiquement un certificat TLS via Let's Encrypt dès que l'enregistrement DNS A de votre domaine pointe vers le VPS.

Toute application supportant OIDC/OAuth2 ou SAML 2.0. Exemples depuis le marketplace ServOrbit : Gitea, Nextcloud, Mattermost, Docmost, Grafana, Dockge et Metabase. Authentik fournit des intégrations pré-construites pour des dizaines d'applications populaires et permet de créer des providers OIDC/SAML personnalisés pour n'importe quelle autre app.

Oui. Authentik supporte la synchronisation depuis une source LDAP — importez les utilisateurs depuis Active Directory ou OpenLDAP avec une synchronisation planifiée. Pour les imports CSV, utilisez l'API REST ou l'outil d'import en masse de la console admin. Les utilisateurs peuvent aussi s'auto-enregistrer via des flux d'enrôlement personnalisables.

Absolument. Authentik est largement utilisé sur des homelabs et des équipes de 2 à 20 utilisateurs. L'édition Community (Apache 2.0) est complète pour ces cas d'usage. L'édition Enterprise ajoute RBAC avancé, un SLA de support et des fonctionnalités pour les grandes organisations, mais reste entièrement optionnelle.

Penpot est un outil de design collaboratif open-source (MPL-2.0) auto-hébergeable, tandis que Figma est un SaaS propriétaire. La différence technique fondamentale : Penpot utilise SVG standard comme format de fichier natif, alors que Figma utilise un format binaire propriétaire. Concrètement, vos fichiers Penpot sont lisibles par n'importe quel éditeur vectoriel, exportables et versionnables dans Git. Sur le plan fonctionnel, Penpot offre le design vectoriel, les composants, le prototypage et le handoff développeur — les mêmes fonctionnalités core que Figma.

Le minimum absolu est 2 Go de RAM — la stack démarre, mais l'export de fichiers complexes (PDF, PNG haute résolution) peut saturer le conteneur `penpot-exporter`. La configuration recommandée pour une utilisation en production est 4 Go de RAM avec 2 vCPU. Sur un VPS ServOrbit 4 Go, la stack Penpot au repos consomme environ 800 Mo, laissant de la marge pour vos autres services. Pour une équipe de plus de 10 utilisateurs actifs simultanément, prévoyez 8 Go.

Oui. Penpot importe nativement les fichiers `.fig` exportés depuis Figma. Dans un projet Penpot, utilisez Import → Figma file pour sélectionner votre export. Les frames, composants, styles et grilles sont convertis en éléments Penpot. Attendez des pertes mineures sur les fonctionnalités Figma spécifiques (certains plugins, effets avancés), mais la structure générale, les calques et les propriétés de style sont préservés. Penpot importe aussi le format `.penpot` natif et les fichiers SVG.

Oui. Penpot est 100 % open-source (MPL-2.0) et la version auto-hébergée n'a aucune limitation sur le nombre d'utilisateurs, de projets ou de fichiers. Il n'y a pas de plan "Team" ou "Enterprise" payant pour l'auto-hébergement — vous payez uniquement l'infrastructure (votre VPS ServOrbit). Les fonctionnalités de collaboration en temps réel, les bibliothèques partagées et le handoff développeur sont toutes disponibles sans aucun coût de licence.

Oui, pour une utilisation en production avec plusieurs utilisateurs. Penpot requiert HTTPS pour les cookies de session sécurisés et les WebSockets qui alimentent la collaboration temps-réel. Sans domaine HTTPS, l'app tourne en mode `disable-secure-session-cookies`, ce qui est acceptable pour un test local mais pas pour une équipe. Lors du déploiement via le marketplace ServOrbit, le provisioner configure automatiquement le reverse proxy Nginx et le certificat Let's Encrypt à partir du domaine que vous avez fourni.

Oui. Penpot supporte l'authentification OIDC (OpenID Connect) et LDAP. Vous pouvez le brancher sur Authentik (disponible sur le marketplace ServOrbit) pour centraliser l'authentification de toute votre stack self-hosted. La configuration se fait via les variables d'environnement `PENPOT_FLAGS` (activer `enable-oidc`) et les paramètres de provider OIDC. Les utilisateurs se connectent alors via votre IdP central — SSO, MFA, passkeys — sans gérer des comptes séparés dans Penpot.

ntfy est un serveur de notifications push open-source (Apache 2.0, ~32 k ⭐) : vous publiez un message sur un topic avec un simple appel HTTP (`curl -d "Message" http://votre-vps/topic`), et n'importe quel abonné — application mobile, navigateur, script — le reçoit en temps réel. L'auto-hébergement sur ServOrbit vous donne des topics privés illimités, sans limites de taux, sans compte tiers, sans abonnement mensuel. Vous possédez entièrement votre canal de notifications.

Non. ntfy fonctionne en HTTP simple sans domaine — vos scripts et outils de monitoring peuvent envoyer des notifications à l'adresse IP de votre VPS directement. Un domaine ajoute HTTPS (recommandé pour les notifications envoyées sur l'internet public) et le support du Web Push API natif des navigateurs, mais le cas d'usage principal — scripts et outils de monitoring qui envoient des notifications à l'app ntfy — fonctionne en HTTP.

Une seule ligne : `curl -d "Job terminé" http://votre-vps:8080/votre-topic`. Ajoutez un titre avec `-H "Title: Backup nuit"` et définissez la priorité avec `-H "Priority: high"`. Aucun SDK, aucune bibliothèque, aucune API key — fonctionne dans tout environnement shell qui dispose de curl : cron, GitHub Actions, GitLab CI, AWX, entrypoints Docker, scripts Python.

Oui. Les apps officielles ntfy pour Android (F-Droid / Play Store) et iOS (App Store) vous permettent d'ajouter n'importe quel serveur ntfy auto-hébergé comme source de notifications. Entrez l'URL de votre serveur (ex. `http://votre-vps:8080`) et souscrivez à un topic. Les notifications arrivent en push même lorsque l'app est en arrière-plan — Android utilise UnifiedPush (F-Droid) ou FCM (Play), iOS utilise APNs.

Pour un VPS privé accessible uniquement à vos scripts, aucune authentification n'est nécessaire. Pour plus de sécurité, exécutez `docker exec <container> ntfy user add admin` pour créer un utilisateur admin, puis définissez `NTFY_AUTH_DEFAULT_ACCESS=deny-all` dans les variables d'environnement pour que seuls les utilisateurs authentifiés puissent publier/souscrire. Chaque script ou outil de monitoring obtient son propre token d'accès via `ntfy token add`.

ntfy consomme moins de 30 Mo de RAM avec le cache SQLite par défaut. L'utilisation disque dépend des paramètres de rétention — par défaut les messages expirent après 12 heures et les pièces jointes ne sont pas stockées côté serveur (elles sont référencées en externe). Un VPS avec 512 Mo de RAM est plus que suffisant pour une instance ntfy personnelle ou d'équipe gérant des milliers de notifications par jour.

restic est le moteur de sauvegarde : chiffré, dédupliqué, incrémental, et piloté entièrement en ligne de commande. Backrest est une interface web et un planificateur posés par-dessus : même moteur, même format de dépôt, mais les dépôts, plans, planifications, rétentions, restaurations et opérations de maintenance se gèrent dans le navigateur au lieu de fichiers cron et de scripts shell. Vos sauvegardes restent des dépôts restic standards, ouvrables à tout moment avec l'outil restic — Backrest n'introduit aucun verrouillage.

Partout où restic sait écrire, ce qui inclut toutes les destinations rclone : Amazon S3, Backblaze B2, Wasabi, MinIO, Azure Blob, Google Cloud Storage, SFTP/SSH, ou un disque local ou monté en réseau. Backblaze B2 est le choix habituel pour un VPS — peu coûteux, compatible S3 et surtout situé en dehors du domaine de panne de votre serveur, ce qui est tout l'intérêt d'une sauvegarde hors site.

Oui, et c'est vous. restic chiffre chaque instantané localement, sur le VPS, avant le moindre envoi : la destination ne reçoit que des blocs opaques. Le mot de passe du dépôt est la clé de chiffrement. Rangez-le dans un gestionnaire de mots de passe : si vous le perdez, les sauvegardes deviennent mathématiquement irrécupérables, et ni ServOrbit ni le fournisseur de stockage ne peuvent en rétablir l'accès.

Le conteneur lui-même est léger : moins de 100 Mo de RAM au repos et quelques centaines de mégaoctets d'image et de cache — un VPS à 1 Go convient largement. Le coût réel se situe à la destination, et la déduplication le rend modeste : après le premier instantané complet, les exécutions suivantes n'envoient que les blocs modifiés, si bien qu'un serveur de 20 Go avec plusieurs mois de rétention quotidienne tient souvent dans quelques dizaines de gigaoctets.

Il sauvegarde ce qui lui est monté. La recette ServOrbit monte `/home`, `/root` et `/etc` de l'hôte en lecture seule sous `/host`, ce qui couvre les données utilisateurs et la configuration système d'un VPS classique. Pour protéger d'autres chemins — un répertoire de données applicatif, un volume Docker — ajoutez le montage correspondant en lecture seule dans le fichier compose : il apparaîtra ensuite dans le sélecteur de chemins du plan.

Backrest affiche l'état et l'historique de chaque plan dans son interface, et exécute des opérations `check` planifiées qui vérifient l'intégrité du dépôt plutôt que de se contenter de signaler que la tâche a démarré. Pour une alerte active, configurez un hook sur échec pointant vers un webhook : un topic ntfy auto-hébergé convient parfaitement et pousse l'échec sur votre téléphone la nuit même. C'est ainsi qu'on évite le scénario classique — découvrir une sauvegarde cassée depuis trois mois au moment précis où on en a besoin.

Meilisearch est un moteur de recherche full-text open source (MIT, 57 k+ étoiles GitHub) conçu pour la recherche utilisateur : tolérance aux fautes de frappe, résultats en moins de 50 ms, support natif de l'arabe, du français et de l'anglais. Une recherche SQL ILIKE scanne toute la table et ignore les fautes de frappe — au-delà de quelques milliers de lignes, elle devient trop lente pour une barre de recherche en temps réel. Meilisearch pré-indexe vos données et répond en quelques millisecondes même sur des millions de documents, sans modifier votre base de données principale.

Le binaire Meilisearch lui-même tourne sous 50 Mo de RAM au repos. La consommation réelle dépend de la taille de vos index : un index de 100 000 produits avec plusieurs attributs textuels occupe environ 200–500 Mo de RAM et autant sur le disque (Meilisearch pré-construit ses index inversés pour la rapidité). Un VPS à 1 Go de RAM convient pour démarrer ; passez à 2–4 Go si votre dataset dépasse le million de documents ou si vous servez un trafic de recherche soutenu.

Oui. Le tokeniseur multilingue de Meilisearch détecte automatiquement la langue de chaque attribut et applique le traitement approprié : segmentation n-gram pour l'arabe (qui gère l'absence de séparateurs de mots standards et la direction RTL), normalisation des diacritiques et liste de mots vides pour le français. Un index qui mélange des champs en arabe et en français répond correctement aux requêtes dans les deux langues sans aucune configuration — idéal pour les projets Maroc/MENA bilingues.

Le provisioner ServOrbit génère automatiquement un `MEILI_MASTER_KEY` fort et aléatoire et démarre Meilisearch en mode `production`. En mode production, chaque appel API doit inclure soit le master key (en en-tête `Authorization: Bearer <KEY>`), soit une clé API dérivée à portée réduite — l'instance rejette toute requête non authentifiée. Le master key est affiché une fois dans votre espace client ServOrbit après le déploiement : conservez-le dans un gestionnaire de mots de passe, car il ne peut pas être récupéré depuis le container en cas de perte (seul un redémarrage avec une nouvelle clé est possible, ce qui invalide les clés dérivées existantes).

Oui, et c'est la pratique recommandée. À partir du master key, vous générez des clés API à portée réduite via l'endpoint `/keys` : lecture seule sur un index spécifique, recherche seulement sans possibilité d'écrire ou de supprimer, accès limité à un sous-ensemble d'attributs, ou contraintes de filtre (l'utilisateur ne peut chercher que dans ses propres données). La clé de recherche peut être intégrée en clair dans votre bundle JavaScript sans risque — elle ne peut ni modifier ni supprimer de données. Le master key, lui, ne doit jamais quitter votre backend.

Non. Meilisearch est un index de recherche, pas une base de données transactionnelle. Le schéma classique : votre application écrit les données dans PostgreSQL (ou toute autre base), puis les synchronise dans Meilisearch (via un webhook, un job Sidekiq/Horizon, ou une tâche planifiée) pour l'indexation. Les requêtes de recherche vont vers Meilisearch ; les lectures de données complètes (fiche produit, commande, profil) restent dans votre base principale. Les deux sont complémentaires : PostgreSQL garantit la cohérence transactionnelle, Meilisearch offre la vitesse et la pertinence de la recherche.

Monica CRM (AGPL-3.0, 22 k+ étoiles) est un gestionnaire de relations personnelles, pas un outil de vente. Là où les CRM d'entreprise comme Twenty ou HubSpot suivent des pipelines, des leads et du chiffre d'affaires, Monica suit le côté humain : anniversaires, notes personnelles, idées de cadeaux, événements de vie et rappels de suivi. Il est conçu pour gérer votre réseau personnel et professionnel — amis, famille, mentors, clients — et non un entonnoir de vente structuré.

Non. L'inscription et la connexion à Monica fonctionnent sans aucune configuration mail. Le premier utilisateur qui s'inscrit sur une instance vierge devient automatiquement l'administrateur — aucun e-mail de vérification n'est envoyé. Le SMTP n'est utile que si vous souhaitez que Monica vous envoie des rappels par e-mail ou des liens de réinitialisation de mot de passe : ces fonctions restent disponibles via le tableau de bord sans SMTP.

Monica v4 prend en charge officiellement MySQL et MariaDB uniquement. La recette ServOrbit utilise MariaDB 11, la base de données open-source compatible MySQL recommandée. PostgreSQL n'est pas pris en charge dans Monica v4 : l'application repose sur des fonctionnalités spécifiques à MySQL et son ORM cible exclusivement MySQL/MariaDB.

Monica lui-même consomme généralement moins de 256 Mo de RAM au repos. MariaDB ajoute 150–300 Mo selon la concurrence des requêtes. Redis ajoute moins de 50 Mo. Au total, un VPS à 1 Go convient confortablement pour un usage personnel (jusqu'à ~5 utilisateurs et des dizaines de milliers de contacts). Passez à 2 Go si vous prévoyez d'héberger une petite équipe ou d'effectuer régulièrement des imports volumineux.

Oui. Monica importe les fichiers vCard (.vcf), qui est le format d'export standard d'iPhone (via iCloud), Android (via Google Contacts) et des outils de bureau (Apple Contacts, Outlook, Thunderbird). Exportez vos contacts depuis votre téléphone ou service cloud, chargez le fichier .vcf dans Paramètres → Importer, et Monica mappe les champs automatiquement. L'import CSV avec mappage de champs personnalisé est également pris en charge.

Monica est une Progressive Web App (PWA) — vous pouvez l'ajouter à l'écran d'accueil de votre téléphone depuis le navigateur (Partager → Sur l'écran d'accueil sur iOS ; Ajouter à l'écran d'accueil sur Chrome Android) et elle se comporte comme une application native avec mise en cache hors ligne. Il n'existe pas d'application iOS ou Android native officielle, mais la PWA fonctionne bien sur mobile.

SearXNG est un moteur de méta-recherche open source qui agrège les résultats de Google, Bing, DuckDuckGo et 280+ sources en une seule requête, sans vous tracer ni conserver votre historique. L'auto-héberger sur votre VPS vous donne une URL de recherche privée pour vos équipes et vos agents IA — sans coût par requête, sans limite de débit et sans données envoyées à des tiers.

Oui. Activez le format JSON dans le fichier `settings.yml` de SearXNG (option `formats: [html, json]`), puis pointez vos outils IA vers `https://votre-domaine.com/search?q=<requête>&format=json`. Open WebUI, n8n, Flowise, LangChain et CrewAI supportent tous SearXNG nativement comme backend de recherche web.

SearXNG (conteneur Python) consomme moins de 256 Mo de RAM, Redis ajoute ~30 Mo. Un VPS ServOrbit à 1 Go de RAM suffit pour un usage personnel ou une petite équipe. Pour un usage avec plusieurs agents IA ou des utilisateurs simultanés, un VPS à 2 Go offre plus de confort.

La méthode la plus simple est l'authentification HTTP Basic Auth configurée dans Nginx — seuls les utilisateurs avec identifiants peuvent accéder à l'interface. Pour un usage API uniquement (agents IA), désactivez l'interface HTML dans `settings.yml` et limitez les plages IP autorisées dans Nginx. Vous pouvez aussi activer `limiter: true` dans les paramètres pour protéger une instance publique des abus (Redis requis pour le limiteur).

SearXNG utilise des techniques d'agrégation similaires à celles de tout moteur de méta-recherche. Pour un usage personnel ou équipe interne, le risque est minimal. Pour un usage public intensif (millions de requêtes/jour), certains moteurs peuvent bloquer votre IP. Activez la rotation de sources dans `settings.yml` et utilisez Redis pour mettre en cache les résultats fréquents — cela réduit considérablement la pression sur chaque moteur individuel.

Non. La fonction de tague automatique par IA est entièrement optionnelle. Karakeep fonctionne comme gestionnaire de marque-pages complet — sauvegarde, crawl, captures d'écran et indexation plein-texte — sans aucune clé IA. Quand vous ajoutez `OPENAI_API_KEY` ou `OLLAMA_BASE_URL`, la génération automatique de tags et de résumés s'active sur les nouveaux enregistrements.

Les trois conteneurs (application Karakeep, Meilisearch et Chrome headless) consomment environ 800 Mo–1,2 Go au repos. Un VPS ServOrbit à 2 Go de RAM est le minimum recommandé. Si vous exécutez également Ollama sur le même VPS pour le tague IA local, un VPS à 4 Go est plus confortable (Ollama nécessite au moins 4 Go pour un petit modèle comme `phi3:mini`).

Oui. Karakeep supporte l'importation depuis Pocket (export JSON), les fichiers de marque-pages Netscape (exportés par tous les navigateurs principaux, Raindrop.io et Pinboard) et son propre format de sauvegarde. Allez dans Settings → Import de votre instance pour téléverser le fichier. Les grandes importations (milliers de marque-pages) sont traitées en arrière-plan — l'importation elle-même est rapide, l'indexation plein-texte se fait de manière asynchrone.

Oui. Si Ollama tourne sur le même VPS (depuis le marketplace ServOrbit ou installé manuellement), ajoutez `OLLAMA_BASE_URL=http://localhost:11434` dans l'environnement Karakeep de votre `docker-compose.yml`. Dans l'interface web, allez dans Settings → AI et sélectionnez votre modèle Ollama préféré. Karakeep l'utilisera pour le tague et la synthèse sans aucun coût d'API ni données quittant votre serveur.

Oui. Karakeep embarque une Progressive Web App (PWA) : ouvrez l'URL de votre instance dans un navigateur mobile, appuyez sur « Ajouter à l'écran d'accueil » et elle s'installe comme une application native. L'intégration avec la feuille de partage du mobile (iOS et Android) vous permet d'envoyer n'importe quel lien depuis n'importe quelle application directement dans votre instance Karakeep en un tap.

Gatus est un outil de monitoring de santé et de page de statut config-as-code (~11.7 k ⭐, Apache 2.0) : vous définissez vos endpoints et leurs conditions de santé dans un fichier YAML versionnable. Uptime Kuma est un moniteur d'uptime à interface graphique — idéal pour ajouter des monitors sans toucher de fichier de config. Gatus propose des conditions plus riches (temps de réponse, expiration TLS, regex du body, résolution DNS) et génère une page de statut publique adaptée au partage avec vos utilisateurs finaux.

Non. Gatus fonctionne directement sur l'adresse IP de votre VPS — la page de statut est accessible à `http://ip-vps:8080` dès le déploiement. Un nom de domaine est recommandé pour une page de statut destinée à vos clients (pour proxifier Gatus derrière nginx avec HTTPS et un sous-domaine comme `status.votre-domaine.com`), mais le monitoring interne et les alertes fonctionnent immédiatement sans domaine.

Connectez-vous en SSH à votre VPS et éditez `/opt/stacks/gatus/config/config.yaml`. Ajoutez un nouveau bloc sous `endpoints:` avec l'URL, l'intervalle et les conditions. Relancez avec `cd /opt/stacks/gatus && docker compose restart gatus`. Le nouvel endpoint apparaît sur la page de statut en quelques secondes. Pas de navigateur, pas d'interface : uniquement un fichier texte que vous pouvez versionner dans un dépôt git.

Gatus intègre plus de 40 canaux d'alerte : Slack, PagerDuty, OpsGenie, Discord, Microsoft Teams, Telegram, Pushover, ntfy, GitHub Issues, e-mail, webhook personnalisé, Mattermost, Gotify et bien d'autres. Configurez le canal une fois dans le bloc `alerting:` de votre config, puis référencez-le par type depuis chaque endpoint. Chaque endpoint supporte des seuils de déclenchement (ex. `failure-threshold: 2` pour n'alerter qu'après 2 échecs consécutifs) et des seuils de rétablissement.

Changez simplement le préfixe de `url:` dans votre endpoint. Pour TCP : `url: "tcp://db.internal:5432"` avec la condition `[CONNECTED] == true`. Pour DNS : `url: "dns://ns1.example.com"` avec `[DNS_RCODE] == NOERROR`. Pour l'expiration TLS : conservez `url: "https://votre-domaine.com"` et ajoutez `[CERTIFICATE_EXPIRATION] > 14d` — Gatus alertera quand il restera moins de 14 jours avant l'échéance. Pour ICMP : `url: "icmp://192.168.1.1"`. Tous les types d'endpoints partagent la même syntaxe de conditions et les mêmes canaux d'alerte.

Grist est un tableur-base de données open-source auto-hébergeable (Apache-2.0, ~11 k ⭐ GitHub). Contrairement à Google Sheets ou Excel, Grist stocke les données dans des tables relationnelles typées avec des références explicites entre tables, des formules Python exécutées côté serveur (accès complet aux bibliothèques Python) et une API REST générée automatiquement sur chaque document. C'est l'alternative open-source à Airtable, sans abonnement ni vendor lock-in. Retrouvez-le dans le <a href="/marketplace/developpement/grist">catalogue ServOrbit</a> ou contactez-nous via [email protected].

Non. Grist stocke chaque document comme un fichier SQLite dans le volume `/persist/docs/`. Aucun service externe n'est requis : ni PostgreSQL, ni Redis, ni Celery. SQLite gère confortablement des milliers de lignes par table. Pour les très grandes instances multi-utilisateurs, Grist peut utiliser PostgreSQL comme base principale — mais le déploiement standard en un seul conteneur utilise SQLite pour tout. Un seul VPS 1 Go RAM suffit pour un usage personnel ou en petite équipe.

Chaque document Grist expose automatiquement une API REST sur `http://ip-vps:8484/api/docs/<docId>/tables/<tableName>/records`. Vous pouvez lister les enregistrements (GET), en créer (POST), modifier (PATCH) ou supprimer (DELETE) sans configurer quoi que ce soit. Récupérez le `docId` depuis l'URL du document dans l'interface web. Utilisez cette API avec n8n, Make, ou tout client HTTP pour intégrer vos données Grist dans vos workflows d'automatisation. L'authentification par clé API est disponible dans les préférences du compte.

Oui. Grist supporte la collaboration temps réel : plusieurs utilisateurs peuvent éditer le même document simultanément, avec propagation des changements en moins d'une seconde et un historique d'audit complet. Le partage se fait document par document via le menu Share, avec trois rôles : lecteur (view-only), éditeur, propriétaire. Pour un système multi-utilisateurs avec authentification par e-mail réelle (pas le `GRIST_DEFAULT_EMAIL` du déploiement initial), configurez un provider OIDC comme Google Workspace, Authentik ou Keycloak via les variables `GRIST_OIDC_*`.

Les documents Grist sont des fichiers SQLite dans le volume `/persist/docs/` — un fichier `.grist` par document. Copiez-les comme n'importe quel fichier. Pour une sauvegarde automatisée et versionée, utilisez Backrest (aussi dans le catalogue ServOrbit) : il snapshote le volume via restic et envoie les incréments chiffrés vers S3, Backblaze B2, ou SFTP sans arrêter Grist. Grist conserve aussi un historique de snapshots par document dans l'interface (menu Document → History) — pratique pour restaurer une version précédente sans accès SSH.

Cet entretien est à votre charge. Nos templates installent une application open source sur votre VPS puis vous en remettent les clés : les nouvelles versions et les correctifs de sécurité relèvent de vous, comme tout ce qui tourne sur un serveur non managé — l'espace client propose l'installation et la désinstallation, pas la montée de version. Suivez le canal de publication de l'éditeur et prenez un instantané depuis votre espace client avant chaque mise à jour, pour pouvoir revenir en arrière si elle se passe mal. Si vous préférez déléguer, la prestation d'administration VPS est disponible en option — écrivez à [email protected].

Logto est une plateforme OIDC/OAuth 2.0 self-hosted que vous déployez sur un VPS via la Marketplace ServOrbit. Une fois déployé, créez votre application dans la console d'administration (port 3002 via tunnel SSH), récupérez le Client ID et l'URL de l'endpoint OIDC, puis installez le SDK officiel pour votre framework (`@logto/react`, `logto-python`, etc.). En 15 lignes de configuration, vos utilisateurs peuvent s'inscrire, se connecter avec des identifiants classiques ou des fournisseurs sociaux (Google, GitHub…), et récupérer un JWT signé que votre API vérifie en une ligne de middleware.

Oui. L'URL ENDPOINT de Logto est l'émetteur OIDC : elle est inscrite dans chaque jeton JWT émis par votre instance. Ce paramètre est fixé au premier démarrage et ne peut pas être modifié sans réinitialiser toute la base de données. Choisissez votre domaine définitif avant le déploiement. Si vous devez changer de domaine ultérieurement, supprimez le volume `logto_db`, redéployez avec le nouveau domaine, puis reconfigurez vos applications.

Ce sont trois outils d'authentification aux rôles distincts. Authelia est un proxy d'authentification (forward auth) : il ajoute MFA et SSO devant vos applications existantes sans modifier leur code, idéal pour protéger un Grafana ou un Nextcloud. Authentik est un fournisseur d'identité complet (OIDC, SAML, LDAP) pour centraliser le SSO de votre infrastructure self-hosted. Logto est une plateforme SDK d'authentification : vous l'intégrez dans le code de votre propre produit pour y ajouter l'inscription utilisateur, la connexion sociale, le MFA et les jetons OIDC, à la manière d'Auth0 ou Clerk.

La console d'administration Logto est liée sur le port 3002 en localhost uniquement pour des raisons de sécurité. Ouvrez un tunnel SSH depuis votre machine locale : `ssh -L 3002:127.0.0.1:3002 root@<ip-de-votre-vps>`, puis accédez à `http://localhost:3002/console` dans votre navigateur. Cette approche garantit que l'accès à la gestion des utilisateurs et des applications n'est possible que depuis une machine ayant les droits SSH sur le VPS.

Oui. Dans la console Logto, vous pouvez créer autant d'Applications que vous le souhaitez (SPA, Native, Backend, Machine-to-Machine). Chaque application obtient un Client ID unique et ses propres URIs de redirection. Un seul VPS Logto peut ainsi centraliser l'authentification de plusieurs projets : un front-end React, une API FastAPI, une app mobile Flutter, chacun avec ses propres rôles et politiques d'accès configurés indépendamment.

Cal.com est l'équivalent open-source de Calendly, auto-hébergé sur votre VPS. Les fonctionnalités sont très proches : types d'événements, synchronisation calendrier, vidéoconférence automatique, webhooks. La différence principale : avec Cal.com vos données de rendez-vous restent sur votre serveur, il n'y a pas de limite de plan (tous les types d'événements sont gratuits) et vous pouvez brancher vos propres clés API Google/Zoom. Calendly convient si vous ne voulez pas gérer de serveur ; Cal.com si vous voulez la maîtrise totale.

Non, pas sans réinitialiser l'instance. `NEXT_PUBLIC_WEBAPP_URL` est ancré dans chaque lien de réservation, le callback OAuth et les cookies NextAuth dès le premier démarrage. Changer le domaine après coup brise l'authentification de tous les utilisateurs existants. Choisissez votre domaine définitif avant de déployer. Si vous devez impérativement le changer, supprimez le volume `calcom_db`, redéployez avec le nouveau domaine, puis reconfigurez les intégrations Google Calendar et les webhooks.

Le SMTP est optionnel pour créer le compte admin (le wizard first-run ne le demande pas). Mais il est indispensable pour envoyer les confirmations de rendez-vous et les invitations calendrier aux invités — sans SMTP, Cal.com fonctionne mais les participants ne reçoivent aucune notification. Configurez-le dans Paramètres → E-mail après le premier démarrage. Un mzodeur SMTP transactionnel (Gmail App Password, Mailgun, Brevo) avec 100–300 envois/jour suffit pour la plupart des usages.

Dans Cal.com, allez dans Paramètres → Calendriers → Connecter Google Calendar. Vous serez redirigé vers la page d'autorisation Google — acceptez les permissions (lecture et écriture de calendrier). Cal.com lit vos événements existants pour bloquer les créneaux occupés et écrit automatiquement chaque nouveau rendez-vous dans votre Google Calendar. Pour que cela fonctionne, vous devez avoir configuré des identifiants OAuth Google dans vos variables d'environnement (`GOOGLE_API_CREDENTIALS`). Alternativement, Cal.com supporte CalDAV pour se connecter à Nextcloud Calendar, Fastmail ou tout serveur CalDAV.

Cal.com (Next.js) + PostgreSQL 16 tournent sur un VPS 2 Go RAM pour un usage individuel ou équipe de moins de 10 personnes, jusqu'à 300–500 rendez-vous/jour. Pour une équipe plus grande (> 10 utilisateurs, centaines de types d'événements) ou si vous hébergez d'autres apps sur le même VPS, préférez 4 Go RAM. Le disque est peu consommé : une instance active avec 10 000 réservations n'occupe que 500 Mo de base de données.

Non. Sans SMTP, vous pouvez quand même créer un compte et vérifier votre adresse e-mail : le lien de vérification s'affiche dans les journaux Docker. Exécutez `docker compose logs reactive-resume | grep verify` et cliquez sur l'URL affichée pour activer votre compte. Le SMTP reste optionnel et ne s'applique qu'aux fonctionnalités futures de notification par e-mail.

Oui. Dans la console Docker, définissez la variable d'environnement `DISABLE_SIGNUPS=true` et redémarrez le conteneur (`docker compose restart reactive-resume`). Les nouveaux visiteurs ne pourront plus créer de compte — seuls les comptes déjà créés pourront se connecter. Pour gérer les utilisateurs existants ou inviter de nouvelles personnes, passez par l'API REST ou les paramètres d'administration.

Non, sans une procédure de réinitialisation complète. Reactive Resume inscrit `APP_URL` dans les jetons JWT et les redirections OAuth au premier démarrage : changer l'URL casse toutes les sessions actives et toutes les URLs publiques de CV. Si vous devez absolument migrer vers un nouveau domaine, sauvegardez vos données (`docker exec db pg_dump -U postgres postgres > backup.sql`), supprimez les volumes Docker, redéployez avec le nouveau domaine et restaurez la sauvegarde — puis reconfigurez `APP_URL`. Planifiez votre domaine définitif avant le premier déploiement.

Non, depuis la version 5.1.0. La génération de PDF est entièrement côté navigateur via la bibliothèque `@react-pdf/renderer` : le PDF est produit directement dans votre navigateur, sans aucun processus Chrome, Puppeteer ou Browserless sur le serveur. Cela réduit l'empreinte mémoire du serveur d'environ 700 Mo et élimine une dépendance d'infrastructure. Si votre instance tourne encore sur une version antérieure à 5.1.0, mettez à jour l'image Docker (`docker pull amruthpillai/reactive-resume:latest && docker compose up -d`).

Deux volumes Docker portent toutes les données de l'instance. Pour une sauvegarde complète : `docker run --rm -v reactive_resume_db:/data -v $(pwd):/backup alpine tar czf /backup/rr-db.tar.gz /data` et `docker run --rm -v reactive_resume_data:/data -v $(pwd):/backup alpine tar czf /backup/rr-data.tar.gz /data`. Pour un dump SQL direct : `docker exec db pg_dump -U postgres postgres > backup.sql`. Restaurez en montant les archives sur des volumes vierges (`docker volume create reactive_resume_db && docker run --rm -v reactive_resume_db:/data -v $(pwd):/backup alpine tar xzf /backup/rr-db.tar.gz -C /`), puis redémarrez avec `docker compose up -d`. Assurez-vous que `APP_URL` est identique entre la source et la destination — sinon les jetons JWT seront invalides.

Comptez 4 Go de RAM au minimum et 8 Go pour être à l'aise : ClickHouse garde en mémoire ses index et ses marques, et une agrégation qui dépasse la mémoire disponible est interrompue plutôt que basculée sur le disque. Deux vCPU suffisent à paralléliser les requêtes, quatre sont confortables. C'est le disque qui décide vraiment : prévoyez 50 à 100 Go de SSD NVMe selon votre durée de rétention, sachant que la compression divise typiquement le volume brut par cinq à dix. Au repos, avant la moindre requête, l'installation occupe environ 270 Mo de RAM.

Non, et ce n'est pas son rôle. ClickHouse est une base analytique (OLAP) : elle est faite pour balayer et agréger de très grandes tables, pas pour servir les petites lectures et écritures transactionnelles d'une application web. Elle n'offre pas de vraies transactions, ses mises à jour et suppressions sont des mutations asynchrones plutôt que des opérations immédiates, et la lecture d'une ligne unique y est plus lente que dans PostgreSQL. Le schéma qui marche consiste à avoir les deux sur le même VPS : PostgreSQL ou MySQL pour l'application, ClickHouse pour les journaux, les métriques et le reporting.

L'installation crée un compte `admin` avec un mot de passe généré pour votre serveur, que vous relevez sur la fiche de l'application dans votre espace client ; le compte `default` livré sans mot de passe par l'image d'origine est retiré au démarrage. ClickHouse embarque sa propre console SQL de navigateur, sur le chemin `/play` : si vous avez attaché un domaine, elle répond sur `https://<votre-domaine>/play` ; sinon, ouvrez un tunnel avec `ssh -L 8123:127.0.0.1:8123 root@<ip-du-vps>` puis rendez-vous sur `http://localhost:8123/play`. Le serveur n'est jamais joignable directement sur l'adresse IP publique.

Deux niveaux, complémentaires. Au niveau de la machine, l'option de sauvegarde de votre VPS prend un instantané du disque entier, volumes Docker compris : c'est la reprise après sinistre, et c'est le filet à activer en premier. Au niveau de la base, ClickHouse dispose d'une commande `BACKUP TABLE … TO Disk(…)` qui produit une sauvegarde cohérente, exportable ensuite hors du serveur : c'est ce qu'il faut pour restaurer une seule table sans revenir en arrière sur tout le serveur. Évitez de copier `/var/lib/clickhouse` à chaud sans arrêter le service — les fusions de partitions en cours rendraient la copie incohérente.

Posez la rétention dans le schéma, pas dans un script de ménage. Déclarez un TTL au moment de créer la table — par exemple `TTL event_date + INTERVAL 90 DAY` — et partitionnez par mois avec `PARTITION BY toYYYYMM(event_date)` : ClickHouse fait alors tomber en arrière-plan les partitions entièrement expirées, ce qui ne coûte presque rien, au lieu d'effacer les lignes une à une. Insérez également par lots de plusieurs milliers de lignes plutôt que ligne à ligne, car les insertions unitaires créent une nuée de petites partitions et déclenchent des fusions coûteuses. Si les requêtes commencent à ralentir, regardez `system.parts` et `system.merges`.

Non, l'image officielle Node-RED n'active aucune authentification par défaut. L'éditeur est accessible à quiconque peut joindre le port 1880. Si vous attachez un domaine public, ajoutez `adminAuth` dans `/data/settings.js` avant d'exposer l'URL : renseignez un nom d'utilisateur et le hash bcrypt de votre mot de passe (obtenu via `node-red-admin hash-pw` dans le conteneur), puis redémarrez le service.

Oui. Le gabarit Marketplace monte un volume Docker nommé `node-red-data` sur `/data`. Node-RED y sauvegarde les flux et la configuration dès que vous cliquez sur « Deploy ». Un redémarrage du VPS ou du conteneur recharge automatiquement vos flux et reprend leur exécution. Pour sauvegarder vos automatisations, créez un instantané VPS depuis l'espace client ou exportez vos flux au format JSON depuis le menu de l'éditeur.

Dans l'éditeur, faites glisser un nœud « mqtt in » ou « mqtt out » depuis la palette. Double-cliquez dessus pour le configurer : renseignez l'adresse de votre broker (IP ou FQDN), le port (1883 par défaut, ou 8883 en TLS), et le topic à écouter ou à publier. Si votre broker exige une authentification, ajoutez-la dans la configuration du nœud. Node-RED maintient la connexion en permanence et reçoit les messages de vos capteurs en temps réel.

Depuis l'éditeur, ouvrez le menu principal (icône hamburger) puis « Manage palette » → onglet « Install ». Recherchez le nœud par son nom (ex. `node-red-contrib-telegrambot`, `node-red-node-mysql`). Cliquez sur « Install » : Node-RED télécharge le module npm, l'installe dans `/data/node_modules` et recharge la palette. Aucun redémarrage du conteneur n'est nécessaire. Si l'installation échoue, vérifiez que le VPS a accès à Internet (npm registry).

Node-RED et n8n s'adressent à des profils différents. Node-RED est orienté développeur bas niveau et IoT : il gère le protocole MQTT nativement, permet de câbler des traitements personnalisés via des fonctions JavaScript, et s'intègre facilement avec du matériel physique. n8n est davantage orienté automatisation métier : il propose des connecteurs prêts à l'emploi pour des centaines de services SaaS (Slack, Gmail, Airtable…), une interface plus orientée workflow no-code, et une gestion des erreurs par run. Les deux sont disponibles dans la Marketplace ServOrbit. Le bon choix dépend de votre usage : IoT/flux temps réel → Node-RED ; intégrations SaaS/workflow métier → n8n.

Oui. Quand le port de transfert (22000) n'est pas joignable directement, Syncthing bascule automatiquement sur les serveurs de relais mondiaux. La synchronisation continue de fonctionner avec une légère augmentation de latence. Pour des performances optimales, vous pouvez ouvrir le port 22000 dans le pare-feu VPS après le déploiement — c'est optionnel.

Installez Syncthing sur l'appareil (bureau, portable, téléphone), copiez son Identifiant d'appareil depuis son interface, puis ajoutez-le comme Appareil distant dans l'interface Syncthing du VPS. L'appareil verra une demande d'association à accepter. Après l'association, partagez les dossiers à synchroniser.

Non. L'interface web de Syncthing n'a aucune authentification par défaut. La toute première action après l'accès est de définir un nom d'utilisateur et un mot de passe dans Réglages > Interface graphique. L'authentification inter-appareils utilise automatiquement des certificats cryptographiques — aucun échange de clés manuel n'est nécessaire.

Syncthing se concentre exclusivement sur la synchronisation pair-à-pair chiffrée — sans accès web aux fichiers, sans calendrier, sans applications. Nextcloud propose une plateforme collaborative complète avec interface web et applications mobiles. Choisissez Syncthing si la confidentialité et la faible consommation de ressources sont prioritaires ; choisissez Nextcloud pour une plateforme cloud complète.

Windmill est livré avec `[email protected]` comme identifiant et `changeme` comme mot de passe. Changez le mot de passe immédiatement après la première connexion depuis Paramètres → Utilisateurs. L'e-mail et le mot de passe peuvent tous deux être modifiés.

n8n et Activepieces sont orientés vers la connexion de services SaaS avec des flux visuels à faible code. Windmill cible les développeurs qui veulent écrire du vrai code (Python, TypeScript, Go, Bash, SQL) orchestré, versionné et exposé automatiquement comme API et interface. Les deux approches sont complémentaires et toutes disponibles au Marketplace.

Un minimum de 2 vCPU et 4 Go de RAM est recommandé pour faire tourner le serveur Windmill, un worker par défaut et un worker natif. Ajoutez des conteneurs workers supplémentaires si vous exécutez de nombreux jobs Python simultanés ou des charges de calcul importantes.

Non pour un usage basique — l'interface est accessible via l'adresse IP ou le sous-domaine gratuit ServOrbit fourni à l'installation. Un nom de domaine est recommandé si vous souhaitez utiliser des fournisseurs OAuth pour l'authentification ou des webhooks nécessitant une URL HTTPS stable.

Oui. Le worker par défaut monte le socket Docker du VPS et fonctionne en mode privilégié, ce qui permet aux scripts d'exécuter des conteneurs Docker éphémères pour un traitement isolé. Cette capacité est disponible sur tous les VPS ServOrbit et n'exige aucune configuration supplémentaire.

Kaneo n'a pas d'identifiants par défaut. À la première ouverture de l'URL, un formulaire d'inscription s'affiche : saisissez votre nom, votre adresse e-mail et un mot de passe. Le premier compte créé obtient automatiquement les droits d'administrateur. Une fois l'équipe configurée, fermez l'inscription depuis Paramètres → Général.

Vikunja est un gestionnaire de tâches complet avec vues Kanban, Gantt, synchronisation CalDAV et tâches récurrentes — proche d'Asana ou TickTick. Kaneo est délibérément plus simple : tableaux Kanban, intégration GitHub et webhooks, sans les vues supplémentaires. Choisissez Kaneo si votre équipe vit dans le code et dans GitHub ; Vikunja si vous avez besoin de Gantt ou de synchronisation calendrier.

Non. Le déploiement ServOrbit configure Kaneo avec DISABLE_EMAIL_OTP_SIGN_IN=true : la connexion se fait par e-mail et mot de passe classiques, sans envoi d'e-mail. Un SMTP n'est utile que si vous souhaitez réactiver la connexion par lien magique (OTP) ou envoyer des notifications.

Non. Kaneo fonctionne sans domaine personnalisé : vous pouvez y accéder via l'URL assignée par ServOrbit (basée sur l'IP de votre VPS). Un domaine est recommandé pour une URL mémorisable et le partage facilité avec votre équipe, mais n'est pas une condition au déploiement.

Toutes les données Kaneo sont dans la base PostgreSQL. Pour créer une sauvegarde : `docker exec kaneo-postgres-1 pg_dump -U kaneo kaneo | gzip > kaneo-backup.sql.gz`. Pour restaurer : `gunzip -c kaneo-backup.sql.gz | docker exec -i kaneo-postgres-1 psql -U kaneo kaneo`. Le volume Docker `postgres_data` contient les fichiers bruts de PostgreSQL — vous pouvez aussi le sauvegarder directement.

Kestra est une plateforme d'orchestration de workflows open-source basée sur YAML. Contrairement à un script cron, chaque flow Kestra est versionné dans Git, observable (logs par tâche, historique d'exécution complet) et retryable automatiquement en cas d'échec. Vous déclenchez vos pipelines par cron, webhook ou appel API, et vous visualisez le graphe de dépendances de vos tâches dans une interface web dédiée.

n8n convient à l'automatisation API no-code : connecter des SaaS, réagir à des webhooks, remplir des feuilles Google. Kestra est taillé pour les pipelines data et ETL orientés code : workflows YAML versionnés dans Git, scripts Python/SQL/Bash, runners Docker isolés et traçabilité complète. Choisissez Kestra si votre équipe écrit du code et a besoin d'un audit trail reproductible ; préférez n8n si vous cherchez un automatiseur drag-and-drop pour des intégrations SaaS.

Kestra tourne sur la JVM et consomme typiquement 512 Mo à 1 Go de RAM au démarrage, auxquels s'ajoute PostgreSQL (environ 150 Mo). Un VPS à 4 Go de RAM et 2 vCPU suffit pour un usage léger à modéré (flows planifiés, quelques webhooks simultanés). Si vos flows lancent des tâches Docker (scripts Python isolés), prévoyez 8 Go de RAM. Minimum disque : 10 Go pour les données Kestra et les logs.

Oui. Kestra monte le socket Docker et peut lancer n'importe quelle image Docker comme tâche via le plugin `io.kestra.plugin.scripts.runner.docker.Docker`. Chaque script (Python, Bash, Go…) tourne dans son propre conteneur isolé avec ses dépendances, gardant le serveur hôte propre. Les résultats et les logs sont capturés par Kestra et visibles dans l'historique d'exécution.

ServOrbit configure Kestra avec l'authentification HTTP basique activée (identifiant `[email protected]` + mot de passe généré automatiquement). Le port 8080 est lié sur 127.0.0.1 — jamais exposé directement sur Internet. Pour renforcer la sécurité : attachez un domaine et activez HTTPS (nginx + Let's Encrypt géré par AWX) ; conservez votre mot de passe généré en lieu sûr ; et sauvegardez régulièrement la base PostgreSQL qui contient tous vos flows et l'historique d'exécution.

Garage est un magasin d'objets compatible S3, écrit en Rust par le collectif Deuxfleurs et publié sous licence AGPLv3. Un stockage objet vous donne une adresse où déposer et récupérer des fichiers par une API standard, plutôt qu'un disque monté : c'est ce qu'utilisent les outils de sauvegarde (restic, Borg), les applications qui conservent les fichiers de leurs utilisateurs, et les sites statiques servis derrière un CDN. Comme l'interface est le S3 standard, votre outillage existant fonctionne sans modification.

Non, et c'est un choix de conception assumé par le projet. L'administration passe par l'outil en ligne de commande `garage` et par une interface d'administration HTTP : le service reste petit et sa surface d'exploitation étroite. Des projets communautaires fournissent une interface dans le navigateur au-dessus de cette API si vous en voulez une. Vos identifiants S3, eux, sont affichés dans votre espace client ServOrbit.

Pour le cas courant — une adresse S3 pour des sauvegardes et des applications — oui. Garage est plus léger, et sa licence AGPLv3 ne réserve aucune fonction à une édition payante, contrairement à ce qui est arrivé à l'édition communautaire de MinIO (console d'administration retirée en 2025, puis arrêt de la publication des images Docker communautaires). Ce sont deux projets distincts et non un remplacement au caractère près : validez vos intégrations spécifiques avant de migrer.

Non, et c'est important de le dire clairement. Un déploiement mono-nœud conserve une seule copie de vos objets, sur un seul disque : il ne remplace pas une sauvegarde. La réplication de Garage est prévue pour une grappe de plusieurs machines, éventuellement réparties sur plusieurs sites — le même binaire la prend en charge quand vous ajoutez des nœuds. Tant que vous n'en avez qu'un, gardez votre discipline de sauvegarde habituelle.

Le service lui-même est très sobre : mesuré à environ 3 Mio de mémoire au repos sur un déploiement mono-nœud. Ce qui dimensionne votre serveur, c'est le volume de données que vous comptez stocker, pas Garage. Un VPS d'entrée de gamme suffit à faire tourner le daemon ; choisissez le disque en fonction de ce que vous y déposerez, et souvenez-vous qu'un nœud unique n'offre aucune redondance.

Whisper reconnaît 99 langues dont l'arabe, le français, l'anglais, l'espagnol et la darija marocaine. La transcription et la traduction vers l'anglais sont gérées par le même modèle, sélectionnées via le paramètre `task` (transcribe ou translate). Le modèle `base` par défaut couvre toutes ces langues ; `large-v3` améliore la précision sur les langues peu représentées.

Le modèle `base` (paramètre par défaut `ASR_MODEL=base`) tourne confortablement sur 1 Go de RAM et 1 vCPU. Il offre une précision solide pour la parole claire dans les langues courantes. Pour les enregistrements bruités ou les accents moins courants, `small` est plus précis et fonctionne bien avec 2 Go de RAM. Le modèle `large-v3` offre la meilleure précision mais requiert au moins 8 Go de RAM et est recommandé pour les offres VPS avec GPU.

Whisper est déployé comme une API REST avec une Swagger UI accessible sur `/docs` pour des tests interactifs. Il n'inclut pas d'application web autonome avec un formulaire de dépôt de fichiers. Pour intégrer Whisper dans un flux de travail sans coder, des outils comme n8n ou Make permettent d'appeler l'API `/asr` directement depuis un workflow automatisé. En ligne de commande, `curl -F "[email protected]" https://votre-adresse/asr?output=txt` suffit.

Oui. L'endpoint `/asr` est compatible avec l'API OpenAI de transcription : toute bibliothèque ou intégration qui appelle l'API OpenAI peut être redirigée vers votre instance en changeant simplement l'URL de base (`base_url`) et en supprimant la clé API. Le paramètre `output` est équivalent au paramètre `response_format` d'OpenAI. Attention : l'endpoint `/asr` n'est pas identique à `/v1/audio/transcriptions` d'OpenAI — certaines bibliothèques qui vérifient le chemin exact nécessitent une légère adaptation.

Non. Tout le traitement se fait en local sur votre VPS : les fichiers audio sont conservés en mémoire pendant la transcription et ne sont jamais écrits sur disque ni transmis à OpenAI ou à un service tiers. Whisper est un modèle de machine learning qui tourne entièrement dans votre conteneur. C'est précisément l'intérêt de l'hébergement autonome pour les contenus sensibles : entretiens, données médicales, enregistrements internes d'entreprise.

ToolJet affiche un assistant de configuration à la première ouverture. Il vous demande votre nom complet, votre adresse e-mail et un mot de passe. Le premier compte créé devient automatiquement le super-administrateur de l'espace de travail. Aucune confirmation par e-mail n'est requise — vous êtes redirigé directement vers l'éditeur après validation.

Non. Le serveur SMTP est entièrement optionnel. Le compte administrateur se crée via l'assistant dans le navigateur, sans aucune confirmation par e-mail. SMTP n'est utile que si vous souhaitez activer la réinitialisation de mot de passe par e-mail ou l'invitation de nouveaux utilisateurs par e-mail. Vous pouvez configurer SMTP plus tard dans Paramètres → Organisation sans avoir besoin de redéployer.

Non. ToolJet CE est licencié AGPL-3.0 — aucune limite de sièges, aucune limite d'applications, aucun frais par utilisateur. La seule contrainte est celle des ressources de votre VPS. Un VPS de 2 Go de RAM gère confortablement des dizaines d'utilisateurs simultanés et des dizaines d'applications. Pour des centaines d'utilisateurs ou des requêtes très lourdes, un VPS 4–8 Go de RAM est recommandé.

Non. ToolJet est configuré avec `requireDomain: false` sur ServOrbit. TOOLJET_HOST accepte aussi bien `http://votre-ip` que `https://votre-domaine.com`. Sans domaine, l'accès public n'est pas activé : utilisez un tunnel SSH — `ssh -L 8096:127.0.0.1:8096 root@votre-ip-vps` — puis ouvrez `http://localhost:8096` dans votre navigateur local. Associer un domaine ultérieurement ne nécessite que de mettre à jour `TOOLJET_HOST` dans le fichier `.env` et de redémarrer les conteneurs.

Retool est un service hébergé, à source fermée, facturé par utilisateur et par mois (environ 10 à 25 dollars par siège). ToolJet CE est entièrement open source (AGPL-3.0), auto-hébergé sur votre VPS et gratuit au-delà du coût d'hébergement. Les fonctionnalités sont comparables — canevas glisser-déposer, connecteurs de sources de données, actions JavaScript, contrôle d'accès par rôle, versionnement des applications. Retool dispose d'une bibliothèque de connecteurs légèrement plus grande ; ToolJet 3.0 (2026) a ajouté la construction d'applications par intelligence artificielle. Le principal avantage de ToolJet CE : toutes vos données métier restent dans votre infrastructure, sans aucun transfert vers un tiers.

Mautic est une plateforme d'automatisation marketing open-source : elle couvre les campagnes email, la segmentation des contacts, le lead scoring, les pages de destination et les workflows pilotés par événements. Listmonk est un outil de newsletters haute performance centré sur l'envoi en masse. Mautic est plus adapté si vous avez besoin de scénarios comportementaux (séquences drip, scoring, branchements conditionnels) ; Listmonk convient mieux si vous envoyez simplement la même newsletter à une grande liste.

Oui. Pour envoyer des campagnes, Mautic doit être connecté à un relay SMTP (Amazon SES, Mailgun, Brevo, SendGrid, Postmark…). Les plages IP des VPS cloud sont généralement bloquées par les principaux FAI et fournisseurs email, ce qui rend l'envoi direct impossible. Configurez votre relay dans Paramètres → Paramètres email dès la fin de l'assistant d'installation, et lancez un email de test pour confirmer la délivrabilité avant toute campagne.

Mautic n'impose aucune limite logicielle sur le nombre de contacts — le plafond réel est la capacité disque et mémoire de votre VPS. En pratique, un VPS 4 Go de RAM gère confortablement des bases de 50 000 à 100 000 contacts avec toutes les fonctionnalités actives (campagnes, tracking, scoring). Pour des listes de plusieurs centaines de milliers, ajustez `innodb_buffer_pool_size` dans MySQL (60 à 70 % de la RAM disponible) et envisagez un VPS dédié pour la base de données.

L'assistant d'installation de Mautic vérifie plusieurs prérequis PHP (extensions mbstring, pdo_mysql, intl, gd…). Si le check échoue sur ServOrbit, c'est généralement parce que le conteneur n'a pas encore eu le temps de démarrer complètement. Attendez 2 minutes et rechargez la page. Si le problème persiste, vérifiez les logs avec `docker compose logs mautic_web` depuis votre VPS et partagez-les avec le support via l'espace client.

Oui. Mautic propose une intégration native avec Salesforce, SugarCRM, HubSpot, Zoho et Pipedrive via ses plugins de CRM. Pour Twenty (qui figure également au catalogue ServOrbit), vous pouvez utiliser l'API REST de Mautic et de Twenty combinées avec un outil d'automatisation comme n8n pour synchroniser contacts et événements entre les deux plateformes.

Saisissez `admin` comme identifiant et le mot de passe généré ADMIN_PASSWORD visible dans votre espace client ServOrbit (onglet identifiants de l'application). L'authentification est activée dès le premier boot — l'instance n'est jamais accessible sans identifiants.

Non. Sans domaine, accédez via un tunnel SSH : `ssh -L 7860:127.0.0.1:7860 root@votre-ip-vps`, puis ouvrez `http://localhost:7860` dans votre navigateur. Associer un domaine active l'accès HTTPS direct — ServOrbit configure automatiquement le proxy nginx et le certificat TLS.

Oui. Utilisez le composant Ollama sur le canevas et renseignez l'URL de base. Si Ollama est installé sur le même VPS via le Marketplace ServOrbit, il est joignable depuis le conteneur LangFlow à `http://host.docker.internal:11434`.

Les deux sont des constructeurs visuels de pipelines LLM. LangFlow est Python natif et cible les développeurs qui veulent écrire des composants personnalisés ou exporter du code Python propre depuis leurs flux. Flowise est davantage orienté no-code, avec un canevas plus accessible. Les deux partagent l'écosystème LangChain mais ont divergé en profil d'utilisateur et en outillage.

Exportez chaque flux individuellement depuis le menu du canevas (export JSON). Pour une sauvegarde complète, copiez la base SQLite : `docker cp langflow-langflow-1:/app/data/langflow.db ./langflow-backup.db`. Restaurez en recopiant le fichier vers la même destination et en redémarrant le conteneur.

Linkwarden n'a pas d'identifiants par défaut. À la première ouverture, cliquez sur « S'inscrire » et créez votre compte avec une adresse e-mail et un mot de passe — le premier compte devient automatiquement propriétaire de l'instance. Aucune confirmation par e-mail n'est requise. Rendez-vous ensuite dans Paramètres → Utilisateurs pour fermer les inscriptions si vous souhaitez un accès par invitation uniquement.

Oui. Linkwarden utilise NextAuth.js pour la gestion des sessions, qui ancre l'URL publique (`NEXTAUTH_URL`) dans les cookies au premier démarrage. Le domaine doit être choisi et le DNS configuré avant de lancer le déploiement. Le modifier après coup impose de réinitialiser la base de données et de réinviter tous les membres — il est préférable de trancher cette question avant de commencer.

Pour une équipe de 5 à 15 personnes, **2 vCPU et 2 Go de RAM** sous Ubuntu 24.04 offrent une marge confortable. L'image Docker de Linkwarden embarque Playwright avec Chromium pour l'archivage automatique des pages — cela porte la consommation à environ 400–600 Mo en charge. Sur un VPS 1 Go, vous pouvez désactiver cette fonctionnalité en posant `DISABLE_NEXT_GENERATION_ARCHIVAL=true` depuis votre espace client, ce qui fait descendre l'empreinte sous 256 Mo.

Les deux gèrent des marque-pages, mais avec des angles distincts. **Karakeep** (ex-Hoarder) est orienté usage personnel : tagging automatique par IA, recherche sémantique et application mobile PWA. **Linkwarden** est orienté collaboration d'équipe : collections partagées, permissions granulaires par membre (lecteur/éditeur/propriétaire), fils de commentaires et extension navigateur multi-utilisateur. Si vous cherchez à centraliser la veille d'une équipe ou d'une agence, Linkwarden est le bon choix ; pour un usage individuel enrichi par l'IA, Karakeep est mieux adapté.

Par défaut, toute personne connaissant l'URL de votre instance peut s'inscrire. Pour fermer les inscriptions, définissez la variable d'environnement `DISABLE_NEW_SIGN_UPS=true` depuis votre espace client ServOrbit. Les membres existants continuent d'accéder à l'instance ; seuls les propriétaires pourront désormais créer des comptes depuis le panneau d'administration. Pour les rôles et permissions par collection, utilisez le menu Paramètres → Utilisateurs.

DrawDB est un éditeur de diagrammes entité-relation (ERD) open source (AGPL-3.0, ~39 k étoiles). Il permet de modéliser visuellement des tables de base de données, de définir des relations FK et d'exporter des scripts DDL SQL pour MySQL, PostgreSQL, SQLite, MariaDB et SQL Server — entièrement dans le navigateur, sans installation ni compte requis.

Non. DrawDB conserve l'état du diagramme dans le localStorage de votre navigateur. Le conteneur Nginx ne traite aucune donnée — il distribue uniquement des fichiers statiques. Pour persister votre schéma entre navigateurs ou postes, exportez le fichier JSON et committez-le dans Git.

DrawDB génère du DDL SQL pour MySQL, PostgreSQL, SQLite, MariaDB et Microsoft SQL Server. Sélectionnez le dialecte dans le menu Exporter → SQL avant de copier le script. Le DDL inclut les CREATE TABLE avec types de colonnes, contraintes NOT NULL, PRIMARY KEY, FOREIGN KEY et DEFAULT.

Oui. Collez vos instructions CREATE TABLE dans la fonction d'import SQL de DrawDB. Il reconstruit automatiquement le diagramme ERD correspondant, relations FK comprises. Idéal pour documenter une base héritée ou visualiser rapidement un schéma inconnu avant de le modifier.

Non. DrawDB fonctionne sans domaine : l'interface est accessible directement sur le port indiqué dans votre espace client ServOrbit (3060 dans le catalogue, mais le port effectif peut différer si celui-ci était déjà pris). Sans domaine, aucun accès public direct n'est disponible : ouvrez un tunnel SSH (`ssh -L 3060:127.0.0.1:3060 root@<votre-ip>`) et accédez à `http://localhost:3060`.

La connexion par défaut est [email protected] avec le mot de passe MyPassword. Changez les deux immédiatement après votre première connexion dans Administration → Votre profil.

Non. Mealie fonctionne sur une adresse IP brute. Un domaine est recommandé pour un accès depuis Internet avec un certificat TLS valide, mais n'est pas requis pour un usage local ou via VPN.

Mealie stocke recettes, images et paramètres dans le volume /app/data de votre VPS. Sauvegardez régulièrement ce dossier pour protéger votre bibliothèque. Vous pouvez aussi exporter toute la bibliothèque en JSON depuis l'interface.

Oui. Mealie gère plusieurs utilisateurs avec des rôles distincts : administrateur, utilisateur (peut ajouter et modifier des recettes) et lecteur (consultation uniquement). Créez les comptes depuis Administration → Utilisateurs.

Mealie analyse le balisage JSON-LD Recipe de la page cible et extrait automatiquement le titre, les ingrédients, les étapes et la photo principale. Pour les sites sans balisage structuré, un scraper de secours prend le relais. Si le résultat est incomplet, l'éditeur manuel vous permet de compléter les champs.

Seafile se concentre exclusivement sur la synchronisation de fichiers ; il n'inclut pas de calendrier, de messagerie ni de magasin d'applications. Cela le rend nettement plus léger — généralement deux fois moins de RAM que Nextcloud sur le même VPS. Choisissez Seafile pour des performances brutes de synchronisation, Nextcloud si vous avez besoin d'une suite de collaboration complète.

Syncthing est pair-à-pair : chaque appareil se synchronise directement avec les autres, sans serveur central. Seafile est client-serveur : tous les appareils passent par le VPS central. Seafile supporte plusieurs utilisateurs, les permissions, le partage par lien et une interface web ; Syncthing est conçu pour des cas d'usage mono- ou bi-appareils sans gestion de comptes.

Oui. Lors de la création d'une bibliothèque, vous pouvez opter pour le chiffrement côté client. La phrase de passe ne quitte jamais votre appareil — le serveur ne stocke que des blocs chiffrés et ne peut pas récupérer vos fichiers même en cas d'accès non autorisé au VPS. Attention : si vous perdez la phrase de passe, les fichiers sont définitivement irrécupérables.

IT-Tools est une application web open source (MIT, ~25 k étoiles) qui regroupe plus de 60 utilitaires pour développeurs — décodeur JWT, générateurs de hachage SHA-256/MD5, UUID v1/v4, encodeur base64, testeur de regex, formateur JSON et bien d'autres. Tout le traitement s'effectue dans le navigateur : aucune donnée n'est envoyée à un serveur.

Non. Chaque outil IT-Tools exécute ses calculs en JavaScript dans votre navigateur. Le conteneur Nginx ne distribue que les fichiers statiques de l'application — il ne reçoit, ne traite et ne transmet jamais vos entrées. Vos jetons JWT, clés API et hachages restent entièrement sur votre machine.

Non. IT-Tools fonctionne sans domaine : l'interface est accessible directement sur le port indiqué dans votre espace client ServOrbit (3765 dans le catalogue ; le port effectif peut différer si celui-ci était déjà pris). Sans domaine, ouvrez un tunnel SSH (`ssh -L 3765:127.0.0.1:3765 root@<votre-ip>`) et accédez à `http://localhost:3765`.

IT-Tools n'a pas d'authentification intégrée. Pour restreindre l'accès : (1) placez-le derrière un reverse proxy (Nginx ou Caddy) avec HTTP Basic Auth ; (2) exposez-le uniquement sur un réseau VPN privé ; ou (3) utilisez le pare-feu ServOrbit pour n'ouvrir le port qu'à vos plages d'IP autorisées.

IT-Tools est extrêmement léger : l'image Docker fait environ 20 Mo, et le conteneur Nginx n'utilise que quelques mégaoctets de RAM au repos. Il ne requiert aucune base de données et s'exécute confortablement sur n'importe quel VPS de 512 Mo sans impacter les autres services.

Django Stack est un template VPS préconfigurée qui installe Python 3.12, Gunicorn, Nginx et PostgreSQL 16 automatiquement. Il est conçu pour les développeurs Python qui souhaitent déployer une application Django en production sans configuration manuelle des composants serveur.

Python 3.12 depuis le PPA deadsnakes. Cette version apporte des gains de performance de 30 à 60 % par rapport à Python 3.10 sur les cycles de requêtes Django typiques. Vous pouvez installer d'autres versions Python en parallèle via le PPA deadsnakes et utiliser virtualenv pour choisir la version par projet.

Installez Redis avec `apt install redis-server`, ajoutez `celery` à votre fichier requirements.txt, puis créez une configuration Supervisor pour votre worker Celery dans /etc/supervisor/conf.d/. Django Stack est conçu pour héberger Gunicorn et des workers Celery sur le même VPS sans configuration supplémentaire des packages système.

Oui. Créez un virtualenv par projet dans /var/www/, un bloc serveur Nginx par domaine (chacun pointant vers un port Gunicorn distinct), et une configuration Supervisor par processus Gunicorn. Chaque projet est ainsi isolé — ses dépendances, son processus et sa configuration ne se perturbent pas.

2 Go pour une application Django avec PostgreSQL et 3 workers Gunicorn. Prévoyez 4 Go si vous ajoutez des workers Celery ou un cache Redis chargé. Chaque worker Gunicorn consomme environ 100 à 200 Mo selon la taille de votre application ; ajustez le nombre de workers en conséquence.

Bytebase est une plateforme DevOps open source pour les bases de données (licence MIT) qui apporte un workflow de revue structuré aux migrations SQL. Elle permet de soumettre, valider et déployer des changements de schéma de façon sécurisée, avec 200+ règles de lint automatiques, un journal d'audit complet et une intégration GitOps pour PostgreSQL, MySQL, MariaDB, MongoDB, Redis, ClickHouse et plus de 20 autres moteurs.

Bytebase supporte plus de 20 moteurs de bases de données : PostgreSQL, MySQL, MariaDB, MongoDB, Redis, ClickHouse, SQL Server, Oracle, TiDB, Snowflake, Spanner, OceanBase et d'autres. Il se connecte à vos serveurs de base de données existants en tant que client — il ne remplace pas votre infrastructure de données, il l'orchestre.

Oui. La Community Edition est gratuite, sans limite d'utilisateurs, et couvre l'intégralité du workflow de gestion des changements, l'éditeur SQL et le journal d'audit. Les fonctionnalités Enterprise (SSO, RBAC fin, masquage des données, workflows de validation personnalisés) nécessitent un abonnement payant. Sur ServOrbit, vous payez uniquement le VPS — Bytebase lui-même ne coûte rien.

Bytebase fonctionne confortablement avec 1 Go de RAM. Le conteneur unique inclut une instance PostgreSQL embarquée — aucun serveur de base de données externe n'est nécessaire. Pour un usage en production avec de nombreux utilisateurs simultanés ou des bases de données volumineuses, 2 Go sont recommandés.

Non. Bytebase est accessible sans domaine via un tunnel SSH — `ssh -L 8080:127.0.0.1:8080 root@<ip>` puis `http://localhost:8080`. Cette configuration convient pour un usage administrateur individuel. Dès que plusieurs utilisateurs doivent y accéder simultanément, attachez un domaine : ServOrbit configure alors nginx et le certificat TLS automatiquement.

Oui. Gotenberg est stable, MIT, utilisé en production par des milliers d'équipes. Il génère des PDF en isolant chaque requête dans un processus Chromium ou LibreOffice séparé — un crash de conversion n'affecte pas les suivantes. Dimensionnez la RAM selon le nombre de requêtes simultanées : comptez ~200 Mo par rendu Chromium concurrent.

Oui. Gotenberg utilise Chromium complet : toutes les polices web (Google Fonts via URL, ou police locale intégrée en base64), les variables CSS, les media queries `@print`, les flexbox et grids sont honorés. Pour les polices locales, incorporez-les en `@font-face` avec le fichier en pièce jointe dans le formulaire multipart.

Gotenberg supporte plus de 20 formats via LibreOffice : DOCX, XLSX, PPTX (et leurs équivalents OpenDocument ODT, ODS, ODP), RTF, TXT, CSV et bien d'autres. La liste complète est dans la documentation officielle. Envoyez le fichier en multipart vers `/forms/libreoffice/convert` — la sortie est toujours un PDF.

Non. Gotenberg est sans état (stateless) : les fichiers téléversés et les PDF générés sont stockés dans un répertoire temporaire puis supprimés immédiatement après la réponse. Aucune base de données, aucun stockage persistant. Vos documents ne transitent que sur votre propre infrastructure.

Le minimum absolu est 512 Mo, mais Chromium consomme ~150–250 Mo par requête concurrente. Pour une utilisation applicative typique (1–3 PDF simultanés), 1–2 Go suffisent. Pour des workloads intensifs (10+ PDF concurrents ou documents LibreOffice volumineux), préférez 4 Go ou plus. Gotenberg ne met pas en cache les contextes Chromium : chaque requête démarre un nouveau processus.

FastAPI est async natif avec validation Pydantic et documentation OpenAPI auto-générée — idéal pour les API REST et microservices. Django est un framework full-stack avec admin intégrée, ORM et moteur de templates — mieux adapté aux applications monolithiques. Pour un backend API pur, FastAPI est plus rapide à développer et à exécuter.

Utilisez Gunicorn comme gestionnaire de processus avec le worker UvicornWorker : `gunicorn main:app -k uvicorn.workers.UvicornWorker --workers 4 --bind 127.0.0.1:8000`. Le nombre de workers recommandé est (2 × vCPU) + 1. Cela combine la gestion de processus de Gunicorn (redémarrage automatique, rechargement progressif) et la performance async d'Uvicorn.

Oui. FastAPI n'impose aucune base de données. Utilisez SQLite, MySQL, MongoDB ou n'importe quelle base via SQLAlchemy (sync ou async) ou Motor pour MongoDB. Le template installe PostgreSQL 16 pour les projets qui en ont besoin — ignorez-le si vous partez sur une autre base.

FastAPI génère automatiquement /docs (Swagger UI) et /redoc (ReDoc) pour chaque endpoint défini. Accédez à https://votre-domaine.com/docs après déploiement. En production, restreignez ces endpoints par un middleware d'authentification ou un préfixe de routeur si votre API n'est pas publique.

1 Go de RAM suffit pour une API FastAPI légère sans base de données sur le même VPS. Prévoyez 2 Go avec PostgreSQL, 4 Go si vous ajoutez Celery et des workers Redis. Chaque worker Uvicorn/Gunicorn consomme environ 50 à 150 Mo selon les dépendances chargées au démarrage.

Plane est l'alternative open source (AGPL-3.0) à Jira et Linear, auto-hébergée sur votre VPS. Les fonctionnalités sont très proches : issues avec états personnalisés, cycles (sprints) avec burndown, modules (epics), pages wiki et vues analytiques. La différence principale : avec Plane, vos données restent sur votre serveur, il n'y a pas de facturation par siège et vous contrôlez entièrement la rétention. Jira et Linear conviennent si vous ne voulez pas gérer de serveur ; Plane si vous voulez la maîtrise totale à coût fixe.

La configuration minimale est de 2 vCPU et 4 Go de RAM sous Ubuntu 24.04 pour une équipe de moins de 10 personnes. Pour une équipe plus grande ou un usage intensif, visez 4 vCPU et 8 Go de RAM. Plane s'appuie sur six composants (Django, React, Celery, PostgreSQL 16, Redis 7, RabbitMQ et MinIO) — tous gérés automatiquement par le template ServOrbit. Un domaine propre est requis pour le bon fonctionnement des redirections et des certificats TLS.

Plane inclut un importateur Jira natif : allez dans Paramètres → Importateurs → Jira, saisissez l'URL de votre instance Jira et un token API Atlassian, sélectionnez le projet à importer et lancez. Les epics deviennent des modules, les sprints des cycles, et les issues conservent leurs descriptions, libellés, priorités et statuts. L'import est non destructif : rien n'est modifié ni supprimé dans Jira pendant la migration. Un import CSV est également disponible pour migrer depuis Linear ou d'autres outils.

Oui. Les cycles sont l'équivalent Plane des sprints : chaque cycle a une date de début, une date de fin, un graphique de burndown et un report automatique des issues non terminées au cycle suivant. La vue Gantt est disponible au niveau projet et au niveau workspace — elle affiche les dépendances entre issues sous forme de chronologie interactive et permet de glisser-déposer les échéances directement sur le diagramme pour les ajuster.

Oui. Installez l'application GitHub Plane (Paramètres → Intégrations → GitHub) sur votre dépôt, puis référencez les issues dans vos messages de commit avec la syntaxe `fix(#123)`, `closes #456` ou `ref #789`. Plane transitionnera automatiquement l'issue selon le mot-clé utilisé. Les pull requests sont également liées aux issues dans la barre latérale, et les branches créées depuis Plane sont nommées d'après l'identifiant de l'issue pour faciliter le traçage.

FileBrowser démarre avec admin comme nom d'utilisateur et admin comme mot de passe. Changez ce mot de passe dès la première connexion depuis Paramètres → Utilisateurs pour sécuriser votre instance.

Oui. FileBrowser est accessible via l'adresse IP de votre VPS et le port attribué (8085 par défaut). Pour un accès chiffré depuis Internet, associez un nom de domaine : la recette du Marketplace ServOrbit configure alors le proxy inverse et le certificat HTTPS automatiquement.

Oui. FileBrowser monte deux volumes Docker indépendants : l'un pour les fichiers qu'il sert (/srv), l'autre pour sa base de données SQLite (/database). Les deux persistent après les redémarrages de conteneur, les mises à jour de l'image et les redémarrages du serveur.

Oui. Depuis Paramètres → Utilisateurs, créez autant de comptes que nécessaire. Chaque compte dispose de son propre répertoire accessible (home directory) et d'un quota de stockage optionnel. Les droits sont gérés par répertoire : un utilisateur peut n'avoir accès qu'à une partie de l'arborescence.

FileBrowser offre une authentification par compte et un contrôle d'accès par répertoire. Pour chiffrer les échanges, placez-le derrière le proxy HTTPS inclus dans la recette du Marketplace ServOrbit (Let's Encrypt automatique avec votre domaine). Les liens de partage public peuvent être temporaires (date d'expiration) ou permanents, et sont sécurisés par lien — un lien révoqué n'est plus accessible.

Go (Gin) Stack est un template VPS préconfiguré qui installe Go 1.22+ depuis le binaire officiel go.dev, Nginx et PostgreSQL 16 automatiquement. Il est conçu pour les développeurs Go qui souhaitent déployer une API Gin en production sans configuration manuelle des composants serveur.

Non. Si vous compilez avec CGO_ENABLED=0 GOOS=linux GOARCH=amd64 sur votre poste, le binaire résultant est 100 % statique et s'exécute sans Go sur le serveur. Le template installe Go 1.22+ pour vous permettre de compiler directement sur le VPS si vous le préférez, mais ce n'est pas nécessaire pour exécuter des binaires pré-compilés.

Oui. Le template installe la chaîne d'outils Go, Nginx et PostgreSQL — pas le framework. Utilisez Echo, Chi, Fiber ou la bibliothèque standard net/http à la place. Gin est recommandé dans la documentation pour son adoption et son routeur à zéro allocation, mais le template est agnostique au niveau du framework.

1 Go est confortable pour une API Gin sans base de données. Ajoutez 1 Go si PostgreSQL tourne sur le même VPS. Un process Gin consomme généralement 15 à 30 Mo de RAM en veille ; le pic mémoire dépend de votre logique de handler et de la taille des caches en mémoire.

L'approche recommandée est une unité systemd : ExecStart pointant vers votre binaire, Restart=always pour la récupération automatique en cas d'échec, et EnvironmentFile pour les secrets. Cela donne journalisation centralisée, limites de ressources et ordonnancement des dépendances (ex : après PostgreSQL). Alternativement, exécutez votre binaire dans un conteneur Docker avec --restart unless-stopped.

Next.js Stack cible les applications React (Next.js), Nuxt Stack cible Vue.js (Nuxt 3). La boîte à outils installée est identique — Node.js LTS, PM2, Nginx, PostgreSQL — mais les frameworks, leur système de build et leurs fichiers de sortie sont différents.

Oui. Chaque application Next.js tourne comme un processus PM2 distinct sur un port différent (3000, 3001, 3002…). Nginx route les requêtes par nom de domaine et proxifie vers le bon processus. Un VPS de 4 Go RAM peut héberger 3 à 5 sites légers simultanément.

Oui. Le template installe Node.js LTS et PM2 qui font tourner n'importe quelle version de Next.js, y compris l'App Router. L'option `output: 'standalone'` dans `next.config.js` fonctionne identiquement avec l'App Router et le Pages Router.

L'ISR de Next.js stocke les pages régénérées dans `.next/cache` sur le disque du VPS. Ce cache persiste entre les rechargements PM2 (zero-downtime). Pour éviter de le vider à chaque déploiement, lancez `pm2 reload` plutôt que `pm2 restart`. Pour plusieurs instances, utilisez un handler de cache Redis.

Un VPS est préférable quand vous avez du trafic SSR important (facturation à l'invocation sur Vercel), des workers ou des crons en arrière-plan, plusieurs projets à mutualiser, ou une exigence de coût fixe. Vercel reste le meilleur choix pour un prototype rapide ou un site léger sans processus annexes.

Typesense (C++, GPLv3) et Meilisearch (Rust, MIT) sont deux moteurs de recherche open source tolérants aux fautes avec REST API, disponibles tous les deux au Marketplace ServOrbit. Typesense est optimisé pour les exigences de latence strictes et inclut la recherche vectorielle / sémantique native. Meilisearch est plus simple à configurer et privilégié pour les petits volumes. Les deux peuvent coexister sur le même VPS — chacun expose son propre port et son propre jeu de clés d'API.

Ne diffusez jamais la clé admin dans le navigateur. Générez une clé search-only avec portée restreinte via l'API Typesense : POST /keys avec `{"actions":["documents:search"],"collections":["ma-collection"],"description":"clé front-end"}` en utilisant la clé admin en en-tête. La clé search-only générée ne peut ni modifier les collections ni lire d'autres index. Exposez-la dans votre bundle JavaScript ; gardez la clé admin exclusivement côté serveur. Vous pouvez aussi ajouter des filtres embarqués pour restreindre les résultats par tenant ou catégorie, non contournables par le client.

Typesense v0.25+ prend en charge les champs de type `float[]` pour stocker des embeddings à côté des champs texte. Déclarez un champ `embedding` de type `float[]` dans votre schéma de collection, puis envoyez vos vecteurs (générés par OpenAI text-embedding-3-small, un modèle local Ollama, etc.) dans chaque document. Pour une requête hybride : utilisez `vector_query` avec votre vecteur de requête et combinez avec `q` pour le ranking BM25 — Typesense fusionne les scores selon un paramètre `alpha` réglable. Aucune base vectorielle séparée (Qdrant, Weaviate) n'est nécessaire pour ce cas d'usage.

Typesense charge ses index en RAM : planifiez environ 1 Mo par tranche de 1 000 documents avec 3 à 5 champs texte. Pour un catalogue de 100 000 produits, comptez ~300 Mo de RAM dédiée ; pour un million de documents, ~3 Go. Un VPS 1 Go suffit pour les projets courants ; passez à 2 ou 4 Go si vous dépassez 500 000 documents ou activez des champs d'embedding (768 à 1 536 dimensions par document = 3 à 6 Mo par 1 000 documents). ServOrbit permet le changement de plan en ligne sans réinstallation : les données restent sur leur volume persistant.

Typesense est compatible avec l'écosystème Algolia InstantSearch : installez `typesense-instantsearch-adapter` (`npm install typesense-instantsearch-adapter instantsearch.js`) et configurez l'adaptateur avec l'URL de votre instance et une clé search-only. Vous obtenez une barre de recherche avec suggestions, facettes, pagination et mise en évidence des termes — sans modifier votre front-end InstantSearch existant. Pour React, utilisez `react-instantsearch` avec le même adaptateur. Pour Vue, `vue-instantsearch`. L'adaptateur translate les appels InstantSearch vers l'API Typesense de manière transparente.

Non. Mailpit est un serveur piège : il accepte toutes les connexions SMTP sur le port 1025 et stocke chaque message dans sa base SQLite locale sans jamais le transmettre. Aucun e-mail ne rejoint une vraie boîte de réception, peu importe l'adresse destinataire configurée dans votre application.

Dans les variables d'environnement ou le fichier de configuration de votre application, définissez l'hôte SMTP sur 127.0.0.1 et le port sur 1025. Aucune authentification, aucun TLS requis par défaut. En Laravel : MAIL_HOST=127.0.0.1, MAIL_PORT=1025, MAIL_ENCRYPTION=null. En Symfony : MAILER_DSN=smtp://127.0.0.1:1025. En Node.js (Nodemailer) : host: '127.0.0.1', port: 1025, secure: false. Votre application doit tourner sur le même VPS que Mailpit pour atteindre le serveur via le loopback.

MailHog n'est plus maintenu depuis 2020 et porte une faille XSS stockée non corrigée (Exploit-DB 50971) : un e-mail contenant du JavaScript malveillant peut compromettre l'interface web. Mailpit est son successeur actif, installé par défaut dans Laravel Sail (depuis v11) et DDEV (depuis v1.22). Il ajoute la recherche plein texte, la notation anti-spam avec les règles SpamAssassin, les vérifications de compatibilité HTML par client mail, une API REST documentée pour la CI, et le support POP3 — le tout dans un binaire Go de moins de 50 Mo de RAM.

Mailpit expose une API REST sur le même port que l'interface web (par défaut 8025). Les points d'entrée principaux : GET /api/v1/messages (liste les e-mails avec pagination), GET /api/v1/message/{ID} (détail d'un e-mail), DELETE /api/v1/messages (vide la boîte), GET /api/v1/search?query=... (recherche plein texte). En PHPUnit (Laravel) : utilisez Http::get('http://127.0.0.1:8025/api/v1/messages') pour vérifier qu'un e-mail a bien été envoyé après une action. En Jest/Vitest : fetch('http://127.0.0.1:8025/api/v1/messages'). Aucune clé d'API requise par défaut.

Par défaut, Mailpit conserve les 500 derniers messages. Lorsque la limite est atteinte, les messages les plus anciens sont automatiquement supprimés pour faire de la place aux nouveaux. Pour modifier la limite : ajoutez la variable d'environnement MP_MAX_MESSAGES dans votre configuration. Mettez MP_MAX_MESSAGES=0 pour une rétention illimitée (attention à l'espace disque), ou une valeur entière pour définir un nombre précis de messages. Les messages sont stockés dans une base SQLite sur le volume mailpit-data, ce qui les rend persistants entre les redémarrages du conteneur.

Le Direct Play signifie que le client lit le fichier original tel quel, sans conversion : usage CPU quasi nul sur le serveur. Le transcodage convertit le flux à la volée quand le client ne supporte pas le format d'origine — cela consomme du CPU. Privilégiez des formats H.264/AAC dans MP4 pour maximiser le Direct Play sur la majorité des appareils.

Des applications officielles gratuites existent pour iOS, Android, Android TV, Roku et Amazon Fire TV. Kodi propose un plugin Jellyfin officiel. La plupart des smart TV récentes (Samsung, LG) sont aussi couvertes. L'interface web fonctionne sur n'importe quel navigateur sans installation.

L'espace nécessaire dépend de votre bibliothèque. En guide approximatif : 1 Go par film SD de 90 min, 4 à 8 Go pour un film HD (1080p), 20 à 50 Go pour un film 4K. Jellyfin lui-même utilise environ 500 Mo pour sa configuration et ses métadonnées. Le stockage des médias est votre principale contrainte.

Jellyfin est 100 % gratuit et open source (GPL-2.0) : aucune fonctionnalité payante, pas de compte obligatoire, pas de télémétrie. Plex est partiellement propriétaire : certaines fonctionnalités (sync hors ligne, lecteur TV avancé) nécessitent un abonnement Plex Pass. Jellyfin s'installe sans compte ; Plex impose un compte serveur lié au service Plex.

Oui. En hébergeant Jellyfin sur un VPS ServOrbit, vous bénéficiez d'une IP publique dédiée et d'une bande passante montante supérieure à une connexion résidentielle. Configurez Nginx en reverse proxy avec un certificat TLS (Let's Encrypt), et votre interface Jellyfin sera accessible depuis n'importe quel appareil ou navigateur dans le monde.

Portainer CE (Community Edition) est entièrement open source sous Apache 2.0 et couvre la grande majorité des cas d'usage : gestion de stacks Docker Compose, contrôle d'accès par équipe, multi-hôtes, logs en direct et terminal interactif. Portainer BE (Business Edition) ajoute des fonctions entreprise : RBAC granulaire, déploiements déclenchés par Git et journaux d'audit avancés. Sur ServOrbit, vous obtenez Portainer CE — gratuit, illimité, aucune licence à gérer.

Portainer doit être exposé uniquement derrière HTTPS avec un mot de passe administrateur solide. Il monte le socket Docker (`/var/run/docker.sock`), ce qui équivaut par définition à un accès root sur l'hôte. Sur ServOrbit, le port 9000 n'est publié que sur la boucle locale — il n'est jamais directement accessible depuis Internet sans passer par le vhost HTTPS de nginx. N'exposez jamais Portainer en HTTP nu.

Portainer couvre toute la surface Docker : conteneurs isolés, images, réseaux, volumes, Swarm et Kubernetes. Dockge se concentre exclusivement sur les stacks Compose et s'apprend plus vite pour ce cas précis — il est aussi plus léger. Komodo cible le GitOps multi-serveurs avec un pipeline de déploiement complet. Si votre objectif est une vue visuelle complète de tout ce que Docker gère sur un VPS — y compris des conteneurs lancés hors Compose — Portainer est l'outil le plus large.

Oui. Installez l'agent Portainer sur chaque VPS supplémentaire et connectez-le à votre instance principale via le menu Environments. Tous les hôtes apparaissent dans une liste unifiée et se pilotent depuis une interface unique. Chaque VPS continue d'exécuter ses conteneurs localement — il n'y a pas d'ordonnanceur central. C'est une vue consolidée de plusieurs machines, pas un orchestrateur de cluster.

Ouvrez un tunnel SSH depuis votre machine locale : `ssh -L 9000:127.0.0.1:9000 root@<ip-vps>`, puis naviguez vers `http://localhost:9000` dans votre navigateur. Le tunnel relaie le port de façon sécurisée sans exposer Portainer à Internet. Avec un nom de domaine, nginx proxifie le port 9000 derrière HTTPS avec un certificat émis automatiquement et vous accédez directement à l'interface via l'URL choisie.

LibreChat est une interface de chat open source auto-hébergée qui vous permet d'utiliser plusieurs fournisseurs IA (OpenAI, Anthropic, Google Gemini, Ollama) depuis une UI unifiée. Contrairement à ChatGPT, LibreChat tourne sur votre propre VPS : vos conversations, clés API et historique restent dans votre MongoDB, sans transmission à des tiers.

LibreChat nécessite au minimum 2 Go de RAM et 2 vCPU (pour MongoDB + Node.js). Nous recommandons 4 Go de RAM pour un usage courant avec plusieurs utilisateurs. Si vous combinez LibreChat avec un modèle Ollama local (Llama, Mistral…), prévoyez 8 Go de RAM minimum et un CPU récent.

Après déploiement, connectez-vous à votre instance LibreChat et allez dans **Paramètres → Clés API**. Vous pouvez ajouter une clé par fournisseur (OpenAI, Anthropic, Google, etc.) directement depuis l'interface. En tant qu'admin, vous pouvez aussi configurer des clés partagées au niveau du serveur dans les variables d'environnement, évitant à chaque utilisateur de saisir la sienne.

Oui. LibreChat supporte les endpoints personnalisés compatibles OpenAI. Déployez Ollama sur le même VPS (ou un autre), puis configurez un endpoint pointant vers `http://localhost:11434/v1` dans `librechat.yaml`. Vous obtenez un setup 100 % local avec des modèles comme Llama 3, Mistral ou Phi-3, sans aucune donnée envoyée vers des APIs cloud.

LibreChat intègre un système multi-utilisateurs. Le premier compte créé après déploiement devient administrateur. Depuis le **Panneau admin**, vous pouvez inviter des utilisateurs, définir des rôles (utilisateur/admin), contrôler l'accès aux modèles et aux fournisseurs, et désactiver l'inscription publique (`ALLOW_REGISTRATION=false`) pour un usage privé. Les clés API peuvent être partagées (admin) ou personnelles (par utilisateur).

BookStack est un wiki open source self-hosted construit sur PHP/Laravel. Il organise la documentation en **étagères, livres, chapitres et pages** — une hiérarchie claire qui rend les contenus navigables immédiatement. Il convient aux équipes qui documentent des procédures, des APIs ou des projets clients, et qui veulent garder cette documentation sur leur propre infrastructure sans abonnement par siège.

BookStack est peu exigeant : **1 Go de RAM** et **15 Go de SSD** suffisent pour une équipe de moins de vingt personnes. La consommation mémoire grimpe surtout avec le volume d'images et de pièces jointes uploadées. Pour une documentation d'équipe étendue ou beaucoup de pièces jointes, **2 Go de RAM et 25 Go de SSD** sont plus confortables. Le CPU est peu sollicité — 1 vCPU convient dans la quasi-totalité des cas.

À la fin de l'installation, ouvrez l'URL de votre domaine (configuré dans votre espace client). Connectez-vous avec les **identifiants par défaut : e-mail `[email protected]`, mot de passe `password`**. Changez immédiatement le mot de passe dans *Paramètres → Profil* — quiconque connaît l'URL peut utiliser ces identifiants avant le changement. Configurez ensuite vos variables SMTP pour activer les invitations utilisateurs par e-mail.

Les trois sont des wikis open source self-hosted, mais avec des approches différentes. **BookStack** impose une hiérarchie étagères/livres/chapitres/pages — idéal si vos équipes ont besoin d'une structure rigide et navigable. **Wiki.js** est plus flexible : arborescence libre, nombreux moteurs d'authentification, stockage Git optionnel — adapté aux projets techniques qui veulent versionner la doc. **Docmost** est un éditeur collaboratif temps réel inspiré de Notion — adapté aux équipes qui travaillent simultanément sur les mêmes documents. En résumé : BookStack pour la structure, Wiki.js pour la flexibilité, Docmost pour la collaboration en temps réel.

Une instance BookStack se restaure à partir de **trois éléments** : le dump de la base MariaDB (`mysqldump`), le volume Docker `bookstack_config` (qui contient les uploads et la configuration Laravel), et la valeur de la variable `APP_KEY`. **Sans APP_KEY**, les contenus chiffrés (notamment les secrets de session) ne peuvent pas être déchiffrés après restauration. Automatisez un `mysqldump` quotidien + une copie du volume `bookstack_config` vers un stockage externe (S3, Backblaze…) et conservez l'APP_KEY hors du serveur (dans un gestionnaire de mots de passe).

Oui — le registre Open VSX intégré couvre des milliers d'extensions populaires : ESLint, Prettier, Python, GitLens, Tailwind CSS IntelliSense, et bien d'autres. Toute extension installée est écrite dans le volume persistant et reste disponible après chaque redémarrage du conteneur.

Oui. Votre répertoire personnel est stocké dans un volume Docker nommé (`code-server-data`) qui est monté sur `/home/coder`. Tous vos fichiers, extensions, configurations Git et paramètres VS Code survivent aux redémarrages et aux mises à jour de l'image. Seul l'état non enregistré en mémoire vive est perdu si le conteneur s'arrête de façon inattendue.

Non. Sans domaine, accédez-y via un tunnel SSH : `ssh -L 8080:127.0.0.1:8080 root@<votre-ip>` puis ouvrez `http://localhost:8080` dans votre navigateur. Rattacher un domaine ajoute HTTPS, ce qui déverrouille le presse-papiers du navigateur, les Web Workers, et permet l'accès depuis des réseaux où le port SSH est bloqué.

Code Server tourne entièrement sur votre propre VPS — vous maîtrisez les données, le runtime et le coût. GitHub Codespaces est un service cloud géré facturé à l'usage (CPU + RAM par heure) hébergé sur l'infrastructure Microsoft. Code Server ne limite pas la durée de session, ne met pas l'environnement en veille, et ne facture pas à l'heure — seul le coût fixe de votre VPS s'applique.

Oui. L'image `codercom/code-server` peut aussi s'exécuter directement avec `docker run`, ou être intégrée dans un `docker-compose.yml` existant à côté d'autres services. Sur bare metal, installez Code Server directement avec la commande officielle `curl -fsSL https://code-server.dev/install.sh | sh` — le binaire s'installe comme service systemd et écoute sur le même port 8080.

Planka est un tableau Kanban open source self-hosted (licence MIT), inspiré de Trello. Il permet aux équipes de gérer leurs projets avec des tableaux, des listes et des cartes sur leur propre infrastructure — sans abonnement mensuel ni données hébergées chez un tiers.

Non. Planka fonctionne directement sur l'adresse IP de votre VPS (port 80, via nginx). Si vous souhaitez un accès HTTPS avec votre propre domaine, rattachez-le depuis votre espace client — ServOrbit configure le certificat TLS automatiquement.

Utilisez l'adresse e-mail `[email protected]` et le mot de passe affiché dans l'onglet **Accès** de votre espace client ServOrbit. Après la connexion, allez dans **Profil → Modifier le profil** pour remplacer l'adresse e-mail par défaut et définir un mot de passe personnel.

Autant que vous le souhaitez. La licence MIT n'impose aucune limite d'utilisateurs. Créez des comptes depuis le panneau **Administration → Utilisateurs** et invitez-les sur les projets de votre choix.

Planka stocke ses données dans deux endroits : la base PostgreSQL (projets, tableaux, cartes, membres) et des volumes Docker nommés (avatars, images de fond, pièces jointes). Sauvegardez les deux avec `docker compose exec postgres pg_dump -U appuser appdb > backup.sql` pour la base, et exportez les volumes via `docker run --rm -v <volume>:/data alpine tar czf - /data`.

Dawarich est une application web open-source (AGPL-3.0) qui remplace Google Timeline. Elle stocke votre historique GPS, visualise vos trajets sur une carte interactive et comptabilise les pays et villes visités — le tout hébergé sur votre propre serveur, sans partager vos données de localisation.

Oui. Dawarich est publié derrière un nom de domaine : l'installation vous demande l'adresse d'accès avant de démarrer, et l'application ne répond qu'à l'hôte déclaré à ce moment-là. Utilisez un sous-domaine de l'un de vos domaines, ou le sous-domaine gratuit fourni avec votre VPS — dans les deux cas, ServOrbit pose l'enregistrement DNS, le reverse-proxy et le certificat HTTPS. C'est aussi ce qui rend possible la synchronisation smartphone via OwnTracks ou Overland, qui a besoin d'une adresse joignable.

Exportez votre historique via Google Takeout : dans Google Account → Données et confidentialité → Télécharger vos données, cochez « Historique des positions » et demandez l'archive. Extrayez le fichier `Records.json` et importez-le dans Dawarich via Paramètres → Import. Le traitement s'exécute en arrière-plan — quelques minutes pour les grandes archives.

OwnTracks (iOS et Android, gratuit, open-source) et Overland (iOS) sont les deux clients supportés. Installez l'une d'elles, renseignez l'URL de votre serveur Dawarich dans les paramètres et activez le reporting de position — Dawarich reçoit les coordonnées en temps réel et les trace automatiquement sur la carte.

Dawarich stocke ses données dans PostgreSQL et des volumes Docker nommés. Sauvegardez la base avec `docker compose exec dawarich_db pg_dump -U app dawarich > backup.sql` et exportez les volumes `dawarich_storage` et `dawarich_watched` via `docker run --rm -v <volume>:/data alpine tar czf - /data`. Exécutez ces sauvegardes régulièrement et stockez-les hors du VPS.

Ruby 3.2 depuis les dépôts officiels Ubuntu 24.04. Rails 7 et Rails 8 tournent tous les deux sur Ruby 3.2 sans problème de compatibilité. Si vous avez besoin d'une autre version, installez rbenv ou asdf en parallèle et gérez plusieurs versions par projet.

Rails Stack installe PostgreSQL par défaut, la base de données recommandée pour Rails en production. Vous pouvez installer MariaDB ou MySQL en parallèle, mais le gabarit reste configuré pour PostgreSQL : colonnes JSONB, recherche plein texte et compatibilité native avec l'ORM Active Record.

Redis est déjà installé par le template Rails Stack. Ajoutez `gem 'sidekiq'` dans votre Gemfile, lancez `bundle install`, créez `config/sidekiq.yml` et configurez une unité systemd qui exécute `bundle exec sidekiq -e production`. Les workers et Puma cohabitent sur le même VPS — pas de dyno séparé à payer.

2 Go de RAM pour une application Rails seule avec PostgreSQL. Ajoutez 1 à 2 Go supplémentaires si vous exécutez des workers Sidekiq. Chaque worker Puma consomme environ 200 à 400 Mo en Rails ; commencez avec 2 workers et ajustez selon l'utilisation mémoire observée via `ps aux` ou `htop`.

Oui. Configurez un socket Unix Puma distinct par projet dans `config/puma.rb`, créez un vhost Nginx par domaine et une unité systemd par processus Puma. Chaque application utilise sa propre base PostgreSQL et son propre espace de noms Redis — elles ne s'interfèrent pas.

Firefly III est une application web open source (AGPL-3.0) de gestion financière personnelle et professionnelle, auto-hébergée sur votre propre VPS. Elle suit vos transactions, gère vos budgets par catégorie, génère des rapports exportables et peut importer vos relevés bancaires — sans abonnement et sans partager vos données avec un tiers.

Non. Firefly III fonctionne sans nom de domaine. Sans domaine attaché, vous y accédez via un tunnel SSH : `ssh -L 8080:127.0.0.1:8080 root@<IP_VPS>` puis `http://localhost:8080` dans votre navigateur. Pour un accès permanent depuis un domaine, ServOrbit pose le vhost Nginx et le certificat HTTPS automatiquement.

Firefly III accepte les fichiers CSV et OFX exportés depuis la plupart des banques. Pour les banques européennes, il supporte également les connecteurs GoCardless (anciennement Nordigen) pour une synchronisation automatique. L'assistant d'import guide la mise en correspondance des colonnes (date, montant, description) et la déduplication des transactions.

Firefly III stocke ses données dans PostgreSQL. Sauvegardez la base avec : `docker compose exec db pg_dump -U appuser appdb > backup.sql`. Planifiez cette commande quotidiennement via cron et stockez le fichier hors du VPS (S3, SFTP) pour une protection complète.

YNAB et Budgea sont des SaaS : ils hébergent vos données sur leurs serveurs, facturent un abonnement annuel (99$/an pour YNAB, 60€/an pour Budgea) et peuvent fermer leur service. Firefly III est auto-hébergé : vous installez l'application sur votre VPS, vous possédez vos données, il n'y a pas d'abonnement. En contrepartie, vous gérez vous-même les mises à jour et les sauvegardes.

Budibase est une plateforme low-code open source (GPL-3.0, 28 000+ étoiles GitHub) qui permet de construire des outils internes, des tableaux de bord et des automatisations sans écrire de code. Contrairement à Retool (SaaS propriétaire, facturation par siège) ou NocoBase (qui part du modèle de données), Budibase part de l'interface : vous choisissez une source de données existante (PostgreSQL, MySQL, REST API…) et composez des écrans en glisser-déposer. Auto-hébergé sur votre VPS, il n'y a aucun coût supplémentaire par utilisateur et vos données restent sur votre infrastructure.

Non. Budibase fonctionne sans nom de domaine via un tunnel SSH : exécutez `ssh -L 8060:127.0.0.1:8060 root@<votre-ip>` puis ouvrez `http://localhost:8060` dans votre navigateur. La connexion est chiffrée par SSH — il n'y a pas besoin de certificat TLS pour un accès personnel ou en équipe restreinte. Si vous souhaitez un accès HTTPS depuis n'importe quel appareil, deux options sont disponibles : rattacher votre propre domaine depuis l'espace client ServOrbit, ou utiliser le sous-domaine gratuit `{app}.{dns_slug}.servorbit-dns.com` inclus avec chaque VPS.

Dès que le provisionnement est terminé, ouvrez un tunnel SSH sur le port 8060 (voir ci-dessus) ou attachez un domaine. La première ouverture de Budibase affiche un **assistant de configuration** qui vous demande de créer le compte administrateur : saisissez une adresse e-mail et un mot de passe. Ce compte est enregistré localement dans CouchDB et est valide immédiatement — aucune confirmation par e-mail n'est nécessaire. Vous pouvez ensuite inviter d'autres utilisateurs depuis les paramètres de l'organisation.

Budibase embarque quatre services dans un seul conteneur Docker : le serveur applicatif Node.js, CouchDB, MinIO et Redis. La consommation mémoire au repos est d'environ **3 Go**, ce qui rend un VPS avec **4 Go de RAM le minimum recommandé**. Pour un usage en production avec plusieurs utilisateurs simultanés ou des jeux de données volumineux, **8 Go** offre une marge de manœuvre plus confortable. Si la consommation dépasse la mémoire disponible, le conteneur peut être tué par l'OOM killer de Linux — choisissez un VPS légèrement surdimensionné plutôt que le strict minimum.

Toutes les données Budibase — schémas d'applications, utilisateurs, automatisations, fichiers uploadés — sont stockées dans le volume Docker `budibase-data`, monté sur `/data` à l'intérieur du conteneur. Pour une sauvegarde complète, archivez ce volume depuis l'hôte : `docker run --rm -v budibase-data:/data -v $(pwd):/backup alpine tar czf /backup/budibase-$(date +%Y%m%d).tar.gz /data`. L'archive obtenue contient l'intégralité du volume. Pour restaurer : stoppez le conteneur Budibase, extrayez l'archive dans un volume vierge, puis redémarrez. Planifiez cette sauvegarde en cron et transférez le fichier vers un stockage externe (S3, B2, NFS) pour une protection complète.

Spring Boot Stack est un template VPS préconfiguré qui installe OpenJDK 21 LTS, Maven, Nginx et PostgreSQL 16 automatiquement. Il est conçu pour les développeurs Java qui souhaitent déployer une application Spring Boot en production sans configuration manuelle des composants serveur.

OpenJDK 21 LTS, le JDK par défaut dans Ubuntu 24.04 LTS (paquet `openjdk-21-jdk`). OpenJDK 21 est une version long-term support qui apporte les Virtual Threads (Project Loom), la concurrence structurée et le pattern matching pour les switch. Vous pouvez installer d'autres versions JDK en parallèle si nécessaire.

Oui. Maven est installé par le template, mais Gradle fonctionne sur le même JDK. Installez-le avec `apt install gradle` ou utilisez le Gradle Wrapper embarqué dans votre projet (`./gradlew build`). Spring Boot Stack est conçu pour accueillir n'importe quel projet Spring Boot, quelle que soit la technologie de build.

Oui. Faites tourner chaque service sur un port distinct (8080, 8081…), créez une unité systemd par service et ajoutez un bloc serveur Nginx par service, routé par préfixe de chemin ou sous-domaine. Systemd gère chaque processus indépendamment — ils ne se perturbent pas.

2 Go pour une application Spring Boot avec PostgreSQL. La JVM consomme typiquement 300 à 500 Mo au repos pour une application Spring Boot standard ; prévoyez plus si vous faites tourner plusieurs services ou augmentez le pool de connexions. Le flag `-Xmx` permet de plafonner l'utilisation du heap par service.

Navidrome implémente l'API Subsonic, le standard de facto du streaming musical self-hosted. Sur Android, Symfonium, DSub et Ultrasonic sont recommandés. Sur iOS, Amperfy et iSub fonctionnent bien. Ces applications se connectent en saisissant l'URL de votre instance, votre identifiant et votre mot de passe — la bibliothèque complète est disponible, avec lecture hors-ligne selon le client.

Oui. Navidrome ne nécessite pas de nom de domaine pour fonctionner. Vous pouvez y accéder depuis votre ordinateur via un tunnel SSH : ouvrez un terminal et lancez ssh -L 4533:127.0.0.1:4533 root@votre-ip-vps, puis accédez à http://localhost:4533 dans votre navigateur. Cette méthode est sécurisée et ne requiert aucune ouverture de port. Pour un accès mobile permanent depuis n'importe où, configurer un sous-domaine avec HTTPS reste l'option la plus pratique.

Navidrome est spécialisé musique uniquement : bibliothèque audio, playlists, scrobbling, API Subsonic pour les applications musicales mobiles. Il est très léger (moins de 256 Mo de RAM) et se configure rapidement. Jellyfin gère l'ensemble des médias — films, séries, musique, photos — avec une interface plus complète mais aussi plus lourde. Si votre usage est exclusivement musical et que vous voulez des clients mobiles dédiés (Symfonium, Amperfy), Navidrome convient davantage. Si vous voulez une médiathèque complète avec vidéo, Jellyfin est fait pour ça.

Navidrome lit tous les formats audio courants : MP3, FLAC, AAC, OGG Vorbis, Opus, M4A, WAV, AIFF et WMA. Il lit les tags ID3, Vorbis Comment et iTunes directement depuis les fichiers. Le transcodage à la volée vers MP3 ou Opus est possible pour les clients qui ne supportent pas le format original — il suffit d'installer ffmpeg sur le serveur, ce que ServOrbit configure automatiquement.

Oui. Navidrome gère nativement plusieurs comptes utilisateurs, chacun avec ses propres playlists, favoris, évaluations, historique d'écoute et paramètres de scrobbling. Le compte administrateur peut créer et gérer les autres comptes depuis l'interface d'administration. Il n'y a pas de limite imposée au nombre d'utilisateurs — la contrainte est celle de la bande passante et de la capacité du VPS.

Oui. OneDev intègre l'URL du serveur dans les liens de clonage, les callbacks de webhooks CI et les URI de redirection OAuth. Sans domaine correctement configuré, ces liens renvoient vers une adresse inaccessible. Vous pouvez utiliser un sous-domaine de votre propre domaine ou le sous-domaine gratuit ServOrbit (`{app}.{dns_slug}.servorbit-dns.com`), qui inclut HTTPS automatiquement — aucun enregistrement de nom de domaine nécessaire.

Les deux sont des forges Git auto-hébergées, mais OneDev va plus loin : il intègre un moteur CI/CD avec un agent de build inclus (pas besoin d'installer un runner séparé), des tableaux Kanban et un registre de paquets dans un seul conteneur. Gitea est plus léger (~200 Mo de RAM) et nécessite l'installation d'un `gitea/act_runner` séparé pour le CI. Choisissez OneDev si vous souhaitez une plateforme DevOps tout-en-un ; choisissez Gitea si vous voulez une forge Git minimaliste et que vous gérez le CI via un service externe.

Oui. OneDev est livré avec un agent de build local intégré dans le conteneur `1dev/server`. Dès que vous poussez un fichier `.onedev-buildspec.yml` dans un dépôt, un pipeline est mis en file d'attente et exécuté sur cet agent — aucune installation supplémentaire. Pour les équipes ayant besoin de builds parallèles ou d'environnements matériels spécifiques, OneDev permet d'ajouter des agents distants sur d'autres machines, mais c'est entièrement optionnel.

Le registre de paquets d'OneDev supporte les formats Docker/OCI (images), npm, Maven/Gradle, NuGet, Helm et d'autres. Chaque format utilise les outils standards (`docker push`, `npm publish`, `mvn deploy`) et les mêmes identifiants que votre instance Git. Tout est hébergé sur le même domaine et sauvegardé dans le même volume — aucun service registre externe n'est nécessaire.

Oui. OneDev intègre un assistant d'import qui transfère les dépôts avec leur historique Git, leurs branches, leurs tags, leurs issues, leurs jalons et leurs pull requests depuis GitHub, GitLab, Gitea et d'autres plateformes. L'assistant est accessible depuis Administration du site → Projets → Importer. Notez que les workflows CI doivent être réécrits au format `.onedev-buildspec.yml`, car OneDev n'est pas compatible avec la syntaxe GitHub Actions.

Huginn se spécialise dans la surveillance web et l'agrégation de données : son Website Agent extrait du contenu de n'importe quelle page via des sélecteurs CSS/XPath, détecte les changements et déclenche des actions sur condition. n8n et Node-RED se concentrent sur l'automatisation de flux entre API avec un éditeur visuel. Huginn est l'outil adapté au suivi de prix, aux alertes de changements web et à l'agrégation RSS ; n8n est plus adapté à la connexion d'API tierces sans code.

Prévoyez 2 Go de RAM minimum — environ 1 Go pour PostgreSQL 16 et 1 Go pour le conteneur Huginn, qui embarque le serveur web et le worker dans un seul processus. Avec plus de 50 agents tournant sur des planifications serrées (toutes les minutes), 4 Go est plus confortable. Côté disque, 15 Go suffisent pour le code, la base de données et l'historique des events.

Après le déploiement depuis le Marketplace ServOrbit, vos identifiants admin sont générés automatiquement et disponibles dans votre espace client (section Marketplace → votre instance Huginn). Connectez-vous avec le nom d'utilisateur `admin` et le mot de passe affiché. Changez ce mot de passe immédiatement dans Compte > Modifier après la première connexion.

Dans votre instance Huginn, cliquez sur New Agent et choisissez le type souhaité (Website Agent, Email Agent, Trigger Agent, etc.). Chaque agent est paramétrable via une interface JSON avec documentation intégrée. Sur ServOrbit, SEED_EXAMPLE_AGENTS est désactivé pour garder l'instance vierge. Si vous souhaitez voir des exemples, activez le paramètre `SEED_EXAMPLE_AGENTS: true` dans la configuration et redémarrez le conteneur — Huginn importe alors des scénarios de démonstration.

Huginn publie de nouvelles images sur ghcr.io/huginn/huginn:latest. Pour mettre à jour, exécutez `docker compose pull && docker compose up -d` dans le répertoire de votre instance. Huginn exécute les migrations de base de données automatiquement au démarrage. Sauvegardez toujours le volume PostgreSQL avant de mettre à jour. Sur ServOrbit, les mises à jour du playbook sont gérées depuis votre espace client.

Non. WhoDB fonctionne sans domaine via un tunnel SSH : ouvrez ssh -L 8080:127.0.0.1:8080 root@<ip-vps> depuis votre ordinateur, puis ouvrez http://localhost:8080 dans votre navigateur. Pour un accès direct depuis n'importe quel navigateur sans tunnel, rattachez un domaine depuis votre espace client ServOrbit — ou utilisez le sous-domaine gratuit {app}.{dns_slug}.servorbit-dns.com inclus avec chaque VPS.

WhoDB supporte PostgreSQL, MySQL, MariaDB, SQLite, MongoDB, Redis, ElasticSearch et ClickHouse. Vous pouvez configurer plusieurs connexions simultanément et basculer entre elles depuis le panneau de gauche sans redémarrer l'application.

WhoDB n'a pas de compte utilisateur propre : il vous demande directement les informations de connexion à votre base de données. Sur l'écran d'accueil, choisissez le moteur dans la liste déroulante (PostgreSQL, MySQL, Redis…), saisissez l'hôte, le port, le nom d'utilisateur et le mot de passe de votre base, puis cliquez sur Connexion. Aucun compte administrateur WhoDB n'est à créer — c'est l'accès à la base elle-même qui est authentifié.

Dans WhoDB, ouvrez Paramètres → Fournisseur IA et entrez l'URL de votre instance Ollama (par exemple http://127.0.0.1:11434 si Ollama tourne sur le même VPS) ou d'un endpoint compatible OpenAI. Choisissez ensuite un modèle dans la liste. Une fois configuré, une zone de texte libre apparaît dans l'onglet Requête : tapez votre question en français ou en anglais, WhoDB génère et exécute la requête SQL (ou la commande Redis) correspondante.

Oui. WhoDB chiffre les sessions et les identifiants de connexion dans un volume Docker persistant (/data) sur votre VPS. Ces données ne sont jamais transmises à un service tiers. Pour renforcer le chiffrement, définissez la variable d'environnement WHODB_ENCRYPTION_KEY avec une chaîne aléatoire de votre choix — sans elle, WhoDB génère une clé par défaut. L'accès à WhoDB lui-même est protégé par votre connexion SSH ou HTTPS si vous avez rattaché un domaine.

Choisissez MySQL si votre application l'exige explicitement — Magento 2, certaines distributions Drupal, ou des plugins PHP qui vérifient le nom du moteur (`mysql_get_server_info()` retourne « MySQL » et non « MariaDB »). Pour la grande majorité des applications PHP (WordPress, PrestaShop, Dolibarr), MariaDB est un remplacement drop-in avec des performances équivalentes et un suivi de sécurité plus réactif. Cas de doute : vérifiez la documentation de votre application.

Non. phpMyAdmin est accessible via un tunnel SSH sans nom de domaine. Ouvrez le tunnel depuis votre poste : `ssh -L 8080:127.0.0.1:PORT root@VOTRE-IP` (PORT = numéro affiché dans votre espace client), puis ouvrez `http://localhost:8080` dans votre navigateur. Le port 3306 de MySQL reste en écoute sur `127.0.0.1` dans le conteneur — accessible depuis vos applications hébergées sur le même VPS.

Créez d'abord un utilisateur dédié dans phpMyAdmin : Comptes utilisateurs → Ajouter un compte utilisateur. Accordez-lui uniquement SELECT, INSERT, UPDATE, DELETE sur la base de votre application — jamais GRANT ni SUPER. Renseignez ensuite la configuration de votre application avec : hôte `127.0.0.1`, port `3306`, nom de la base, utilisateur et mot de passe. L'utilisateur root est réservé à l'administration — ne l'utilisez pas dans votre application.

phpMyAdmin n'est exposé qu'en écoute locale (`127.0.0.1`) — il n'est pas accessible directement depuis Internet. Vous y accédez uniquement via un tunnel SSH, ce qui signifie que seules les personnes disposant d'une clé SSH sur le VPS peuvent l'ouvrir. Pour les environnements de production, privilégiez les connexions par un compte applicatif avec des droits minimaux, et n'accédez à phpMyAdmin qu'occasionnellement pour l'administration.

Oui. Les deux templates déploient leurs conteneurs dans des réseaux Docker isolés et n'interfèrent pas. Chaque stack écoute sur son propre port hôte (loopback uniquement) alloué dynamiquement par ServOrbit — aucune collision de ports n'est possible. Un VPS de 4 Go de RAM peut héberger les deux confortablement pour des charges modérées.

HedgeDoc (anciennement CodiMD) est un éditeur Markdown open source (AGPL-3.0) pour la collaboration en temps réel. Chaque note dispose d'une URL unique partageable ; plusieurs personnes éditent simultanément avec des curseurs visibles. Il supporte les diagrammes Mermaid et PlantUML, les formules LaTeX via MathJax, les blocs de code pour plus de 200 langages, un mode présentation, et l'export en un clic vers Markdown, HTML ou PDF. Sur ServOrbit, HedgeDoc se déploie en Docker Compose avec PostgreSQL comme base de données.

Oui. HedgeDoc nécessite un nom de domaine ou sous-domaine pour que les liens de partage de notes et les connexions WebSocket soient accessibles depuis l'extérieur. Si vous n'avez pas de nom de domaine personnel, le sous-domaine gratuit ServOrbit fourni avec chaque application convient parfaitement : `{app}.{slug}.servorbit-dns.com`, avec HTTPS intégré.

Après le déploiement, ouvrez votre domaine dans le navigateur et cliquez sur S'inscrire. Le tout premier compte enregistré devient automatiquement le compte Hôte (administrateur). Désactivez ensuite les inscriptions publiques dans Paramètres → Système pour empêcher les accès non sollicités. Le mot de passe admin n'est pas pré-généré : c'est vous qui le choisissez à l'inscription.

Oui. Les diagrammes Mermaid, PlantUML et Vega-lite s'affichent dans l'aperçu split-screen au fur et à mesure que vous tapez. Les formules LaTeX sont rendues par MathJax — entourez vos formules de `$...$` pour les formules en ligne ou de `$$...$$` pour les blocs. Exportez la note entière en PDF, Markdown ou HTML depuis le menu principal en un clic.

HedgeDoc stocke ses données à deux endroits : la base PostgreSQL (notes, utilisateurs, sessions) et le volume Docker `hedgedoc_uploads` (images attachées). Sauvegardez les deux avec les commandes suivantes : `docker compose exec -T database pg_dump -U appuser appdb | gzip > backup.sql.gz` `docker run --rm -v hedgedoc_uploads:/data alpine tar czf - /data > uploads.tar.gz` Automatisez ces deux commandes avec un job cron quotidien.

Trigger.dev est une plateforme open source (Apache-2.0) d'orchestration de tâches en arrière-plan pour TypeScript. Elle permet de définir des jobs durables directement dans votre code : ils s'exécutent avec retries automatiques, contrôle de la concurrence et tableau de bord en temps réel. À la différence d'un BullMQ ou d'un cron classique, les tâches Trigger.dev sauvegardent leur état entre les étapes — un crash ne fait jamais repartir de zéro. Sur ServOrbit, toute la stack (webapp, PostgreSQL, Redis, ElectricSQL, docker-provider, coordinator) se déploie en un compose.

Oui. Le système de connexion par magic link génère des URLs de callback à partir des variables `LOGIN_ORIGIN` et `APP_ORIGIN`. Sans domaine valide, ces liens sont malformés et l'authentification échoue. Sur ServOrbit, le sous-domaine gratuit `{app}.{slug}.servorbit-dns.com` fourni avec chaque VPS convient parfaitement : il est disponible dès le déploiement avec HTTPS intégré.

Trigger.dev utilise une authentification par magic link, sans mot de passe. Ouvrez `https://votre-domaine` et saisissez votre adresse email. Le lien d'authentification est imprimé dans les logs du container webapp — récupérez-le avec : `docker compose logs webapp | grep 'magic-link'`. Collez ce lien dans votre navigateur pour accéder au tableau de bord. Aucun serveur d'email n'est nécessaire pour ce premier accès.

Trigger.dev intègre ElectricSQL pour synchroniser en temps réel l'état des runs entre la base de données et l'interface webapp. ElectricSQL exige des slots de réplication logique PostgreSQL, qui ne sont disponibles que si `wal_level` vaut `logical`. Le compose ServOrbit inclut cette configuration dans la commande de démarrage PostgreSQL — vous n'avez rien à modifier manuellement.

Tirez les dernières images et redémarrez la stack : `docker compose pull && docker compose up -d`. Trigger.dev exécute automatiquement les migrations de base de données au démarrage de la webapp. Consultez les notes de version sur github.com/triggerdotdev/trigger.dev/releases avant chaque mise à jour — certaines versions majeures peuvent requérir des étapes de migration supplémentaires.

Automatisch est une alternative open source à Zapier, auto-hébergée sur votre VPS. Elle vous permet de connecter plus de 100 applications (GitHub, Slack, Notion, Stripe, Google Sheets…) via des déclencheurs et des actions visuels, sans écrire de code. Contrairement aux solutions cloud, toutes vos données restent sur votre serveur et il n'y a aucun abonnement ni limite de tâches.

Automatisch génère des URLs de webhook uniques à partir de la variable `HOST`. Ces URLs permettent aux services externes (GitHub, Stripe, Typeform…) d'envoyer des événements à vos workflows. Sans domaine valide, les URLs pointent vers `localhost` et ne sont pas accessibles depuis Internet. Sur ServOrbit, le sous-domaine gratuit fourni avec chaque VPS fonctionne dès le déploiement.

Après le déploiement, rendez-vous sur `https://votre-domaine/auth/sign-up`. Saisissez votre adresse email et un mot de passe pour créer le premier compte administrateur. Aucun email de confirmation n'est envoyé : vous êtes connecté immédiatement. Il est recommandé de créer le compte dès la fin du déploiement, avant que quelqu'un d'autre n'accède à l'URL.

Pour les intégrations OAuth (Slack, GitHub, Google Sheets, Notion…), créez une application OAuth chez le fournisseur et enregistrez ses identifiants dans Automatisch. Renseignez le `CLIENT_ID` et le `CLIENT_SECRET` dans Automatisch sous Settings → Apps. L'URL de callback est généralement `https://votre-domaine/app/<service>/auth/callback`. Une fois ces identifiants en place, la connexion OAuth s'établit via le bouton **Connect** depuis l'onglet Connections.

Tirez les dernières images Docker et redémarrez la stack : `docker compose pull && docker compose up -d`. Automatisch exécute automatiquement les migrations de base de données au démarrage. Consultez les notes de version sur github.com/automatisch/automatisch/releases avant chaque mise à jour — certaines versions majeures peuvent requérir des étapes de migration spécifiques.

Kimai est un gestionnaire de temps open source (MIT) que vous hébergez sur votre propre VPS. Il vous permet d'enregistrer des heures par projet, client et activité, de définir des taux horaires, de générer des feuilles de temps et des factures PDF, et de produire des rapports détaillés — sans abonnement mensuel et sans partage de données avec un tiers.

Non. Kimai fonctionne sans domaine via tunnel SSH : `ssh -L 8080:127.0.0.1:8001 root@<ip-vps>` puis `http://localhost:8080`. Pour un accès depuis n'importe quel navigateur, attachez un domaine depuis votre tableau de bord ServOrbit ou utilisez le sous-domaine gratuit `{app}.{dns_slug}.servorbit-dns.com` inclus avec chaque VPS.

Vos identifiants administrateur sont affichés sur la carte de l'app dans l'espace client dès le déploiement : identifiant `[email protected]`, mot de passe généré automatiquement. Après connexion, vous pouvez modifier l'adresse e-mail et le mot de passe depuis les paramètres du profil.

Oui. Kimai inclut un module de facturation intégré. Filtrez vos entrées de feuilles de temps par client et par période, puis cliquez sur **Créer une facture** pour obtenir un document PDF ou HTML. Vous pouvez personnaliser le modèle (logo, couleurs, conditions de paiement, TVA) depuis les paramètres de facturation.

Toutes les données de Kimai sont stockées dans trois volumes Docker : `kimai_db` (base de données MySQL), `kimai_data` (fichiers importés) et `kimai_public` (avatars). Sauvegardez-les avec `rsync` ou SFTP depuis l'hôte, ou utilisez `mysqldump` pour un export SQL de la base de données. Kimai exporte aussi les feuilles de temps en CSV et XLSX directement depuis l'interface.

CapRover est une plateforme PaaS (Platform as a Service) open source qui vous permet de déployer des applications en quelques clics sur votre propre serveur. Il repose sur Docker et Docker Swarm, gère automatiquement les certificats SSL via Let's Encrypt et propose plus de 280 templates préconfigurés (WordPress, Ghost, n8n, Nextcloud…). Sur ServOrbit, CapRover est disponible dans la Marketplace et se provisonne en moins de 60 secondes.

Non, un nom de domaine n'est pas obligatoire pour démarrer CapRover. Le panneau d'administration est accessible sur le port 3000 de votre VPS immédiatement après le provisionnement. Un domaine wildcard (ex. ``*.apps.mondomaine.com``) est toutefois nécessaire si vous souhaitez exposer vos applications déployées sous des sous-domaines dédiés — cette configuration se fait depuis le panneau CapRover lui-même, après installation.

Après le provisionnement du VPS depuis la Marketplace ServOrbit, accédez à `http://<IP-de-votre-VPS>:3000` dans votre navigateur. La page de connexion s'affiche immédiatement. Le mot de passe par défaut est `captain42` — changez-le dès la première connexion dans Paramètres → Captain Settings. Vous pouvez ensuite configurer votre domaine wildcard pour accéder au panneau via `captain.mondomaine.com`.

CapRover lui-même consomme environ 200 à 300 Mo de RAM. Le minimum pour un usage réel (CapRover + quelques applications déployées) est de 2 Go de RAM ; ServOrbit recommande le plan VPS Power (8 GB) pour un confort optimal. Gardez en tête que chaque application que vous déployez via CapRover consomme sa propre mémoire — prévoyez un plan avec suffisamment de RAM selon votre charge.

Oui, CapRover prend en charge plusieurs méthodes de déploiement : depuis un dépôt Git (GitHub, GitLab, Bitbucket) avec un webhook pour les déploiements automatiques, depuis un `Dockerfile` ou un fichier `captain-definition`, ou encore via les plus de 280 templates de la communauté en un clic. Il propose aussi une CLI (`caprover deploy`) pour les pipelines CI/CD.

Non, Homepage n'a pas d'authentification intégrée. Il est conçu pour un accès en loopback (via tunnel SSH) ou VPN. Pour exposer Homepage sur une URL publique, placez-le derrière un reverse proxy qui ajoute une authentification HTTP Basic ou OAuth, ou utilisez Cloudflare Access devant l'instance.

Depuis la version 0.9.0, Homepage valide l'en-tête HTTP Host pour prévenir les attaques par injection d'en-tête. Sans cette variable, vous obtiendrez une erreur « Invalid host ». Sur un VPS ServOrbit, si vous accédez via tunnel SSH (http://localhost:3000), utilisez HOMEPAGE_ALLOWED_HOSTS="*". Si vous avez un domaine (ex. home.mondomaine.com), inscrivez-le à la place pour plus de sécurité.

Homepage lit les métadonnées Docker via le socket monté en lecture seule (/var/run/docker.sock:ro). Ajoutez les labels suivants sur chacun de vos conteneurs que vous souhaitez voir apparaître : homepage.group (le groupe, ex. « Médias »), homepage.name (le nom affiché), homepage.href (l'URL). Homepage les détecte et les affiche automatiquement sans modifier services.yaml.

Toute la configuration de Homepage vit dans des fichiers YAML montés dans un volume Docker nommé homepage-config, accessible dans /opt/stacks/homepage/config/ sur votre VPS. Les fichiers principaux sont : services.yaml (vos services groupés), bookmarks.yaml (vos liens favoris), widgets.yaml (barre de widgets en haut), settings.yaml (thème, langue, moteur de recherche). Les modifications sont appliquées automatiquement au prochain rechargement de la page — aucun redémarrage du conteneur n'est nécessaire.

Homepage consomme moins de 128 Mo de RAM pour le conteneur lui-même — aucune base de données n'est requise. C'est l'une des applications les plus légères du Marketplace. Sur un VPS ServOrbit, même la formule entrée de gamme est largement suffisante pour Homepage. Prévoyez de la marge pour les autres services que vous souhaitez afficher dans le tableau de bord (Nextcloud, Jellyfin, etc.) plutôt que pour Homepage lui-même.

Directus est un headless CMS et une data platform open source (Apache-2.0) qui se pose au-dessus de n'importe quelle base SQL — PostgreSQL, MySQL, SQLite, MariaDB — et génère une API REST et GraphQL complète par-dessus. Il offre également une interface d'administration no-code pour modéliser le contenu, gérer les enregistrements et définir des permissions granulaires. En production, il sert d'arrière-boutique à des applications web et mobiles — un frontend interroge `/items/<collection>` en REST ou GraphQL, Directus renvoie les données sans qu'un développeur ait écrit un seul endpoint.

Non. Directus fonctionne sans domaine via un tunnel SSH : `ssh -L 8055:127.0.0.1:<port> root@<ip>` puis `http://localhost:8055`. Pour les front-ends en production qui doivent joindre l'API depuis l'extérieur, rattachez un domaine depuis votre espace client ServOrbit — nginx proxifie vers le conteneur Directus en HTTPS automatiquement. Vous pouvez aussi utiliser le sous-domaine gratuit `{app}.{dns_slug}.servorbit-dns.com` inclus avec chaque VPS.

Le déploiement ServOrbit utilise SQLite par défaut : une seule base de données dans un fichier, aucun service externe à gérer. C'est le point de départ recommandé pour un usage solo ou pour tester l'API. Pour une utilisation multi-utilisateurs ou pour de fortes charges en lecture/écriture, vous pouvez éditer le fichier Compose dans `/opt/directus/` et basculer vers PostgreSQL en ajoutant un conteneur `postgres:16` et en remplaçant `DB_CLIENT=sqlite3` par `DB_CLIENT=pg`.

Directus avec SQLite (configuration par défaut sur ServOrbit) fonctionne confortablement avec 512 Mo de RAM. Pour un projet en production avec plusieurs utilisateurs simultanés ou des transformations d'images fréquentes, 1 Go est recommandé. Si vous ajoutez PostgreSQL sur le même VPS, prévoyez 2 Go au total. Un VPS ServOrbit Cloud S (1 Go de RAM) est suffisant pour commencer ; passez au Cloud M (2 Go) pour un usage d'équipe.

Les deux s'installent sur une base SQL existante et génèrent une API, mais leurs orientations diffèrent. NocoDB est tourné vers la saisie et l'organisation : son interface ressemble à un tableur Airtable, idéale pour que des équipes non techniques créent et modifient des enregistrements sans code. Directus est davantage orienté développeur : il génère une API consommable par des applications front-end et met l'accent sur le contrôle du schéma, les flows d'automatisation et la gestion de médias. En pratique, NocoDB convient à un outil interne ou un CRM léger, tandis que Directus est préférable comme backend d'une application web ou mobile publique.

Non. En mode autonome, Lobe Chat fonctionne sans domaine via un tunnel SSH : `ssh -L 3210:127.0.0.1:3210 root@votre-vps` puis `http://localhost:3210`. Pour un accès HTTPS public permanent, rattachez un domaine depuis votre espace client ServOrbit ou utilisez le sous-domaine gratuit du VPS — nginx proxifie Lobe Chat en HTTPS sans configuration manuelle.

En mode autonome (image Docker sans base de données), les clés API sont stockées dans le navigateur (localStorage) et ne quittent jamais votre appareil. Pour les centraliser côté serveur et les masquer aux navigateurs, passez au mode base de données avec PostgreSQL — documenté dans notre guide de déploiement avancé sur le blog.

Ajoutez la variable d'environnement `ACCESS_CODE=votre-secret` au démarrage du conteneur : Lobe Chat demandera ce code à chaque nouvelle session. Pour une sécurité renforcée, placez un reverse proxy avec authentification basique devant le port 3210 (Nginx `auth_basic`, Caddy `basicauth`) ou restreignez l'accès à certaines IP via le pare-feu.

Oui. Si Ollama tourne sur le même VPS, configurez `http://localhost:11434` comme URL Ollama dans Paramètres → Fournisseurs → Ollama. Dans le conteneur Docker, utilisez `http://host.docker.internal:11434` si Docker n'a pas accès au réseau hôte. Vous obtenez un assistant 100% local (Llama 3, Qwen, Mistral…) sans coût d'API — augmentez la RAM du VPS selon la taille du modèle.

En mode autonome (image Docker par défaut), l'historique est stocké dans le navigateur (localStorage) : il n'est pas conservé si vous changez de navigateur ou d'appareil, et un redémarrage du conteneur ne l'efface pas. Pour une persistance côté serveur, utilisez le mode base de données (PostgreSQL + volume Docker) documenté dans notre guide avancé — toutes les conversations sont alors sauvegardées et accessibles depuis n'importe quel appareil.

Non. Le `MASTERKEY` (variable `ENCRYPTION_KEY` dans ServOrbit) est utilisé pour chiffrer les secrets en base PostgreSQL dès le 1er démarrage. Le modifier ultérieurement rendrait tous les secrets illisibles et ZITADEL refuserait de démarrer. Conservez-le dans un gestionnaire de mots de passe sécurisé. En cas de perte, la seule option est une réinstallation complète.

Non. ZITADEL ancre l'`issuer` OIDC (l'URL de votre instance) au 1er démarrage via `ZITADEL_EXTERNALDOMAIN`. Cette valeur est stockée en base et tous les tokens JWT émis la contiennent. La modifier casse toutes les intégrations OIDC existantes. Si vous avez besoin d'un autre domaine, réinstallez l'instance depuis zéro.

Oui. ZITADEL est écrit en Go et consomme moins de 100 Mo de RAM au repos, contre 512 Mo à 1 Go pour Keycloak en JVM. Il est donc adapté aux VPS d'entrée de gamme (2 Go RAM). La base PostgreSQL ajoute environ 50 Mo supplémentaires. Un VPS 2 Go RAM suffit pour un usage équipe (10–50 utilisateurs).

Dans la console ZITADEL, allez dans **Instance Settings** → **Login Policy** → activez **Passkeys / WebAuthn**. Vos utilisateurs peuvent ensuite enregistrer leur appareil (Touch ID, Face ID, clé FIDO2) depuis **My Profile** → **Passwordless**. L'authentification sans mot de passe est disponible immédiatement — aucun plugin supplémentaire n'est requis.

ZITADEL est conçu nativement pour le multi-tenant. Chaque **Organisation** est un espace isolé avec ses propres utilisateurs, groupes, applications et politiques de sécurité (MFA, SSO, restrictions de domaine email). Les utilisateurs peuvent appartenir à plusieurs organisations avec des rôles différents dans chacune. Les tokens JWT incluent automatiquement les claims d'organisation — vos applications n'ont qu'à les lire.

Non. SiYuan fonctionne sur le port 6806 sans nom de domaine. Ouvrez un tunnel SSH depuis votre machine locale : `ssh -L 6806:127.0.0.1:<port> root@<ip-vps>` puis accédez à `http://localhost:6806` dans votre navigateur. Pour un accès HTTPS permanent depuis les applications de bureau ou mobile, rattachez un domaine depuis votre espace client ServOrbit ou utilisez le sous-domaine gratuit `{app}.{dns_slug}.servorbit-dns.com` inclus avec chaque VPS.

ServOrbit génère automatiquement un code d'accès (`ADMIN_PASSWORD`) au moment du provisionnement du VPS. Ce code est transmis à SiYuan via la variable d'environnement `SIYUAN_ACCESS_AUTH_CODE` et sert à protéger l'accès à l'interface web. Vous retrouvez ce code dans votre coffre de credentials ServOrbit. Vous pouvez le modifier ultérieurement depuis Paramètres → Compte → Code d'authentification d'accès dans SiYuan.

Oui. SiYuan propose des applications natives open source pour Windows, macOS, Linux, iOS et Android. Dans les paramètres de l'application, définissez le point de terminaison de synchronisation (sync endpoint) sur l'adresse HTTPS de votre VPS et saisissez votre code d'accès. La synchronisation est incrémentale et chiffrée de bout en bout. Vous pouvez également accéder à l'interface web complète depuis n'importe quel navigateur sans installer d'application.

SiYuan permet d'exporter des documents individuels ou des carnets entiers dans plusieurs formats. Depuis le menu contextuel d'un document ou d'un carnet, choisissez Exporter puis sélectionnez : Markdown (fichiers `.md` et dossier d'assets), HTML (page autonome), Word (.docx) ou PDF. L'export Markdown est lisible sans SiYuan et peut être importé dans d'autres outils comme Obsidian ou Logseq. Vous pouvez aussi copier directement le volume Docker `/siyuan/workspace` pour une sauvegarde complète.

SiYuan consomme généralement moins de 256 Mo de RAM pour un workspace personnel actif. Un VPS ServOrbit avec 1 Go de RAM est suffisant pour un usage individuel ou en équipe de deux à trois personnes. Pour des workspaces très liés (plusieurs milliers de blocs, nombreux graphes) ou une utilisation multi-utilisateurs intensive, 2 Go de RAM offrent une meilleure fluidité. Le conteneur Docker SiYuan n'embarque aucun service supplémentaire — la base SQLite est légère et les requêtes sur les blocs sont optimisées.

Non. Semaphore UI écoute sur le port 3000 sans nom de domaine. Ouvrez un tunnel SSH depuis votre machine locale : `ssh -L 3000:127.0.0.1:<port> root@<ip-vps>` puis accédez à `http://localhost:3000` dans votre navigateur. Pour un accès HTTPS permanent depuis toute l'équipe, rattachez un domaine depuis votre espace client ServOrbit ou utilisez le sous-domaine gratuit `{app}.{dns_slug}.servorbit-dns.com` inclus avec chaque VPS.

ServOrbit génère automatiquement un mot de passe admin (`ADMIN_PASSWORD`) au moment du provisionnement du VPS. Ce mot de passe est transmis à Semaphore UI via la variable d'environnement `SEMAPHORE_ADMIN_PASSWORD` et sert à protéger l'accès initial. Vous le retrouvez dans votre coffre de credentials ServOrbit. Changez-le immédiatement après votre première connexion depuis Profile → Change Password.

Non. Semaphore UI utilise SQLite, une base de données clé-valeur embarquée écrite en Go. Toutes les données (projets, inventaires, tâches, logs) sont stockées dans un seul fichier monté dans un volume Docker. Aucun PostgreSQL, MySQL ou Redis n'est nécessaire — le déploiement reste un unique conteneur.

Semaphore UI supporte Ansible, Terraform, OpenTofu et les scripts Bash. Chaque projet est configuré avec son propre backend d'exécution. Vous pouvez gérer des playbooks Ansible dans un projet et des plans Terraform dans un autre depuis la même instance, avec des inventaires et des Key Stores distincts pour chaque contexte.

Oui. Semaphore UI gère plusieurs comptes utilisateurs avec un contrôle d'accès par rôle : Viewer (lecture seule), Task Runner (peut déclencher des tâches) et Admin (gestion complète du projet). Créez des comptes depuis Settings → Users, puis assignez les rôles par projet. Les rôles s'appliquent au niveau du projet, ce qui vous permet d'accorder plus de droits sur un projet non-critique que sur la production.

Oui. Saleor Commerce est déployé avec `requireDomain=true` sur ServOrbit : le domaine est figé au premier démarrage dans l'URL de l'API du tableau de bord (`API_URL`) et dans la variable `ALLOWED_CLIENT_HOSTS`. Ces valeurs ne peuvent pas être modifiées après le lancement sans recréer les volumes Docker. Attachez votre domaine depuis votre espace client ServOrbit **avant** de déployer.

Le tableau de bord Saleor est accessible à la racine de votre domaine : `https://votre-domaine/`. Les identifiants sont générés automatiquement au déploiement et affichés dans votre espace client ServOrbit. L'adresse e-mail du compte admin est `[email protected]` ; changez-la et le mot de passe dès la première connexion dans le tableau de bord sous Compte → Modifier le profil.

Saleor exige au moins un **canal de vente** avant de pouvoir créer des produits. Un canal définit la devise, les règles de prix et les pays de livraison. Sans canal, le formulaire de création de produit est vide et inopérant. Allez dans Catalogue → Canaux → Créer un canal, renseignez un nom (ex. « Défaut »), une devise (MAD, EUR…) et un pays, puis revenez à la création de produits.

Non. Saleor est une plateforme **headless** : elle fournit l'API GraphQL et le tableau de bord d'administration, mais pas de vitrine cliente intégrée. Vous devez apporter votre propre frontend — un site Next.js, une application React Native ou tout framework capable de consommer une API GraphQL. La communauté Saleor maintient un storefront Next.js de référence sur GitHub que vous pouvez forker comme point de départ.

Le minimum absolu est **2 Go de RAM** pour faire tourner la pile complète : API Django, worker Celery, PostgreSQL 15 et Valkey 8. En pratique, **4 Go sont recommandés** pour la production : PostgreSQL a besoin de marge sous les requêtes simultanées, et le worker Celery peut traiter plusieurs tâches en parallèle. Avec 2 Go, la pile démarre mais se retrouvera sous pression dès qu'un pic de trafic ou un import de catalogue important sera lancé.

Flarum est un logiciel de forum open source (MIT) écrit en PHP avec une interface SPA moderne (Ember.js). Contrairement à phpBB ou MyBB, l'interface se met à jour en temps réel sans rechargement de page — nouveaux messages, notifications et réactions apparaissent instantanément. Flarum intègre aussi un système d'extensions Composer qui permet d'ajouter polls, badges, SSO OAuth et bien d'autres fonctionnalités sans modifier le code source.

Oui. Flarum ancre son URL publique (FLARUM_BASE_URL) lors de l'installation initiale et ne peut pas la changer sans recréer les volumes. Attachez votre domaine depuis votre espace client ServOrbit avant de déployer. Sans domaine, l'accès est possible en SSH tunnel, mais les liens internes générés par Flarum (invitations, notifications e-mail, partages) seront incorrects.

Flarum crée automatiquement un compte administrateur avec les identifiants flarum (login) et flarum (mot de passe). Ces identifiants sont publiquement connus — changez le mot de passe immédiatement après la première connexion sur /admin. Sur ServOrbit, un avertissement s'affiche dans votre espace client tant que le mot de passe n'a pas été modifié.

Depuis le panneau d'administration de Flarum (Administration → Extensions), vous pouvez activer les extensions officielles et communautaires disponibles. Pour des extensions non listées, connectez-vous en SSH à votre VPS et exécutez `docker exec -it <conteneur_flarum> composer require <vendor/package>` — Flarum recharge les extensions au redémarrage. Les extensions sont persistées dans le volume /data/extensions.

Flarum stocke ses données dans deux endroits : le volume Docker /data (assets, extensions installées, fichiers de storage) et la base MariaDB. Pour sauvegarder : copiez le répertoire du volume /data via rsync ou un snapshot Docker, et exportez la base avec `docker exec <db> mysqldump -uflarum -p$DB_PASSWORD flarum > flarum_backup.sql`. Pour restaurer : remontez les volumes et ré-importez le dump SQL avant de redémarrer Flarum.

Komodo est disponible en template VPS dans le catalogue ServOrbit et couvre la gestion de conteneurs Docker sur serveur unique comme sur flotte multi-serveurs, avec une approche GitOps intégrée. Contrairement à Portainer, dont la version communautaire disparaît avec Portainer 3.0, Komodo reste entièrement open source. Il permet de déployer, surveiller et mettre à jour vos stacks depuis une interface centralisée. Voir notre guide sur les alternatives à Portainer 3.0 pour choisir la solution adaptée à votre situation. Activez Komodo sur votre VPS ServOrbit en quelques clics depuis le catalogue.

Depuis votre espace client ServOrbit, accédez à la section Marketplace, choisissez l'application souhaitée dans le catalogue, sélectionnez votre VPS cible et confirmez le déploiement. Le template configure automatiquement le conteneur, les volumes persistants et le réseau. Pour les paramètres avancés (variables d'environnement, ports exposés), une étape de personnalisation est proposée avant l'activation. Aucune commande Docker manuelle n'est nécessaire : le déploiement est opéré par le système de templates VPS de ServOrbit. Votre application est accessible en quelques minutes après activation.

La Marketplace ServOrbit couvre le déploiement et la mise à jour des templates applicatifs ; la gestion fine des images Docker (pull d'un tag spécifique, nettoyage des images non utilisées, inspection des couches) reste une opération de bas niveau réalisée en SSH sur votre VPS. Sur votre VPS avec accès root, vous disposez de la commande docker image et de docker system prune pour libérer de l'espace. Pour une interface graphique complète de gestion d'images, des templates comme Komodo ou Dockge sont disponibles dans le catalogue et offrent cette fonctionnalité.