Every environment now starts locked down
New containers are created with access already restricted, LDAP users stop being asked for passwords you don't manage, and environments come back online the moment a payment clears.
PlatformSeptember 7, 2026
Secure by default, and no dead time once a payment is resolved
Version 1.6 changes how protected an environment is the day it is created, and removes the waiting that used to follow a resolved billing situation. If you manage environments for your own customers as a partner, both changes apply across your whole base without any extra work on your side.
It also brings a deeper migration analysis, along with traceability and authentication work that runs behind the scenes. Everything included in this release is listed below.
1. Security
Nothing left to configure before an environment is safe to use
New containers are protected from the moment they are created
Firewall rules are now applied automatically as part of container creation. Only the ports your environment actually needs — 8069, 8072 and 22 — are reachable, and only through the corresponding proxy. Everything else is closed.
There is no hardening step to remember and no window where a fresh environment sits exposed. Whether you create one container or provision a dozen for different customers, they all start from the same secure baseline.
Your LDAP users stop being asked to change passwords you don't manage
If your users authenticate through LDAP, their credentials live in your own directory — not here. From this release, those accounts are exempt from the platform's internal password rules, so nobody gets an expiration warning or a forced reset for a password Binhex Cloud has no control over.
One less source of confusion for your users, and one less support conversation for whoever manages their access.
This applies only to LDAP-authenticated accounts. Local users continue to follow the standard password policies.
2. Service Continuity
A resolved payment brings the environment back immediately
Suspension and reactivation now follow payment status on their own
When an invoice goes overdue, the corresponding database is suspended automatically. And as soon as the payment is registered, the environment comes back by itself — no ticket, no waiting for someone on our side to process it, no dead time between paying and working again.
For partners managing several customer environments, this removes the most frustrating part of any billing incident: the gap between the problem being solved and the service actually returning. Environment status and account status now stay aligned without anyone in the middle.
3. Migrations
A more complete picture of the system before it moves
Migration analysis data now lives in the platform
Our migration analysis script has been updated to produce more detailed data about the system being migrated, and the platform now receives and displays it directly. Scope and effort estimates are built on more complete information, in the same place where the environment is managed.
The analysis runs in two modes: before a migration, and as a routine monthly analysis — so the picture of a system doesn't stop at the moment of the move.
4. Internal Operations
Faster answers when something needs to be checked
The following improvements are used by our technical and support teams. You won't see them in your portal, but you'll notice them in how quickly a question about your environment gets answered.
The full record of every environment, in one place
Results from automated provisioning and maintenance operations — status, logs and execution metadata from Ansible playbooks and tasks — are now stored permanently instead of being lost once the operation finishes. A new shortcut on the container record also opens every Jenkins job related to that container in a single place.
When you ask what happened to an environment, our team starts from the complete history already on screen, rather than piecing it together across systems.
A dedicated credential for every internal integration
The internal endpoints consumed by Jenkins, n8n and the containers themselves are being migrated from session-based authentication to per-system API keys (Bearer tokens). Each integration can be traced and revoked on its own, which makes access across the platform precise and easy to audit.
This migration is being rolled out progressively across the technical endpoints.
5. Under the Hood
Everything else that shipped in 1.6
The rest of this release is maintenance and internal cleanup. Nothing here needs any action on your side — we list it so the record of what changed is complete.
Improvements
- Notifications to the container owner and its followers are paused while a migration is running, so nobody receives alerts about an environment that is mid-process.
- Password strength is now validated on the container creation form, so a weak credential can't reach a live environment.
- The captcha on the registration form has been detached and made optional, so it can be enabled or disabled independently.
- Proxmox model cleanup: the SSH key field has been removed from Proxmox nodes, and the domain field has moved from container templates to node level for more accurate configuration.
- The "New" button has been hidden on the container view, so environments are always created through the standard flow.
Fixes
- Expiration warnings are sent correctly again: the "warning email sent" flag now resets when the expiration date is extended or the container is marked as permanent.
- Fixed errors when retrieving Proxmox cluster information while checking node availability.
- The Tokens button is now hidden on containers that have no active AI agents.
- The IP address is configured and validated correctly after restoring a container from backup.
Thinking about migrating?
Talk to our team about moving a system you're currently evaluating — or create a workspace and see for yourself how the platform secures and manages your environments, with Emma AI inside from day one.