Évaluer Opfield

Cette page répond aux questions que les acheteurs et leurs équipes de sécurité posent habituellement avant de choisir Opfield. Chaque réponse est courte et renvoie à la page qui documente le comportement en détail. Les réponses décrivent la version actuelle ; les éléments de la feuille de route sont signalés dans la matrice des plans.

Peut-on auto-héberger Opfield avec un plan payant ?

Oui. Chaque plan — Community, Personal, Business et Enterprise — peut être installé et exploité sur votre propre infrastructure. Un plan payant est une clé de licence appliquée à une installation auto-hébergée ; il ne déplace pas le plan de contrôle ailleurs. Le cloud managé, dans lequel l’équipe Opfield exploite le plan de contrôle, est une option des plans Personal et Business, vendue avec la clé de licence dans votre compte Opfield. C’est une alternative, jamais une condition d’un plan.

Community ne nécessite pas de clé de licence et autorise jusqu’à 25 nœuds gérés, 3 utilisateurs et 1 groupe de permissions personnalisé. Les clés Personal, Business et Enterprise couvrent chacune une installation Opfield active, sans ces quotas. Les fonctionnalités payantes sont livrées sous la forme d’un cœur commercial signé que l’installation télécharge et vérifie ; voir Cœur commercial. Consultez Installer Opfield ou l’installation manuelle si votre revue n’autorise pas l’exécution d’un installateur envoyé directement dans un shell.

Où sont stockés nos secrets et nos clés dans une installation auto-hébergée ?

Dans l’installation. Opfield est un plan de contrôle que vous exploitez vous-même ; les identifiants qu’il utilise pour piloter votre infrastructure restent donc dans votre environnement :

Les identifiants stockés — secrets et variables d’environnement Docker, identifiants de registre, jetons DNS et d’hébergeurs, clés SSH, secrets OIDC et SMTP, identifiants de bases de données, clés des fournisseurs d’IA, clés privées des autorités de certification et d’ACME, ainsi que la clé de licence elle-même — sont chiffrés par chiffrement d’enveloppe AES-256-GCM et stockés dans la base PostgreSQL propre à l’installation.
La clé maîtresse qui les protège (PKI_MASTER_KEY) est générée sur votre hôte pendant l’installation et conservée dans le fichier .env de l’installation, et non dans la base de données. Elle ne quitte pas l’hôte, sauf si vous la copiez.
La clé privée TLS d’Opfield reste sur l’hôte Opfield. Chaque nœud géré conserve localement la clé privée de son démon, et les nœuds Storage conservent les clés TLS des bases de données dans un stockage appartenant au démon.

Protégez l’hôte Opfield comme un système privilégié et sauvegardez la clé maîtresse séparément des sauvegardes de la base de données : une sauvegarde de base sans sa clé maîtresse ne peut pas être déchiffrée. Voir Modèle de sécurité et Mises à jour, sauvegardes et restauration.

Qu’est-ce qu’Opfield envoie au service de licences ?

Uniquement des métadonnées d’installation. Opfield contacte https://license.opfield.dev pour enregistrer l’installation, envoyer un signal de présence (heartbeat) — toutes les 15 minutes avec une clé payante et toutes les 30 minutes en Community —, activer ou désactiver une clé, autoriser la version cible avant une mise à jour et, pour une installation sous licence, télécharger le cœur commercial signé.

Les requêtes contiennent l’identifiant de l’installation, son nom (le nom d’hôte de l’URL publique configurée, ou le nom d’hôte du serveur), la version d’Opfield, la version du schéma des droits et un jeton d’installation. Un nonce d’enregistrement à usage unique est envoyé lors de l’enregistrement, la clé payante lors de son activation, et la version cible, l’identifiant de version et le chemin du fichier lors d’une mise à jour. La configuration de l’infrastructure, le contenu des ressources, les secrets, les journaux, le nombre d’utilisateurs ou de ressources, les prompts et les réponses des modèles ne sont pas envoyés.

Les vérifications de permissions et de droits utilisent l’état de licence mis en cache dans votre installation ; les opérations individuelles n’attendent donc pas le service de licences. Les autres connexions sortantes, comme la vérification des nouvelles versions, sont listées dans Ce qui quitte une installation auto-hébergée.

Que se passe-t-il si la licence expire ou si le service de licences est injoignable ?

