Marketplace

Choisissez un VPS Cloud puis sélectionnez le template souhaité : l'environnement est installé automatiquement. Les apps qui exigent un domaine sont servies en HTTPS sur l'adresse choisie à l'installation — un sous-domaine de l'un de vos domaines ou le sous-domaine gratuit du VPS ; les autres n'ont pas d'adresse publique et s'ouvrent par un tunnel SSH.

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 (170 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, publié sur 127.0.0.1 et relayé en HTTPS par le reverse-proxy nginx que ServOrbit pose sur l'adresse choisie à l'installation. Git par SSH est publié sur le port 2222 — pour éviter tout conflit avec le SSH de l'hôte VPS sur le port 22 —, mais lui aussi sur 127.0.0.1 seulement : il n'est pas joignable depuis Internet. Clonez en HTTPS, ou passez par un tunnel SSH.

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.

Le SSH Git de Gitea n'est publié que sur 127.0.0.1:2222 : `git clone ssh://git@<your-domain>:2222/<user>/<repo>.git` ne répond donc pas depuis l'extérieur. Clonez en HTTPS (`git clone https://<your-domain>/<user>/<repo>.git`), ou ouvrez d'abord un tunnel SSH vers le VPS — `ssh -L 2222:127.0.0.1:2222 root@<ip>` — puis utilisez `git clone ssh://git@localhost:2222/<user>/<repo>.git`. Un bloc Host dans `~/.ssh/config` (HostName localhost, Port 2222) évite ensuite de préciser le port à chaque commande Git.

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 donc une adresse en HTTPS — et ServOrbit la met en place pour vous : l'installation de Vaultwarden demande un sous-domaine de l'un de vos domaines ou le sous-domaine gratuit fourni avec votre VPS, puis ServOrbit pose l'enregistrement DNS, le reverse-proxy nginx et le certificat Let's Encrypt. Aucun proxy à configurer vous-même.

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. Ce sont deux apps distinctes de la Marketplace, chacune dans son propre conteneur, sans conflit de port (Ollama sur 11434, Qdrant sur 6333/6334). Prévoyez la RAM en conséquence : Ollama demande à lui seul 8 Go minimum pour un modèle 7B, auxquels s'ajoute la mémoire de Qdrant. Vous obtenez 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. Sur ServOrbit, l'installation vous demande cette adresse : un sous-domaine de l'un de vos domaines ou le sous-domaine gratuit fourni avec votre VPS — ServOrbit pose l'enregistrement DNS, le reverse proxy nginx et le certificat TLS (si la zone DNS de votre domaine n'est pas gérée par ServOrbit, faites d'abord pointer un enregistrement A vers le VPS).

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 et anglais dans la recette ServOrbit, l'arabe pouvant être ajouté), 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, avec un réglage à faire pour l'arabe. L'image Docker intègre Tesseract, et la recette ServOrbit pose `PAPERLESS_OCR_LANGUAGE=fra+eng` : l'OCR traite d'emblée le français et l'anglais, pas l'arabe. Pour l'ajouter, éditez en SSH le `docker-compose.yml` de `/opt/paperless-ngx` : passez la variable à `fra+eng+ara`, ajoutez `PAPERLESS_OCR_LANGUAGES: ara` (qui installe le pack de langue au démarrage), puis lancez `docker compose up -d`. Les documents mixtes sont alors traités dans les trois 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.

Oui, mais pas forcément un domaine acheté : sur ServOrbit, l'installation de NocoBase réclame une adresse — un sous-domaine de l'un de vos domaines, ou le sous-domaine gratuit fourni avec votre VPS. ServOrbit pose alors l'enregistrement DNS, le reverse-proxy nginx et le certificat Let's Encrypt. Le port 13000 n'est publié que sur 127.0.0.1 : NocoBase n'est pas joignable sur `http://ip-de-votre-vps:13000`, y compris pour un usage interne.

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.

Oui, une adresse est exigée — sans qu'il faille acheter un domaine. Sur ServOrbit, l'installation de Glance réclame un sous-domaine de l'un de vos domaines ou le sous-domaine gratuit fourni avec votre VPS, et ServOrbit pose l'enregistrement DNS, le reverse-proxy nginx et le certificat HTTPS, ce qui protège aussi les cookies de session. Le port 8080 n'est publié que sur 127.0.0.1 : Glance n'est pas joignable sur l'adresse IP du VPS.

É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 — sans qu'il faille acheter un domaine : l'installation accepte un sous-domaine de l'un de vos domaines ou le sous-domaine gratuit fourni avec votre VPS. ServOrbit pose l'enregistrement DNS, nginx et le certificat TLS Let's Encrypt (si la zone DNS de votre domaine n'est pas gérée par ServOrbit, faites d'abord pointer un enregistrement A 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://127.0.0.1:8080/topic` depuis votre VPS), et n'importe quel abonné — application mobile, navigateur, script — le reçoit en temps réel. Sur ServOrbit, ntfy n'écoute que sur 127.0.0.1 : pour des abonnés hors du VPS, exposez-le vous-même à une adresse en HTTPS. L'auto-hébergement vous donne des topics privés illimités, sans limites de taux, sans compte tiers, sans abonnement mensuel.

Pour l'installer, non : ntfy n'exige pas de domaine sur ServOrbit, mais aucune URL ne lui est alors attribuée — son port 8080 n'est publié que sur 127.0.0.1. Les scripts et outils de monitoring qui tournent sur le VPS publient directement sur `http://127.0.0.1:8080/<topic>`, et l'interface s'ouvre par un tunnel SSH (`ssh -L 8080:127.0.0.1:8080 root@<ip>`). En revanche, pour publier depuis une autre machine, recevoir sur l'app mobile ou utiliser le Web Push des navigateurs, le serveur doit être joignable à une adresse en HTTPS — un reverse-proxy sur votre domaine, à configurer vous-même en SSH.

Une seule ligne, depuis le VPS : `curl -d "Job terminé" http://127.0.0.1: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, entrypoints Docker, scripts Python. Depuis une autre machine (GitHub Actions, GitLab CI, AWX), remplacez l'URL par l'adresse HTTPS publique de votre serveur ntfy, à configurer vous-même : la recette ServOrbit ne publie le port 8080 que sur 127.0.0.1.

Oui, à condition que l'app puisse joindre votre serveur. La recette ServOrbit ne publie ntfy que sur 127.0.0.1:8080 et ne lui attribue aucune URL : exposez-le d'abord à une adresse en HTTPS (reverse-proxy sur votre domaine, à configurer en SSH). Les apps officielles ntfy pour Android (F-Droid / Play Store) et iOS (App Store) vous permettent alors d'ajouter ce serveur : entrez son URL (ex. `https://ntfy.votre-domaine.com`) 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 reste consultable à tout moment dans votre espace client, depuis les applications installées de votre VPS (bouton « Révéler »), qui le lit dans le `.env` de votre serveur — ServOrbit n'en garde aucune copie. Le changer impose un redémarrage avec une nouvelle clé, 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.

La version de Monica installée par la recette ServOrbit (image monicahq/monicahq:apache, branche 2.x) prend en charge officiellement MySQL et MariaDB uniquement. La recette utilise MariaDB 11, la base de données open-source compatible MySQL recommandée. PostgreSQL n'est pas pris en charge dans cette version : 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. Le plus petit VPS ServOrbit, VPS Start (4 GB RAM), suffit donc largement pour un usage personnel ou une petite équipe, et laisse de la marge pour plusieurs agents IA ou des utilisateurs simultanés.

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. Le plus petit VPS ServOrbit, VPS Start (4 GB RAM), suffit donc largement. Si vous ajoutez Ollama (une app distincte de la Marketplace) sur le même VPS pour le tagging IA local, prévoyez nettement plus : Ollama demande à lui seul 8 Go minimum pour un modèle 7B.

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 n'exige pas de domaine sur ServOrbit, mais aucune URL ne lui est alors attribuée : son port 8080 n'est publié que sur 127.0.0.1. Ouvrez la page de statut par un tunnel SSH — `ssh -L 8080:127.0.0.1:8080 root@<ip>` — puis `http://localhost:8080`. Pour une page de statut destinée à vos clients, il faut proxifier Gatus vous-même derrière nginx avec HTTPS et un sous-domaine comme `status.votre-domaine.com` ; le monitoring interne et les alertes, eux, fonctionnent dès le déploiement sans domaine.

Connectez-vous en SSH à votre VPS : Gatus est installé dans `/opt/gatus` et sa configuration vit dans le volume Docker nommé `gatus-config`. L'image Gatus n'embarque pas de shell : éditez le fichier via le conteneur d'initialisation, `cd /opt/gatus && docker compose run --rm gatus-init vi /config/config.yaml`, et ajoutez un nouveau bloc sous `endpoints:` avec l'URL, l'intervalle et les conditions. Relancez avec `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 catalogue ServOrbit 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 `/api/docs/<docId>/tables/<tableName>/records`. Sur ServOrbit, Grist n'a pas d'URL publique (port 8484 publié sur 127.0.0.1 seulement) : depuis le VPS, appelez `http://127.0.0.1:8484/api/docs/…` ; depuis votre poste, ouvrez d'abord un tunnel `ssh -L 8484:127.0.0.1:8484 root@<ip>` puis utilisez `http://localhost:8484/api/docs/…`. 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 ou tout client HTTP qui atteint ce port. 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, et c'est le cas par défaut sur ServOrbit : la recette ne publie pas le port de transfert 22000 (seule l'interface 8384 est publiée, sur 127.0.0.1). Syncthing bascule alors automatiquement sur les serveurs de relais mondiaux, et la synchronisation fonctionne avec une légère augmentation de latence. Ouvrir le port 22000 dans le pare-feu VPS ne suffit donc pas pour une connexion directe : il faudrait aussi recréer le conteneur en SSH en publiant ce port — 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 — mais aucune URL n'est attribuée à Windmill : l'interface (port 8000, publié sur 127.0.0.1 seulement) s'ouvre par un tunnel SSH, `ssh -L 8000:127.0.0.1:8000 root@<ip>`, puis `http://localhost:8000`. Un nom de domaine en HTTPS, avec un reverse-proxy à configurer vous-même, devient nécessaire 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 s'installe sans domaine, mais ServOrbit ne lui attribue alors aucune URL : son port 5173 n'est publié que sur 127.0.0.1. Accédez-y par un tunnel SSH — `ssh -L 5173:127.0.0.1:5173 root@<ip>` — puis `http://localhost:5173`. Un domaine (avec un reverse-proxy HTTPS à configurer vous-même) reste recommandé pour une URL mémorisable et un 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. Si la RAM est comptée, vous pouvez désactiver cette fonctionnalité en ajoutant `DISABLE_NEXT_GENERATION_ARCHIVAL=true` à la section `environment` du `docker-compose.yml` de `/opt/linkwarden` (en SSH — pas depuis l'espace client), puis `docker compose up -d`, 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, ajoutez la variable `DISABLE_NEW_SIGN_UPS=true` à la section `environment` du `docker-compose.yml` de `/opt/linkwarden`, en SSH (elle ne s'édite pas depuis l'espace client), puis lancez `docker compose up -d`. 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`.

Oui, en dehors de l'offre revendeur, qui est de l'hébergement mutualisé cPanel/WHM sans VPS. Vous commandez des VPS depuis votre espace client, au tarif public — il n'existe ni tarif grossiste ni remise sur volume —, y déployez une app de la Marketplace (Mattermost, Nextcloud…) ou vos propres stacks via vos scripts ou images Docker, puis les livrez à vos clients au prix que vous fixez. Le VPS est non managé : l'installation, la maintenance et le support de vos clients restent à votre main. Pour en parler, contactez notre équipe commerciale à [email protected].

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 n'exige pas de domaine sur ServOrbit, mais aucune URL ne lui est attribuée : son port 9000 n'est publié que sur 127.0.0.1, pas sur l'adresse IP du VPS. Pour un usage personnel, ouvrez-le par un tunnel SSH (`ssh -L 9000:127.0.0.1:9000 root@<ip>`, puis `http://localhost:9000`). Un accès depuis Internet avec un certificat TLS valide demande un domaine et un reverse-proxy, à configurer vous-même.

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) — à orchestrer avec le déploiement Docker Compose officiel de Plane (Plane n'est pas encore proposé à la commande sur la Marketplace 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 n'exige pas de domaine sur ServOrbit — mais aucune URL ne lui est alors attribuée : son port (8085 par défaut) n'est publié que sur 127.0.0.1, pas sur l'adresse IP du VPS. Accédez-y par un tunnel SSH : `ssh -L 8085:127.0.0.1:8085 root@<ip>`, puis `http://localhost:8085`. Pour un accès chiffré depuis Internet, le reverse-proxy HTTPS est à configurer vous-même : ServOrbit ne le pose pas pour cette app.

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.

Oui, sur des VPS que vous commandez depuis votre espace client — l'offre revendeur ServOrbit, elle, est de l'hébergement mutualisé cPanel/WHM, sans VPS. Déployez Vikunja depuis la Marketplace, ou installez Plane vous-même : Plane n'est pas proposé à la commande sur la Marketplace. Vous livrez ensuite l'outil à vos clients sous votre propre domaine et fixez librement votre prix, les VPS étant facturés au tarif public, sans tarif grossiste. Pour toute question, contactez notre équipe commerciale à [email protected] ou ouvrez un ticket depuis votre espace client.

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 n'exige pas de domaine sur ServOrbit, mais aucune URL ne lui est alors attribuée et aucun nginx n'est posé : Planka écoute sur le port 1337, publié sur 127.0.0.1 seulement. Accédez-y par un tunnel SSH — `ssh -L 1337:127.0.0.1:1337 root@<ip>` — puis ouvrez `http://localhost:1337`. Un accès HTTPS sur votre propre domaine est à configurer vous-même (reverse-proxy et certificat TLS).

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.

Oui, vous pouvez déployer Mattermost ou Rocket.Chat sur un VPS dédié à chaque client et les inclure dans votre offre. Les deux sont disponibles en templates VPS dans la Marketplace, ce qui accélère le déploiement. Les VPS se commandent depuis votre espace client, au tarif public : ils ne font pas partie de l'offre revendeur, qui est de l'hébergement mutualisé cPanel/WHM. Pour un accompagnement sur l'architecture ou la facturation, contactez notre service des ventes via [email protected].

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.

Docmost est disponible en template VPS dans la Marketplace ServOrbit : vous pouvez déployer une instance par client sur un VPS dédié et la servir sous votre propre sous-domaine. C'est vous qui gérez ce sous-domaine et l'interface de Docmost ; rien, côté ServOrbit, ne s'applique automatiquement aux applications déployées sur un VPS. Les VPS se commandent depuis votre espace client, au tarif public : ils ne font pas partie de l'offre revendeur, qui est de l'hébergement mutualisé cPanel/WHM.

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 (`/opt/huginn`). 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, la Marketplace installe et désinstalle l'application ; les mises à jour se font ainsi, en SSH.

Oui. Vaultwarden est disponible en template VPS dans la Marketplace : commandez un VPS dédié, déployez-y Vaultwarden sous votre propre domaine et présentez-le à vos clients sous votre marque. Chaque organisation cliente reçoit sa propre instance ou sa propre organisation Vaultwarden, ce qui isole les coffres. Le VPS est facturé au tarif public, sans tarif grossiste, et vous fixez librement votre prix. Pour toute question, contactez notre équipe commerciale à [email protected].

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.

Oui, Open WebUI et LibreChat sont disponibles en templates VPS dans la Marketplace ServOrbit.com. Chaque déploiement tourne sur un VPS dédié avec accès root, que vous commandez depuis votre espace client : vous pouvez personnaliser l'interface, gérer les accès et connecter vos propres clés API. Les conversations et l'historique restent sur ce VPS ; seules les requêtes envoyées à un fournisseur d'IA externe (OpenAI, Anthropic…) quittent la machine. Pour un accompagnement sur mesure, demandez un devis via le formulaire de contact.

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.

Oui : sur un VPS ServOrbit, vous pouvez déployer depuis la Marketplace des outils de monitoring — Grafana, Uptime Kuma et Gatus y sont disponibles en templates VPS — et en donner l'accès à vos clients sous votre propre domaine. Le VPS se commande depuis votre espace client, en dehors de l'offre revendeur, qui est de l'hébergement mutualisé cPanel/WHM ; son accès root vous laisse la main sur la machine et les applications installées, y compris leur apparence lorsque l'outil permet de la personnaliser. Gérez les accès par client en créant des organisations ou des espaces de travail distincts selon l'outil choisi.

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…). CapRover n'est pas encore proposé à la commande sur la Marketplace ServOrbit ; vous pouvez l'installer vous-même sur votre VPS ServOrbit en suivant sa documentation officielle.

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 dès la fin de son installation. 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.

