Evaluar Opfield

Esta página responde a las preguntas que suelen hacer los compradores y sus revisores de seguridad antes de elegir Opfield. Cada respuesta es breve y enlaza a la página que documenta el comportamiento en detalle. Las respuestas describen la versión actual; los elementos de la hoja de ruta están marcados en la matriz de planes.

¿Podemos autoalojar Opfield con un plan de pago?

Sí. Todos los planes (Community, Personal, Business y Enterprise) se pueden instalar y operar en tu propia infraestructura. Un plan de pago es una clave de licencia que se aplica a una instalación autoalojada; no traslada el plano de control a ningún otro sitio. La nube gestionada, en la que el equipo de Opfield opera el plano de control, es un complemento de los planes Personal y Business que se vende junto con la clave de licencia en tu cuenta de Opfield. Es una alternativa, nunca un requisito de un plan.

Community no necesita clave de licencia y permite hasta 25 nodos gestionados, 3 usuarios y 1 grupo de permisos personalizado. Las claves Personal, Business y Enterprise cubren cada una una instalación activa de Opfield sin esas cuotas. Las funciones de pago se entregan como un commercial core firmado que la instalación descarga y verifica; consulta Commercial core. Consulta Instala Opfield o la instalación manual si tu revisión no permite pasar un instalador directamente a una shell.

¿Dónde están nuestros secretos y claves en una instalación autoalojada?

Dentro de la instalación. Opfield es un plano de control que ejecutas tú, así que las credenciales que usa para operar tu infraestructura se quedan en tu entorno:

Las credenciales guardadas (secretos y valores de entorno de Docker, credenciales de registros, tokens de DNS y de proveedores de hosting, claves SSH, secretos de OIDC y SMTP, credenciales de bases de datos, claves de proveedores de IA, claves privadas de autoridades de certificación y de ACME, y la propia clave de licencia) se cifran con cifrado de sobre AES-256-GCM y se guardan en la propia base de datos PostgreSQL de la instalación.
La clave maestra que las protege (PKI_MASTER_KEY) se genera en tu host durante la instalación y se guarda en el archivo .env de la instalación, no en la base de datos. No sale del host salvo que la copies.
La clave privada TLS propia de Opfield se queda en el host de Opfield. Cada nodo gestionado conserva localmente la clave privada de su daemon, y los nodos Storage guardan las claves TLS de las bases de datos en almacenamiento propiedad del daemon.

Protege el host de Opfield como un sistema privilegiado y haz copia de seguridad de la clave maestra por separado de las copias de seguridad de la base de datos: una copia de seguridad de la base de datos sin su clave maestra no se puede descifrar. Consulta Modelo de seguridad y Actualizaciones, copias de seguridad y restauración.

¿Qué envía Opfield al servicio de licencias?

Solo metadatos de la instalación. Opfield contacta con https://license.opfield.dev para registrar la instalación, para enviar un heartbeat (cada 15 minutos con una clave de pago y cada 30 minutos en Community), para activar o desactivar una clave, para autorizar la versión de destino antes de una actualización y, en una instalación con licencia, para descargar el commercial core firmado.

Las peticiones incluyen el ID de instalación, el nombre de la instalación (el nombre de host de la URL pública configurada, o el nombre de host del servidor), la versión de Opfield, la versión del esquema de derechos y un token de instalación. Durante el registro se envía un nonce de registro de un solo uso, la clave de pago cuando la activas, y la versión de destino, el ID de la versión y la ruta del archivo durante una actualización. No se envían la configuración de la infraestructura, el contenido de los recursos, los secretos, los logs, los recuentos de usuarios o de recursos, los prompts ni las respuestas de los modelos.

Las comprobaciones de permisos y de derechos del plan usan el estado de licencia en caché guardado en tu instalación, de modo que las operaciones individuales no esperan al servicio de licencias. Otras conexiones salientes, como la comprobación de versiones, se enumeran en Qué sale de una instalación autoalojada.

¿Qué ocurre si la licencia caduca o el servicio de licencias no es accesible?

