# Skupper 2: a virtual application network across clouds, VMs and mainframes

> A Go implementation of a Virtual Application Network that gives location independent, secure connectivity between workloads in public cloud, private cloud, virtual machines, bare metal and mainframes. Version 2 replaces the CLI-first model with Kubernetes custom resources, and it is not interoperable with version 1.

**skupperproject/skupper** — Skupper is an implementation of a Virtual Application Network, enabling rich hybrid cloud communication.

- Repository: https://github.com/skupperproject/skupper
- Website: http://skupper.io
- Stars: 705 · Forks: 93
- Language: Go
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/skupperproject-skupper

## What a virtual application network actually is

Skupper allows you to create a Virtual Application Network, or VAN, enabling secure, location independent communication between systems including public cloud, private cloud, virtual machines, bare metal hosts, and mainframes.

The concept matters more than the implementation. A normal application network assumes the topology: a service lives at an address, and clients reach it through a name service and a network path. A virtual application network replaces both with a logical overlay. An address becomes a name that the network resolves wherever the peer happens to be, and the path becomes something the network constructs for you.

That is what makes the mainframe and bare metal entry in the list meaningful rather than decorative. A mainframe cannot run a sidecar proxy that assumes a modern Linux userland, and it cannot be given a routable address in your VPC. It can, however, run a Skupper router, which is a small process that joins the overlay and forwards traffic for the services behind it.

The audience is therefore platform teams with estates that do not share a network, a runtime or a cloud. The project description calls it an implementation of a Virtual Application Network enabling rich hybrid cloud communication, and the readme says the objective of v2 is to better support a full declarative model so that applications and VANs can be more easily deployed in fully automated frameworks.

That last phrase is the theme of version 2. The problem is not connectivity, which version 1 solved. The problem is doing it in a way that survives being managed by software instead of by hand.

## Version 2 is a different model, not a new release

The most important thing to understand before evaluating Skupper 2 is that it is a redesign, and the readme is unusually direct about the consequences.

Skupper v2 sites are not interoperable with v1 sites. The plan is to provide tools to assist users to migrate their v1 installations to a v2 deployment as the release approaches.

So this is a cutover, not an upgrade. A deployment that mixes a v1 site and a v2 site does not connect, and the migration tools are planned rather than described in detail in this readme.

The readme also notes that version 1 of Skupper, on the v1 branch, is working in many production environments and has significantly reduced the time, effort and expense of deploying applications to a hybrid multicloud. And Skupper v1 will continue to be maintained but no new significant features are planned.

That is a fair and useful position for an adopter to weigh. If you have a working v1 deployment, nothing forces you to move, and the v1 branch keeps receiving fixes. If you are starting fresh, v2 is the version you will live with, and the v1 to v2 tooling will matter to you only if you are migrating.

The release numbers tell you the same story. The recent releases are 2.2.3 on 2026-09-30, 2.2.2 on 2026-08-17, and 1.9.6 on 2026-06-18, so the v1 line is still getting patch releases while the v2 line moves at its own pace. The last push was on 2026-10-19.

## Custom resources replace the CLI as the interface

The release highlights describe what changed, and the first item is the interface.

The introduction of Custom Resource Definitions for a more intuitive and flexible declarative interfaces for users, with an equivalent implementation for Linux. Alongside that there are architectural improvements for the primary components, for example the controller, the CLI, and the non-Kube executable, a flexible PKI implementation allowing users to easily provide their own certificates as required, a network collector and console that is deployed separately from the site components, and simpler integrations for centralized application network definition.

The CRD piece is the substantive one. A CRD means the network definition becomes an object in the Kubernetes API, so it can be created by a manifest, reviewed in a pull request, and reconciled by a controller. That is what the phrase deployed in fully automated frameworks means in practice, and it is the difference between a VAN you configure and a VAN you declare.

The equivalent implementation for Linux matters because the same declarative model has to work when the endpoint is not in Kubernetes. A mainframe, a bare metal host or a virtual machine running something other than Kubernetes has no API server to host a CRD, so there is a parallel mechanism that expresses the same intent.

The separate deployment of the network collector and console is the other architectural note. The observer side of the system, which is what shows you what the network looks like, is not bundled into the site components. That is a deliberate separation of the data plane from the tooling around it, and it means the observer can be upgraded or run centrally without touching the routers that carry your traffic.

