Ahora cada entorno nace protegido

Los contenedores nuevos quedan protegidos desde el momento en que se crean

Las reglas de firewall se aplican ahora automáticamente como parte de la creación del contenedor. Solo quedan accesibles los puertos que tu entorno necesita de verdad —8069, 8072 y 22— y únicamente a través del proxy correspondiente. Todo lo demás queda cerrado.

No hay un paso de hardening que recordar ni una ventana en la que un entorno recién creado quede expuesto. Tanto si creas un contenedor como si aprovisionas una docena para distintos clientes, todos arrancan desde la misma base segura.

Tus usuarios LDAP dejan de recibir avisos para cambiar contraseñas que no gestionas

Si tus usuarios se autentican por LDAP, sus credenciales viven en tu propio directorio, no aquí. A partir de este release, esas cuentas quedan exentas de las reglas internas de contraseña de la plataforma, así que nadie recibe un aviso de caducidad ni un cambio forzado por una contraseña que Binhex Cloud no controla.

Una fuente de confusión menos para tus usuarios, y una conversación de soporte menos para quien gestiona sus accesos.

Esto se aplica únicamente a cuentas autenticadas por LDAP. Los usuarios locales siguen sujetos a las políticas de contraseña estándar.

La suspensión y la reactivación siguen ahora el estado de pago por sí solas

Cuando una factura entra en mora, la base de datos correspondiente se suspende automáticamente. Y en cuanto se registra el pago, el entorno vuelve por sí mismo: sin ticket, sin esperar a que alguien de nuestro lado lo procese, sin tiempo muerto entre pagar y volver a trabajar.

Para los partners que gestionan varios entornos de clientes, esto elimina la parte más frustrante de cualquier incidencia de facturación: el hueco entre resolver el problema y recuperar de verdad el servicio. El estado del entorno y el estado de la cuenta quedan alineados sin nadie en medio.

Los datos del análisis de migración ya viven en la plataforma​

Nuestro script de análisis de migración se ha actualizado para generar datos más detallados sobre el sistema que se va a migrar, y la plataforma ya los recibe y los muestra directamente. Las estimaciones de alcance y esfuerzo se construyen sobre información más completa, en el mismo sitio donde se gestiona el entorno.

El análisis funciona en dos modos: antes de una migración y como análisis mensual rutinario, de forma que la visión de un sistema no se queda en el momento del traslado.

Las siguientes mejoras las usan nuestros equipos técnico y de soporte. No las vas a ver en tu portal, pero sí las vas a notar en la rapidez con la que se responde a una pregunta sobre tu entorno.

El registro completo de cada entorno, en un solo sitio

Los resultados de las operaciones automatizadas de aprovisionamiento y mantenimiento —estado, logs y metadatos de ejecución de los playbooks y tareas de Ansible— se almacenan ahora de forma permanente en lugar de perderse al terminar la ejecución. Además, un nuevo acceso directo en la ficha del contenedor abre todos los jobs de Jenkins relacionados con ese contenedor en un único lugar.

Cuando preguntas qué ha pasado con un entorno, nuestro equipo parte del histórico completo ya en pantalla, en vez de reconstruirlo entre sistemas.

Una credencial propia para cada integración interna

Los endpoints internos que consumen Jenkins, n8n y los propios contenedores están migrando de autenticación por sesión a claves API por sistema (tokens Bearer). Cada integración se puede trazar y revocar por separado, lo que hace que los accesos dentro de la plataforma sean precisos y fáciles de auditar.

Esta migración se está desplegando de forma progresiva en los distintos endpoints técnicos.

El resto de este release es mantenimiento y limpieza interna. Nada de esto requiere ninguna acción por tu parte: lo listamos para que el registro de lo que ha cambiado esté completo.

Mejoras

• Las notificaciones al propietario del contenedor y a sus seguidores se pausan mientras se ejecuta una migración, de modo que nadie recibe avisos sobre un entorno que está en pleno proceso.
• Se ha añadido validación de fortaleza de contraseña en el formulario de creación de contenedores, para que una credencial débil no llegue a un entorno activo.
• El captcha del formulario de registro se ha desacoplado y ahora es opcional, así que puede activarse o desactivarse de forma independiente.
• Limpieza del modelo de Proxmox: se ha eliminado el campo de clave SSH de los nodos y el campo de dominio pasa de las plantillas de contenedor al nivel de nodo, para una configuración más precisa.
• Se ha ocultado el botón «Nuevo» en la vista de contenedores, de forma que los entornos se crean siempre por el flujo estándar.

Correcciones

• Los avisos de expiración vuelven a enviarse correctamente: el indicador de «email de aviso enviado» se reinicia al ampliar la fecha de expiración o al marcar el contenedor como permanente.
• Corregidos los errores al obtener información del clúster de Proxmox durante la comprobación de disponibilidad de nodos.
• El botón de Tokens se oculta ahora en los contenedores que no tienen agentes de IA activos.
• La dirección IP se configura y se valida correctamente tras restaurar un contenedor desde una copia de seguridad.