Hi everyone,
For a while now, experimental.parallel-instances has let you install the same snap multiple times side-by-side (e.g. <snap-name>, <snap-name>_<key1>, <snap-name>_<key2>), each with its own data, revisions and sandbox. It’s been very useful for developers, CI setups, and anyone who needs to track multiple channels of a snap simultaneously — but it’s remained experimental, and we want to change that as part of the planned updates to snapd experimental features.
We’re doing the work needed to move parallel instances from an opt-in experimental flag to a natively supported, default-on feature of snapd, and we wanted to share where things stand and ask for your input.
What’s changing: interface-aware checks
One of the biggest gaps blocking stabilization was that snapd didn’t verify whether the interfaces a snap plugs or slots actually make sense to duplicate. Most interfaces are generally fine — two parallel instances each get their own confinement, their own mount namespace, etc. But a meaningful subset of interfaces grant access to resources that are physically or structurally singular, or grant ownership to a global single name, and letting two instances fight over them can silently break things in ways that are hard to diagnose.
We are currently going through snapd’s interface catalog and are classifying each interface’s plug and/or slot side as either safe for parallel instances, or not — and where not, snapd will now reject the install with a clear error rather than let you discover the conflict at runtime.
A few examples of interfaces we’re marking unsupported, and why:
-
The various
*-supportinterfaces (e.g.docker-support,lxd-support,kubernetes-support,checkbox-support) — these are very application-specific interfaces that usually evolve with their own development. Unless specifically requested, these are currently marked unsupported. -
The
*-driver-libsinterfaces (e.g.opengl-driver-libs,vulkan-driver-libs,cuda-driver-libs) — these currently lack the appropriate instance-aware separation in snapd and could potentially be enabled in the future. -
dm-crypt— this manages a global kernel device-mapper state that isn’t scoped per snap instance, so concurrent operations from two instances can conflict with each other’s mappings. -
posix-mq— POSIX message queues are identified by a single global, non-namespaced name; two instances would collide on the same queue name and can’t both bind/own it independently. -
shared-memory(non-private mode) — in non-private mode the shared memory segment is identified by a name the instances don’t control independently, so two instances would map and mutate the same segment with no coordination. -
bluez,network-manager,fwupd,x11,wayland— these are unsupported on the slot side as they own their well-known socket or D-Bus names and two instances can’t both own that name/socket.
Note that this is not an exhaustive list — we’re still working through the full interface catalog.
Separately, several interfaces are marked unsupported on the slot side simply because their slot can only be provided by snapd, base or a gadget snap — and none of those essential snap types support parallel instances.
For interfaces that are supported (the vast majority), nothing changes. For the ones that aren’t, you’ll get an install-time error telling you exactly which plug or slot and interface is blocking the parallel install.
A note on existing parallel installs
The supported interfaces check is also applied during snap refreshes. If you already have a snap installed as a parallel instance under an older snapd, and you upgrade to a snapd version where one of that snap’s plugged/slotted interfaces has since been marked unsupported for parallel instances, refreshing that parallel instance will also be blocked — with the same kind of error you’d get from a fresh install. You’ll see a clear message identifying the responsible interface.
If this potentially affects a snap you rely on, let us know and we’ll take a closer look at those restricted interfaces.
Classic confinement
Snaps with classic confinement introduce some additional challenges, which we’re still looking to address because we know that some use cases depend on it.
Timeline
Several of these interface-support changes — along with other foundational fixes to make parallel instances more robust — are on track to land in the upcoming snapd 2.79 release.
We’d like your input
We’d like to hear more about how parallel instances are actually being used. If you’re currently running (or planning to run) snaps as parallel instances, we’d really appreciate hearing from you:
-
Which snap(s) are you installing as parallel instances and what are the use cases?
-
If possible, share a link to the snap’s snapcraft.yaml so we can look at what interfaces/plugs/slots it declares.
-
Have you observed any errors or unexpected behavior with parallel instances so far?
This will help us better understand the requirements behind the different use cases of parallel instances and help us catch edge cases we haven’t thought of yet.
Thanks for reading, and we’re looking forward to your feedback!