Los discos ya no crecen sin límite

Un plano de control que maneja builds, imágenes y logs en muchos servidores puede llenar un disco sin que nadie lo note. En la 2.12.3, todo lo que crece tiene un límite.

• El registro interno guarda dos builds por contenedor, borra los builds de las fuentes eliminadas y deja de aceptar builds nuevos cuando su disco llega al 90 %.
• Los nodos Docker eliminan las imágenes que nadie ha usado en 12 horas. Cada contenedor conserva la imagen con la que se ejecuta y otra para volver atrás.
• Los logs de contenedores en los nodos Docker tienen un tamaño acotado, también los de contenedores creados antes de Opfield o fuera de él. Los nodos nginx mantienen los logs de rutas dentro de un límite y borran los de rutas eliminadas.
• El WAL y los slots de replicación de Postgres ya no llenan el disco de una base de datos.
• Housekeeping mantiene acotados los datos propios de Opfield incluso cuando está desactivado, y se ejecuta al momento cuando un disco de Opfield llega al 90 %. Además muestra qué ocupa cada disco: las tablas más grandes, Redis, los logs de contenedores y las imágenes antiguas de cada nodo.

Nuevas alertas integradas avisan a tiempo: alerta de disco al 85 % para cada disco de datos de un nodo, disco de Opfield lleno, discos de bases de datos llenos y Housekeeping detenido.

Una protección para la consola de los agentes

El asistente y los clientes MCP pueden ejecutar comandos en la consola de un nodo. Se ejecutan como root, para que un agente pueda reparar un nodo de verdad. Docker, containerd y Podman están ocultos en esa consola: un comando que usa Docker se rechaza y la respuesta indica la herramienta de Opfield que hay que usar en su lugar.

Es una protección contra errores, no una barrera de seguridad. Evita que un agente cambie por descuido un contenedor gestionado a espaldas de Opfield. Además, los agentes ya no pueden ejecutar comandos por SSH en hosts que son nodos de Opfield.

Si aun así alguien detiene, cambia o elimina a mano un contenedor gestionado, salta la nueva alerta integrada «Container changed outside Opfield», que explica qué implica el cambio.

Reglas de acceso en orden

Las reglas de una lista de acceso se evalúan de arriba abajo y gana la primera que coincide. Hasta ahora no se podía cambiar el orden, así que una regla de permiso añadida después de una denegación amplia nunca llegaba a aplicarse. Ahora las reglas se pueden reordenar desde la interfaz, la API y MCP, y las que nunca pueden coincidir quedan marcadas.

Orden de conmutación para bases de datos y almacenamiento

En Postgres gestionado, almacenes clave-valor, ClickHouse y almacenamiento S3 con disponibilidad, ahora puedes definir el orden de conmutación: qué servidor toma el relevo primero cuando falla el principal.

Registro en S3

El registro interno puede guardar sus datos en S3 en lugar del disco del host de Opfield. Al cambiar de almacenamiento se comprueba cada imagen que el registro conserva para las cargas de trabajo.

Pages y páginas de error

Los proyectos de Pages sirven su propio 404.html para las rutas que no existen, con estado 404.

Todas las páginas que genera el propio nginx (errores, clientes denegados, upstreams inaccesibles, el servidor por defecto) son ahora páginas de Opfield. Las páginas de error de tus aplicaciones pasan sin cambios.

Fuentes de Git

• Un contenedor con fuente de Git puede volver a su build anterior desde la pestaña Source, la API o MCP.
• Un build fallido muestra el paso del Dockerfile que falló y su código de salida, y la fuente explica por qué un build falló o no desplegó nada.
• Las variables de entorno, los secretos y los volúmenes se pueden configurar antes del primer build, y el primer build arranca enseguida.
• La política de seguridad de builds puede bloquear solo las vulnerabilidades que tienen corrección, para los paquetes de la aplicación o para todos los paquetes.

También en esta versión

Las rutas detrás de Cloudflare ven la IP real del cliente en las listas de acceso, los límites de peticiones y los logs. Postgres gestionado funciona con imágenes propias de Opfield, y PostGIS y pgRouting se instalan bajo demanda desde la pestaña Extensions.