Une fois CapRover installé sur votre VPS, accédez à `http://<IP-de-votre-VPS>:3000` dans votre navigateur. La page de connexion s'affiche immédiatement. CapRover ne demande aucun identifiant, seulement un mot de passe : celui défini à l'installation ; lorsque l'installation passe par la Marketplace ServOrbit, il est généré pour votre serveur et vous le retrouvez dans la section Applications de votre espace client (bouton « Révéler »). Configurez ensuite votre domaine wildcard pour accéder au panneau via `captain.mondomaine.com`, activez HTTPS pour le tableau de bord, puis changez le mot de passe si vous le souhaitez.

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 du volume Docker nommé homepage-config, monté sur /app/config dans le conteneur (l'app est installée dans /opt/homepage sur votre VPS). Pour les modifier en SSH : `cd /opt/homepage && docker compose exec homepage vi /app/config/services.yaml`. 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. Le plus petit VPS ServOrbit, VPS Start (4 GB RAM), couvre donc ces besoins, usage d'équipe compris.

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.

En tant que revendeur ServOrbit, vous commandez un VPS pour le compte de votre client depuis votre Espace agence, installez Chatwoot via la marketplace ou manuellement, puis fixez librement votre prix de revente. La commande du VPS est réglée depuis le portefeuille de votre agence, au tarif public majoré de votre marge éventuelle — il n'existe pas de tarif grossiste ; vous gérez la facturation client avec votre propre outil (Dolibarr, Stripe…). Pour simplifier, vous pouvez créer le compte de votre client depuis votre Espace agence afin qu'il gère lui-même ses accès.

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. Le plus petit VPS ServOrbit, VPS Start (4 GB RAM), suffit donc largement pour un usage individuel ou en équipe de deux à trois personnes, y compris pour des workspaces très liés (plusieurs milliers de blocs, nombreux graphes) qui demandent plutôt 2 Go. 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, placez Semaphore UI derrière un reverse proxy HTTPS, avec un domaine ou un sous-domaine qui pointe vers votre VPS. Semaphore UI n'est pas encore proposé à la commande sur la Marketplace ServOrbit : ces indications valent pour une installation que vous réalisez vous-même sur votre VPS.

Semaphore UI n'est pas encore proposé à la commande sur la Marketplace ServOrbit. Lorsque l'installation passe par la Marketplace, ServOrbit génère automatiquement un mot de passe admin (`ADMIN_PASSWORD`) au provisionnement, le transmet à Semaphore UI via la variable d'environnement `SEMAPHORE_ADMIN_PASSWORD` et vous le retrouvez dans votre coffre de credentials ServOrbit ; si vous installez Semaphore UI vous-même sur votre VPS, définissez cette variable dans votre configuration Docker. Dans les deux cas, 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. Le domaine de Saleor Commerce 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. Faites pointer votre domaine vers votre VPS **avant** de déployer. Saleor Commerce n'est pas encore proposé à la commande sur la Marketplace ServOrbit : vous pouvez l'installer vous-même sur votre VPS.

Le tableau de bord Saleor est accessible à la racine de votre domaine : `https://votre-domaine/`. Lorsque l'installation passe par la Marketplace ServOrbit, les identifiants sont générés automatiquement au déploiement et affichés dans votre espace client (Saleor Commerce n'y est pas encore proposé à la commande ; si vous l'installez vous-même, ce sont ceux que vous avez définis). 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. L'installation vous demande donc une adresse : un sous-domaine de l'un de vos domaines ou le sous-domaine gratuit fourni avec votre VPS — ServOrbit pose l'enregistrement DNS, nginx et le certificat HTTPS. Choisissez d'emblée l'adresse définitive : la changer ensuite fausserait les liens internes générés par Flarum (invitations, notifications e-mail, partages).

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. Les variables d'environnement et les ports ne s'éditent pas depuis l'espace client : pour les ajuster après l'installation, modifiez en SSH le fichier `.env` ou le `docker-compose.yml` de l'app dans `/opt/<app>`, puis lancez `docker compose up -d`. Le déploiement lui-même ne demande aucune commande Docker manuelle : il 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 installe et désinstalle les templates applicatifs ; leurs mises à jour, comme la gestion fine des images Docker (pull d'un tag spécifique, nettoyage des images non utilisées, inspection des couches), se font 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é.