La infraestructura en ejecución sigue funcionando. Ni la caducidad ni un servicio de licencias inaccesible detienen ni eliminan contenedores, Deployments, Compose Projects, Routes, certificados, motores de bases de datos gestionadas ni despliegues de Pages publicados.

Caducidad de la clave. Tras la fecha de caducidad, el plan de pago sigue totalmente activo durante un periodo de gracia específico de cada plan: 24 horas en Personal, 3 días en Business y 7 días en Enterprise. El Dashboard muestra una advertencia durante el periodo de gracia. Tras el periodo de gracia, las cargas de trabajo, el plano de datos y los datos siguen funcionando; las copias de seguridad programadas, las restauraciones en bases de datos existentes, la visualización, los logs, la monitorización, la revelación de credenciales y la eliminación de los recursos de pago existentes siguen funcionando. Crear recursos de pago y cambiar su configuración queda bloqueado, y el reenvío a SIEM y el acceso al registro externo se pausan hasta la renovación.
Servicio de licencias inaccesible. Una instalación de pago que era válida conserva su plan durante 100 días desde la hora de emisión de su último estado de licencia firmado, con el estado Licensed with warning. Esto no prolonga una fecha de caducidad conocida. Tras 100 días, el comportamiento coincide con el de una caducidad normal. Las instalaciones Community siguen funcionando mientras el servicio no es accesible, y una instalación Community sin clave también se actualiza sin él. Activar una clave de pago, y actualizar una instalación que tiene o tuvo un plan de pago, requieren que el servicio sea accesible; una actualización fallida deja en ejecución la versión actual. Consulta Requisitos previos de la actualización en la 2.11.
Recursos por encima de los límites de Community. Los límites de Community solo se aplican al crear un nodo gestionado, un usuario o un grupo de permisos personalizado. Los nodos, usuarios y grupos existentes por encima del límite siguen funcionando y nunca se eliminan.
Bajada de plan y renovación. Una bajada a un plan de pago inferior conserva el plan superior durante su periodo de gracia. Renovar la clave restablece todas las operaciones sin reconstruir recursos. Las instalaciones que tuvieron un plan de pago siguen recibiendo actualizaciones con el commercial core, de modo que los recursos de pago existentes siguen funcionando tras una actualización.

La revocación, la transferencia de la clave a otra instalación, la desactivación o una clave no válida no tienen periodo de gracia: las reglas posteriores al periodo de gracia se aplican de inmediato, y las cargas de trabajo en ejecución siguen funcionando. Los estados de licencia del servicio están firmados y Opfield los verifica, de modo que una respuesta falsificada o repetida no puede cambiar el plan. Consulta Bajada de plan y caducidad.

¿Puede un equipo reiniciar contenedores y leer logs sin adoptar el proyecto?

Sí para los contenedores independientes, y en modo de solo lectura para los proyectos Compose externos.

Los contenedores independientes, incluidos los iniciados con docker run fuera de Opfield, aparecen en su nodo Docker sin un paso de adopción. Un grupo puede recibir docker:containers:manage para un contenedor para iniciarlo, detenerlo, reiniciarlo o matarlo y leer sus logs, sin acceso a otros contenedores ni a detalles del host. manage también permite recrear; no hay un ámbito solo de reinicio.
Los proyectos Compose externos se descubren a partir de las etiquetas de Docker Compose. docker:compose:view para un proyecto muestra sus servicios, su estado, la monitorización y los logs agregados en todos los planes. Reiniciar un proyecto externo, o un contenedor concreto que pertenezca a él, no está disponible: las acciones de ciclo de vida requieren adoptar el proyecto, lo que requiere Personal o superior. Tras la adopción, docker:compose:manage para ese proyecto inicia, detiene o reinicia el proyecto completo.

Las concesiones pueden apuntar a un recurso, a un nodo o a una carpeta de Docker. Consulta Opera cargas de trabajo sin adoptarlas para ver los ámbitos exactos y cómo se comportan las identidades de los recursos cuando los contenedores se recrean fuera de Opfield.

¿Cómo entregamos un proyecto Docker Compose existente?

Adopta el proyecto descubierto. La adopción es una transferencia explícita de la propiedad y requiere Personal o superior. Pegas el archivo Compose completo (Opfield no lo lee del host), y Opfield lo valida, lo guarda como la primera revisión inmutable y lo aplica con el mismo nombre de proyecto Compose.

