Pourquoi Opfield

Opfield remplace votre pile d’infrastructure. Ingress, TLS, conteneurs, déploiements, basculement, bases de données, stockage objet, sauvegardes, supervision, journaux, alertes, pages de statut, réseau privé et contrôle d’accès : un seul produit, une seule installation, un seul modèle de permissions, un seul journal d’audit.

Vous cessez d’assembler une plateforme à partir d’une douzaine d’outils et vous vous consacrez à l’exploitation de vos services.

Ce qu’Opfield remplace

Au lieu de	Vous obtenez dans Opfield	Pourquoi c’est mieux
nginx ou Traefik, certbot, cert-manager	Des Routes et des domaines avec certificats ACME automatiques, PKI interne, listes d’accès et pages de maintenance	Pas de fichiers de configuration, pas de tâches cron de renouvellement, pas de certificats expirés. Une Route se crée dans un formulaire et se vérifie sur-le-champ
Portainer et autres panneaux Docker	Conteneurs, projets Compose, images, volumes, réseaux, journaux, fichiers et consoles sur chaque nœud	Un seul endroit pour toute la flotte au lieu d’un panneau par hôte, avec des permissions jusqu’au conteneur individuel
Coolify, Dokku, PaaS de type Heroku	Builds Git, déploiements avec bascule de slots et retour arrière, Apps avec environnements, Pages pour les sites statiques	Fonctionne sur vos serveurs, à côté de vos bases de données et de votre ingress, sous les mêmes permissions et le même audit
Kubernetes	Docker Availability : les charges de travail s’exécutent sur un ensemble de nœuds et passent sur un autre nœud en cas de panne	Le basculement sans cluster. Pas d’etcd, pas de CNI, pas d’ingress controller, pas d’opérateurs, pas de YAML. Un nouveau nœud rejoint la flotte en une commande
Opérateurs de bases de données et bases hébergées	PostgreSQL managé, stockages clé-valeur, ClickHouse et stockage objet S3 avec haute disponibilité et liens privés	Une base de données se crée dans un formulaire, s’exécute sur vos nœuds Storage et reste accessible aux charges de travail sans port ouvert
Scripts et services de sauvegarde	Sauvegardes planifiées des bases de données vers S3, FTP, FTPS ou SFTP ; restauration qui n’écrase jamais la source ; tâches de copie entre stockages ; export chiffré qui restaure toute l’installation sur un autre hôte	Les sauvegardes se configurent par base dans l’interface, s’exécutent selon un calendrier et se restaurent en une action
VPN, bastions, ports de gestion ouverts	Secure Links et relais	Les nœuds se connectent en sortie. Les charges de travail et les bases de données n’ont besoin d’aucun port ouvert. Chaque session de console est limitée et auditée
Prometheus, Grafana, Loki, Alertmanager	Métriques des nœuds et des conteneurs, journaux centralisés, règles d’alerte, notifications	Rien à déployer et aucun tableau de bord à construire : chaque métrique et chaque journal sont déjà rattachés à leur ressource
Statuspage, Uptime Kuma	Pages de statut publiques avec composants et incidents	Le statut provient des ressources qu’Opfield supervise déjà
Jetons, scripts et intégrations d’IA séparés	API REST, OAuth et serveur MCP	Les personnes, les scripts et les agents d’IA utilisent les mêmes permissions limitées et apparaissent dans le même journal d’audit

Les moteurs utilisés sont éprouvés : Docker exécute les conteneurs, PostgreSQL stocke les données, nginx sert le trafic. Opfield les installe, les relie entre eux, les maintient en fonctionnement et les rétablit.

Plus simple

