Run deployment and operational workflows inside a disconnected network. OptimusHub provides a self-hosted platform for deploying applications, services, and supported infrastructure without depending on public cloud control planes. It installs inside your network, and a fully disconnected deployment works with zero required outbound connectivity.
Talk to us about your operating environment →OptimusHub runs inside your network, on your infrastructure, with your data. Here's exactly what that means.
OptimusHub runs entirely inside your network. There is no public SaaS backend and no vendor cloud in the request path.
A fully air-gapped install works with zero outbound connections. Optional integrations - a Git remote, a registry, SMTP - are opt-in, never required for the platform to run.
Operational data, configuration, credentials, and audit logs live in a database you deploy and control, inside your perimeter. Nothing is mirrored to us.
OptimusHub connects to your virtualization platform, clusters, and hosts using the credentials and network paths you configure - no VPNs or trust boundaries to rebuild.
OptimusHub operates your workloads but is not in their request path. Your applications don't call it, depend on it, or route traffic through it to run.
Moving off OptimusHub is an operational migration, like retiring any management tool: export configuration and audit history, repoint CI/CD and access controls, decommission the instance.
No telemetry, no phone-home, no license-check callbacks.
RBAC, SSO (LDAP / OIDC), and an internal PKI enforced inside your network.
Every platform action - who, what, when, from where - recorded in a database you control.
Access control, audit trail, and internal PKI that support your own audit program. No certification is claimed.
Running air-gapped is not only a security posture - it changes how deployment, access, and audit actually get done day to day. Without one shared platform, disconnected sites tend to be managed through whatever the last engineer on-site set up: local scripts, manual change logs, and access granted by memory rather than policy.
With one platform to provision, deploy, and operate, deployment, access control, and audit logging work the same way whether the environment has internet access or none at all - so a disconnected site isn't a special case your team has to remember how to handle. For the general deployment workflow, see on-prem application deployment.
What runs locally. The platform, its database, identity and access control (RBAC, LDAP / OIDC), the internal PKI, and the audit trail all run inside your network. The built-in CI/CD engine uses prebuilt offline runner images for .NET, Go, Java, Node, PHP, Python, Ruby, and Rust.
Before you disconnect. Installation uses a tarball installer that verifies the bundle's SHA-256 before installing. Offline bundles cover runner images, infrastructure images, and vulnerability scan databases, and a global CA trust store supports internal certificate authorities. Any images and packages your own workloads need must also be made available inside the network before you deploy them.
How artifacts are introduced and deployed. Kubernetes clusters can be deployed in air-gapped networks, and the deployment automation can install runtimes such as Docker, git, and Python on air-gapped hosts. The vulnerability scan database can be uploaded offline. Applications and databases are then deployed from the platform's catalogs, or through CI/CD pipelines, as Docker containers, on Kubernetes, or as services running directly on machines.
How updates are handled. The OptimusHub Updater has a local upload path: you transfer the per-image archives and release manifest from the release package, and the updater loads them, verifies SHA-256 integrity, restarts the stack, runs a health check, and reverts to the previous image versions if the update fails.
External services and limitations. The platform requires no outbound connectivity to run. Connections to an identity provider, your virtualization platform for VM provisioning, a Git service, a container registry, or SMTP are used only if you enable them, over network paths you configure inside your perimeter. The contents of the offline bundles, supported host operating systems, and the topology for sites that mix connected and disconnected networks depend on your environment, so confirm them with us before planning an installation.
Bring the details of your disconnected or restricted environment. We'll help map where this fits.
Talk to us about your operating environment →