Los volúmenes con nombre conservan su nombre. Opfield no renombra ni añade prefijos al proyecto ni a sus volúmenes, así que Docker Compose reutiliza los volúmenes <project>_<volume> existentes, o los volúmenes con un name: explícito, y sus datos. Para los servicios con estado, como Temporal, mantén sin cambios las claves de los volúmenes y compara la lista de volúmenes con el proyecto descubierto antes de la primera aplicación.
env_file no es compatible. Declara las variables en environment: y proporciona sus valores como variables de Opfield y secretos cifrados del proyecto mediante la interpolación ${NAME}.
Se rechazan los bind mounts del host, incluidas las rutas relativas como ./config. Mueve los archivos de configuración a la imagen o a un volumen con nombre.
Trabajos puntuales. No hay docker compose run ni hook previo al despliegue. Ejecuta un comando de migración a través de la consola del contenedor de un servicio, o modélalo como un servicio restart: "no" al que esperan otros servicios mediante depends_on; un servicio de un solo uso terminado aparece como no en ejecución.
Otros límites. Los servicios deben usar imágenes ya construidas salvo que el proyecto tenga un origen Git en Business o Enterprise, y se rechazan claves como container_name, privileged, cap_add, devices, network_mode y deploy. Consulta la configuración de Compose compatible completa.
Eliminación. Eliminar un proyecto gestionado elimina los volúmenes que le pertenecen. Haz antes una copia de seguridad de los datos persistentes.

Cuenta con que la primera aplicación recree los contenedores de los servicios, y ensaya la adopción en una copia de staging. Los Compose Projects no se pueden mover entre nodos con la migración entre nodos, y sus contenedores no se pueden exportar como archivos GWCA. Los contenedores independientes sí: la migración copia los datos de los volúmenes y conserva sus nombres, mientras que los archivos GWCA nunca incluyen datos de los volúmenes. Consulta Compose Projects y Migraciones y archivos de contenedores.

¿Qué diferencia hay entre las bases de datos gestionadas y las externas?

Opfield trabaja con PostgreSQL, almacenes clave-valor (Redis y Valkey) y ClickHouse en dos modelos:

Una base de datos gestionada la aprovisiona y la ejecuta Opfield como un contenedor con almacenamiento de tamaño fijo en un nodo Storage. Opfield gestiona su ciclo de vida, el redimensionamiento, la publicación TLS, los logs, las extensiones de PostgreSQL y las vinculaciones privadas que inyectan los ajustes de conexión en las cargas de trabajo.
Una conexión externa guarda cifrados los datos de conexión de una base de datos que se ejecuta en otro lugar. Opfield prueba la conexión, supervisa el estado y proporciona exploradores y consolas, pero no aprovisiona, pausa, redimensiona, vincula ni elimina ese motor.

Ambos modelos requieren Personal o superior, y ambos se pueden proteger con copias de seguridad de bases de datos programadas en una conexión de almacenamiento.

Consulta la visión general de bases de datos para ver la comparación completa.

¿Hay ayuda con la migración?

Lleva tu stack a Opfield indica el orden del traslado y una comprobación para cada paso, en cualquier plan. Business incluye Guided Onboarding and Configuration Review, y Enterprise incluye Assisted Deployment and Migration, como ventajas del plan; el alcance de esa ayuda lo define el acuerdo comercial. Para obtener ayuda con la migración en otro plan o para un proyecto concreto, contacta con el equipo de Opfield en [email protected] o a través del sitio web de Opfield.

¿Dónde están los precios?

Los precios actuales de los planes se publican en la sección de precios del sitio web de Opfield. Esta documentación no define precios ni compromisos de precio; las condiciones contractuales y de precios, incluidas las de Enterprise, corresponden al acuerdo comercial aplicable. Las funciones y los límites de los planes se enumeran en Planes y derechos.

Siguientes pasos

Compara las capacidades necesarias en la matriz de planes.
Revisa el modelo de seguridad y los requisitos del host.
Planifica el traslado con Lleva tu stack a Opfield.