The decision framework is simple: match the model to where the file actually needs to be rebuilt. Halo covers the high-volume paths files already move through, and its Zero Trust Kiosk checks removable media at the door, Genesis is the engine itself on the command line, the Embedded Engine puts the rebuild inside your own software, and Meteor works where a server cannot reach.
Glasswall Halo
Managed Kubernetes
Halo is Kubernetes-native, so it runs on the managed control plane you already buy: Azure AKS, Amazon EKS, Google GKE or Oracle OKE. It auto-scales horizontally under high-volume file flows and puts the rebuild inline on the paths files already travel, integrated through the Integration APIs, Web gateway integration and Microsoft 365 storage protection.
Glasswall Halo
Self-managed Kubernetes
Or run the cluster yourself. A private Kubernetes cluster in your own datacentre or your own cloud subscription, on the virtual hosts you already operate: VMware vSphere, Proxmox or Amazon EC2. Same engine and the same policy model, on hardware you control.
Glasswall Halo
Virtual machine appliance
For sites that do not run Kubernetes themselves, Halo ships as a sealed virtual machine image, OVA or VHD: RHEL 9 hardened to DISA STIG with FIPS enabled, running single-node RKE2, dropped straight into the hypervisor you already operate. Same engine and the same policy model, with nothing for your team to assemble.
Glasswall Halo
Managed SaaS
No cluster to stand up and nothing to operate. Safeware hosts Halo in our own infrastructure and runs it for you; you integrate through the Integration APIs or Web gateway integration.
Glasswall Halo
Zero Trust Kiosk
USB sticks, SD cards and discs are checked at the door, before their files reach your network. Encrypted drives are unlocked at the kiosk, the files go through Halo and your other checks, and the engineer collects what passed. One kiosk can run Halo by itself with no network connection, or many kiosks can share a central Halo on your network.
Glasswall Genesis
Command-line binary
The CDR engine itself, as one self-contained binary driven from the command line, and the same engine Halo and Meteor run. Any language that can start a process can call it, so it embeds in an OEM product just as readily as it drops into a build pipeline or a container step, on Linux, Windows and macOS, x64 and Arm64, with the runtime compiled in so there is nothing to install first.
Glasswall Embedded Engine
Embedded library
The other way to embed. Where Genesis is invoked as a process, the Embedded Engine links in as a native library: a C/C++ core with Java, Python and C# wrappers, so the file is rebuilt in process, inside your own binary, before your own code opens it. Choose it over the Genesis CLI when in-process is a hard requirement rather than a preference.
Glasswall Embedded Engine
Cross-domain diode
For a cross-domain solution, the Embedded Engine rebuilds the file, then Transform to XML rewrites it as simple XML that a diode or gateway can check against a schema on the far side. The XML is turned back into the original format on arrival and checked again before the file reaches the high-trust network. Assessable against cross-domain control sets, not itself accredited.
Glasswall Meteor
Desktop agent
A single Windows installer with watched input and output folders: drop a file in, collect a rebuilt copy out, no integration work. Files are cleaned on the endpoint, and Meteor Pro extends the same engine across 200+ local and cloud storage platforms.
Glasswall Meteor
Air-gapped network
Runs fully disconnected inside an air-gapped, classified or in-country network: no internet dependency and no cloud call-out while a file is processed, with updates and policy delivered as offline packages. Files, policy and audit logs stay inside your boundary.