Qdrant (Rust) se concentre sur la recherche par similarité vectorielle pure avec des filtres de payload — sans schéma ni vectorisation intégrée. Weaviate (Go) ajoute une couche de schéma, des vectorizers intégrés (text2vec-openai, text2vec-cohere, img2vec) qui appellent des modèles d'embedding à l'ingestion, une API GraphQL et un support multimodal natif. Choisissez Qdrant pour les performances brutes sur des vecteurs déjà calculés par votre code ; choisissez Weaviate quand vous voulez que la base gère la vectorisation elle-même, ou quand vous avez besoin de la syntaxe de requête GraphQL.

Weaviate lui-même consomme 400–600 Mo au repos. La mémoire totale dépend de votre index : nombre d'objets, dimension des vecteurs et paramètres HNSW. Un VPS 4 Go gère confortablement des collections de quelques centaines de milliers d'objets en 1536 dimensions (embeddings OpenAI ou Cohere). Pour des millions d'objets, activez la quantification binaire (jusqu'à 32× de réduction) ou utilisez un VPS 8 Go.

Weaviate est lié à `127.0.0.1` — il n'a pas d'adresse publique par défaut. Pour l'atteindre depuis votre poste, ouvrez un tunnel SSH : `ssh -L 8080:127.0.0.1:<port> root@<ip-vps>` (remplacez `<port>` par le port affiché sur la fiche de votre application dans votre espace client). L'API REST et l'API GraphQL répondent ensuite sur `http://localhost:8080`. Vous pouvez aussi appeler Weaviate directement depuis une application qui tourne sur le même VPS, sans tunnel, via `http://127.0.0.1:8080`.

Weaviate expose les deux. L'API GraphQL est recommandée pour les requêtes de similarité (`nearVector`, `nearText`, `nearImage`) et la récupération d'objets avec filtres — c'est ce qu'utilisent LangChain et LlamaIndex. L'API REST est plus pratique pour la gestion du schéma (`/v1/schema`), l'import en lot (`/v1/batch/objects`) et les opérations CRUD sur des objets individuels. Les deux sont accessibles sur le port 8080 ; le port 50051 est réservé au protocole gRPC, utilisé par les clients officiels Go, Python et TypeScript pour des performances accrues.

Par défaut, ce déploiement Weaviate utilise `DEFAULT_VECTORIZER_MODULE=none` : vous fournissez vos propres vecteurs à l'import. Pour activer un module cloud, il faut ajouter les variables d'environnement correspondantes au conteneur — elles ne s'éditent pas depuis votre espace client : Weaviate tourne dans un conteneur `weaviate` lancé par `docker run`, que vous recréez en SSH avec les variables voulues, en reprenant ses ports et son volume `weaviate_data`. Exemple pour text2vec-openai : ajoutez `-e ENABLE_MODULES=text2vec-openai` et `-e OPENAI_APIKEY=<votre-clé>`. Weaviate appellera alors l'API d'OpenAI à chaque import ou requête `nearText`. Consultez la documentation Weaviate pour la liste complète des modules disponibles et leurs variables.

Non. L'inférence fonctionne sur CPU uniquement via Ollama. Un processeur serveur moderne traite un modèle 7B Q4_K_M à 2–5 tokens/seconde — utilisable pour du Q&A documentaire où la précision prime sur la vitesse. Pour une inférence plus rapide sur de plus grands modèles, un VPS avec GPU accélère le débit de 10 à 30 fois.

Pour du Q&A documentaire général sur CPU : `qwen2.5:7b` ou `mistral:7b` (Q4_K_M, ~4–5 Go). Pour des documents longs (juridiques, techniques) : `llama3.1:8b`. Pour un démarrage léger avec 8 Go de RAM : `qwen2.5:3b` (~2,3 Go). Pour les embeddings : `nomic-embed-text` (270 Mo) offre une excellente qualité de récupération sémantique.

Oui. Définissez la variable d'environnement `OPENAI_API_BASE=https://api.openai.com/v1` et fournissez votre `OPENAI_API_KEY`. Le pipeline RAG utilisera alors OpenAI pour les embeddings et la génération, tandis que vos documents restent indexés localement sur le VPS.

Oui. PrivateGPT embarque un moteur de stockage vectoriel intégré qui conserve vos fragments indexés sur disque dans le volume Docker `private-gpt-data`. Vous n'avez pas besoin de lancer un conteneur Qdrant ou ChromaDB séparé. L'index survit aux redémarrages du conteneur.

PrivateGPT est lié à `127.0.0.1` — il n'a pas d'adresse publique par défaut. Pour l'atteindre depuis votre poste, ouvrez un tunnel SSH : `ssh -L 8080:127.0.0.1:<port> root@<ip-vps>` (remplacez `<port>` par le port affiché dans votre espace client ServOrbit), puis ouvrez `http://localhost:8080/ui`. Pour une URL HTTPS permanente, associez un domaine depuis votre espace client.

Non. Airflow est un orchestrateur de workflows, pas un moteur de calcul. Il planifie et monitore des tâches Python sur CPU — les tâches elles-mêmes peuvent appeler des API GPU ou des clusters Spark, mais Airflow n'a besoin que de RAM et de CPU standard.

LocalExecutor exécute les tâches en parallèle dans des processus locaux sur le même serveur que le scheduler — idéal pour des centaines de tâches par jour sur un seul VPS, sans Redis. CeleryExecutor distribue les tâches sur plusieurs workers distants — nécessaire pour des milliers de tâches concurrentes ou plusieurs serveurs. Pour un usage courant sur un VPS ServOrbit, LocalExecutor est la recommandation.

En mode LocalExecutor, comptez 1 à 2 Go de RAM au repos (webserver + scheduler + PostgreSQL). Pour des DAG Python chargeant pandas ou de gros fichiers, prévoyez 4 Go afin d'avoir de la marge pour les processus de tâches. Le mode CeleryExecutor — avec workers et Redis — réclame 4 à 8 Go selon le nombre de workers.

Ouvrez un tunnel SSH : `ssh -L 8080:127.0.0.1:<port> root@<ip-vps>` (remplacez `<port>` par le port affiché dans votre espace client), puis accédez à `http://localhost:8080`. Pour une URL publique permanente, attachez un domaine dans votre espace client — nginx proxifiera vers Airflow et provisionnera un certificat TLS automatiquement.

Oui. Construisez une image Docker dérivée de `apache/airflow:3.3.0` avec un fichier `requirements.txt` : ajoutez une ligne `FROM apache/airflow:3.3.0` puis `RUN pip install --no-cache-dir votre-package`. Utilisez cette image dans votre compose à la place de l'image officielle. C'est la méthode recommandée — installer des paquets au runtime est lent et non reproductible.

Non. Verdaccio écoute sur le port 4873 en interne et est accessible via un tunnel SSH sans domaine : `ssh -L 4873:127.0.0.1:<port> root@<ip-vps>`. Pour un accès permanent à toute l'équipe ou vos pipelines CI, rattachez un domaine depuis votre espace client ServOrbit — nginx le proxifiera en HTTPS automatiquement.

Oui. Verdaccio implémente le protocole npm complet. Yarn et pnpm supportent tous deux la configuration d'un registre personnalisé : l'option `--registry` en ligne de commande, `registry=` dans `.npmrc`, ou `npmRegistryServer:` dans `.yarnrc.yml` pour Yarn 2+. Aucun plugin supplémentaire n'est nécessaire.

Non. Verdaccio proxifie npmjs.org par défaut : toute demande de package absent du registre local est transmise au registre public, mise en cache, puis servie. Vous continuez à utiliser tous les packages publics normalement, et vos packages privés restent sur votre VPS.