## The component set, and the build behind it

The repository tree is a good map of the system, because Skupper is a set of cooperating binaries rather than one program.

There is a controller, a CLI, a network observer, a system controller, a kube adaptor, and a source image. The cmd directory holds the entry points and the readme links point into it: a simple declarative example under cmd/controller/example, the network observer deployment under cmd/network-observer, the CLI documentation under cmd/skupper, and Helm charts under charts. There is also a Redis example in a separate skupper-example-redis repository on the v2 branch, which is the kind of small thing that tells you the intended usage pattern is one VAN per application topology.

The Makefile confirms the build. The default target builds skupper, controller, kube-adaptor, network-observer, system-controller and generate-doc. Container images go to quay.io/skupper, and the platform list is linux/amd64 and linux/arm64. The Go version is pinned to 1.26, the Go directive in go.mod is 1.26.0 with a toolchain line of go1.26.9, and the Kubernetes dependencies sit at 0.33.0 with controller-runtime at 0.21.0.

The image list in the tree is longer than the target list because some are for development only: Dockerfile.ci-test, Dockerfile.cli, Dockerfile.controller, Dockerfile.kube-adaptor, Dockerfile.must-gather, Dockerfile.network-observer, Dockerfile.source and Dockerfile.system-controller. The must-gather image in particular is the kind of thing a support engineer asks for, and its presence says the project expects to be debugged in production.

The dependencies also hint at what the routers speak. There are AMQP libraries from Azure and from interconnectedcloud, a Prometheus client, OpenAPI generators, a Cobra based CLI, and the skupper-libpod library, which is how the router is managed inside Podman or Docker on the endpoint hosts.

## A first deployment, following the projects own examples

The readme does not carry an install command, and it points you at worked examples instead, which is the honest way to start with a system that has both a Kubernetes and a non Kubernetes path.

The entry points are the Simple Declarative Example under cmd/controller/example, the CLI Example under cmd/skupper, the Network Observer Deployment under cmd/network-observer, the Helm Charts under charts, and the Redis example repository for a complete application.

The order that makes sense is the one those links imply. Start with the declarative example, because a CRD-based network is defined as a manifest and the example shows the shape of one. Use the CLI example to understand what the controller does with it, including the non Kubernetes equivalent. Install the Helm charts when you are ready to put it into a cluster, and treat the Redis example as the reference topology.

The observer is a separate deployment, so it does not have to be installed at the same time as the site components. That is worth noting when you are sequencing a first install, because the readme's phrase for it is that it is deployed separately from the site components.

The module metadata for the project is visible in its own go.mod:

```toml
module github.com/skupperproject/skupper

go 1.26.0

toolchain go1.26.9
```

For questions, feedback or reporting of issues encountered using the v2 preview, the readme asks you to use the Skupper community mailing list or create a GitHub issue as described on the Skupper web site community page. Note the wording, v2 preview. The project is describing itself as a preview, and the v1 branch as the version working in many production environments.

## Where Skupper is the wrong tool

There are clear cases where this is the wrong choice, and they come down to what the network actually has to span.

The first is when everything is in one cluster. A service mesh gives you service discovery, traffic policy and mTLS inside a cluster, with a well understood operational model and per-service configuration. Skupper exists for the case a mesh does not cover, which is connectivity that leaves the cluster boundary. If your traffic never crosses that boundary, a mesh is the more conventional tool and you have fewer moving parts.

The second is when every endpoint is a modern workload with a routable address. The virtual application network is most valuable when an endpoint is hard to reach, for example a mainframe or a bare metal host on a private network. If all peers are containers with stable addresses and you already have working ingress, Skupper is solving a problem you do not have.

The third is the v1 to v2 cutover, which is a real cost if you already run v1. Sites do not interoperate across the versions, the migration tools are planned, and a v1 deployment that is working in production is not obviously a candidate for disruption. The readme's own position is that v1 keeps being maintained without new significant features, which is a reasonable path for an existing deployment and a poor one for a new one that wants the declarative model.

The fourth is a requirement for a running router on every endpoint. Each participating system needs something to join the network, including the mainframes, and that is an operational footprint in a mainframe estate that needs its own approval process.

