You can give a disconnected site the cloud's self-service without a connection. Orion is built to run air-gapped. You mirror its images and charts into a local registry, the license is checked on site, and nothing phones home. Admins set up templates once, and users launch web apps, containers, Linux desktops or Windows VMs from a browser catalog. Updates, data movement and accreditation stay your team's process.
At a disconnected site, getting compute usually means a ticket and a VM someone builds by hand. Teams in the cloud get a catalog and a launch button, and the people at the site know it.
An infrastructure lead at a large organization that runs several disconnected sites put it in one line on a call with us this summer. “Being able to go cloud without moving to the cloud is definitely a huge thing.” On the same call, one of our advisors said an energy utility had asked for nearly the same thing. They have air-gapped sites, on-prem hardware and cloud, and they wanted the cloud experience brought down to them instead of moving everything up.
That’s a fair ask, and it’s harder than it sounds. Plenty of cloud-style tools assume a connection home, for licensing, updates or telemetry. At a site with no internet connection, that assumption is the first thing that breaks.
What does “cloud” mean at a site with no internet?
When people at these sites say they want the cloud, they rarely mean a provider. They mean the way the cloud works for the user. You pick what you need from a catalog, it starts in minutes, you give it back when you’re done, and nobody files a ticket. Admins set the menu and the limits once and stop building the same VM by hand every week.
None of that needs a public cloud. It needs software that runs on the hardware already at the site and never has to call out.
How does Orion run on a closed network?
There is no separate disconnected edition. The same Orion release runs connected or offline. The license is a file Orion checks locally, Orion doesn’t phone home, and no logs leave the site.
To install on a closed network, you mirror our container images and Helm charts into an internal registry and point the cluster at it. The air-gapped install guide lists what to mirror. Connected and disconnected clusters run the same version, so the site isn’t stuck on a special build that drifts from everyone else’s.
Once it’s up, the experience at the site is the same one users get anywhere else. Admins author templates in Orion Admin and assign them to workspaces. Users log in from a browser and launch what they need, whether that’s a web app, a container, a Linux desktop or a Windows VM. Sign-in goes through the identity system you already run, over LDAP, with groups mapped to roles. Workloads run as the user’s own UID and GID, so file permissions on site storage behave the way they already do. Idle workloads hibernate or shut down after an idle period the admin sets, with a warning first, so the hardware comes back without anyone chasing it.
Monitoring stays local too. Node health shows on the Networking page in Orion Admin, and cluster metrics come from the kube-prometheus-stack plugin running on the same cluster. The security page has more on how Orion runs inside your boundary.
Who handles accreditation?
You do. Because Orion runs inside your boundary, on your hardware, your security team assesses it the way they assess any other software you install. In federal systems that usually means an Authority to Operate. Under the NIST Risk Management Framework, a senior official at your organization reviews the package and decides whether to accept the risk. Utilities, research operators and other regulated sites have their own versions of that sign-off.
The decision is yours, and the evidence has to describe your deployment. We send security documentation on request. Ask for it early. Security review is the step most likely to run long, and it’s easier to start before a pilot than halfway through one.
What stays hard at a disconnected site?
Orion doesn’t make the network less disconnected. Some things stay your problem, and I’d rather say so up front.
Updates still move the way everything else moves onto a closed network. Someone carries new images in, checks them and loads them into the registry. That process belongs to your team, and it should be written down before the first install.
Data movement is a planning problem. If a pilot needs terabytes of data on site, moving and validating it can take longer than the pilot itself. Put it in the schedule.
Hardware at these sites tends to be old, mixed or both. Orion runs on mixed nodes, x86 and ARM, bare metal and hypervisors, so a site can use what it has. It still can’t make a ten-year-old server faster.
And if the site has a handful of users and one app, you probably don’t need a platform. A well-run VM and a good runbook may be enough. Orion starts paying off when several teams share the hardware and the ticket queue is the bottleneck.
How do you try it without a purchase order?
Community Edition is free to install and runs two workloads at a time before a license is needed. It installs on a closed network the same way the paid version does. When you want to test with real teams, a Proof of Value runs on your own hardware, self-serve or with our engineers. Our edge and air-gapped page has the rest.
If you’re planning a site, talk to our team.
WRITTEN BY
Tony Como
Tony runs go-to-market at Juno, from first outreach to production deployment. He works across sales, partnerships, and operations to help technical teams move faster without adding infrastructure overhead.