Tirez la nouvelle image et redémarrez le conteneur : `docker compose pull && docker compose up -d`. Verdaccio stocke tous les packages dans le volume Docker `verdaccio-storage`, qui est préservé entre les mises à jour d'image — aucune migration de données n'est nécessaire.

Créez d'abord un compte avec `npm adduser --registry https://votre-verdaccio.com`, puis authentifiez-vous avec `npm login --registry https://votre-verdaccio.com`. Dans votre package, ajoutez `"name": "@votre-org/nom-du-package"` dans `package.json` et vérifiez que votre `.npmrc` contient `@votre-org:registry=https://votre-verdaccio.com`. Publiez avec `npm publish`. Les packages scopés sous `@votre-org/*` seront automatiquement routés vers votre registre Verdaccio.

Unleash est une plateforme de feature flags open source (Apache-2.0) qui vous permet d'activer ou désactiver des fonctionnalités dans votre application en temps réel, sans redéploiement. Concrètement, vous encapsulez une nouvelle fonctionnalité derrière un toggle dans votre code, et c'est l'interface Unleash qui décide si ce toggle est actif ou non pour chaque utilisateur. Vous pouvez ainsi déployer du code en production de façon sereine, activer la fonctionnalité progressivement (rollout à 5 %, 20 %…), cibler un segment d'utilisateurs spécifique, ou déclencher un kill switch immédiat en cas de problème — sans toucher au code ni relancer un déploiement.