And the fifth is a project still labelled a preview. The readme asks for feedback on the v2 preview specifically, and the second major version of a networking project is where the deployment ergonomics usually need a second pass.

## The licence, the channels and what the version split costs

Two practicalities close out the picture.

The licence is Apache-2.0, recorded both in the LICENSE file at the root of the repository and in the image labels the Makefile stamps onto every artefact, with org.opencontainers.image.licenses set to Apache-2.0. The images also carry the standard OpenContainers labels for the source URL, the documentation URL, the version and the revision, which is a small sign of a project that publishes consumable artefacts properly.

The version split is the real cost to plan for. The v1 branch keeps getting patch releases, with 1.9.6 published on 2026-06-18 alongside the 2.2.x line, so a support commitment to Skupper spans two incompatible network models.

And there is a documentation boundary worth naming. The readme gives you the map, which is to say the links, the highlights, and the interoperability statement, but the operational detail lives on the Skupper website and in the per component readmes in the cmd directory. In particular, the readme excerpt here does not describe the PKI options in detail beyond saying the implementation is flexible and lets you provide your own certificates, and it does not describe how the network collector and console are configured. Those are things you will have to look up before you commit to an architecture.

What you can conclude from the readme is the shape of the thing: a router-based overlay, a CRD-based declarative model on Kubernetes with a Linux equivalent, an observer that is separate from the data plane, and a v2 that is not drop-in compatible with a v1 that is still in production use somewhere.

## Conclusion

Adopt Skupper 2 if you need application traffic to cross cloud, cluster and even mainframe boundaries without rewriting each application to understand the network, and if your platform is Kubernetes since the declarative model is CRD based. Skip it if you can use a service mesh inside one cluster, because Skupper exists for the cases a mesh does not cover. Verify first that every endpoint you need to connect is supported, that the mainframes or bare metal hosts can run a Skupper router, and that you can accept the v1 to v2 migration, since v2 sites are not interoperable with v1 sites.

## FAQ

### What does Skupper provide?

Skupper allows you to create a Virtual Application Network enabling secure, location independent communication between systems including public cloud, private cloud, virtual machines, bare metal hosts, and mainframes.

### Are Skupper 2 and Skupper 1 interoperable?

No. Skupper v2 sites are not interoperable with v1 sites, and the plan is to provide tools to assist users to migrate their v1 installations to a v2 deployment. Skupper v1 will continue to be maintained but no new significant features are planned.

### What changed in Skupper version 2?

The release introduces Custom Resource Definitions for more intuitive and flexible declarative interfaces with an equivalent implementation for Linux, architectural improvements for the controller, CLI and non-Kube executable, a flexible PKI implementation allowing users to provide their own certificates, a network collector and console deployed separately from the site components, and simpler integrations for centralized application network definition.

### How do I get started with Skupper 2?

The readme points to worked examples rather than an install command: a simple declarative example under cmd/controller/example, the CLI example under cmd/skupper, the network observer deployment under cmd/network-observer, the Helm charts under charts, and a Redis example in the separate skupper-example-redis repository.

### Which components make up a Skupper 2 deployment?

The build target produces skupper, controller, kube-adaptor, network-observer, system-controller and generate-doc, and the container images are built from Dockerfile.cli, Dockerfile.controller, Dockerfile.kube-adaptor, Dockerfile.network-observer and Dockerfile.system-controller. The observer is deployed separately from the site components.

### What licence is Skupper released under and how recent is it?

Apache-2.0, recorded in the LICENSE file and stamped onto the container images as the org.opencontainers.image.licenses label. The repository is not archived, the last push was on 2026-10-19, and the recent releases are 2.2.3 on 2026-09-30, 2.2.2 on 2026-08-17 and 1.9.6 on 2026-06-18.

## Sources

- [License: Apache-2.0](https://github.com/skupperproject/skupper/blob/main/LICENSE)
- [Project website](http://skupper.io)
- [README](https://github.com/skupperproject/skupper/blob/main/README.md)
- [Releases](https://github.com/skupperproject/skupper/releases)
- [skupperproject/skupper on GitHub](https://github.com/skupperproject/skupper)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/skupperproject-skupper