L’infrastructure en cours d’exécution continue de fonctionner. Ni l’expiration ni l’indisponibilité du service de licences n’arrêtent ou ne suppriment les conteneurs, Deployments, projets Compose, Routes, certificats, moteurs de bases de données managées ou déploiements Pages publiés.

Expiration de la clé. Après la date d’expiration, le plan payant reste pleinement actif pendant une période de grâce propre à chaque plan : 24 heures en Personal, 3 jours en Business et 7 jours en Enterprise. Le tableau de bord affiche un avertissement pendant la période de grâce. Ensuite, les charges de travail, le plan de données et les données continuent de fonctionner ; les sauvegardes planifiées, les restaurations dans des bases existantes, la consultation, les journaux, la supervision, l’affichage des identifiants et la suppression des ressources payantes existantes continuent de fonctionner. La création de ressources payantes et la modification de leur configuration sont bloquées, et la transmission vers le SIEM et l’accès aux registres externes sont suspendus jusqu’au renouvellement.
Service de licences injoignable. Une installation payante précédemment valide conserve son plan pendant 100 jours après la date d’émission de son dernier état de licence signé, avec le statut Licensed with warning. Cela ne prolonge pas une date d’expiration connue. Au-delà de 100 jours, le comportement est celui d’une expiration ordinaire. Les installations Community continuent de fonctionner tant que le service est injoignable, et une installation Community sans clé se met aussi à jour sans lui. L’activation d’une clé payante, ainsi que la mise à jour d’une installation qui détient ou a détenu un plan payant, exigent que le service soit joignable ; une mise à jour échouée laisse la version actuelle en fonctionnement. Voir Prérequis de mise à jour en 2.11.
Ressources au-delà des limites Community. Les limites Community ne s’appliquent qu’à la création d’un nœud géré, d’un utilisateur ou d’un groupe de permissions personnalisé. Les nœuds, utilisateurs et groupes existants au-delà de la limite continuent de fonctionner et ne sont jamais supprimés.
Rétrogradation et renouvellement. Une rétrogradation vers un plan payant inférieur conserve le plan supérieur pendant sa période de grâce. Le renouvellement de la clé rétablit toutes les opérations sans reconstruire les ressources. Les installations qui ont détenu un plan payant continuent de recevoir les mises à jour avec le cœur commercial ; les ressources payantes existantes continuent donc de fonctionner après une mise à jour.

La révocation, le transfert de la clé vers une autre installation, la désactivation ou une clé invalide ne donnent droit à aucune période de grâce : les règles d’après la période de grâce s’appliquent immédiatement, et les charges de travail en cours continuent de fonctionner. Les états de licence fournis par le service sont signés et vérifiés par Opfield ; une réponse falsifiée ou rejouée ne peut donc pas modifier le plan. Voir Rétrogradation et expiration.

Une équipe peut-elle redémarrer des conteneurs et lire les journaux sans adopter le projet ?

Oui pour les conteneurs autonomes, et en lecture seule pour les projets Compose externes.

Les conteneurs autonomes, y compris ceux lancés avec docker run hors d’Opfield, sont listés sur leur nœud Docker sans étape d’adoption. Un groupe peut recevoir docker:containers:manage pour un seul conteneur afin de le démarrer, l’arrêter, le redémarrer ou le tuer et de lire ses journaux, sans accès aux autres conteneurs ni aux détails de l’hôte. manage autorise aussi la recréation ; il n’existe pas de scope limité au redémarrage.
Les projets Compose externes sont découverts à partir des labels Docker Compose. docker:compose:view pour un projet affiche ses services, leur état de santé, la supervision et les journaux agrégés, quel que soit le plan. Le redémarrage d’un projet externe, ou d’un conteneur individuel qui en fait partie, n’est pas disponible : les actions de cycle de vie exigent d’adopter le projet, ce qui nécessite Personal ou supérieur. Après l’adoption, docker:compose:manage pour ce projet permet de démarrer, d’arrêter ou de redémarrer l’ensemble du projet.

Les droits peuvent cibler une ressource, un nœud ou un dossier Docker. Voir Exploiter des charges de travail sans les adopter pour les scopes exacts et le comportement des identités de ressources lorsque des conteneurs sont recréés hors d’Opfield.

Comment confier un projet Docker Compose existant à Opfield ?

