---
title: Charmhub | Deploy Enterprise Store using Charmhub - The Open Operator Collection
description: Deploy the latest version of Enterprise Store on any cloud.
url: https://charmhub.io/enterprise-store/docs/upgrading
---

# Enterprise Store

[Colin Christophe](https://charmhub.io/publisher/colin-c "View all packages from Colin Christophe")

* [Colin Christophe](https://charmhub.io/publisher/colin-c "View all packages from Colin Christophe")

Platform:

24.04

stable 7

```
juju deploy enterprise-store
```

[Learn to deploy on juju >](https://juju.is/docs/juju/manage-applications)

---

Share your thoughts on this charm with the community on discourse.

[Join the discussion](https://discourse.charmhub.io/)

# Upgrading

There are 2 parts of the charm that can be upgraded. The charm itself, and the

`enterprise-store.snap` that is managed by the charm.

If the snap is installed from the snapstore, and the instance on which it is

installed, can reach the snapstore, it will update itself automatically.

If the snap is installed as a resource, then upgrading means attaching a newer

`store-bundle` tarball as the `store-bundle` resource. The tarball contains the

`core22`, `snapd` and `enterprise-store` snaps together with their matching

`*.assert` files, so all of them are updated together whenever a new tarball is

attached (because `enterprise-store` depends on `core22`). The store assertion

(`proxy.assert`) is applied only on the first bootstrap, so update tarballs may

omit it.

Upgrading the charm is done via juju, it is simply a matter of running the

[juju command to upgrade applications](https://juju.is/docs/upgrading-applications)

juju refresh enterprise-store

## [Rolling operations](https://charmhub.io/enterprise-store/docs/upgrading#p-42307-rolling-operations)

When multiple units of `enterprise-store` are deployed, snap and configuration

changes (including charm upgrades that trigger the `upgrade-charm` hook) are

coordinated through the `rollingops-peers` peer relation (`charmlibs-rollingops`)

so that at most one unit restarts its services at a time. While queued, units

report `MaintenanceStatus("Waiting for rolling-ops lock")`; no manual action is

required.

---