Unleash propose des SDKs officiels pour Node.js, Python, Java, Go, .NET (C#), Ruby, PHP, iOS (Swift) et Android (Kotlin). La communauté maintient également des SDKs pour Rust, Elixir, Clojure et d'autres langages. Tous les SDKs officiels implémentent le même algorithme d'évaluation et évaluent les flags localement dans votre application — sans aucun round-trip réseau par requête, pour une latence nulle.

Dans l'interface Unleash, ouvrez votre flag, puis cliquez sur **Add strategy** dans l'environnement cible (ex. `production`). Sélectionnez la stratégie **Gradual rollout** et positionnez le curseur sur le pourcentage souhaité (ex. 10 %). Unleash utilise un hash du `userId` pour garantir que le même utilisateur voit toujours le même résultat — la même 10 % voit la feature à chaque visite. Vous pouvez augmenter progressivement ce pourcentage depuis l'interface sans modifier votre code ni redéployer votre application.

Tirez la nouvelle image et redémarrez les conteneurs : `docker compose pull && docker compose up -d`. Les migrations de base de données PostgreSQL s'exécutent automatiquement au démarrage de la nouvelle version — aucune intervention manuelle n'est nécessaire. Le volume PostgreSQL (`unleash-db`) est préservé entre les mises à jour, donc aucune donnée (projets, flags, stratégies, métriques) n'est perdue. Consultez le changelog Unleash sur GitHub avant chaque mise à jour majeure pour repérer d'éventuels breaking changes dans l'API SDK.

Les variables d'environnement nécessitent un redéploiement complet de votre application pour changer de valeur. Unleash évalue les flags à l'exécution via le SDK : vous modifiez un toggle dans l'interface et toutes les instances de votre application en cours d'exécution le prennent en compte en quelques secondes — sans toucher au binaire, sans redéploiement, sans downtime. De plus, Unleash permet des règles complexes impossibles avec des variables d'environnement : rollout progressif par pourcentage, ciblage par userId, par plan tarifaire, par pays. Et chaque changement est tracé dans le log d'audit avec l'auteur et l'horodatage.

Blinko est une application de prise de notes open-source (GPL-3.0) propulsée par l'IA. Elle organise vos notes sous forme de cartes atomiques — une idée par carte — avec recherche plein texte et recherche sémantique intégrée. En connectant un modèle Ollama ou tout endpoint compatible OpenAI, vous pouvez poser des questions en langage naturel sur l'ensemble de votre historique de notes. Tout reste sur votre VPS, sans compte cloud ni abonnement.

Non. Blinko publie son port uniquement sur localhost (127.0.0.1), ce qui signifie qu'aucun domaine n'est requis. Sans domaine, ouvrez un tunnel SSH depuis votre machine locale : `ssh -L 1111:127.0.0.1:<port> root@<ip-vps>` (le port réel est affiché dans votre espace client ServOrbit, pas nécessairement 1111), puis ouvrez `http://localhost:1111` dans votre navigateur. Pour un accès permanent depuis plusieurs appareils, rattachez l'un de vos domaines depuis votre espace client — nginx proxifie le conteneur en HTTPS avec renouvellement automatique du certificat — ou utilisez le sous-domaine gratuit `{app}.{dns_slug}.servorbit-dns.com` inclus avec chaque VPS.

Blinko et sa base de données PostgreSQL consomment ensemble environ 400 à 600 Mo de RAM au repos. Un VPS de 1 vCPU et 1 Go de RAM suffit pour une instance mono-utilisateur ou une petite équipe. Si vous prévoyez d'activer la recherche IA avec un sidecar Ollama sur le même VPS, prévoyez au moins 4 Go de RAM selon la taille du modèle (les modèles 7B nécessitent généralement 6 à 8 Go). Pour un usage purement client (endpoint OpenAI externe), 1 à 2 Go de RAM restent suffisants même avec la recherche sémantique activée.

Dans Blinko, allez dans Paramètres → IA. Entrez l'URL d'un endpoint compatible OpenAI et le nom du modèle. Deux options : (1) Utiliser l'API OpenAI directement — entrez `https://api.openai.com/v1`, votre clé API et le nom du modèle (ex. `gpt-4o-mini`). (2) Garder tout sur votre serveur — déployez une instance Ollama sur le même VPS depuis le Marketplace ServOrbit (catégorie IA et Machine Learning), puis pointez Blinko sur `http://localhost:<port-ollama>/v1` avec le nom du modèle Ollama téléchargé (ex. `llama3.2`). Une fois configuré, Blinko indexe vos notes existantes sous forme de vecteurs et la barre de recherche comprend les requêtes en langage naturel.

Toutes les données Blinko vivent dans deux volumes Docker : `blinko-db` (base de données PostgreSQL) et `blinko-uploads` (pièces jointes et fichiers uploadés). Pour sauvegarder : (1) Exportez la base avec `docker exec blinko-db-1 sh -c 'pg_dump -U blinko blinko' > backup_$(date +%Y%m%d).sql`. (2) Copiez le dossier de pièces jointes via SFTP. Pour restaurer sur un nouveau VPS : démarrez les conteneurs, puis importez le dump avec `docker exec -i blinko-db-1 psql -U blinko blinko < backup.sql` et rechargez les pièces jointes. Automatisez avec un cron quotidien sur le VPS.

Non, RustDesk peut fonctionner entièrement hors connexion internet lorsque les deux machines sont sur le même réseau local ou lorsqu'un serveur relay (`hbbs`/`hbbr`) est déployé sur votre propre VPS. Dans une configuration self-hosted, le serveur de rendezvous (`hbbs`) et le serveur relay (`hbbr`) sont installés sur votre infrastructure et les clients configurés pour pointer vers ces adresses. Les clients peuvent alors se connecter directement entre eux (connexion P2P) si la topologie réseau le permet, ou passer par votre relay privé. Aucune donnée ne transite par les serveurs publics de RustDesk lorsque votre propre infrastructure est correctement configurée.

Khoj est un assistant IA open source (AGPL-3.0) que vous hébergez sur votre propre VPS. Il indexe automatiquement vos notes Obsidian, documents PDF et emails pour vous permettre de poser des questions en langage naturel sur votre base de connaissance privée. Il embarque aussi des agents autonomes capables de rechercher sur le web et d'agréger des sources externes.

Oui, une adresse est nécessaire — mais pas forcément un domaine acheté. Khoj l'utilise pour ses URLs d'authentification, ses liens de partage et ses callbacks de tâches planifiées. À l'installation, choisissez un sous-domaine de l'un de vos domaines ou le sous-domaine gratuit fourni avec votre VPS : ServOrbit pose l'enregistrement DNS, nginx et le certificat HTTPS. Seule exception : si la zone DNS de votre domaine n'est pas gérée par ServOrbit, faites d'abord pointer un enregistrement A vers l'IP de votre VPS.

ServOrbit crée un compte admin initial avec l'adresse email [email protected] et un mot de passe aléatoire affiché dans votre espace client. Connectez-vous à l'interface web sur votre domaine, rendez-vous dans Paramètres pour configurer un LLM (Ollama ou OpenAI), puis créez votre propre compte utilisateur si besoin.

Khoj est compatible avec Ollama (modèles locaux comme Llama 3, Mistral ou Qwen), OpenAI et Anthropic. Pour un usage 100 % local sans coût API, installez Ollama sur le même VPS ou une machine du réseau et configurez-le dans Paramètres → LLM. Pour de meilleures performances, une clé OpenAI (gpt-4o-mini) fonctionne très bien.

Khoj nécessite au minimum 4 Go de RAM et 2 vCPUs. Le service charge des modèles d'embedding au démarrage et utilise PostgreSQL avec pgvector pour le stockage vectoriel. Prévoyez 20 Go de disque comme base, plus de l'espace selon le volume de documents à indexer. Khoj ne nécessite pas de GPU : l'inférence LLM est déléguée à votre LLM configuré.

ArchiveBox est un outil d'archivage web open source (MIT) qui vous permet de sauvegarder des pages web, articles, vidéos et médias directement sur votre VPS. Au lieu de compter sur des services tiers comme Pocket ou Archive.org, vous stockez vos archives dans votre propre infrastructure : chaque URL que vous soumettez génère une capture en HTML, PDF, capture d'écran PNG, WARC et texte brut. Vous pouvez ensuite retrouver ces pages même si elles ont disparu du web, les partager avec votre équipe via des liens signés, ou les utiliser comme preuves numériques dans un contexte légal.

ArchiveBox écoute sur le port 5797 (serveur ASGI Daphne) en interne, uniquement sur l'interface loopback (127.0.0.1) — il n'est pas directement exposé sur internet. Pour accéder à l'interface depuis votre navigateur, ouvrez un tunnel SSH : `ssh -L 5797:127.0.0.1:<port-exposé> root@<ip-vps>` puis naviguez sur `http://localhost:5797/`. L'interface d'administration est à `/admin/`. Pour un accès permanent sans tunnel, rattachez un domaine ou sous-domaine depuis votre espace client ServOrbit : nginx proxifiera le trafic en HTTPS automatiquement.

Pour chaque URL soumise, ArchiveBox peut produire simultanément : un miroir HTML complet via wget (avec assets CSS/JS/images), une capture HTML autonome en un seul fichier via SingleFile, une capture d'écran PNG pleine page, un PDF (rendu Chromium), un fichier WARC conforme ISO 28500 avec index CDX, un JSON du DOM JavaScript final, et du texte brut indexé pour la recherche plein texte. yt-dlp est également intégré pour l'archivage vidéo (YouTube, Vimeo, Twitter, etc.). Chaque extracteur peut être activé ou désactivé globalement dans le fichier `.env` ou par URL depuis l'interface web.

Non, ArchiveBox ne nécessite pas de domaine pour fonctionner. Par défaut, le conteneur écoute sur le loopback (127.0.0.1) et est accessible en ouvrant un tunnel SSH depuis votre poste de travail. C'est suffisant pour un usage solo. Si vous souhaitez un accès permanent depuis n'importe quel navigateur ou depuis votre équipe, vous pouvez rattacher un sous-domaine depuis votre espace client ServOrbit : le serveur nginx est configuré automatiquement et un certificat TLS Let's Encrypt est provisionné. Une fois le domaine actif, pensez à mettre à jour la variable `ARCHIVEBOX_CSRF_TRUSTED_ORIGINS` dans votre compose pour éviter les erreurs CSRF.

La mise à jour se fait en deux commandes depuis votre VPS : `docker compose pull` pour télécharger la nouvelle image, puis `docker compose up -d` pour recréer le conteneur avec la nouvelle version. ArchiveBox exécute automatiquement les migrations Django au démarrage — vos données d'archive dans le volume `archivebox-data` sont préservées intégralement. Consultez les notes de version sur le dépôt GitHub avant chaque mise à jour majeure pour vérifier les éventuelles migrations de schéma ou changements de configuration. En cas de problème, le volume `archivebox-data` est indépendant du conteneur : vous pouvez revenir à l'image précédente avec `docker compose up -d --image <version>` sans perdre vos archives.

Teable est une alternative open source à Airtable (AGPL-3.0). Comme Airtable, il propose des vues grille, kanban, galerie et formulaire pour organiser vos données de façon visuelle. La différence majeure est que Teable stocke chaque table directement dans PostgreSQL — vous disposez donc d'un accès SQL complet à vos données, d'une portabilité totale et d'un coût nul par utilisateur ou par ligne. Sur ServOrbit, Teable tourne sur votre propre VPS : vos données ne quittent jamais votre infrastructure.

Après le déploiement, naviguez vers l'URL fournie par ServOrbit. Teable affiche une page d'inscription : le premier compte créé devient propriétaire de l'espace de travail. Il n'existe pas de compte administrateur prédéfini — vous choisissez vos identifiants lors de cette première inscription. Une fois connecté, vous pouvez inviter des collaborateurs depuis les paramètres de l'espace de travail et définir leurs rôles (visualiseur, éditeur ou propriétaire).

Chaque table Teable expose automatiquement une API REST. Depuis l'interface Teable, ouvrez Paramètres → Jetons d'API pour générer un jeton d'accès. L'API suit le standard REST (GET, POST, PATCH, DELETE) sur `/api/table/{tableId}/record`. Vous pouvez connecter cette API à des outils d'automatisation comme n8n ou Zapier, ou l'appeler directement depuis votre application backend pour lire ou écrire des données en temps réel.

Les trois outils sont complémentaires. NocoDB se connecte à une base de données PostgreSQL ou MySQL existante et l'expose en tableur collaboratif — idéal si vous avez déjà un schéma à visualiser. Grist adopte le modèle « document avec formules Python », plus puissant pour l'analyse. Teable crée ses propres tables PostgreSQL depuis zéro et mise sur la collaboration visuelle en temps réel — c'est le plus proche de l'expérience Airtable. Choisissez NocoDB pour wraper l'existant, Grist pour l'analyse, Teable pour créer une nouvelle base collaborative.

Teable nécessite au minimum 2 Go de RAM pour faire tourner les trois conteneurs (PostgreSQL 15, Redis 7 et le serveur applicatif). Pour une utilisation confortable avec plusieurs collaborateurs, 4 Go de RAM et 2 vCPUs sont recommandés. Prévoyez au moins 20 Go de disque SSD pour les volumes PostgreSQL et les assets uploadés. Teable ne requiert pas de GPU — toutes les opérations sont effectuées sur le CPU.

Oui. Commandez des VPS depuis votre espace client et déployez-y, via la Marketplace, des solutions collaboratives open source comme Mattermost ou Nextcloud, sans dépendre des licences Microsoft. Ces VPS sont facturés au tarif public et ne font pas partie de l'offre revendeur, qui est de l'hébergement mutualisé cPanel/WHM : vous les refacturez à vos clients au prix que vous fixez. Consultez la page offre revendeur ou contactez-nous à [email protected] pour un accompagnement adapté.

Teable propose une compatibilité partielle avec l'API Airtable. L'import via l'API Airtable (endpoint REST) est pris en charge nativement dans Teable : vous renseignez votre clé API Airtable et l'identifiant de votre base, et Teable reconstruit les tables, les champs et les enregistrements. Les types de champs courants (texte, nombre, date, case à cocher, sélection unique et multiple, lien entre tables) sont mappés automatiquement. En revanche, certaines fonctionnalités Airtable sans équivalent direct dans Teable ne sont pas importées : les automatisations, les interfaces et les scripts. Les pièces jointes sont téléchargées et stockées localement sur votre VPS ServOrbit. Pour une base de moins de 50 000 enregistrements, l'import complet prend généralement moins de 10 minutes. Le template Teable est disponible sur /applications/bases-de-donnees/teable. Après la migration, vérifiez les vues filtrées et les formules calculées — leur syntaxe diffère légèrement entre les deux outils.

Plane et Kaneo répondent à des besoins différents. Plane est un outil de gestion de projet complet, concurrent d'Asana et Jira : il propose des cycles (sprints), des modules (epics), une roadmap, des vues multiples (liste, tableau kanban, calendrier, feuille de calcul), un suivi du temps, des rapports analytiques et une API riche. C'est le bon choix pour des équipes produit ou logiciel qui gèrent des backlogs complexes. Kaneo est un outil minimaliste orienté kanban : tableau de colonnes, tâches, étiquettes, assignés — c'est tout. Son interface est délibérément épurée, sa prise en main est immédiate et ses ressources serveur sont très faibles (moins de 256 Mo de RAM). C'est le bon choix pour une petite équipe ou un projet solo qui veut un tableau visuel sans la complexité d'un outil complet. Sur ServOrbit, Kaneo est disponible sur VPS depuis /applications/collaboration/kaneo ; Plane n'est pas encore proposé à la commande sur la Marketplace, mais vous pouvez l'installer vous-même sur votre VPS. Si vous hésitez, commencez par Kaneo — il est plus simple de migrer vers Plane ensuite que de revenir en arrière.

Penpot est disponible dans la marketplace ServOrbit comme application prête à déployer. Depuis votre espace VPS, sélectionnez Penpot, choisissez votre VPS de destination (minimum 4 Go RAM recommandé) et lancez l'installation en un clic. ServOrbit configure automatiquement Docker, le reverse proxy nginx et le certificat TLS. Vous obtenez une instance Penpot privée avec vos propres comptes utilisateurs, idéale pour remplacer Figma sans abonnement mensuel.

Headscale est un serveur de coordination open source compatible Tailscale qui vous permet de gérer votre propre réseau mesh privé sans dépendre d'un service cloud tiers. Disponible dans la marketplace ServOrbit, il s'installe en un clic sur votre VPS et vous donne un contrôle total sur l'accès réseau entre vos machines. C'est la solution idéale pour sécuriser l'accès à vos services internes (bases de données, back-offices) sans exposer de ports publics.

Oui. Flowise est disponible dans la Marketplace ServOrbit (catégorie Automatisation) : vous pouvez le déployer sur un VPS directement depuis sa fiche. LangFlow et n8n y sont également proposés si vous préférez une autre approche pour construire des flux d'agents IA.

Oui. BookStack est un logiciel open source sous licence MIT : son déploiement, y compris pour vos clients, ne génère aucun surcoût de licence. Chaque instance tourne sur son propre VPS, isolée des autres, et se déploie depuis le template BookStack de notre Marketplace. Les VPS se commandent depuis votre espace client, au tarif public — ils ne font pas partie de l'offre revendeur, qui est de l'hébergement mutualisé cPanel/WHM —, et vous fixez librement le prix facturé à vos clients.

Baserow est une plateforme no-code open source (MIT) qui vous permet de créer des bases de données visuelles sans écrire de SQL. Vous organisez vos données en tables et en champs (texte, nombre, date, pièce jointe, formule…), vous invitez votre équipe, vous basculez entre plusieurs vues (grille, kanban, galerie, formulaire) et vous exposez chaque table via une API REST auto-générée. Pensez à Airtable, mais hébergé sur votre propre VPS, sans limite de lignes et sans abonnement par siège.

Non, Baserow n'exige pas de nom de domaine pour démarrer. Baserow n'est pas encore proposé à la commande sur la Marketplace ServOrbit ; si vous l'installez vous-même sur votre VPS, vous pouvez y accéder par l'adresse IP du serveur, puis, pour une URL personnalisée en HTTPS, faire pointer un domaine ou un sous-domaine vers votre VPS et placer Baserow derrière un reverse proxy avec un certificat TLS.

Le conteneur tout-en-un Baserow (Django, Celery, Redis et PostgreSQL) démarre avec environ 700 Mo de RAM au repos. Un VPS de 2 Go convient à une petite équipe (5–10 utilisateurs). Pour des espaces de travail plus importants, un trafic API soutenu ou l'importation de fichiers volumineux, 4 Go de RAM et 2 vCPUs sont recommandés. Aucun GPU n'est nécessaire.

La première fois que vous accédez à votre instance Baserow, une page d'inscription s'affiche. Saisissez votre adresse e-mail et choisissez un mot de passe : le premier compte créé devient administrateur de l'espace de travail. Cette page n'est visible qu'une seule fois — dès qu'un compte existe, les visiteurs suivants voient la page de connexion classique. Créez votre compte immédiatement après l'installation de Baserow.

Connectez-vous à votre VPS en SSH et exécutez : ```bash docker compose pull && docker compose up -d ``` Baserow applique les migrations de base de données automatiquement au démarrage. Vos données dans le volume `baserow-data` sont conservées d'une version à l'autre. Consultez les releases GitHub de Baserow avant de mettre à jour pour connaître les nouveautés et les éventuelles précautions de migration.

Pocket ID n'est pas encore proposé à la commande sur la Marketplace ServOrbit ; vous pouvez l'installer vous-même sur un VPS Ubuntu 24.04 avec Docker. Prévoyez un domaine (obligatoire — OIDC exige HTTPS), déployez le conteneur, configurez nginx en HTTPS et définissez la variable APP_URL. À la fin, visitez https://votre-domaine pour terminer la configuration.

Dans l'interface d'administration Pocket ID, ouvrez OIDC Clients → Nouveau client. Renseignez le nom de l'application et l'URL de callback (ex. https://git.votre-domaine.com/user/oauth2/pocket-id/callback). Pocket ID génère un client ID et un secret à copier dans la configuration OIDC de votre application. Gitea, Nextcloud, Grafana et n8n supportent OIDC nativement.

Toutes les données Pocket ID — utilisateurs, clients OIDC, passkeys et sessions — sont stockées dans un fichier SQLite dans le volume Docker `pocket_id_data`. Sauvegardez le répertoire `/app/data` du conteneur : `docker cp pocket-id:/app/data /chemin/sauvegarde`. Pour une sauvegarde automatique, ajoutez cette commande dans un cron quotidien.

Le protocole OpenID Connect (OIDC) impose que l'émetteur (`issuer`) soit une URL HTTPS valide — il ne peut pas fonctionner en HTTP ni avec une adresse IP. L'APP_URL est figée à la première installation car elle ancre l'identifiant de l'émetteur OIDC : toutes les applications clientes vérifient que les tokens proviennent bien de cette URL. Si vous n'avez pas encore de domaine, vous pouvez utiliser le sous-domaine gratuit ServOrbit fourni avec chaque VPS.

Partiellement. Penpot est un outil de design d'interface vectoriel : il gère les flyers, affiches et mises en page simples mieux que Publisher, mais il n'est pas orienté PAO. Il n'intègre pas de modèles de flux texte multicolonne, de gestion des fonds perdus ni d'export PDF/X pour l'imprimerie offset. Pour des besoins print professionnels complexes, Scribus reste une alternative open source plus adaptée. Pour des communications internes, flyers numériques ou newsletters web, Penpot couvre la majorité des cas.

Depuis votre espace client ServOrbit, rendez-vous dans le Marketplace, sélectionnez Vane dans la catégorie Intelligence Artificielle et cliquez sur Installer. Le script de provisionnement déploie le conteneur Docker, monte le volume de données dans /home/vane/data et configure le reverse proxy nginx. L'application est prête en quelques minutes. Accédez-y via un tunnel SSH (ssh -L 3000:127.0.0.1:3000 root@<ip>) ou depuis votre navigateur si vous avez configuré un domaine.

Vane est agnostique vis-à-vis du LLM : vous pouvez connecter Ollama (modèles locaux tournant sur le même VPS ou un autre serveur), OpenAI, Google Gemini, Groq ou Anthropic. Si vous ne configurez aucun fournisseur, Vane fonctionne en mode recherche seule (résultats SearXNG sans synthèse). Pour les réponses par LLM sans envoyer de données vers un service tiers, installez Ollama sur le même VPS et pointez Vane vers http://localhost:11434 dans Paramètres → Fournisseurs de modèles.

Non. Vane ne nécessite pas de nom de domaine. L'application est accessible via un tunnel SSH depuis votre machine locale : ssh -L 3000:127.0.0.1:3000 root@<ip-de-votre-vps> puis http://localhost:3000 dans votre navigateur. Si vous souhaitez un accès direct depuis le navigateur sans tunnel, configurez un sous-domaine ou domaine personnalisé via ServOrbit.

Toutes les données de Vane — historique des conversations, paramètres et configuration des fournisseurs LLM — sont stockées dans le volume Docker vane-data, accessible à /home/vane/data dans le conteneur. Pour sauvegarder, exécutez sur votre VPS : docker run --rm -v vane_vane-data:/data -v /backup:/backup alpine tar czf /backup/vane-$(date +%Y%m%d).tar.gz -C /data . Pour restaurer, créez d'abord le volume, puis extrayez l'archive dans le volume avant de relancer Vane.

Le calcul part de trois postes : les abonnements SaaS actuels (coût mensuel × nombre d'utilisateurs × nombre d'outils), le coût des VPS qui hébergeront les outils de remplacement, au tarif public, et le temps de migration estimé. Pour chaque client, l'économie nette sur 12 mois correspond à la différence entre l'abonnement annuel remplacé et le coût annuel de ces VPS, dont vous déduisez le temps que vous passerez à les maintenir. Notre équipe commerciale peut vous aider à monter ce calcul via le formulaire Contact → Devis.

Depuis votre espace client ServOrbit, rendez-vous dans le Marketplace, sélectionnez TREK dans la catégorie Collaboration et cliquez sur Installer. Le script de provisionnement déploie le conteneur Docker, monte les volumes de données dans /app/data et /app/uploads et configure le reverse proxy nginx. TREK est prêt en quelques minutes. Le compte administrateur est créé automatiquement au premier démarrage — les identifiants sont disponibles dans votre espace client sous Applications installées → TREK → Identifiants.

Non. TREK ne nécessite pas de nom de domaine. L'application est accessible via un tunnel SSH depuis votre machine locale : ssh -L 3000:127.0.0.1:3000 root@<ip-de-votre-vps> puis http://localhost:3000 dans votre navigateur. Si vous souhaitez un accès direct depuis n'importe quel appareil ou souhaitez activer OIDC et les notifications e-mail, configurez un sous-domaine ou domaine personnalisé via ServOrbit et ajoutez APP_URL dans les variables d'environnement de TREK.

Toutes les données de TREK sont stockées dans deux volumes Docker : trek-data (base de données SQLite et paramètres) et trek-uploads (pièces jointes). Pour sauvegarder, exécutez sur votre VPS : docker run --rm -v trek_trek-data:/data -v /backup:/backup alpine tar czf /backup/trek-data-$(date +%Y%m%d).tar.gz -C /data . Répétez avec trek-uploads pour les pièces jointes. Pour restaurer, créez d'abord les volumes, extrayez les archives dans les volumes respectifs, puis relancez TREK.

Oui. TREK supporte l'authentification unique via OIDC. Pour l'activer, ajoutez dans les variables d'environnement de TREK : OIDC_ISSUER (URL de votre fournisseur), OIDC_CLIENT_ID et OIDC_CLIENT_SECRET. TREK est compatible avec Authentik, Pocket ID, Keycloak et tout fournisseur OIDC standard. Vous pouvez également définir OIDC_ONLY=true pour imposer le SSO comme unique méthode de connexion. APP_URL doit être configuré pour que le callback OIDC fonctionne correctement.

Depuis votre espace client, ouvrez le Marketplace, sélectionnez Termix, choisissez l'adresse d'accès (un sous-domaine de l'un de vos domaines ou le sous-domaine gratuit du VPS) et cliquez sur Installer. Le script déploie le conteneur Docker et configure nginx en HTTPS, WebSockets compris pour le terminal SSH. Comptez 1 Go de RAM au minimum.

Oui, Termix s'ouvre en HTTPS sur un domaine — mais vous n'avez pas à en acheter un. Chaque VPS ServOrbit dispose d'un sous-domaine gratuit (termix.{dns_slug}.servorbit-dns.com) avec certificat HTTPS, que vous pouvez choisir à l'installation. Vous pouvez aussi utiliser un sous-domaine de l'un de vos domaines.

Ouvrez l'adresse HTTPS de Termix dès la fin de l'installation : le formulaire de création de compte s'affiche, et le premier compte créé devient administrateur. Créez-le immédiatement, puis désactivez l'inscription publique dans les paramètres d'administration et activez la double authentification (TOTP) ou une passkey.

Toutes les données de Termix — base SQLite, clés de chiffrement générées au premier démarrage, plugins — sont dans le volume Docker monté sur /app/data. Sauvegardez ce volume (par exemple avec une archive tar planifiée ou les snapshots du VPS) : sans les clés qu'il contient, les identifiants SSH enregistrés ne peuvent plus être déchiffrés.

Depuis votre espace client, ouvrez le Marketplace, sélectionnez Databasus et cliquez sur Installer. Le script déploie le conteneur, qui initialise sa base interne au premier démarrage. Comptez 1 Go de RAM au minimum, plus l'espace disque des sauvegardes si vous les gardez sur le VPS.

Databasus n'exige pas de domaine. Son interface est publiée sur la boucle locale du VPS : ouvrez un tunnel SSH avec `ssh -L 4005:127.0.0.1:4005 root@<ip-du-vps>` (adaptez le port à celui affiché dans l'espace client), puis ouvrez http://localhost:4005. Pour un accès permanent en HTTPS, attachez un domaine ou le sous-domaine gratuit du VPS.

Oui. La recette déclare l'hôte host.docker.internal, qui désigne le VPS depuis le conteneur : indiquez-le comme hôte de la base. Le serveur PostgreSQL ou MySQL doit alors écouter sur l'interface du réseau Docker et autoriser cette connexion ; créez de préférence un utilisateur en lecture seule dédié aux sauvegardes.

Oui, au moins une copie. Une sauvegarde stockée sur le disque du VPS protège contre une erreur humaine, pas contre la perte de la machine. Ajoutez une destination externe — S3, Cloudflare R2, Google Drive, SFTP — et activez le chiffrement AES-256-GCM pour que les fichiers restent illisibles sur ce stockage.

Depuis votre espace client, ouvrez le Marketplace, sélectionnez OpenProject, choisissez l'adresse d'accès (un sous-domaine de l'un de vos domaines ou le sous-domaine gratuit du VPS) et cliquez sur Installer. Le script déploie l'image Docker officielle et configure nginx en HTTPS. Le premier démarrage prend trois à cinq minutes ; prévoyez 4 Go de RAM et 2 vCPU.

Oui, OpenProject s'ouvre en HTTPS sur un domaine et refuse les requêtes adressées à un autre nom — mais vous n'avez pas à en acheter un. Chaque VPS ServOrbit dispose d'un sous-domaine gratuit (openproject.{dns_slug}.servorbit-dns.com) avec certificat HTTPS, que vous pouvez choisir à l'installation. Vous pouvez aussi utiliser un sous-domaine de l'un de vos domaines.

Le compte administrateur est créé à l'installation : identifiant admin, mot de passe généré et affiché dans votre espace client, à côté de l'adresse de l'application. Aucun changement n'est imposé à la première connexion : changez-le vous-même depuis Mon compte, puis activez la double authentification.

Après l'installation, OpenProject n'a pas de serveur d'envoi configuré : les invitations, rappels et notifications ne partent pas. Renseignez un serveur SMTP dans Administration → E-mails et notifications (hôte, port, identifiants), puis envoyez un e-mail de test depuis la même page.

La base PostgreSQL et les pièces jointes sont dans deux volumes Docker, montés sur /var/openproject/pgdata et /var/openproject/assets. Sauvegardez les deux ensemble, conteneur arrêté (ou par les snapshots du VPS), ou utilisez la sauvegarde intégrée dans Administration → Sauvegarde.

Depuis votre espace client, ouvrez le Marketplace, sélectionnez Healthchecks, choisissez l'adresse et cliquez sur Installer. Le script déploie le conteneur, crée le compte administrateur et publie l'application en HTTPS. Un VPS Ubuntu 24.04 avec 1 Go de RAM suffit.

Oui, Healthchecks construit ses URL de ping et les liens de ses alertes sur son adresse. Inutile d'en acheter un : chaque VPS ServOrbit dispose d'un sous-domaine gratuit (healthchecks.{dns_slug}.servorbit-dns.com) avec HTTPS. Vous pouvez aussi utiliser un sous-domaine de l'un de vos domaines.

Ouvrez l'adresse de l'application et connectez-vous avec l'identifiant [email protected] et le mot de passe généré affiché dans votre espace client. Les inscriptions publiques sont fermées : changez l'adresse e-mail et le mot de passe depuis les paramètres du compte, puis invitez votre équipe.

L'envoi d'e-mails demande un serveur SMTP. Ajoutez EMAIL_HOST, EMAIL_PORT, EMAIL_HOST_USER, EMAIL_HOST_PASSWORD et DEFAULT_FROM_EMAIL au fichier .env de l'application, puis redémarrez le conteneur. En attendant, les canaux webhook, Slack, Mattermost, ntfy ou Gotify fonctionnent sans configuration côté serveur.

Depuis votre espace client, ouvrez le Marketplace, sélectionnez Hasura, choisissez l'adresse et cliquez sur Installer. Le script déploie PostgreSQL et le moteur Hasura, génère l'admin secret, connecte la base et publie l'API en HTTPS. Un VPS Ubuntu 24.04 avec 1 Go de RAM suffit pour démarrer.

Oui, l'API de Hasura est appelée par vos frontends et vos applications mobiles : elle doit répondre en HTTPS sur un nom stable. Inutile d'en acheter un : chaque VPS ServOrbit dispose d'un sous-domaine gratuit (hasura.{dns_slug}.servorbit-dns.com) avec HTTPS. Vous pouvez aussi utiliser un sous-domaine de l'un de vos domaines.

Ouvrez https://votre-domaine/console et saisissez l'admin secret affiché dans votre espace client. Il n'y a pas de nom d'utilisateur : ce secret donne tous les droits sur l'API et la base. Ne le placez jamais dans le code d'un frontend ; vos utilisateurs s'authentifient avec un jeton JWT.

Ajoutez HASURA_GRAPHQL_JWT_SECRET au fichier .env de l'application (/opt/hasura), avec l'URL des clés publiques (jwk_url) de votre fournisseur : Logto, Authentik, Zitadel ou Auth0. Relancez avec docker compose up -d, puis définissez les permissions de chaque rôle dans l'onglet Permissions de la console.

Depuis votre espace client, ouvrez le Marketplace, sélectionnez Jenkins, choisissez l'adresse et cliquez sur Installer. Le script déploie Jenkins LTS dans Docker, avec un volume de données dédié, et le publie en HTTPS derrière nginx. Un VPS Ubuntu 24.04 avec 2 Go de RAM suffit pour démarrer.

Oui, Jenkins est partagé par l'équipe et reçoit les webhooks de vos dépôts Git : il doit répondre en HTTPS sur un nom stable. Inutile d'en acheter un : chaque VPS ServOrbit dispose d'un sous-domaine gratuit (jenkins.{dns_slug}.servorbit-dns.com) avec HTTPS. Vous pouvez aussi utiliser un sous-domaine de l'un de vos domaines.

Ouvrez l'adresse HTTPS de Jenkins : l'assistant demande le mot de passe initial d'administration. Il est affiché dans votre espace client, sur la fiche de l'application installée. Installez ensuite les plugins suggérés et créez votre propre compte administrateur ; le mot de passe initial ne sert plus après cette étape.

Pas directement sur le serveur Jenkins installé par le Marketplace : par sécurité, le socket Docker du VPS n'y est pas monté, car il donnerait à n'importe quel build l'accès root au serveur. Branchez un agent de build en SSH, par exemple un second VPS avec Docker, et ciblez-le dans votre Jenkinsfile avec un label.

Depuis votre espace client, ouvrez le Marketplace, sélectionnez Keycloak, choisissez l'adresse et cliquez sur Installer. Le script déploie Keycloak et sa base PostgreSQL dans Docker, avec un volume de données dédié, et le publie en HTTPS derrière nginx. Un VPS Ubuntu 24.04 avec 2 Go de RAM suffit pour démarrer.

Oui. Keycloak signe ses jetons et construit ses redirections OIDC et SAML sur son adresse HTTPS publique, il doit donc répondre sur un nom stable. Inutile d'en acheter un : chaque VPS ServOrbit dispose d'un sous-domaine gratuit (keycloak.{dns_slug}.servorbit-dns.com) avec HTTPS. Vous pouvez aussi utiliser un sous-domaine de l'un de vos domaines.

Ouvrez https://votre-domaine/admin et connectez-vous avec l'identifiant admin et le mot de passe affiché dans votre espace client, sur la fiche de l'application. Ce compte du realm master est temporaire : créez votre propre administrateur avec le rôle admin, puis désactivez le compte d'origine.

Créez un realm dédié à vos applications, puis ajoutez-y un client OpenID Connect : déclarez les URL de redirection de votre application et récupérez son secret. Dans l'application, indiquez l'adresse de découverte https://votre-domaine/realms/<votre-realm>/.well-known/openid-configuration ; la plupart des frameworks configurent le reste à partir d'elle.

Depuis votre espace client, ouvrez le Marketplace, sélectionnez VictoriaMetrics, choisissez l'adresse et cliquez sur Installer. Le script déploie le conteneur officiel, génère le mot de passe de l'utilisateur admin, active l'authentification et publie l'interface en HTTPS. Un VPS Ubuntu 24.04 avec 1 Go de RAM suffit pour démarrer.

Oui : vos serveurs y envoient leurs métriques et Grafana l'interroge, elle doit répondre en HTTPS sur un nom stable. Inutile d'en acheter un : chaque VPS ServOrbit dispose d'un sous-domaine gratuit (victoriametrics.{dns_slug}.servorbit-dns.com) avec un certificat HTTPS. Vous pouvez aussi utiliser un sous-domaine de l'un de vos domaines.

Ouvrez https://votre-domaine/vmui et saisissez l'utilisateur admin et le mot de passe affiché dans votre espace client. Les mêmes identifiants protègent l'API de requête et l'ingestion : Prometheus, vos agents et Grafana les utilisent en authentification basique.

Ajoutez à prometheus.yml un bloc remote_write dont l'URL est https://votre-domaine/api/v1/write, avec basic_auth (utilisateur admin et le mot de passe), puis rechargez Prometheus. Il continue de collecter et duplique chaque point vers VictoriaMetrics. Grafana Alloy, vmagent et Telegraf acceptent la même adresse.

Depuis votre espace client, ouvrez le Marketplace, sélectionnez Kener, choisissez l'adresse et cliquez sur Installer. Le script déploie Kener et son cache Redis, génère la clé secrète des sessions et publie la page de statut en HTTPS. Un VPS Ubuntu 24.04 avec 1 Go de RAM suffit.

Oui, mais pas forcément en acheter un. Kener refuse les requêtes dont l'origine diffère de son adresse HTTPS : il lui faut un nom stable. Chaque VPS ServOrbit dispose d'un sous-domaine gratuit (kener.{dns_slug}.servorbit-dns.com) avec un certificat HTTPS ; vous pouvez aussi utiliser un sous-domaine de l'un de vos domaines, par exemple status.votre-domaine.ma.

Ouvrez https://votre-domaine/account/signin juste après l'installation et remplissez le formulaire « Create Admin Account ». Le premier compte créé devient l'administrateur et le formulaire disparaît ensuite : créez-le sans attendre. Aucun mot de passe n'est généré à l'avance.

Renseignez un serveur SMTP (SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASSWORD, SMTP_SENDER) ou une clé Resend dans le fichier docker-compose.yml de l'application, relancez avec docker compose up -d, puis activez les abonnements dans l'administration de Kener. Vos visiteurs s'inscrivent ensuite depuis la page de statut.

Depuis votre espace client, ouvrez le Marketplace, sélectionnez marimo et cliquez sur Installer. Le script déploie le conteneur officiel avec pandas, polars, numpy et altair, génère le mot de passe de l'éditeur et crée le volume qui conserve vos notebooks. Un VPS Ubuntu 24.04 avec 2 Go de RAM est recommandé.

Le mot de passe de l'éditeur est généré à l'installation et affiché dans votre espace client, sur la fiche de l'application. marimo le demande sur sa page de connexion ; la session reste ensuite ouverte dans votre navigateur. Sur le VPS, il figure aussi dans le fichier .env de la pile, sous la clé ADMIN_PASSWORD.

Oui. marimo n'exige pas de domaine : sans domaine, ouvrez un tunnel SSH (ssh -L 2718:127.0.0.1:<port> root@<ip-du-vps>) puis http://localhost:2718, avec le port affiché dans votre espace client. Pour un accès HTTPS direct, attachez un sous-domaine de l'un de vos domaines ou le sous-domaine gratuit du VPS.

Les notebooks sont de simples fichiers .py enregistrés dans le volume Docker marimo-data, monté sur /app. Le plus sûr est de versionner ce dossier dans un dépôt Git ; vous pouvez aussi archiver le volume, et les sauvegardes du VPS le couvrent comme le reste du disque.

Depuis votre espace client, ouvrez le Marketplace, sélectionnez Kutt, choisissez l'adresse de vos liens courts et cliquez sur Installer. Le script déploie le conteneur officiel, génère la clé secrète des sessions, crée le volume de la base SQLite et configure nginx en HTTPS. Un VPS Ubuntu 24.04 avec 512 Mo de RAM suffit.

Oui, mais pas forcément en acheter un. Kutt forme chaque lien court avec son domaine : sans adresse publique, les liens pointeraient vers une machine locale. Chaque VPS ServOrbit dispose d'un sous-domaine gratuit (kutt.{dns_slug}.servorbit-dns.com) avec un certificat HTTPS ; pour des liens vraiment courts, utilisez plutôt un sous-domaine bref de l'un de vos domaines, par exemple go.votre-domaine.ma.

Ouvrez votre adresse en HTTPS juste après l'installation : Kutt vous redirige vers le formulaire de création du compte administrateur. Saisissez votre e-mail et un mot de passe solide ; le premier compte créé devient l'administrateur, c'est pourquoi il faut le créer sans attendre. Aucun mot de passe n'est généré à l'avance, et les inscriptions publiques restent fermées.

Générez une clé d'API dans les paramètres de votre compte Kutt, puis envoyez un POST sur /api/v2/links avec l'en-tête X-API-KEY et un corps JSON contenant target, l'adresse longue. Les champs customurl, password, description et expire_in sont optionnels. La réponse contient le champ link, le lien court ; chaque membre de l'équipe a sa propre clé.

Depuis votre espace client, ouvrez le Marketplace, sélectionnez Certimate, choisissez l'adresse de la console et cliquez sur Installer. Le script déploie le conteneur officiel, génère le mot de passe administrateur et l'applique avant le premier démarrage, crée le volume des données et configure nginx en HTTPS. Un VPS Ubuntu 24.04 avec 512 Mo de RAM suffit.

Oui : Certimate est une console d'administration web, publiée sur un domaine en HTTPS derrière nginx. Inutile d'en acheter un : chaque VPS ServOrbit dispose d'un sous-domaine gratuit (certimate.{dns_slug}.servorbit-dns.com) avec certificat HTTPS. Vous pouvez aussi choisir un sous-domaine de l'un de vos domaines, par exemple certs.votre-domaine.ma.

Ouvrez l'adresse de la console : l'identifiant est [email protected] et le mot de passe est celui généré à l'installation, affiché dans votre espace client sur la fiche de l'application. Le mot de passe d'usine publié par le projet (1234567890) n'est jamais actif sur une installation ServOrbit. Changez l'e-mail et le mot de passe dès la première connexion.

Oui. Un flux Certimate obtient le certificat (par exemple un wildcard par défi DNS-01 chez Cloudflare ou OVHcloud), puis le copie par SSH sur vos serveurs et exécute la commande de rechargement choisie, comme nginx -t && systemctl reload nginx. Utilisez une clé SSH dédiée et un compte limité aux répertoires des certificats. D'autres cibles existent : cPanel, Nginx Proxy Manager, Kubernetes ou webhook.

Depuis votre espace client, ouvrez le Marketplace, sélectionnez GreptimeDB, choisissez l'adresse et cliquez sur Installer. Le script déploie le conteneur officiel, génère le mot de passe de l'utilisateur admin, active l'authentification sur toute l'API HTTP et publie le tableau de bord en HTTPS. Un VPS Ubuntu 24.04 avec 2 Go de RAM suffit pour démarrer.

Oui. Vos serveurs y envoient leurs métriques, logs et traces, et Grafana l'interroge : GreptimeDB doit répondre en HTTPS sur un nom stable. Inutile d'en acheter un : chaque VPS ServOrbit dispose d'un sous-domaine gratuit (greptimedb.{dns_slug}.servorbit-dns.com) avec un certificat HTTPS. Vous pouvez aussi utiliser un sous-domaine de l'un de vos domaines.

Ouvrez https://votre-domaine/dashboard/ et saisissez dans les paramètres de connexion du tableau de bord l'utilisateur admin et le mot de passe affiché dans votre espace client. Les mêmes identifiants protègent l'API SQL, l'API Prometheus et l'ingestion : Grafana et vos agents les utilisent en authentification basique.

Dans l'OpenTelemetry Collector, déclarez un exportateur OTLP/HTTP vers https://votre-domaine/v1/otlp avec un en-tête Authorization en authentification basique. Les traces exigent en plus l'en-tête X-Greptime-Pipeline-Name: greptime_trace_v1 : placez-les sur un second exportateur, car cet en-tête fait refuser les logs. Ils arrivent dans les tables opentelemetry_logs et opentelemetry_traces.

Depuis votre espace client, ouvrez les Applications en 1 clic, sélectionnez MLflow, choisissez l'adresse et cliquez sur Installer. Le script déploie le conteneur officiel, génère le mot de passe du compte admin, active l'authentification sur l'interface et l'API et publie le serveur en HTTPS. Un VPS Ubuntu 24.04 avec 2 Go de RAM suffit pour démarrer.

Oui : vos scripts et votre équipe se connectent au serveur, et MLflow n'accepte que les noms d'hôte déclarés. Inutile d'en acheter un : chaque VPS ServOrbit dispose d'un sous-domaine gratuit (mlflow.{dns_slug}.servorbit-dns.com) avec certificat HTTPS. Vous pouvez aussi utiliser un sous-domaine de l'un de vos domaines.

Ouvrez l'adresse de votre serveur en HTTPS : le navigateur demande un identifiant. Saisissez admin et le mot de passe affiché dans votre espace client. Vous pouvez le changer ensuite par l'API users/update-password ; le nouveau mot de passe est conservé aux redémarrages.

Installez le client avec pip install mlflow, puis définissez MLFLOW_TRACKING_URI sur l'adresse HTTPS de votre serveur, ainsi que MLFLOW_TRACKING_USERNAME et MLFLOW_TRACKING_PASSWORD. Chaque mlflow.start_run() de vos notebooks et scripts enregistre alors ses paramètres, métriques et fichiers sur votre VPS.