SerpApi.Org
Canonical officially announced the Enterprise Store on July 21, 2026 — a generally available, on-premises edge proxy that lets organizations install and update Ubuntu software packages in air-gapped and internet-restricted environments without routing every device through the public internet.
The launch matters for a specific reason that goes beyond feature additions: it closes a structural gap that has quietly blocked snap adoption in regulated industries for years. Because the Snap Store's backend is proprietary and not self-hostable — unlike APT, where organizations can run a full local mirror entirely on their own hardware — enterprises that could not permit outbound internet access had no supported path to snap-based deployments. The Enterprise Store is a proxy, not a standalone store, which means it still depends on Canonical's upstream infrastructure for content — but it resolves the connectivity problem that made the format categorically impractical for air-gapped environments. Administrators managing power plants, manufacturing control systems, or classified government networks can now manage snap packages and charm operators through a single, locally controlled distribution layer.
What Canonical Enterprise Store Does — and What It Cannot Do
The Enterprise Store sits between devices and Canonical's public software stores. Client machines register with the local proxy, and all snap-related traffic from registered devices flows through it rather than reaching out directly to snapcraft.io or the Charmhub.
This architecture provides four capabilities that were previously unavailable or unsupported in enterprise snap deployments:
Local caching means that once a package arrives at the proxy from Canonical's upstream, every subsequent request from fleet devices is served locally. In large deployments, this reduces both outbound bandwidth consumption and the latency of repeat downloads.
Air-gapped offline mode allows the store to operate in fully disconnected environments. Administrators export snap packages and their cryptographic assertions — signed metadata that devices use to verify package authenticity — from an internet-connected system, physically transfer the data to the isolated network, and import it into the local proxy. From that point, client devices in the isolated network install and update from the local store without any external connectivity.
There is an important architectural constraint here: the documentation explicitly warns that switching an active proxy between online and offline modes has "undesirable and not clearly defined consequences" for already-connected devices. Air-gap mode is a one-time configuration decision for the lifetime of a deployment, not a toggle administrators can flip as circumstances change.
Granular revision control lets teams pin specific snap or charm versions across the fleet through an Overrides API. When a client requests a package, the proxy returns the pinned revision rather than whatever version Canonical has published upstream. For regulated industries — where a software version change can trigger a compliance review, a re-certification process, or an industrial control system restart — this deterministic delivery model addresses an objection that previously made snaps a non-starter alongside traditional APT package management.
High availability support allows organizations to deploy multiple Enterprise Store instances behind a standard reverse proxy. The reverse proxy routes traffic and performs health checks across backend units; if one instance goes down, clients continue receiving packages from surviving nodes. Shared state — including revision overrides and device registrations — is maintained through a PostgreSQL database that administrators must configure separately. For organizations used to simple file-based APT mirrors, the PostgreSQL dependency represents added operational complexity.
One Proxy for Snaps and Charms — the Unified Governance Surface
A technically significant aspect of the Enterprise Store is its handling of two distinct artifact types: snaps and charms.
Snaps are self-contained application packages, compressed using SquashFS and sandboxed via AppArmor and seccomp. They are designed to auto-update and work across desktop, server, cloud, and IoT environments without requiring distribution-specific packaging.
Charms are a different kind of artifact. They encode the operational logic for deploying, scaling, configuring, integrating, and managing applications over time — primarily in cloud and Kubernetes contexts. They are the foundation of Canonical's Juju ecosystem. Previously, organizations managing both snaps and charms in restricted environments had to handle them through separate mechanisms.
The Enterprise Store consolidates this into a single proxy, giving infrastructure teams one governance surface for both software delivery (snaps) and software operations (charms). For organizations running hybrid Kubernetes clusters in air-gapped data centers, that consolidation reduces the number of trust boundaries, audit surfaces, and operational procedures that compliance teams need to track.
Why This Took So Long: The Structural Constraint Snap Inherited
The Snap Store Proxy — the predecessor to the Enterprise Store — has existed in Canonical's Ubuntu Pro subscription tier for several years, providing basic caching and revision override for snap packages. The rebranding to "Enterprise Store" reflects the formal addition of charm support, HA configuration guidance, and an upgraded position in Canonical's enterprise portfolio.
But the more substantive question is why a fully air-gapped-capable version took this long to reach general availability — and the answer is architectural. Traditional APT repositories are an open format: any organization can run a complete local mirror using tools like apt-mirror or aptly with no dependency on Canonical's infrastructure. Snaps do not work this way. The Snap Store backend is proprietary — clients interact with it through a defined API, but organizations cannot run their own equivalent of that backend independently.
This is why the Enterprise Store is a proxy rather than a mirror: it cannot serve content that has not first been approved and published through Canonical's infrastructure. In practice this means an air-gapped Enterprise Store must be seeded from an internet-connected instance — the data path always flows through Canonical's systems at some point. For many enterprise and government environments, this is acceptable. For environments where the contents of every deployed package must be verified without reliance on any external vendor's infrastructure, it remains a meaningful constraint.
How It Fits Into Ubuntu Pro — and What Enterprise Deployment Actually Costs
The Enterprise Store ships as part of Ubuntu Pro, Canonical's commercial support and security subscription tier. Ubuntu Pro is free for personal use on up to five machines, allowing individual administrators to evaluate the proxy in a lab environment before proposing a production rollout.
For production deployments — particularly across large fleets, regulated environments, or OT networks — Canonical directs organizations to contact its commercial team for pricing and deployment planning. Canonical's 2024 annual report, filed with UK Companies House, showed subscription revenue of $235 million, up 19% year over year, out of total revenue of $292 million. Ubuntu Pro subscriptions are the primary revenue driver as Canonical has systematically bundled enterprise tooling — Extended Security Maintenance, Livepatch, Landscape, and now the Enterprise Store — into the tier.
The Ubuntu Pro model means there is no separate line-item purchase for the Enterprise Store. But for large-scale regulated deployments, the proxy is not free in the practical sense: it requires a PostgreSQL instance, server hardware or VM resources sufficient for the proxy and its cache, network engineering for HA configuration, and administrative overhead for managing air-gap export and import cycles. Organizations evaluating the total cost of ownership against alternatives — Red Hat's Satellite content management platform, for instance — should account for those operational components.
Why Regulated Industries and OT Environments Are the Real Target
The supply chain security pressure that makes tools like the Enterprise Store increasingly necessary has intensified significantly over the past five years. Major supply chain incidents — including the SolarWinds compromise in 2020 and the XZ Utils backdoor in 2024 — demonstrated that automated update mechanisms can be attack vectors, not just delivery systems. The U.S. Executive Order 14028 on cybersecurity (2021) and the EU's Cyber Resilience Act, currently driving compliance timelines across European enterprises, have both elevated software distribution governance from an IT preference to a regulatory requirement.
Ubuntu holds approximately 33.9% of general server deployments globally and leads in cloud environments as of 2025. That footprint means the snap ecosystem's enterprise adoption story has real stakes: if snaps remain impractical in the most security-sensitive segments of that footprint, those segments — OT, defense, regulated finance, critical infrastructure — either stay on APT-based deployments permanently or move to other distributions where fully open package distribution is available.
The Enterprise Store is Canonical's answer to that pressure. Whether it is sufficient will depend on how regulated industries and government agencies evaluate the remaining constraint: the proxy's dependency on Canonical's proprietary upstream. For environments where "no outbound internet, ever, by any mechanism" is the actual requirement, the seeding step during initial setup — exporting packages from an internet-connected instance before air-gapping the proxy — may require review at procurement and security architecture level.
How to Get Started
The Enterprise Store documentation is available at documentation.ubuntu.com/enterprise-store and includes a getting-started guide for both online proxy mode and air-gapped deployments. Ubuntu Pro subscribers with up to five machines can begin an evaluation immediately; the enterprise-store snap was available on the 3/stable channel since November 2025, meaning the underlying software is not new — what the July 21 announcement formalizes is Canonical's commercial support commitment and the product's official name and identity.
Organizations with larger fleets, compliance requirements, or complex OT network architectures can contact Canonical directly for evaluation planning and architecture review.
Frequently Asked Questions
What is the Canonical Enterprise Store and how is it different from the old Snap Store Proxy?
The Enterprise Store is the renamed and expanded successor to the Snap Store Proxy, which has been part of Ubuntu Pro for several years. The key additions in the GA release are official charm support (the Snap Store Proxy handled only snaps), high availability configuration guidance, and formal commercial support as a named product. The underlying architecture — an on-premises edge proxy that routes registered device traffic through a local cache rather than directly to Canonical's public infrastructure — is the same.
Can Ubuntu snaps work in a fully air-gapped environment with no internet access?
Yes, with an important caveat: the Enterprise Store can operate in offline mode, but seeding it requires an internet connection at least once. An administrator must export snap packages and their cryptographic assertion metadata from an internet-connected Enterprise Store instance, physically transfer that data to the isolated network, and import it into the offline proxy. After that seeding step, devices on the isolated network install and update from the local store without any internet access. The documentation explicitly warns against toggling air-gap mode on an active deployment, so offline mode is a configuration decision made at setup time, not an on-demand switch.
Why can't I just run my own full Snap Store the same way I can run a local APT mirror?
This is a structural difference between the two formats. APT repositories use an open, standardized format — any organization can run a complete local mirror with no dependency on Canonical. The Snap Store backend is proprietary; Canonical has not published the server-side infrastructure as open source. The Enterprise Store is therefore a proxy to Canonical's upstream rather than a standalone store. All content it serves must first be published through Canonical's infrastructure. For organizations that require completely vendor-independent package distribution, this is a meaningful distinction.
Does the Enterprise Store protect against supply chain attacks on snap packages?
Partially. Revision pinning — the ability to lock devices to a tested, approved package version — prevents unplanned upstream updates from reaching production systems, which is one vector for supply chain compromise. The proxy architecture also means that the internet-facing download surface is reduced to a single controlled point rather than every device in the fleet. However, the Enterprise Store does not independently verify package contents; it relies on Canonical's upstream signing and assertion infrastructure. A compromise of Canonical's upstream store would still affect packages served through the proxy unless revision overrides are in place for the affected packages.
