Index des fonctionnalités

Zone	Documentation actuelle
Questions avant achat	Évaluer Opfield
Ingress, domaines, Routes, TLS	Vue d’ensemble de l’ingress
Conteneurs et Deployments Docker	Vue d’ensemble de Docker
Projets Compose	Projets Compose
Builds Git et Build Workers	Sources Git et Build Workers
Apps et environnements	Apps
Bases de données managées et externes	Vue d’ensemble des bases de données
Stockages clé-valeur	Stockages clé-valeur
Bases de données et stockage sur plusieurs serveurs	Bases de données et stockage sur plusieurs serveurs
Sauvegarde et restauration des bases de données	Sauvegardes des bases de données
Connexions de stockage et stockage objet managé	Stockage
Liaisons privées aux bases de données	Liaisons applicatives aux bases de données
Pages	Vue d’ensemble de Pages
Hébergeurs : VM issues de comptes cloud et de Proxmox comme nœuds	Hébergeurs
Relay Pool et relais protégés	Relay et Relay Pool, Relais protégés
Liaison avec le compte cloud	Opfield Cloud
Supervision, journaux, notifications et statut	Supervision et signaux d’exploitation
Identité et permissions	Authentification, utilisateurs et groupes
AI Workspace	AI Workspace
Opfield Inference	Opfield Inference
Sécurité et exploitation	Modèle de sécurité

Disponibilité et versions cibles

Apps — disponible en 2.12, tous les plans : regrouper les ressources d’une application dans des environnements avec des nœuds autorisés, des variables et secrets partagés, la maintenance, la promotion par empreinte d’image, l’arrêt et un coupe-circuit. Un utilisateur qui peut consulter une ressource d’une app voit aussi l’app, limitée aux ressources qu’il peut consulter. Voir Apps.
Bases de données et stockage sur plusieurs serveurs — disponible en 2.12, Business/Enterprise : PostgreSQL, stockages clé-valeur, ClickHouse et stockage SeaweedFS managés sur 2 à 5 nœuds Storage avec basculement automatique via des témoins, ou paire répliquée avec basculement manuel. Voir Bases de données et stockage sur plusieurs serveurs.
Stockages clé-valeur Valkey — disponible en 2.12, Personal et supérieur : les nouveaux stockages clé-valeur managés exécutent Valkey et fonctionnent avec les clients Redis ; les stockages plus anciens migrent avec Move to Valkey. Voir Stockages clé-valeur.
Relais protégés et liaison cloud — disponible en 2.12, tous les plans. Voir Relais protégés et Opfield Cloud.
Workload Availability (HA) — disponible, Business/Enterprise : réplication ou basculement pour les Containers et Deployments sans montages et pour des projets Compose entiers, avec un ordre de priorité des nœuds facultatif et un retour automatique sur le primaire. Lorsque chaque participant exécute 2.11, les nœuds basculent d’eux-mêmes sans Opfield (basculement du plan de données). Voir le guide HA.
Groupes d’ingress — disponible, Business/Enterprise : une Route, un domaine, un site Pages ou la page de statut servis simultanément par plusieurs nœuds Ingress nginx, avec livraison, santé et journaux par membre, et un point de terminaison de santé pour les répartiteurs de charge. Voir Groupes d’ingress.
Stockage — disponible en 2.11, Personal et supérieur : connexions à des stockages compatibles S3, FTP, FTPS et SFTP, et stockage objet SeaweedFS managé avec des liens privés de charges de travail et des Secure Links. Voir Stockage.
Liens entre conteneurs — disponible en 2.11.1, Personal et supérieur : accès privé d’un Container, d’un Deployment ou d’un service Compose à un port d’une autre charge de travail, sur le même nœud ou sur un autre, sans port publié. Voir Liens entre conteneurs.
Sauvegarde et restauration des bases de données — disponible en 2.11, Personal et supérieur : sauvegardes natives des bases PostgreSQL, clé-valeur et ClickHouse managées et externes vers des connexions de stockage. Voir Sauvegardes des bases de données.
Export de configuration d’Opfield pour le transfert vers une autre instance — disponible en 2.12, tous les plans. Voir Export de configuration.

Les versions futures sont des estimations. La matrice des plans ne liste que ce qui figure dans le produit ; la feuille de route liste le reste avec les plans prévus.

La CLI Opfield générale est attendue en 2.13 avec tous les plans, et le démon de gestion Bastion / SSH en 2.14 en Business et Enterprise. Le système de plugins est documenté séparément comme future infrastructure du cœur : pas encore implémenté, provisoirement pas avant 2.20, sans date de sortie garantie.

État des fonctionnalités

État	Signification
Prêt	Disponible dans le produit actuel, sous réserve des prérequis du plan et de l’exécution
Prêt, sur activation	Disponible mais masqué ou inactif tant qu’un administrateur ne l’active pas
Avantage du plan	Avantage commercial ou de niveau de service plutôt qu’une fonctionnalité d’exécution

L’inclusion dans un plan et la disponibilité à l’exécution sont distinctes. Les fonctionnalités qui ne figurent pas encore dans le produit ne figurent pas dans la matrice des plans ; la feuille de route indique les plans auxquels elles sont destinées.