Adoptez le projet découvert. L’adoption est un transfert de propriété explicite et nécessite Personal ou supérieur. Vous collez le fichier Compose complet — Opfield ne le lit pas sur l’hôte —, puis Opfield le valide, l’enregistre comme première révision immuable et l’applique sous le même nom de projet Compose.

Les volumes nommés conservent leur nom. Opfield ne renomme pas et ne préfixe pas le projet ni ses volumes ; Docker Compose réutilise donc les volumes <project>_<volume> existants, ou les volumes dotés d’un name: explicite, ainsi que leurs données. Pour les services avec état comme Temporal, gardez les clés de volumes inchangées et comparez la liste des volumes avec le projet découvert avant la première application.
env_file n’est pas pris en charge. Déclarez les variables dans environment: et fournissez leurs valeurs sous forme de variables Opfield et de secrets de projet chiffrés via l’interpolation ${NAME}.
Les montages de répertoires de l’hôte (bind mounts) sont refusés, y compris les chemins relatifs comme ./config. Placez les fichiers de configuration dans l’image ou dans un volume nommé.
Tâches ponctuelles. Il n’existe ni docker compose run ni hook avant déploiement. Exécutez une commande de migration via la console d’un conteneur de service, ou modélisez-la comme un service restart: "no" que les autres services attendent via depends_on ; un service ponctuel terminé est signalé comme arrêté.
Autres limites. Les services doivent utiliser des images préconstruites, sauf si le projet dispose d’une source Git en Business ou Enterprise, et les clés comme container_name, privileged, cap_add, devices, network_mode et deploy sont refusées. Voir la configuration Compose prise en charge complète.
Suppression. La suppression d’un projet géré supprime les volumes qui lui appartiennent. Sauvegardez d’abord les données persistantes.

Attendez-vous à ce que la première application recrée les conteneurs des services, et répétez l’adoption sur une copie de préproduction. Les projets Compose ne peuvent pas être déplacés entre nœuds par la migration inter-nœuds, et leurs conteneurs ne peuvent pas être exportés en archives GWCA. Les conteneurs autonomes, eux, le peuvent : la migration copie les données des volumes et conserve leurs noms, tandis que les archives GWCA n’incluent jamais les données des volumes. Voir Projets Compose et Migrations et archives de conteneurs.

Quelle est la différence entre bases de données managées et externes ?

Opfield prend en charge PostgreSQL, les stockages clé-valeur (Redis et Valkey) et ClickHouse selon deux modèles :

Une base de données managée est provisionnée et exploitée par Opfield sous forme de conteneur avec un stockage de taille fixe sur un nœud Storage. Opfield gère son cycle de vie, son redimensionnement, sa publication TLS, ses journaux, les extensions PostgreSQL et les liaisons privées qui injectent les paramètres de connexion dans les charges de travail.
Une connexion externe stocke, chiffrés, les détails de connexion d’une base qui s’exécute ailleurs. Opfield teste la connexion, surveille l’état de santé et fournit des explorateurs et des consoles, mais il ne provisionne pas, ne met pas en pause, ne redimensionne pas, ne lie pas et ne supprime pas ce moteur.

Les deux modèles nécessitent Personal ou supérieur, et tous deux peuvent être protégés par des sauvegardes de bases de données planifiées vers une connexion de stockage.

Voir Vue d’ensemble des bases de données pour la comparaison complète.

Proposez-vous une aide à la migration ?

Migrer votre pile vers Opfield indique l’ordre de la migration et une vérification pour chaque étape, quel que soit le plan. Business inclut Guided Onboarding and Configuration Review, et Enterprise inclut Assisted Deployment and Migration, en tant qu’avantages du plan ; l’étendue de cette assistance est définie par le contrat commercial. Pour une aide à la migration avec un autre plan ou pour un projet particulier, contactez l’équipe Opfield à [email protected] ou via le site web d’Opfield.

Où trouver les tarifs ?

Les tarifs actuels des plans sont publiés dans la section tarifs du site web d’Opfield. Cette documentation ne définit ni prix ni engagement tarifaire ; les conditions contractuelles et tarifaires, y compris celles d’Enterprise, relèvent du contrat commercial applicable. Les fonctionnalités et limites des plans sont listées dans Plans et droits.

Étapes suivantes

Comparez les fonctionnalités nécessaires dans la matrice des plans.
Examinez le modèle de sécurité et les prérequis des hôtes.
Planifiez la migration avec Migrer votre pile vers Opfield.