Antes de actualizar, ten en cuenta que los archivos de contenedores usan ahora el formato de Opfield (.ofca). Los archivos exportados con versiones anteriores no se pueden importar.

Las instalaciones autoalojadas se actualizan como siempre. Las instalaciones gestionadas en la nube se actualizan en su ventana de mantenimiento.

Qué incluye

Una instalación gestionada es un Opfield completo, la misma versión que la autoalojada, en <name>.opfield.cloud. Se compra y se gestiona en el portal de cuenta, junto con una clave de licencia de pago (Personal, Business o Enterprise). No está disponible con Community.

• Región: Finlandia. Alemania está prevista.
• Acceso con tu cuenta de Opfield. El propietario entra en la instalación con la misma cuenta que usa en el portal.
• Copias de seguridad diarias. Cada día se hace una copia. También puedes hacer una cuando quieras y restaurar desde el portal. Tras eliminar la instalación, la copia más reciente se guarda unos días para poder recuperarla.
• Actualizaciones en tu ventana de mantenimiento. Eliges el día y la hora (UTC). Opfield hace una copia, se actualiza y vuelve con la nueva versión. También puedes actualizar al momento.
• Tus nodos siguen siendo tuyos. Conectas tus propios servidores con tokens de un solo uso desde el portal. Las cargas de trabajo, las bases de datos y el almacenamiento se ejecutan en ellos, no en la VM gestionada.

Planes

Los precios son mensuales, aparte de la clave de licencia, y se renuevan con ella.

Doce meses cuestan lo mismo que once. Puedes pasar de Standard a Extended en cualquier momento pagando la diferencia por el resto del periodo; Opfield se reinicia una vez. Bajar de plan se aplica al final del periodo pagado.

Correo incluido

Opfield envía correos del sistema: códigos de acceso, enlaces para crear y restablecer contraseñas, invitaciones. Una instalación autoalojada necesita un proveedor SMTP para ello. Una instalación gestionada los envía desde el primer momento, desde <name>@mail.opfield.cloud, en los dos planes y sin coste adicional.

Los límites dan de sobra para el correo del sistema y mantienen limpia la reputación del remitente compartido:

• Standard: 500 al mes, 50 al día, 25 por hora.
• Extended: 2000 al mes, 200 al día, 50 por hora.

Tu propio dominio

La instalación puede responder en tu propio dominio, por ejemplo ops.example.com. Añade el dominio en la página de la instalación, crea el registro CNAME que aparece y Opfield obtiene un certificado para él. La dirección en opfield.cloud sigue funcionando. Las passkeys están ligadas a la dirección, así que hay que volver a añadirlas tras un cambio; la página te avisa antes.

IA incluida

Opfield tiene un asistente de IA integrado y un servidor MCP para tus propios agentes. Ambos necesitan un modelo. En una instalación gestionada, Opfield Cloud AI ya está conectado:

• Free, con cada instalación gestionada: uso de modelos incluido.
• S, 9 $/mes.
• M, 29 $/mes, con el doble de uso que S.

Hay dos modelos: Opfield Swift para el trabajo rápido del día a día y Opfield Heavy para tareas más largas y complejas. El uso se muestra como porcentaje de cada ventana, con la hora en que se reinicia. Cuando una ventana se agota, el asistente lo dice y vuelve a funcionar tras el reinicio. El resto de Opfield sigue funcionando.

Cómo empezar

En el portal de cuenta, activa «Host it in our cloud» al comprar una clave, o elige «Add managed cloud» en la página de una clave que ya tengas. Tras el pago, la instalación se configura automáticamente y recibes un correo cuando está lista. Los planes y precios también están en la página de precios.

Las mismas reglas que para una persona

Los agentes no tienen un modelo de permisos aparte. Un cliente MCP se conecta a https://<your-opfield>/api/mcp e inicia sesión con OAuth en nombre de un usuario. En la pantalla de consentimiento, el usuario elige los scopes que recibe el cliente, y nunca pueden ir más allá de lo que el propio usuario puede hacer. El acceso limitado a carpetas, nodos o recursos concretos funciona igual: un agente con acceso a la carpeta de una aplicación ve esa carpeta y nada más. El agente puede llamar a get_my_access para saber qué se le ha concedido y dónde puede crear recursos.