Utilisez cet index pour répondre à trois questions d’évaluation : si Opfield prend en charge le processus, quel prérequis d’infrastructure le fournit, et quel plan l’admet. Une fonctionnalité peut être documentée et sous licence, mais indisponible sur une installation donnée parce que le rôle de nœud, le connecteur, le fournisseur ou la capacité d’exécution requis n’est pas sain.

Familles de produits actuelles

Ingress : domaines, Routes, TLS, listes d’accès, maintenance, vérifications de santé, upstreams gérés et placement nginx.
Apps (tous les plans) : environnements, nœuds autorisés, variables et secrets partagés, maintenance avec codes d’accès, promotion, arrêt et démarrage, et coupe-circuit.
Docker : conteneurs autonomes, Deployments blue/green, inventaire et cycle de vie Compose, images, volumes, réseaux, registres, builds, migrations, archives, tâches, supervision et liens entre conteneurs. Le cycle de vie Compose géré, les Deployments blue/green, les migrations, les archives, les volumes sur image disque et les liens entre conteneurs nécessitent Personal ou supérieur ; les builds Git et Secure Runtime nécessitent Business ou supérieur.
Bases de données (Personal et supérieur) : connexions externes, PostgreSQL, stockages clé-valeur (Valkey, compatible avec les clients Redis) et ClickHouse managés, explorateurs, supervision, TLS direct, liaisons applicatives privées, sauvegarde et restauration planifiées et, en Business et Enterprise, plusieurs serveurs avec basculement.
Stockage (Personal et supérieur) : connexions S3, FTP, FTPS et SFTP avec un explorateur d’objets, stockage objet SeaweedFS managé avec clés d’accès, liens privés de charges de travail et écouteurs publics facultatifs, tâches de copie côté serveur entre stockages S3, et migration des anciens clusters MinIO pilotée par l’assistant.
Pages (Personal et supérieur) : déploiements statiques immuables, tags, Routes, aperçus et builds Git facultatifs (Business et supérieur).
Nœuds et Relay : enrôlement par rôle, signalement des capacités, mises à jour signées, supervision, exploitation de Relay à plusieurs membres et relais protégés.
Identité : utilisateurs, groupes, MFA, OIDC, jetons, OAuth, scopes de ressources et usurpation d’identité.
Visibilité opérationnelle : santé, métriques, journaux, tâches, alertes, notifications, pages de statut (Personal et supérieur), journalisation structurée (Business et supérieur), audit avec export en Business et supérieur, et SIEM (Enterprise). Chaque signal est affiché sur la ressource à laquelle il appartient.
Automatisation et IA : REST, OAuth, MCP, chat d’AI Workspace et Opfield Inference avec tous les plans ; Plan Mode, Scenarios et Sandboxes d’IA à partir de Personal.
Sécurité : PKI système, PKI interne destinée aux utilisateurs (Enterprise), secrets chiffrés, audit, frontières d’admission et contrôles de cycle de vie à échec fermé.

Prérequis d’exécution

Un droit de plan ne remplace pas la capacité de l’hôte. Secure Runtime nécessite une capacité gVisor saine, les builds Git nécessitent un Build Worker dédié, les bases de données managées nécessitent un nœud Storage préparé, l’ingress public nécessite un nœud Ingress joignable, et les liens privés nécessitent un chemin Relay sain.

Utilisez la page propre à chaque fonctionnalité pour vérifier les prérequis, les conséquences sur le cycle de vie et le comportement de reprise avant d’activer une fonctionnalité en production. Voir Plans et droits pour le comportement des plans.

Parcours d’évaluation

Pour évaluer Opfield, exécutez une application réelle de bout en bout : une application publique, sa base de données privée, les nœuds sur lesquels elle s’exécute et les personnes qui l’exploitent. Vérifiez le déploiement, le contrôle d’accès, le trafic client, la supervision, la reprise après panne et l’audit sur ce parcours, puis ajoutez les fonctionnalités dont votre modèle d’exploitation a besoin, comme les builds Git, Pages, les bases de données managées, l’IA ou le SIEM.

Consignez chaque résultat comme :

pris en charge et vérifié sur l’installation testée ;
pris en charge avec un prérequis non satisfait ;
restreint par le plan ;
en développement ; ou
hors du périmètre produit d’Opfield.

Cela évite de confondre un positionnement sur la feuille de route, un contrôle désactivé dans l’interface et une capacité d’exécution en échec.

Périmètre du produit

Opfield exploite l’ingress, les charges de travail, les bases de données, le stockage objet, les sauvegardes, la supervision, la journalisation, les alertes, les pages de statut et les accès pour tout ce qui se trouve sur ses nœuds ; voir Pourquoi Opfield pour les outils qu’il remplace. En dehors de ce périmètre se trouvent le système d’exploitation des hôtes lui-même (les mises à jour du système et la sécurité des hôtes restent de votre ressort) et les formats de charges de travail autres que les conteneurs et les projets Compose : Opfield n’exécute pas de manifestes Kubernetes ni de charts Helm.