Overview
Key features and supported configurations
Abstract
Chapter 1. Key features
Red Hat Service Interconnect is a Red Hat build of the open source Content from skupper.io is not included.Skupper project. Skupper introduces an application network, linking services across the hybrid cloud.
An application network enables communication between services running in different network locations. It allows geographically distributed services to connect as if they were all running in the same site.

The following are key features of Skupper:
- Private to public site connectivity: You expose only specific services and ports to a remote site.
-
Minimal effort: A few
skupperCLI commands to expose services from one site to another, or define services in YAML. - Security: mTLS for all cross site communication.
- Load balancing and failover of services.
Chapter 2. Supported standards and protocols
Red Hat Service Interconnect supports the following TLS versions for site links:
- TLS 1.2
- TLS 1.3
Chapter 3. Supported configurations
Table 3.1. Red Hat Enterprise Linux CLI (using dnf)
| x86-64 | aarch64 | s390x | ppc64le | |
|---|---|---|---|---|
| Red Hat Enterprise Linux 8 | Yes | Yes | Yes | Yes |
| Red Hat Enterprise Linux 9 | Yes | Yes | Yes | Yes |
| Red Hat Enterprise Linux 10 |
Kubernetes sites (primary support)
Service Interconnect is supported on all versions of Red Hat OpenShift Container Platform that are in Full or Maintenance support. For more information, see the following articles:
Support for Non-OpenShift distributions of Kubernetes requires Kubernetes version 1.28 or later.
Ingress types (primary support)
- LoadBalancer
- OpenShift Routes (supported only on OpenShift)
Other ingress types fall under commercially reasonable support.
Table 3.2. Red Hat Enterprise Linux Podman sites (primary support)
| x86-64 | aarch64 | s390x | ppc64le | |
|---|---|---|---|---|
| Red Hat Enterprise Linux 8 | Yes | Yes | Yes | Yes |
| Red Hat Enterprise Linux 9 | Yes | Yes | Yes | Yes |
Table 3.3. Router (primary support)
| x86-64 | aarch64 | s390x | ppc64le | |
|---|---|---|---|---|
| Red Hat Enterprise Linux 8 | Yes | Yes | Yes | Yes |
| Red Hat Enterprise Linux 9 | Yes | Yes | Yes | Yes |
For use in Kubernetes and local system sites.
The Skupper router is not supported for standalone use as a messaging router.
Table 3.4. CLI (binary download)
| x86-64 | aarch64 | s390x | ppc64le | |
|---|---|---|---|---|
| Linux | Yes | Yes | Yes | Yes |
| Mac | Yes | |||
| Windows | Yes |
Kubernetes distributions (commercially reasonable support)
Red Hat will provide assistance running Service Interconnect on any CNCF-certified distribution of Kubernetes. Note, however, that our testing is done on OpenShift.
Kubernetes Ingress types (commercially reasonable support)
- Gateway
- Contour
- Nginx (This requires configuration for TLS passthrough.)
- NodePort
Table 3.5. Podman sites (commercially reasonable support)
| x86-64 | aarch64 | s390x | ppc64le | |
|---|---|---|---|---|
| Linux | Yes | Yes | Yes | Yes |
Service Interconnect requires Podman version 4 or later.
Upgrades
- Red Hat supports upgrades from one downstream minor version to the next, with no jumps.
- While Red Hat aims to have compatibility across minor versions, Red Hat recommends upgrading all sites to the latest version.
Disconnected operation
Red Hat supports deployment of Service Interconnect in disconnected environments.
If you have applications that require long lived connections, for example Kafka clients, consider using a load balancer as ingress instead of a proxy ingress such as OpenShift route. If you use an OpenShift route as ingress, expect interruptions whenever routes are configured.
For information about the latest release, see Red Hat Service Interconnect Supported Configurations.
Port negotiation limitation
If your protocol negotiates the communication port, for example active FTP, you cannot use that protocol to communicate across an application network.
Appendix A. About Service Interconnect documentation
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Revised on 2026-06-30 11:34:22 UTC