Los agentes pueden hacer con los recursos casi todo lo que hace una persona. Algunas cosas se quedan en el navegador a propósito: la suplantación de usuarios, el consentimiento OAuth, la creación de tokens de API o autorizaciones, y el inicio de sesión y las sesiones del propio usuario. Un agente no puede darse más permisos.

El endpoint MCP solo acepta tokens OAuth emitidos para él; los tokens de la API REST no funcionan allí. Además, el usuario necesita el permiso de MCP, así que un administrador decide quién puede conectar agentes.

Todo queda en el registro de auditoría

Cada acción de un agente pasa por las mismas comprobaciones que un clic en la interfaz y se guarda en el mismo registro de auditoría, con el usuario y el token de origen. Para ver qué cambió un agente durante la noche, basta con abrir el registro de auditoría.

Protecciones contra errores

Los permisos deciden qué puede hacer un agente. Pero algunos errores ocurren dentro de esos permisos, así que Opfield añade protecciones:

• Protección de la consola. Los agentes pueden ejecutar comandos como root en la consola de un nodo, lo que les permite repararlo. Docker, containerd y Podman están ocultos allí, y un comando de Docker se rechaza indicando la herramienta de Opfield que hay que usar. Es una protección contra errores, no una barrera de seguridad: evita que un agente cambie un contenedor gestionado a espaldas de Opfield.
• Sin SSH a los nodos. Los agentes no pueden ejecutar comandos por SSH en hosts que son nodos de Opfield. Para eso está la consola del nodo, con su protección.
• Los cambios fuera de Opfield se ven. Si aun así alguien detiene, cambia o elimina a mano un contenedor gestionado, salta la alerta integrada «Container changed outside Opfield».
• Reintentos seguros. Las operaciones de creación aceptan una clave de idempotencia, así que un agente que reintenta tras un tiempo de espera no crea un duplicado.

Herramientas de Docker en lugar de un shell

La mayor parte del trabajo de un agente con las cargas de trabajo pasa por herramientas específicas y no por comandos de shell: listar contenedores de todos los nodos Docker, leer logs y métricas, reiniciar, actualizar una imagen, cambiar la configuración, gestionar despliegues con slots y vuelta atrás, proyectos Compose, volúmenes, redes y fuentes de Git con sus builds. Como son operaciones de Opfield, las rutas, los Secure Links y la disponibilidad siguen siendo coherentes tras un cambio, y cada paso queda auditado.

Los agentes también pueden leer la documentación y las skills de Opfield a través de MCP antes de cambiar nada.

Ejemplo: un servicio caído

Un usuario escribe a un agente: «La API de facturación devuelve 502 desde esta mañana. Averigua por qué y arréglalo». Una sesión típica:

1. find_resource encuentra la ruta y el contenedor que hay detrás; get_route muestra el upstream.
2. get_docker_container muestra que el contenedor se reinicia una y otra vez y que su fuente de Git desplegó un build nuevo a las 07:40.
3. get_docker_container_logs muestra que el proceso termina al arrancar porque falta una nueva variable de entorno obligatoria.
4. El agente lo explica y ofrece dos opciones: volver al build anterior o añadir la variable.
5. El usuario elige volver atrás. El agente llama a manage_docker_source con rollback y vuelve a comprobar los logs y la ruta: el contenedor funciona y la ruta responde 200. La vuelta atrás aparece en el registro de auditoría con el nombre del usuario.

Nadie necesitó acceso por shell al servidor, y el agente no hizo nada fuera de los permisos del propio usuario.

Cómo empezar

Añade el servidor MCP en tu cliente con la dirección de tu Opfield, inicia sesión y elige los scopes. Empieza con scopes de solo lectura, mira en el registro de auditoría lo que hace el agente y amplía el acceso a medida que ganes confianza. Si prefieres no configurar un cliente, el asistente integrado en Opfield usa las mismas herramientas y las mismas reglas.