• Installation en une commande. curl -fsSL https://get.opfield.dev | bash sur un serveur Linux avec Docker, puis un assistant de configuration dans le navigateur.
• Ajout d’un serveur en une commande. Copiez-la depuis Nodes > Add Node, exécutez-la sur le serveur : le nœud est enrôlé, mis à jour et surveillé à partir de ce moment.
• Aucun cluster à exploiter. Le basculement, l’ingress, les certificats et les bases de données fonctionnent sans plan de contrôle supplémentaire à installer, mettre à niveau et déboguer.
• Mises à jour signées et automatiques. Opfield se met à jour, ainsi que ses démons, vérifie chaque version avant de l’exécuter et annule de lui-même une mise à jour échouée.
• Une seule interface à apprendre. Un nouvel ingénieur apprend un produit au lieu de dix, et trouve chaque ressource, son état de santé, ses journaux et son historique au même endroit.

Mieux

• Un seul modèle de permissions. Accordez à un développeur un conteneur, une base de données ou un dossier de Routes. Pas de root partagé, pas de mots de passe d’administration partagés, pas de listes d’utilisateurs par outil.
• Un seul journal d’audit. Chaque action, qu’elle vienne d’une personne, d’un jeton d’API ou d’un agent d’IA, enregistre qui l’a effectuée, sur quoi, où elle s’est exécutée et si elle a réussi.
• Les ressources se connaissent. Un domaine pointe vers une Route, la Route vers une charge de travail, la charge de travail vers sa base de données et son nœud. Quand quelque chose casse, vous voyez toute la chaîne, et non dix tableaux de bord séparés.
• Aucun port ouvert. Les nœuds, les charges de travail et les bases de données sont joints via des relais, par des connexions sortantes. La surface d’attaque de chaque serveur se réduit.
• Conçu pour l’exploitation par l’IA. Le serveur MCP expose tout ce qu’une personne peut faire, sous les mêmes permissions. Un agent peut déployer, diagnostiquer et corriger, et chaque étape est auditée.

Un exemple

L’entreprise a besoin d’un nouveau portail client.

1. Opfield construit l’application à partir du dépôt approuvé.
2. Un nœud Docker l’exécute sur deux serveurs avec Availability.
3. Opfield crée une base de données PostgreSQL managée et la lie à l’application sans montrer le mot de passe à quiconque.
4. Une Route relie le domaine public, un certificat TLS automatique et l’application.
5. Les sauvegardes de la base de données s’exécutent chaque nuit vers le stockage S3 de l’entreprise.
6. Les métriques, les journaux et les alertes de chaque composant sont actifs dès la première minute.

Une seule personne réalise cela dans un seul produit en moins d’une heure. Avec une pile d’outils séparés, il faut plusieurs équipes, plusieurs jours et une quantité de code d’assemblage que seul son auteur comprend.

À qui s’adresse Opfield

Opfield s’adresse aux entreprises qui exécutent leurs services sur leurs propres serveurs, dans un seul centre de données ou chez plusieurs fournisseurs, et qui veulent :

• une production qu’une équipe peut exploiter en toute sécurité sans donner l’accès root à tout le monde ;
• le basculement, les sauvegardes et la supervision sans devoir d’abord construire une plateforme ;
• une seule piste d’audit pour les personnes et l’automatisation ;
• moins d’outils, moins d’intégrations et moins de personnes qui sont seules à savoir comment quelque chose fonctionne.

Ce qui reste de votre ressort

• Les serveurs et les données. Opfield s’exécute sur des serveurs qui vous appartiennent ou que vous créez via un hébergeur. Vos données restent là où vous les placez.
• Le système d’exploitation des hôtes. Opfield exécute tout sur un nœud ; les mises à jour du système et le durcissement des hôtes restent à votre charge.
• Le format des charges de travail. L’unité de travail est un conteneur ou un projet Compose. Opfield n’exécute pas de manifestes Kubernetes ni de charts Helm, et vous n’en avez pas besoin.

Pour aller plus loin

Ouvrez la visite du produit pour découvrir les principales zones de l’interface, vérifiez les prérequis des hôtes et du réseau et installez Opfield.