When these exchanges require the ports of different services to be publicly exposed, the attack surface increases and the network configuration becomes more cumbersome to maintain. Creating a private network between applications directly addresses this problem without requiring you to deploy or manage VPN infrastructure.

This approach allows cloud services to communicate directly with one another, over any port, without exposing the ports required for these exchanges to the Internet. Data travels over an encrypted overlay network that is independent of the physical network. On Clever Cloud, Network Groups provide this functionality: they establish WireGuard tunnels between resources, with no low-level network configuration.

Why exposing your services to the Internet is a problem

When application components communicate over public ports, each exposed service becomes a potential entry point. This has three practical consequences:

• Larger attack surface: every public access point must be secured, monitored, and maintained.
• Unnecessary exposure of technical ports: some protocols require dedicated ports for internal communications, even though they are not intended to be publicly accessible. A private network lets you use them without creating new entry points from the Internet.
• Reliance on external tunnels: connecting services distributed across several zones usually requires you to configure and manage an additional network layer, often a VPN.

Connecting services within a private network allows their internal traffic to flow without exposing the ports used for these communications. However, this does not disable any public access that is already configured. If only an API gateway should provide access to the backends from the Internet, you must also block their public endpoints.

How a private network between applications works

The approach is based on an overlay network: a logical network layer built on top of the existing physical network. Resources have private connectivity to one another, and their communications are encrypted by default. Because the overlay is independent of the underlying physical network, it can connect resources distributed across multiple zones or datacenters.

Consider an application comprising a public API, several backend services, and a database: only the API is exposed to the Internet. The internal services and database communicate with one another over the private network, using the ports they require.

Creating a private network between applications on Clever Cloud

Network Groups provide this setup. Each resource attached to a Network Group receives a private IP address from a dedicated CIDR, as well as an internal domain name in the format "<memberID>.m.<ngID>.cc-ng.cloud". The resources can then connect directly to one another, over any port, with no network configuration required.

A Network Group can connect Clever Cloud applications, add-ons, and external machines within the same private network. Communications are encrypted using WireGuard, a protocol known for its simplicity and speed.

You can create and manage Network Groups from the Clever Cloud Console, Clever Tools (CLI), or the public API. For example, from the command line:

clever features enable ng
clever ng create monNG --link app_xxx,postgresql_xxx

Note: add-on compatibility depends on their generation. Add-ons deployed since 2024 are compatible; older ones may require a migration or restart. See the documentation for the current limitations.

When should you use a private network between applications?

Network Groups are not a standalone solution: they enable certain secure architectures rather than replace an existing product. Several use cases are common.

• Protect applications behind an API gateway: the backends remain unreachable from outside while still being accessible from the gateway.
• Deploy Keycloak for high availability: multiple Keycloak instances synchronise over the private network without being publicly exposed.
• Enable microservices to communicate: in a distributed architecture, services communicate continuously without opening public ports or configuring tunnels.
• Integrate external resources: connect a local machine or third-party server to your Clever Cloud applications over an encrypted channel.

Connect your services without the complexity of a VPN

With Network Groups, private connectivity becomes a platform capability rather than infrastructure that you have to build and maintain. You choose which resources need to communicate; Clever Cloud establishes the encrypted private network between them. This allows you to use the ports required for internal communications without exposing them publicly, whether your resources are in the same zone, distributed across several data centres or, where applicable, external to Clever Cloud.

FAQ

What is the difference between a VPN and a private network between applications?

The main difference is what you have to manage. With a traditional VPN, you generally need to deploy, configure, and maintain connectivity between the relevant machines or networks. With Network Groups, Clever Cloud manages this layer for you: you attach the resources to the group, and the platform establishes encrypted private connectivity using WireGuard.

Do you need to modify your application code to use Network Groups?

In most cases, no. You do not need to rewrite your application. The change is in the configuration, not the code: the calling application must target the destination service using its internal Network Group domain name (<memberID>.m.<ngID>.cc-ng.cloud) and the required port, usually through an environment variable. No specific library or application changes are required for the traffic to use the private network.

Does a private network between applications work with machines outside Clever Cloud?

Yes. A Network Group can connect Clever Cloud applications, add-ons, and external machines within the same private network. However, support for attaching an external peer is still being stabilised during the testing phase.

Does a private network make an application invisible from the Internet?

No, not by itself. Network Groups provide private access to resources, but they do not disconnect an application from the Internet. Restricting public exposure is handled by other platform mechanisms.

Developed with Please Open It, a specialist in SSO and identity management, the service lets you deploy a complete IAM solution on dedicated infrastructure in just a few clicks, while Clever Cloud and Please Open-It handle its operation, updates and ongoing maintenance.

As discussed when Keycloak as a Service became generally available, we have worked on a pricing model designed to make the service accessible to developers, solopreneurs, non-profit organisations, businesses and larger enterprises alike.

This pricing will come into effect on November 1, 2026. The first invoice reflecting the new pricing will therefore be issued in early December 2026.

We also recommend reviewing the number of active users across your instances to estimate the impact of the new pricing structure on your bill. This information will be added to the Keycloak dashboard before the new pricing takes effect.

Why the pricing is changing

Keycloak as a Service is more than simply hosting a Keycloak instance.

Each service relies on several dedicated resources — a Java application, a PostgreSQL database and a File System Bucket — as well as the operation and ongoing maintenance of the service.

This includes:

• tracking Keycloak versions and validating updates before making them available;
• handling security vulnerabilities, which is particularly critical for an authentication component;
• pre-configuring and simplifying many aspects of the service, including themes, plugins, metrics, and realm imports and exports;
• backups, observability and associated support;
• features developed around the service, including Secured Multi Instances, IP filtering, metrics and Grafana dashboards;
• continued product development with Please Open-It.

During the launch phase, part of this managed service was not billed separately. The introduction of this new pricing model now makes it possible to account for the service as a whole and to continue its development.

This change also comes with an increase in the minimum size of Keycloak as a Service instances. The base price, previously €37.25 per month for the minimum configuration, will therefore increase to €47 per month from November 1, 2026.

What is changing in the billing model

Until now, Keycloak as a Service billing was based primarily on the various technical resources used by the service: the Java runtime, PostgreSQL database and storage.

The minimum configuration was therefore previously billed at €37.25 per month. From November 1, 2026, the minimum instance size will increase and the base service price will rise to €47 per month.

From 1 November, billing will follow a model that is more directly tied to the Keycloak service itself and how it is used.

It consists of two components:

• a monthly price per service, set at €47 excl. VAT, including up to 100 active users per month;
• an additional charge per active user, with lower per-user rates at higher user volumes.

An active user is a user who has had at least one active session during the month, for example following a login or token refresh.

When does this pricing take effect?

It is important to distinguish between the date from which usage begins to be metered and the date on which it appears on your invoice.

In practical terms, the first invoice affected will be the one issued in early December 2026, covering your usage for November.

The variable portion of the price remains directly linked to your actual use of the service.

How can you prepare for the change to your invoice?

No action is required to continue using Keycloak as a Service: your existing services will continue to operate as normal.

However, you can use the coming weeks to review the instances that are currently active within your organisation, particularly any test or staging environments that are no longer in use.

We also recommend checking the number of active users across your instances to estimate the impact of the new pricing structure on your invoice.

If you would like a more precise estimate, our teams can review your configuration and usage levels with you to produce a simulation.

Contact us to review your situation with our teams.

For an IT department, SAML 2.0 addresses a practical question: how can an employee be given access to dozens of applications with a single authentication process, while centralising authentication policies through an identity provider?

What is SAML 2.0?

This centralisation of authentication is precisely what SAML standardises. Version 2.0 of the standard was approved by OASIS (Organization for the Advancement of Structured Information Standards) in March 2005 at its highest level of ratification. It brought together three earlier initiatives: SAML 1.1, the Liberty Alliance ID-FF 1.2 profile and contributions from the Shibboleth project. It was also adopted as an international recommendation by the International Telecommunication Union (ITU-T X.1141).

Technically, the SAML protocol is based on assertions: XML security tokens that describe a user, the “principal", and their authentication. These assertions are exchanged between two roles:

• The Identity Provider (IdP), which authenticates the user.
• The Service Provider (SP), which is the application the user wants to access.

More than twenty years after its ratification, SAML 2.0 is not a legacy protocol. It remains widely deployed in businesses, the public sector and academia, where it continues to provide a foundation for identity federation.

How does SAML authentication work?

SAML authentication involves three parties: the user, the Identity Provider (IdP) and the Service Provider (SP). In the most common scenario, known as “SP-initiated” authentication, the exchange works as follows:

Trust between the IdP and the SP cannot be established automatically. It must be configured beforehand through an exchange of metadata, including certificates, endpoints and identifiers. This allows each party to verify the authenticity of the other party’s messages. The assertion’s cryptographic signature guarantees that it came from the expected identity provider and has not been altered.

Components of the SAML 2.0 standard

The SAML 2.0 standard consists of several complementary components:

• Assertions: the statements themselves, which can contain three types of information: authentication information, attributes such as a role, department or email address, and, less commonly, an authorisation decision.
• Protocols: the request and response messages used to carry assertions.
• Bindings: the methods used to transport these messages over the web, for example through an HTTP redirect or an HTTP POST request.
• Profiles: predefined combinations of components for a particular use case. The best-known example is the Web Browser SSO Profile.
• Metadata: the technical description exchanged between the IdP and SP to establish trust.

Although SAML can carry authorisation decisions, its main uses remain Single Sign-On and attribute exchange. Fine-grained authorisation is generally handled by other mechanisms.

SAML 2.0, OAuth 2.0 and OpenID Connect: what are the differences?

These three standards are often confused, even though they do not address the same question:

• SAML 2.0 deals with authentication and Single Sign-On. It is based on XML and is widely established in enterprise environments, cross-organisational federations and the public sector.
• OAuth 2.0 deals with authorisation. It delegates access to a resource (for example, “Can this application read my calendar?”) and does not handle authentication on its own.
• OpenID Connect (OIDC) adds an authentication layer to OAuth 2.0, allowing an application to establish a user’s identity, particularly through an ID token in JWT format. It is suitable for web and mobile applications, while API access relies on OAuth 2.0 access tokens.

In practice, SAML 2.0 and OpenID Connect coexist. SAML remains the standard for existing enterprise applications, while OpenID Connect is generally used for new developments. The choice between SAML, OAuth 2.0 and OpenID Connect depends on the type of application, its authentication requirements and how access to APIs must be delegated.

Implementing SAML 2.0 with Keycloak

The most common way to deploy SAML 2.0 without reimplementing the protocol is to use an Identity and Access Management (IAM) solution. Keycloak, a leading open-source solution in this field, can act as a SAML 2.0 identity provider. It also supports OpenID Connect, allowing legacy SAML applications and newer OIDC developments to share the same authentication service.

Clever Cloud offers Keycloak as a Service: a fully managed Keycloak service hosted in France and operated with the expertise of Please Open It, a partner specialising in Keycloak. This approach removes the burden of operating the identity server, including updates, availability and backups, from internal teams, while allowing them to retain control over SAML and OIDC settings.

“SAML 2.0 remains essential in enterprise environments because of its long history (2005) but also because of its network simplicity: everything passes through the user’s browser, with no direct connection required between the application and the identity server. In contrast, the modern OpenID Connect standard requires direct server-to-server communication to remain secure. OIDC’s ‘100% browser-based’ mode, the Implicit Flow, has now been abandoned because it is considered too vulnerable.”

Mathieu Passenaud
Co-founder at Please Open It

FAQ

Is SAML 2.0 still used in 2026?

Yes. Ratified in 2005, SAML 2.0 remains widely deployed in businesses, the public sector and academia for Single Sign-On and identity federation. It coexists with OpenID Connect, which is often preferred for new web and mobile projects.

What is the difference between SAML and SSO?

SSO, or Single Sign-On, is a principle: users authenticate once to access multiple applications. SAML is one of the protocols that can implement this principle across domains. OpenID Connect is another.

Does SAML handle authentication or authorisation?

It can handle both, but it is mainly used for Single Sign-On and attribute exchange. The protocol can carry authorisation decisions, although this capability is rarely used in practice.

Should I choose SAML 2.0 or OpenID Connect?

The choice primarily depends on the protocol supported by the application. SAML 2.0 is suitable for services designed to use SAML federation, while OpenID Connect is generally appropriate for authenticating users in web and mobile applications. OAuth 2.0 access tokens are used to control access to APIs. Both approaches can coexist behind the same identity provider, such as Keycloak.

Does Keycloak support SAML 2.0?

Yes. Keycloak can act as a SAML 2.0 identity provider and also supports OpenID Connect, allowing both protocols to be used together.

What Is a French Managed Kubernetes Service?

A French Kubernetes service is a managed Kubernetes service provided by a French company. Depending on the offering, the infrastructure may be located in France or elsewhere in Europe and may run on a public cloud, a private cloud or dedicated machines.

Why Choose a French Kubernetes Provider?

Greater Digital Sovereignty

Entrusting orchestration to AWS, Google Cloud or Azure exposes organisations to a proprietary ecosystem and a non-European legal framework. Choosing a domestic provider reduces this dependency and supports a broader digital sovereignty strategy that goes beyond technical portability alone.

Clear Infrastructure Location and Responsibility

Knowing exactly where the control plane and worker nodes are running—and who is responsible for operating them—has become a key selection criterion for regulated industries and public-sector buyers alike.

Easier European Compliance

Infrastructure operated in Europe can simplify certain compliance processes relating to data location and transfers outside the European Union.

Local Support and Contract Management

Having a provider in the same time zone, billing in euros and documentation available in French can shorten resolution times and streamline contractual relationships.

French Managed Kubernetes Providers

The descriptions below reflect the offerings available at the time of writing. These services evolve rapidly, so always check the provider’s official website before making a decision.

OVHcloud Managed Kubernetes Service (MKS)

OVHcloud offers MKS, its managed Kubernetes service for the public cloud, in two tiers. MKS Free provides a free managed control plane. MKS Standard, launched in September 2025, adds a 99.99% SLA, with a control plane distributed across a three-availability-zone region (initially Paris, followed by Milan) dedicated etcd storage of up to 8 GB, and a choice of CNI plugins, including Cilium. The service integrates with the OVHcloud Public Cloud ecosystem.

Scaleway Kubernetes Kapsule

Kapsule is a CNCF-certified managed Kubernetes service for the public cloud. Its shared control plane is free, with a dedicated control plane available as an option for mission-critical workloads, while autoscaling is supported natively. The service integrates with Scaleway’s services and emphasises digital sovereignty and GDPR compliance for the European market.

Clever Kubernetes Engine (CKE)

CKE is Clever Cloud’s managed Kubernetes service. It runs on infrastructure located in France, with no dependency on a foreign hyperscaler. Each cluster runs on its own virtual machines, with no infrastructure shared between customers. The control-plane architecture can be configured according to the selected topology, ranging from an all-in-one bundle to one VM per component. The experience remains true to standard Kubernetes, with no lock-in mechanisms or need to rewrite manifests. Cluster state is stored in Materia etcd, an implementation of the etcd protocol developed in France and built on FoundationDB. CKE integrates with managed databases, S3-compatible object storage, IAM, observability services and private networking through Network Groups. The product is currently in public beta.

Comparing French Managed Kubernetes Services

French Kubernetes offerings are based on different architectures and operating models. The most useful comparison criteria are infrastructure location, hosting model, availability guarantees, level of integration with cloud services and compatibility with the standard Kubernetes ecosystem.

None of these offerings is inherently superior to the others. The right choice depends on the required operating model and the level of assurance expected.

French Kubernetes vs AWS EKS, Google GKE and Azure AKS

AWS EKS, Google GKE and Azure AKS remain the most comprehensive managed Kubernetes services in terms of their wider service portfolios and global reach. In return, they increase dependency on their respective ecosystems. A French offering addresses the same orchestration requirements while keeping the control plane and data subject to European law.

French providers host their infrastructure in France or elsewhere in Europe, under European law and with locally operated integrations. Hyperscalers offer a broader service portfolio and global reach, at the cost of greater dependency on their ecosystems.

The general criteria for selecting a managed cluster (irrespective of the national dimension) also warrant careful consideration. These include version policies, autoscaling, storage and the responsibility model.

Key takeaways

The best French Kubernetes service ultimately depends on your specific context. Some organisations will prioritise a generally available offering backed by strong contractual guarantees, while others will seek close integration with their cloud platform or existing environment. OVHcloud, Scaleway and Clever Cloud currently offer different approaches to managed Kubernetes. The choice primarily depends on operational, governance and compliance requirements, as well as the expected level of maturity.

FAQ

Are There Any French Managed Kubernetes Providers?

Yes. Several French companies offer managed Kubernetes services, including OVHcloud with Managed Kubernetes Service, Scaleway with Kubernetes Kapsule and Clever Cloud with Clever Kubernetes Engine. These solutions differ in their infrastructure models, level of managed service and integration with each provider’s cloud ecosystem.

What Is the Difference Between French and European Kubernetes?

A French Kubernetes service is provided by a French company, while a European Kubernetes service is provided by a company established in the European Union. In both cases, it is important to examine the infrastructure’s actual location, the entity that operates the service and the law applicable to the data.

Does a French Provider Guarantee Digital Sovereignty?

No. A provider’s nationality alone is not enough to guarantee sovereignty. Sovereignty also depends on the infrastructure operator, any subcontractors involved in the hosting chain and the legal frameworks to which they are subject.

Can You Use Helm and Terraform with a French Kubernetes Service?

Yes, provided that the service uses a standard Kubernetes implementation. The services offered by OVHcloud, Scaleway and Clever Cloud remain compatible with widely used ecosystem tools such as kubectl, Helm and Terraform, as well as GitOps practices.

How Do French Kubernetes Services Compare with AWS EKS?

AWS EKS benefits from an extensive portfolio of cloud services and a global presence. French offerings generally emphasise operations carried out in Europe, local support and integration with locally operated infrastructure. The right choice depends on each project’s technical, regulatory and organisational constraints.

What Is the Difference Between Managed and Self-Hosted Kubernetes?

The main difference lies in operational responsibility. With managed Kubernetes, the provider operates the control plane and handles part of the platform’s maintenance. With self-hosted Kubernetes, the organisation remains responsible for installing, updating, monitoring and securing the cluster, as well as ensuring its availability. Managed Kubernetes reduces the operational burden, while self-hosting provides greater control over the infrastructure.

Can You Migrate from One Kubernetes Provider to Another?

Yes, provided that a standard Kubernetes implementation is used. YAML manifests, Helm charts and deployment tools generally remain portable from one provider to another. However, certain provider-specific dependencies, such as storage, networking and managed services, may require adaptations.

Which French Kubernetes Service Is Best for an SME?

The right choice depends on the project’s requirements. An SME may prefer an offering with a free control plane for its initial deployments or seek closer integration with a particular cloud ecosystem. In all cases, compatibility with standard Kubernetes makes it easier to move to another offering if requirements change.

A compliance manager's field report.

When I joined Clever Cloud four years ago, I walked into a deeply technical culture: no collaborative suite, no conventional project management tool. Everything lives in GitLab, GitHub and terminals.

Running an integrated management system (ISO 9001, ISO 27001, HDS, regulatory compliance) is formalisation work: policies, procedures, security rules.

So we started out the conventional way, on a collaborative suite.

Some of the habits that came with it quickly turned into a time sink. Version numbers tracked by hand in a spreadsheet. PDFs sent to the steering committee for sign-off. Signatures. Folders labelled "approved" and "in progress". Links breaking every time a format changed.

Human checks everywhere, so mistakes waiting to happen. And above all: developers never go into those tools. Their documentation sits in GitLab.

So we made a simple call. The entire documentation set in Markdown, version-controlled in GitLab, in the same place as the technical documentation.

What that changes in practice:

• a complete, native history: commits, diffs, authors
• every change goes through a merge request, with at least one approval from a third party. Segregation of duties no longer rests on a declared process, it is carried by the tool
• the technical population reads the policies all year round, not only at the annual awareness session (the new challenge is the non-technical profiles, who now learn GitLab during onboarding, as I did four years ago)

Then we automated. A monthly script reads the platform changelogs, drafts the updates in the right places across the policies, and opens the merge requests. What is left for me is the review, then approval by whoever owns the subject. That is where the month becomes 30 minutes.

And the real change is somewhere else. We no longer update documents for the audit, once a year. We update them at every actual change to the information system. In front of the auditor, the sources, the versions and the approvals are right there. Compliance becomes a measured state rather than a declared one.

That is how I picture compliance as code from an integrated management system governance standpoint. What it changes at a deeper level is the tempo: compliance now moves at the speed of the information system, not at the speed of the audit calendar.

The control plane consists of Kubernetes’ standard components: the API server, etcd (the datastore that stores the cluster’s state), the scheduler and the controller manager. If the control plane fails, workloads that are already running continue to operate, but the cluster can no longer be managed: no new deployments, no scaling, and no response to kubectl commands. Managed services remove responsibility for precisely this layer from engineering teams.

Why is Kubernetes difficult to operate yourself?

Kubernetes  is a container orchestration standard, not a turnkey product. Deploying a cluster without a managed layer means handling:

• version upgrades (the Kubernetes project actively supports the three most recent minor releases);
• internal TLS certificate rotation;
• high availability of the control plane across multiple nodes;
• backup and consistency of the etcd datastore;
• security patches, often under tight time constraints.

These tasks are repetitive, consume valuable engineering time, and are a frequent source of incidents when not performed correctly. Managed services are specifically designed to remove this operational burden from product teams.

Use cases: when managed Kubernetes delivers value

Kubernetes—whether managed or self-managed—becomes relevant in specific scenarios. It is not a systematic replacement for a PaaS: the two approaches address different needs.

Managed Kubernetes is well suited when:

• the architecture includes multiple interdependent services requiring fine-grained orchestration (rolling updates, resource management by namespace);
• workloads are already built for Kubernetes and delivered as Helm charts or YAML manifests;
• the team requires multi-cluster or hybrid environments (on-premises + cloud);
• operating the control plane represents a real and measurable cost for SRE or DevOps teams.

A PaaS remains a better fit when:

• the application deployment model (code push with platform-managed build and runtime) matches the way your team works;
• you want to focus on application code without managing orchestration primitives (networking, scheduling, node management);
• your applications do not require fine-grained control over workload placement or the cluster’s network topology.

Comparison table: self-managed Kubernetes vs managed Kubernetes vs PaaS

Note: here, vanilla refers to a standard Kubernetes experience, with no changes to native Kubernetes behaviour and no proprietary tooling imposed.

Common mistakes when choosing or adopting managed Kubernetes

Managed Kubernetes in Europe: which sovereignty criteria matter?

For organisations subject to the GDPR, sector-specific regulations (healthcare, public sector, defence) or data residency requirements, where the cluster is hosted is a compliance issue, not just a performance consideration.

Points to verify:

• physical location of the    datacenters (country and applicable jurisdiction);
• identity of the operator and the involvement of foreign subcontractors in the hosting chain;
• infrastructure certifications (SecNumCloud, ISO 27001, HDS, depending on the provider and the offering);
• potential access to data by non-European third parties, particularly under extraterritorial legislation.

A managed Kubernetes service operated in France by a French provider addresses these requirements without requiring additional user-side configuration. This is the approach taken by Clever Kubernetes Engine (CKE), operated end to end in France by Clever Cloud, with no foreign hyperscaler involved in the hosting chain.

Key takeaways

Managed Kubernetes is relevant when your organisation already relies on Kubernetes and maintaining the control plane represents a meaningful operational burden. It is not a universal solution: when a PaaS deployment model matches the way your team works, it often remains the most straightforward choice. For organisations with European sovereignty requirements, the choice of provider and hosting location is critical.

The key selection criteria are vanilla compatibility (no vendor lock-in), the release policy, a clear division of responsibilities between provider and user, and the overall cost model: list price plus internal engineering costs.

FAQ

What is managed Kubernetes?

A service in which the cloud provider manages the Kubernetes control plane (provisioning, updates and availability). The user manages workloads and node pools, but not the cluster’s critical infrastructure.

What is the difference between managed Kubernetes and a PaaS?

A PaaS handles the build, deployment and execution of what you deliver (source code or a container image) without requiring you to define the underlying orchestration. Managed Kubernetes retains the standard Kubernetes interface (kubectl, Helm and YAML manifests), allowing you to manage these primitives while delegating control plane operations to the provider. These are two distinct operational models that are complementary rather than interchangeable.

Does managed Kubernetes create a risk of vendor lock-in?

It depends on the implementation. A vanilla offering (with no changes to Kubernetes’ native behaviour and no proprietary tooling imposed) allows workloads to be migrated without rewriting them. By contrast, non-standard CRDs or provider-specific networking integrations can create dependency on a specific provider.

Who is responsible for what in a managed Kubernetes cluster?

The provider manages the control plane: updates, availability and patching. The user remains responsible for node pools (sizing and scaling), workloads, application security and RBAC policies.

How can I tell whether my organisation needs managed Kubernetes rather than a PaaS?

The key question is architectural complexity. If your applications require orchestration across multiple services or advanced networking capabilities, or are already designed for Kubernetes, managed Kubernetes is appropriate. If you are deploying relatively standard services, a PaaS will usually be faster and less expensive to operate.

Managed Kubernetes in France: what sovereign options are available?

In France, several providers offer managed Kubernetes on sovereign infrastructure, including Scaleway (Kubernetes Kapsule), OVHcloud (Managed Kubernetes Service) and Clever Cloud with CKE. Beyond location, the key differentiators are the actual level of sovereignty (operator, subcontractors involved in the hosting chain), vanilla compatibility and the shared responsibility model between provider and user.

Kubernetes is a container orchestrator; the cloud is where it most often runs. The term "Kubernetes cloud" therefore covers two related realities: running Kubernetes on cloud infrastructure, and relying on a managed Kubernetes service operated by a provider.

Kubernetes Is Not a Cloud

Kubernetes is an open source container orchestrator. How Kubernetes works comes down to orchestrating containers spread across a set of machines: it schedules their placement, deploys them, supervises their lifecycle, and manages their scaling and network exposure. These containers are often built with Docker, and the distinction between Kubernetes and Docker is itself a common source of confusion.

What Kubernetes does not do is provide the underlying machines, storage, and network. It needs infrastructure to run on, and that infrastructure can take several forms: physical servers (bare metal), virtual machines, a private cloud, or a public cloud. This is the layer a cloud provider supplies.

Hence a frequent confusion: comparing "Kubernetes" with "AWS", or Kubernetes with a cloud provider in general. The two sit at different layers. A cloud provider sells infrastructure and often offers a managed Kubernetes service on top of it. Kubernetes orchestrates the containers running on that infrastructure. You do not choose between Kubernetes and the cloud: you can run Kubernetes on a cloud, or use the managed Kubernetes that cloud offers.

In other words, choosing an infrastructure and choosing who operates the cluster are two separate decisions. That is what shapes the types of offerings described below.

Running Kubernetes in the Cloud: Managed or Self-Managed

Once that relationship is clear, two operating models appear. Either you install and operate Kubernetes yourself on machines rented from a cloud provider, or you use a managed service where the provider operates the control plane for you.

The control plane is the dividing line between the two. It groups the components that drive the cluster: the apiserver, etcd (the datastore that holds the cluster state), the scheduler, and the controller-manager. Operating it yourself means handling version upgrades, which the Kubernetes project requires you to keep up with since it only supports its three most recent minor versions, internal TLS certificate rotation, high availability of these components across several nodes, etcd backup and consistency, and security patches under time pressure. A managed service takes this layer off your hands: you keep control of your workloads, your node pools, and their security, but no longer administer the cluster's critical infrastructure.

Not every need calls for a full cluster. Lighter distributions, such as K3s, exist and are worth evaluating depending on the workload and the context. And Kubernetes, managed or not, is one operating model among others. A PaaS follows a different one: you ship code, and the platform handles the build, execution, and scaling, without you having to operate an orchestrator. PaaS and Kubernetes meet different, complementary needs, and a single organization can use both.

The Three Types of Offerings for Running Kubernetes in the Cloud

Offerings fall into three types, depending on whether you operate the cluster yourself or a provider does, and, in the latter case, on whether that provider is a global hyperscaler or a European player.

Self-Managed on Cloud Infrastructure

You rent compute, storage, and network from a provider, then install and operate Kubernetes yourself. This approach gives the most complete control over the cluster and the underlying infrastructure, at the cost of the operational burden described above. It makes sense when specific infrastructure, network, or compliance constraints are not covered by the managed offerings available. This approach also suits teams that want to retain direct control over every component of the cluster, from the container runtime to scheduling and internal network configuration.

Managed by a Hyperscaler

The large global cloud providers offer managed Kubernetes services: Amazon EKS, Google GKE, Microsoft AKS. The provider operates the control plane, and you deploy your workloads with the standard Kubernetes tooling. These offerings are tightly integrated with each provider's ecosystem, which is their strength when your other services already run there, and the point to watch if you ever consider moving away. Their operators, however, fall under non-European jurisdictions, including for the regions they run in Europe. These offerings therefore do not meet a European sovereignty requirement, a decisive criterion for certain sectors and certain types of data.

Managed by a European Provider

Several European providers offer managed Kubernetes on infrastructure located within the European Union. Location matters, but it does not make an offering sovereign. A datacenter sitting in Europe remains within reach of the US CLOUD Act if the company operating it answers to a foreign jurisdiction. What determines sovereignty is the operator’s ownership structure and the legal jurisdictions that apply to it, not simply where the servers are located.

On this ground, several players offer managed Kubernetes: OVHcloud (Managed Kubernetes Service) and Scaleway (Kubernetes Kapsule). Clever Cloud offers Clever Kubernetes Engine, a managed Kubernetes service operated by a European company based in France. Beyond location, these offerings differ in their actual degree of sovereignty, which depends on the operator and its subcontracting chain, as well as in how well they integrate with the tools you already use. For a closer look, French managed Kubernetes offerings are covered in a dedicated article.

Kubernetes Cloud: Key Takeaways

"Kubernetes cloud" refers to running Kubernetes on cloud infrastructure, along with the managed services providers offer so you do not have to operate the cluster yourself. The line between self-managed and managed runs through the control plane, the layer a provider either takes on or does not. Three types of offerings then appear: self-managed on cloud infrastructure, managed by a hyperscaler, and managed by a European provider, bearing in mind that a European location alone is not enough to make an offering sovereign. Which one fits depends on your infrastructure constraints, the tooling already in place, and your requirements around data and sovereignty. Ultimately, the cloud supplies the infrastructure, Kubernetes orchestrates the workloads running on it, and the managed model determines whether you or the provider operates the cluster.

What remains is to work out when a managed Kubernetes service makes sense and how to choose one, and to clarify what a sovereign Kubernetes really means.

FAQ

Is Kubernetes a cloud?

No. Kubernetes is a container orchestrator, not an infrastructure provider. A cloud supplies the servers, storage, and network; Kubernetes orchestrates the containers running on top of them. You can run it on a cloud, or use the managed Kubernetes service a cloud offers.

Can you run Kubernetes outside the cloud, on bare metal or on-premises?

Yes. Kubernetes is infrastructure-agnostic: it runs on physical servers, virtual machines, private or public clouds, and in hybrid environments combining several of these. The cloud is the most common setting, not a requirement.

Are "Kubernetes cloud" and "managed Kubernetes" the same thing?

Not exactly. "Kubernetes cloud" broadly means running Kubernetes on cloud infrastructure, which covers both a cluster you operate yourself and a managed service. "Managed Kubernetes" specifically refers to the offering where a provider operates the control plane for you. Every managed Kubernetes is Kubernetes in the cloud, but the reverse is not always true.

What is the difference between Kubernetes and a cloud provider like AWS?

They operate at different layers. AWS is a cloud provider: it sells infrastructure and offers, on top of it, a managed Kubernetes service (Amazon EKS). Kubernetes is the orchestrator that drives the containers on that infrastructure. Setting them against each other is like confusing the warehouse with the system that organizes what goes into it.

FoundationDB made this idea famous. Instead of relying only on unit tests and real-cluster end-to-end tests, it runs distributed workloads inside a simulated world where time, network faults, process failures, and scheduling decisions can be explored and reproduced from a seed. TigerBeetle pushed a complementary discipline: make invariants part of the code, assert the shape of the state continuously, and turn silent corruption into loud local failures.

At Clever Cloud, we have been applying that direction to Rust infrastructure software. Moonpool, developed by Pierre Zemb, gives Rust systems a deterministic simulation environment where time, networking, tasks, randomness, and storage can be virtualized behind provider traits. Magnetar is where we apply that approach to a client for Apache Pulsar. This is also the approach that we are taking in Sōzu.

Magnetar is a from-scratch Apache Pulsar client driver in Rust. It is built around a sans-io protocol core, a production Tokio engine, and a Moonpool engine for deterministic simulation. This first public release is meant for engineers who want to try Magnetar, evaluate the architecture, compare behavior with existing Pulsar clients, and help shape a stronger Rust-native Pulsar ecosystem.

The goal is not only to expose a Rust API around Pulsar. The goal is to build a client whose difficult behavior can be inspected, replayed, and made to fail before production gets the chance.

A Pulsar client is part of the distributed system

It is tempting to think about a client library as the easy side of a distributed system. The broker is where replication, storage, ownership, and coordination live. The client only connects, sends messages, receives messages, and acknowledges them.

That view does not survive contact with a real Apache Pulsar client.

A serious Pulsar client has to manage producers, consumers, readers, partitioned topics, multi-topic consumers, pattern subscriptions, transactions, schemas, authentication, proxy routing, broker lookup, cluster failover, reconnect, backoff, batching, chunking, ack grouping, unacked-message tracking, negative acknowledgements, retry-letter and dead-letter flows, observability, and a long list of Pulsar Improvement Proposals.

Many of the hard bugs are not about one command being encoded incorrectly. They are about time and ordering. A broker drops while a publish is in flight. A reconnect happens while a consumer has pending acknowledgements. A token refresh races with a session reset. A proxy lookup points to a new broker while the old connection is still draining. A topic migrates and the client must rebuild enough state to continue without pretending the old session still exists.

That means a Pulsar client is not just a convenience wrapper around a socket. It is part of the distributed system. It owns state that has to remain coherent while the world around it changes.

If that state is hidden inside runtime tasks, channel queues, implicit clocks, and timing accidents, then the client becomes hardest to reason about exactly when precision matters most. Magnetar starts from the opposite assumption: make the protocol state explicit, drive it through narrow boundaries, and keep the I/O outside.

From the Rust Pulsar ecosystem to Magnetar

Magnetar comes from experience with the Rust Pulsar ecosystem, including maintaining and using pulsar-rs. That work matters. It gave Rust users an Apache Pulsar client and created the practical context in which the next generation of driver work could be evaluated.

Magnetar is not an article-length criticism of what existed before it. It is a continuation of the same ecosystem from a different architectural starting point. After spending time with real Pulsar usage, the shape of the next step became clearer: a Rust Pulsar driver should make the protocol/runtime boundary sharper, make difficult behavior reproducible, track parity explicitly, and make testability a first-class design constraint.

That is why Magnetar does not begin with the public builder API. It begins with the protocol.

The user-facing API matters, and the first release already exposes a broad surface. But for a distributed client, the deeper question is what happens underneath that API when the broker moves, the connection drops, the clock advances, a timeout fires, a subscription is rebuilt, or the same trace is replayed under a different runtime.

The sans-io core

The heart of Magnetar is magnetar-proto. It is a synchronous protocol state machine. It has no sockets. It does not depend on Tokio. It does not spawn tasks. It does not use async. It does not read the host clock on the protocol hot path.

Its shape follows the same broad idea that made quinn-proto influential in the Rust networking world: feed bytes in, poll bytes out, poll semantic events, and ask the state machine when its next timer expires.

Conceptually, the interface looks like this:

> connection.handle_bytes(now, bytes);

connection.poll_transmit(&mut out);
connection.poll_event();
connection.poll_timeout();

That small shape is a large architectural choice.

handle_bytes lets an engine feed wire bytes into the state machine. poll_transmit drains outbound frames. poll_event yields semantic events that the runtime must react to, such as authentication challenges, lookup outcomes, checksum mismatches, reconnect signals, or protocol-level transitions. poll_timeout lets the runtime ask when to wake the state machine again.

The state machine does not decide where bytes come from. It does not know whether the network is a real TCP stream, a TLS stream, a byte pipe inside a simulator, or a scripted broker in a differential harness. It does not decide what "now" means. The engine passes time in.

The public traits in magnetar-proto follow the same rule. They are not runtime services hidden behind async callbacks. They are small protocol contracts at the points where the state machine needs a decision or a transformation: AuthProvider produces authentication bytes, Schema defines encoding, decoding, schema data, and broker-resolved schema hooks, MessageEncryptor and MessageDecryptor describe payload crypto over bytes and message metadata, ServiceUrlProvider exposes the current service URL for failover, and HealthProbe uses a poll-style contract instead of binding the protocol crate to an async runtime. The pattern is deliberate: the protocol core can ask for facts, bytes, or readiness, while the I/O, caching, refresh logic, network probes, and scheduler stay outside.

This separation is not just a clean layering exercise. It is what makes the protocol testable without a broker, without a socket, and without an async runtime. A protocol bug can be reduced to a fixture: feed these bytes at this instant, poll these outputs, assert this event stream, and replay the same sequence again.

For an Apache Pulsar client, that matters because the wire protocol is not only a happy path. It includes producer creation, consumer subscription, acks, nacks, transactions, broker errors, redirects, authentication challenges, topic migration, replicated-subscription markers, schema metadata, batching, chunking, and close paths. Each of these has state. Each state transition is easier to reason about when it is not mixed with socket reads, task scheduling, and runtime-specific wakeups.

No channels as an architectural constraint

Magnetar also makes an unusual Rust async choice: channel primitives are banned from the workspace.

The straightforward architecture for a network client is often producer future to channel, channel to driver task, driver task to channel, channel to consumer future. That can work, but it spreads state across queues and tasks. Backpressure becomes implicit. Close semantics become library-specific. Dropped futures can leave messages stranded in places that are hard to inspect. The debugging question becomes "where did this message go?"

Magnetar uses a different pattern. State lives inside the protocol state machine and the runtime-owned shared connection. User-facing futures register wakers in slabs keyed by operation identifiers. The driver owns the I/O loop, feeds bytes into the state machine, drains outbound frames, and wakes the matching futures as outcomes arrive.

This is not an aesthetic ban on channels. It is a way to keep ownership of state explicit. When the driver rebuilds producers after a reconnect, when a consumer waits for a message, when an ack outcome is delivered, or when a pending operation fails because a session is gone, the relevant state is in the state machine and can be inspected there.

That design has trade-offs. It puts more pressure on the correctness of the state machine. It requires careful lock ordering. It requires reviewers to understand waker registration and wakeup paths. But it also makes the behavior much easier to simulate, replay, and compare across runtimes.

Two engines, one state machine

Magnetar ships two engines that drive the same protocol core.

The default engine is magnetar-runtime-tokio. It is the production execution path: TCP, TLS through tokio-rustls, driver tasks, real time, real sockets, and the public PulsarClient surface most users will reach first.

The second engine is magnetar-runtime-moonpool. It drives the same magnetar-proto::Connection state machine through Moonpool providers. Instead of baking in the runtime, Moonpool exposes provider traits for networking, time, task spawning, randomness, and storage. Under a production-style provider bundle, the engine can run against real I/O. Under simulation providers, those same categories can be virtualized.

This is where deterministic simulation becomes practical. The client can be driven in a world where time advances under control, network delivery can be reordered or interrupted, tasks run under a deterministic scheduler, randomness is seeded, and failures can be replayed from the same seed.

Moonpool is not a mock. A mock usually replaces a component with simplified behavior. That is useful for many unit tests, but it is not the same thing as exercising a real client through hard interleavings.

Moonpool is also not a normal end-to-end test. An e2e test runs the real system, which is essential, but it usually runs with real time, real networking, and failures that are difficult to reproduce once the timing has moved on.

Moonpool sits in a different space. It keeps the client code close to the real execution path while virtualizing the providers that make distributed behavior hard to reproduce. The point is not to avoid e2e tests. The point is to add a regime where failures are not anecdotes. They become seeds.

Magnetar's Moonpool engine uses the same protocol state machine as the Tokio engine. The TLS path is also driven in a way that preserves the simulation boundary: instead of relying on tokio-rustls, the Moonpool engine drives rustls::ClientConnection over the byte pipe directly. That keeps TLS handshakes under the same deterministic control as the rest of the simulated network.

Differential testing: making the engines agree

Two engines are useful only if they do not silently become two different clients.

Magnetar therefore includes a differential harness. It runs a trace, such as connect, open producer, send, subscribe, receive, ack, seek, and close, against both the Tokio and Moonpool engines, then compares the user-visible event streams.

This matters because the Moonpool engine is used to find bugs that are difficult to expose with real time and real sockets. For that to be meaningful, the simulated engine must remain observationally aligned with the production engine at the user boundary.

If Tokio and Moonpool drift, the simulator becomes less trustworthy. If the differential harness keeps them aligned, then a seed failure in the simulated world is much more likely to point at a real property of the client, not a separate test-only implementation.

This is also why Magnetar's validation policy is strict about cross-runtime coverage. Behavioral changes are expected to exercise the sans-io layer, the Tokio runtime, the Moonpool runtime, differential equivalence, and the e2e surface when applicable. That is more work than adding one unit test. It is also the cost of making deterministic simulation a real engineering tool rather than a side experiment.

Java parity as a credibility contract

Simulation is not a substitute for feature breadth. It is what makes feature breadth less fragile.

Apache Pulsar has a mature Java client, and for many users that client defines what "a Pulsar client" means. Basic produce and consume are not enough. A credible client must cover the behaviors applications rely on: batching, compression, transactions, schemas, partitioned topics, multi-topic and pattern consumers, retries, dead-letter flows, authentication providers, proxy support, failover, admin operations, and the PIPs that shape modern Pulsar usage.

Magnetar tracks Java-client parity as a public contract. The README carries the parity matrix and the engine-by-engine status. The article does not need to reproduce that matrix, but the matrix itself is important. It gives users a way to evaluate the project as a Pulsar client, not as a narrow experiment around one happy path.

This is the reason Magnetar's first public release is broader than a minimal demo. It includes the protocol foundation, the public facade, runtime engines, admin support, authentication providers, message crypto, CLI work, observability hooks, and a growing list of PIP surfaces.

The exact reason for tracking parity is simple: users do not choose a client library only because its internal architecture is elegant. They choose it because it can represent the system they actually run. Architecture makes that surface maintainable. Parity makes it useful.

Beyond produce and consume

The phrase "Pulsar client" can hide a lot of surface area. From the outside, the first examples usually look small: build a client, create a producer, send a payload, subscribe with a consumer, receive a message, acknowledge it. Those examples are useful because they show the entry point. They are not enough to evaluate the client.

Real Pulsar applications depend on behaviors that only appear after the first demo works. A producer may need batching, compression, chunking, access modes, sequence ids, send timeouts, per-message properties, transactions, interceptors, and latency statistics. A consumer may need batch receive, cumulative acknowledgements, batch-index acknowledgements, nack backoff, ack timeout handling, retry topics, dead-letter topics, seek, pause/resume, subscription modes, and per-partition behavior. Applications with strict schemas need Avro, JSON, Protobuf, Protobuf-native, KeyValue, primitive schemas, and broker-side schema lookup semantics. Deployments with security requirements need token auth, mTLS, OAuth2, SASL, Kerberos/GSSAPI, Athenz, TLS provider choices, and a way to reason about crypto behavior without making every build drag every provider.

Those features are not independent checkboxes. They interact. Batching interacts with compression and send timeouts. Chunking interacts with sequence ids and redelivery. Transactions interact with acknowledgements. Reconnect interacts with producers, consumers, lookups, proxy routing, and failover. Observability has to describe the behavior without leaking secrets or flooding operators under churn.

That is why Magnetar's feature work and architecture work are tied together. The more complete the surface becomes, the more important it is that the protocol state is explicit and that the runtime boundary is narrow. A broad client built on accidental state becomes harder to maintain as it becomes more useful. A broad client built on replayable state gives maintainers a better chance to keep feature growth from turning into hidden behavior.

Validation as architecture

Magnetar's test strategy is intentionally layered because each layer catches a different class of bug.

The sans-io layer lets protocol behavior be tested without sockets or async tasks. The project testing documentation currently records more than 270 unit tests in magnetar-proto. Those tests exercise the state machine directly: bytes in, events out, transmit buffers out, state transitions checked.

Runtime integration tests exercise the glue that pure protocol tests cannot cover. The Tokio engine and Moonpool engine each have their own integration surfaces, and the project enforces runtime parity so one engine does not quietly fall behind the other.

The deterministic chaos pack targets the failure schedules that motivated the architecture in the first place: reconnect, failover, virtual-clock timers, TLS handshake ordering, in-flight publishes, broker migration, and adversarial network behavior. The Moonpool engine documentation describes a daily Moonpool seed sweep with 128 freshly rolled random seeds in parallel. The number is less important than what it represents: the client is being driven through schedules that a human would not write by hand.

Differential equivalence tests compare the two runtime worlds. They ask a direct question: if the same trace is run through Tokio and Moonpool, does the user see the same behavior?

End-to-end tests still matter. They keep Magnetar honest against a real Apache Pulsar broker. Simulation can make failures reproducible, but it does not replace compatibility with the system users actually deploy.

Taken together, these layers are not ceremony. They are part of the architecture. The point is not to collect large test numbers. The point is to put validation pressure exactly where distributed clients fail: protocol state, runtime boundaries, reconnect logic, timing, equivalence, and real broker behavior.

What reproducibility changes in practice

The practical value of deterministic simulation is not that it makes tests more sophisticated. It changes the debugging loop.

When a traditional end-to-end test fails because of timing, the first question is often whether the failure is reproducible at all. If it is not, engineers start adding sleeps, logs, larger timeouts, or retry loops. Some of those changes are useful. Many of them only move the failure somewhere else. The failure remains a story: "we saw it once in CI".

With a deterministic simulation, the failure should become an artifact. The artifact is a seed, a trace, and a state transition that can be replayed. The question changes from "can we make it happen again?" to "what invariant did this schedule violate?"

That difference matters for a client library. Client bugs often sit at the boundary between user code and the broker. They are easy to misattribute. A publish can fail because the broker closed the connection, because the client lost an outcome, because the reconnect path rebuilt the producer too late, because an ack was delivered to the wrong waiter, because a timeout fired against stale session state, or because the runtime task died after the protocol had already transitioned.

If all of that behavior is spread across tasks, channels, timers, and sockets, a failure report is hard to compress. If the protocol state machine is explicit, the runtime boundary is narrow, and the same sequence can be replayed under controlled providers, the report can become much smaller: this seed, this trace, this event order, this invariant.

That is why Magnetar treats reproducibility as part of the client design. The point is not only to catch more bugs. The point is to make the bugs that do appear cheaper to understand and safer to fix.

It also changes code review. A reviewer can ask whether a behavior is covered at the right layer. Is this a pure protocol transition? Then the sans-io test should feed bytes and assert events. Is it runtime glue? Then Tokio and Moonpool need equivalent coverage. Is it an observable behavior shared by both engines? Then the differential harness should compare the event streams. Is it broker compatibility? Then an e2e test should touch a real Pulsar broker.

Those questions are more precise than "did we add tests?" They connect the test to the failure model.

What to inspect first

For engineers reading Magnetar for the first time, the best entry point is not a single file. It is the relationship between the documents and the code.

The README gives the public surface: what the client exposes, which features are implemented, how the Java-client parity matrix is tracked, which PIPs are supported, and how the two engines are positioned. That is the user-facing contract.

The architecture document explains the shape underneath that contract. It shows the crate topology, the dependency direction, the sans-io boundary, the driver loop, the event model, the producer and consumer paths, the runtime engines, TLS sites, schemas, PIP coverage, and the validation strategy. That is the system map.

The ADR series explains why the system has this shape. ADR-0004 records the sans-io split. ADR-0003 records the no-channels rule. ADR-0011 records clock injection. ADR-0010 records the Java parity decision. ADR-0019 records how the production Tokio engine and the Moonpool engine relate to the parity goal. ADR-0024 records the cross-runtime testing policy.

This matters because Magnetar is intentionally not only a code drop. It is a set of engineering decisions with a public audit trail. If you disagree with the design, the ADRs give you the right surface to discuss. If you want to contribute a feature, the parity matrix and validation policy tell you what "done" means. If you want to evaluate the simulation work, the Moonpool engine documentation and the differential harness show how the same protocol core is driven in different worlds.

The first release should therefore be read in two ways. As a Pulsar user, look at the client surface and the parity matrix. As a Rust infrastructure engineer, look at the state-machine boundary and the simulation strategy. The interesting part of Magnetar is that both views are meant to reinforce each other.

What the first public release gives you

This first public release is a technical entry point. It is for engineers who want to try Magnetar, read the architecture, inspect the ADRs, compare behavior with existing Pulsar clients, and help shape the Rust-native Pulsar ecosystem.

The high-level client API starts with the usual shape:

let client = PulsarClient::builder()
    .service_url("pulsar://localhost:6650")
    .build()
    .await?;

let producer = client
    .producer("persistent://public/default/orders")
    .create()
    .await?;

That API is important because the client must be usable. But the release is also an invitation to inspect the lower layers. Read the README for the feature matrix. Read the architecture document for the sans-io design. Read the ADRs for the decisions behind no channels, swappable engines, clock injection, Java parity, Moonpool parity, TLS provider choices, and cross-runtime validation. Read the Moonpool engine documentation if you are interested in how deterministic simulation can be applied to a real network client.

The important point for this article is the direction: Magnetar is public so engineers can evaluate both the client surface and the engineering model behind it.

The inaugural technical entry point is available via v1.0.0, while the current state of the driver can be tracked in the v1.2.0 release. 

Why this matters beyond Magnetar

Magnetar is an Apache Pulsar client. It is also a concrete example of how we want to build more Rust infrastructure software.

Distributed systems fail through state transitions. Some of those transitions are obvious and easy to test. Many are not. They happen when time advances in an unlucky place, when a retry overlaps with a close path, when a broker drops a connection after accepting part of the session, when a callback is registered just after a notification, or when a reconnect path rebuilds one handle but not another.

You can try to chase those bugs after they happen. Sometimes that is unavoidable. But the architecture can make the chase easier or harder.

A client with a pure protocol core, explicit events, injected time, replaceable I/O, deterministic seeds, and cross-runtime comparison gives engineers better tools. It lets them reduce a failure to a trace. It lets them replay that trace. It lets them ask whether a simulated failure corresponds to the production runtime. It lets them add an invariant where a silent state drift used to hide.

That is the direction Magnetar takes. Make the protocol explicit. Make the runtime replaceable. Make failures reproducible. Make correctness something the code has to demonstrate continuously.

Thank you to Pierre Zemb for Moonpool and for pushing this deterministic-simulation direction in Rust, and to the contributors and maintainers in the Rust Pulsar ecosystem whose work made the next step possible.

Magnetar is open source. The code, architecture notes, ADRs, and documentation live at github.com/CleverCloud/magnetar.

References

Magnetar

• Magnetar repository. Public Rust Apache Pulsar client repository. https://github.com/CleverCloud/magnetar
• Magnetar README. Public feature surface, Java client parity matrix, supported PIPs, engine coverage, and status. https://github.com/CleverCloud/magnetar/blob/main/README.md
• Magnetar architecture. Sans-io rationale, crate topology, driver loop, protocol state machine, and tests. https://github.com/CleverCloud/magnetar/blob/main/ARCHITECTURE.md
• Magnetar documentation index. Moonpool engine, testing, CLI, observability, logging, PIP features. https://github.com/CleverCloud/magnetar/blob/main/docs/README.md
• Moonpool engine documentation. Deterministic-simulation engine, chaos pack, differential harness, provider model. https://github.com/CleverCloud/magnetar/blob/main/docs/moonpool-engine.md
• Testing documentation. Test categories and validation commands. https://github.com/CleverCloud/magnetar/blob/main/docs/testing.md
• ADR-0004. Sans-io magnetar-proto and swappable I/O engines. https://github.com/CleverCloud/magnetar/blob/main/specs/adr/0004-sans-io-protocol-core.md
• ADR-0010. Full Java-client parity scope. https://github.com/CleverCloud/magnetar/blob/main/specs/adr/0010-v0-1-full-java-parity.md
• ADR-0024. Cross-runtime test and coverage policy. https://github.com/CleverCloud/magnetar/blob/main/specs/adr/0024-cross-runtime-test-and-coverage-policy.md

Ecosystem

• pulsar-rs. Existing Rust Apache Pulsar client project. https://github.com/streamnative/pulsar-rs
• Apache Pulsar. Distributed messaging and streaming platform. https://pulsar.apache.org/
• Apache Pulsar Java client. Reference client surface for many Pulsar users. https://pulsar.apache.org/docs/

Deterministic simulation

• FoundationDB testing. Deterministic simulation and fault injection lineage. https://apple.github.io/foundationdb/testing.html
• TigerBeetle TigerStyle. Assertion-first engineering style. https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md
• TigerBeetle VOPR. Simulation testing approach. https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/internals/vopr.md
• Moonpool repository. Deterministic simulation for Rust systems, developed by Pierre Zemb. https://github.com/PierreZ/moonpool
• moonpool-sim. Simulation engine crate for Moonpool. https://crates.io/crates/moonpool-sim

It is a function distinct from containerization itself, which packages an application and its dependencies into a standard format. The differences between Docker and Kubernetes rest precisely on that distinction: Docker builds and runs containers, Kubernetes orchestrates them. Today, Kubernetes is the de facto standard for container orchestration, but orchestration as a concept exists independently of the tool that implements it.

Why orchestration exists

Running three containers on a single server does not call for orchestration. You start them, monitor them manually, and restart one yourself if it crashes. The nature of the problem changes the moment an application becomes a distributed system: several services, several machines, variable traffic, frequent deployments. The operational questions that appear then are concrete. Which machine should this new container run on? What happens if a node goes down in the middle of the night? How do you move from version 1.4 to 1.5 with no visible interruption? How does one internal service find another when IP addresses change on every restart?

Each of these questions has a possible manual answer, one you can even script. Orchestration is about automating them coherently, under a single model.

The five core functions of orchestration

Kubernetes handles these questions through a declarative model built on reconciliation loops: you describe the desired state of the system, and the orchestrator constantly compares that desired state to the actual state to bring them together. The five functions that follow are instances of this general mechanism.

Scheduling: placing containers on the right machines

Scheduling answers one question: when a new container needs to start, which machine in the cluster should run it? On a cluster of a few nodes with identical profiles, the decision is trivial. On a real cluster, it is not: some machines have GPUs and others do not, some are already loaded, some applications must be isolated while others must instead be co-located for latency reasons.

The kube-scheduler component makes this choice in two steps: filtering, which rules out the nodes that cannot host the pod (insufficient capacity, affinity constraints, taints and tolerations), and scoring, which ranks the remaining nodes against several criteria. The pod is then assigned to the chosen node through a binding operation with the API server. The quality of the decision depends on the information given to the scheduler. It is the resource requests declared on the pods that drive placement: the scheduler looks for a node whose available capacity covers those requests. The limits, on the other hand, play no part in placement; they cap a container’s consumption once it is running.

Scaling: matching capacity to real traffic

Scaling automates a decision that is simple to state: how many copies of a service should run at a given moment? Too many copies cost money. Too few cause incidents at the first spike.

Scaling is a function common to every orchestrator; the mechanisms vary by implementation. In Kubernetes, it rests on three distinct building blocks. The Horizontal Pod Autoscaler (HPA), part of core Kubernetes, adjusts the number of pods in a deployment based on a metric. To do so it relies on the Metrics Server, a component you install separately, because metric collection is not provided by default. The Vertical Pod Autoscaler (VPA), also shipped as a separate project, adjusts the resources allocated to each pod. The Cluster Autoscaler, finally, adds or removes whole nodes according to aggregate needs. These mechanisms assume reliable metrics: an HPA driven by CPU, when the service is actually constrained by disk I/O, will not produce the expected result.

Self-healing: replacing what fails

Past a certain number of machines, failures stop being exceptional events and become background noise. A disk fails, a kernel panic happens, a container leaks memory and ends up OOM-killed. Without orchestration, every failure triggers human intervention, more or less urgent. With orchestration, these events are absorbed without intervention.

Within Kubernetes, the mechanism rests on two elements. First, probes (liveness, readiness, startup) that let it know whether a container is actually working, and not merely whether it has started. Second, the principle that any object managed by a controller (Deployment, StatefulSet, DaemonSet) is constantly compared against the desired state: if a pod disappears, the controller requests a new one. The effectiveness of self-healing depends on how well the probes are configured: probes that are too strict cause unnecessary restarts, while probes that are too lenient allow unhealthy containers to remain running.

Service discovery and internal load balancing

In a dynamic container environment, where each Pod has an ephemeral IP address, two services that need to communicate cannot rely on static IP configurations. Service discovery solves this through a layer of indirection. In Kubernetes, a Service object groups a set of pods (selected by labels) under a stable DNS name and a virtual IP. CoreDNS, the cluster’s internal DNS server, resolves these names. Traffic sent to the Service IP is distributed across the ready pods via kube-proxy. This principle is not specific to Kubernetes: other orchestrators meet the same need differently. On Clever Cloud, for instance, services find each other through configuration injection between applications and through Network Groups, an encrypted private network with internal DNS resolution.

Several types of Services exist (ClusterIP for internal traffic, NodePort and LoadBalancer for external traffic), alongside the notion of Ingress for application-level HTTP routing. Although it may appear simple, this network layer accounts for much of Kubernetes’ operational complexity, including CNI plugin selection, network policies and east-west traffic observability.

Rolling updates and rollbacks

Shipping a new version to production without interrupting the service is a risky operation when done by hand. Kubernetes treats it as a state transition: you change the Deployment manifest to point to the new image version, and the controller applies the configured rollout strategy.

The RollingUpdate strategy (the default) progressively replaces old pods with new ones, guaranteeing that a minimum number stays available at all times. The Recreate strategy stops everything and then restarts, useful for incompatible schema migrations. In case of failure, the rollout does not revert on its own to the previous state: it stops, the new pods that fail their probes do not replace the old ones, and it is an operator who triggers the return to the previous version with kubectl rollout undo. For this to work, the versions must be compatible with each other during the transition, which implies discipline on API contracts and database migrations.

Beyond the five core functions

Kubernetes orchestration does not stop at these five functions. In practice, a production Kubernetes cluster also manages application configuration (ConfigMaps), secrets (with or without encryption at rest), persistent storage through PersistentVolumeClaims, authorization (RBAC), network isolation (NetworkPolicies), observability (logs, metrics, traces), and certificate lifecycle management. Each of these introduces an additional operational responsibility beyond the core orchestration functions.

Without an orchestrator vs with Kubernetes: a function-by-function comparison

The table does not rank the two columns. It shows that Kubernetes provides a unified model for these five functions, where an approach without an orchestrator handles them separately with different tools. For a system that does not need this unification, the left-hand column remains perfectly valid.

Common practices worth knowing

Choose the tool based on the need, not by default. Not every application needs scheduling, automatic scaling or service discovery at the level Kubernetes offers. A PaaS, a VM-based deployment or an application managed by systemd can meet many needs through a different operational model.

Think about observability from the start. A Kubernetes cluster without centralized logs, aggregated metrics and traces quickly becomes hard to operate beyond a handful of services. Observability is an integral part of orchestration, not an optional add-on.

Define requests and limits before enabling autoscaling. The HPA and the Cluster Autoscaler rely on the pods’ declared resources to decide on scaling. Without declarations, their decisions rest on partial information.

Get probe configuration right. Poorly configured liveness and readiness probes can undermine both self-healing and traffic routing.

When Kubernetes orchestration becomes relevant

No single one of the five functions, taken in isolation, justifies bringing Kubernetes into a system. A deployment script, a properly configured load balancer or a monitoring tool with automatic restart capabilities can each cover one of these functions individually. What justifies adopting an orchestrator is the point where the five functions all become necessary at once, on an infrastructure distributed enough to make ad hoc solutions expensive to maintain.

Concretely, that corresponds to architectures with a dozen services or more, deployed across several machines, with frequent deployment cycles, significant load variations and resilience requirements that no longer tolerate manual intervention. For contexts more constrained in resources (edge, IoT, development machines, small clusters), a lightweight Kubernetes distribution such as K3s can be a good fit. A PaaS also meets these needs, as it does many other application profiles (industrialized deployment, automatic scaling, resilience, updates), with an operational model distinct from Kubernetes.

When Kubernetes does become relevant, the next question rarely concerns installation and more often day-to-day operations: control plane updates, etcd management, certificate rotation, observability, backups. That observation is what explains the growing adoption of managed Kubernetes services. At Clever Cloud, Clever Kubernetes Engine addresses this need with Materia etcd, a serverless implementation of the etcd API built on FoundationDB that takes over from standard etcd, a known bottleneck at scale, on sovereign infrastructure spread across our three Paris datacenters.

Container orchestration in summary

Container orchestration automates several categories of operational decisions, chief among them five main classes: where to place a container, when to start more of them, what to do when one of them fails, how they find one another, and how to move from one version to the next without interruption. Kubernetes brings these functions together under a unified model, making it the de facto standard for distributed systems that require all of them. The useful question, faced with a project, is not whether you should do orchestration, but which of these functions are actually needed, and at what level of automation.

FAQ - Kubernetes orchestration

What is the difference between containerization and orchestration?

Containerization packages an application and its dependencies into a standardized format that runs identically on any compatible host. Orchestration automates the management of a fleet of containers in production: placement, scaling, self-healing, service discovery, updates. Docker is the reference tool for the former, Kubernetes for the latter.

Do you necessarily need Kubernetes to orchestrate containers?

No. Kubernetes is the most widely adopted orchestrator, but others exist: HashiCorp’s Nomad, which orchestrates containers, VMs and binaries in a single cluster, or Docker Swarm, still maintained but with declining adoption. Apache Mesos, long cited as an alternative, was retired to the Apache Attic in October 2025 and is no longer in active development. Beyond that, a PaaS like Clever Cloud covers the full set of these orchestration functions (placement, automatic scaling, self-healing, rolling updates, service discovery) with its own control plane, independent of Kubernetes. It is that control plane that orchestrates both the applications running in VMs and the containers of the platform’s Docker runtime.

Is container orchestration necessary for CI/CD?

No, but the two are often used together. Modern CI/CD pipelines produce container images as their final artifact, and the orchestrator (Kubernetes or another) takes over to deploy and operate those images. CI/CD and orchestration are two complementary stages of the application lifecycle.

Does K3s allow orchestration in constrained environments?

Yes. K3s is a CNCF-certified Kubernetes distribution designed for resource-limited environments (edge, IoT, development machines, small clusters). It keeps the standard Kubernetes APIs while reducing the resource footprint and deployment complexity.

Does managed Kubernetes change the orchestration functions available?

No. Managed Kubernetes provides the same set of orchestration functions as a self-hosted cluster, since it is the same Kubernetes. The difference lies in how operational responsibilities are split: the provider takes on control plane management, updates, and the underlying monitoring. Users then focus on their application workloads.

Which orchestration function is the hardest to master?

Networking is frequently cited as the most complex. Service discovery, internal load balancing, NetworkPolicies, Ingress, CNI plugin, east-west traffic observability: the Kubernetes network layer concentrates a significant share of advanced operational topics and remains a frequent source of production incidents.

This release is a milestone: the underlying machine is now ready for the product features we have been waiting to build on top of it. Rather than a list of patches, we've grouped the work into six themes; for each, we say two things — what shipped, and what it makes possible, for the people running their applications on the platform and for the operators who run Sōzu on their own infrastructure.

1. A from-scratch HTTP/2 multiplexer

Sōzu's HTTP/1 stack had already been rewritten around kawa, our pivot format: a single internal representation of the HTTP message, independent of its protocol version — the same idea as HAProxy's HTX. The HTTP/2 multiplexer is its natural extension: it adds session management and stream multiplexing on top of kawa.

It supports the full protocol matrix (H1↔H1, H1↔H2, H2↔H1, H2↔H2), with shared stream state, HPACK compression via loona-hpack, backend H2 connection pooling, RFC 9218 Extensible Priorities for stream prioritisation, and per-listener ALPN negotiation so each TLS connection lands on the right code path. Around 181 end-to-end tests and two cargo-fuzz targets keep the parser and the HPACK decoder honest — including regression guards that pin large-response integrity byte-for-byte across an H1-backend → H2-frontend path, the exact boundary where edge-triggered epoll readiness bugs hide.

For Clever Cloud customers, the practical impact is simple: every application served by the platform now speaks HTTP/2 by default, on the frontend — no opt-in, no code change, no configuration. Enabling HTTP/2 all the way to the backend stays a per-cluster choice — a cluster, in Sōzu's model, is one of your applications; turned on end-to-end, it unlocks gRPC across the whole chain. Page loads finish in fewer TCP connections; browsers can coalesce requests across hostnames that share a certificate (we honour RFC 7540 §9.1.1 SAN coalescing, so when the certificate, authority and connection conditions line up, Firefox and Chrome can reuse a single connection across your cdn.example.com and assets.example.com instead of opening parallel ones). It is, in the best sense, a quiet platform upgrade.

It is also the structural prerequisite for what comes after — HTTP/3 over QUIC and stronger streaming foundations at the edge. The mux rewrite is the part of the roadmap that had to land first.

2. Security as a baseline, not a toggle

The second half of the H2 rewrite is the part nobody asks for until it's missing: flood and DoS hardening. Sōzu 2.0 ships built-in mitigations for CVE-2023-44487 (Rapid Reset), CVE-2024-27316 (CONTINUATION flood), CVE-2025-8671 (MadeYouReset), and the PING / SETTINGS / empty-DATA flood family from CVE-2019-9512/CVE-2019-9515/CVE-2019-9518. Each mitigation surfaces a dedicated counter — twelve metrics under h2.flood.violation.* — so a SIEM can window the trip rate without parsing logs. Seventeen HPACK rejection reasons are surfaced the same way; that is the first operator-visible signal for request-smuggling probes against the H2 stack.

The rest of the security work fans out across the proxy: a per-(cluster, source-IP) connection cap with 429 Too Many Requests; opt-in eviction of the oldest sessions when the accept queue saturates; hardening across the command channel, the HTTP/1 parser, the pattern-trie router (closing a routing-bypass through unanchored regex) and the wildcard matcher; audit-log sanitisation against Trojan-Source and SIEM column-smuggling; and a TLS certificate hot-rotation that never drops the working certificate on failure, even if the new one is malformed. Four dependency advisories cleared in the same window.

Every privileged mutation now lands in a structured audit log: each control-plane action is recorded as a Command(verb=…, actor_uid=…, actor_user=…, result=…) line — who did what, from where, and whether it succeeded. Two dedicated sinks ship it out: audit_logs_target for the human-readable stream, and audit_logs_json_target for one stable-schema JSON object per line, so the trail tails straight into a SIEM (Wazuh, Elastic, Loki, Splunk) without a bespoke parser — in a shape designed for PCI-DSS 10.5.

The product framing is straightforward: our job is to operate the platform and shield your applications as soon as we can. When the next H/2 vulnerability in this class lands at 9pm on a Friday, it does not have to translate into a patch-and-redeploy weekend across thousands of applications — attacks of this class are largely absorbed or mitigated at the proxy, surfaced as a counter on a dashboard, while applications keep serving traffic. Trust-by-default is not a marketing claim; it is the cumulative effect of dozens of small, defensive fixes shipped at the layer where the security boundary actually lives.

3. Visibility on every layer

The largest single user-facing addition in 2.0 is sozu top — an operator TUI (behind the tui Cargo feature) that gives you a live btop/htop-style view across seven panes: Overview, Clusters, Backends, Listeners, H2, Certificates, Events. Colour-blind-safe palette, customisable themes — the essentials fit in a terminal, no external dashboard required.

Underneath the TUI, the metric surface itself was rewritten. The mux exposes per-frame-type counters and a breakdown by RFC 9113 error code, TLS handshake telemetry, per-status HTTP counters, and new worker lifecycle gauges. The access log gains TLS and forwarding fields (version, cipher, SNI, ALPN, XFF chain), x_request_id propagation end-to-end, and client and server RTT — enough to follow a request from one hop to the next.

A new command, SetMetricDetail, lets an operator raise metric cardinality on demand via a time-bounded lease that expires: production stays low-cardinality by default, and deep inspection becomes a one-off decision rather than a config rewrite.

For Clever Cloud, this is the foundation of the next chapter of customer-facing observability — per-application latency percentiles, per-cluster availability, TLS handshake breakdowns, request IDs you can follow across hops. The metrics now exist at the proxy. The next step is to surface them in the Clever Cloud console where they belong, alongside the build and deploy views — so you do not need an external APM to understand the traffic your application actually sees.

4. Traffic policies that you can finally toggle

Sōzu 2.0 reshapes the entire frontend-policy surface (#1231): typed HSTS (RFC 6797) configurable per listener and per frontend; URL rewrite (host, path, port) with regex capture propagation from the routing trie into rewrite templates; request- and response-header rewriting per frontend — add, set, or delete any header (an empty value deletes it, HAProxy del-header parity), with listener-scoped X-Real-IP injection and anti-spoof elision of client-supplied values on top; HTTP 301 / 302 / 308 redirects through a typed RedirectPolicy enum; and HTTP Basic authentication per frontend, with SHA-256-hashed credentials and a constant-time compare via the subtle crate (the credential boundary is hardened against timing side-channels — the audit caught it at review time).

This is the part of the release where the product opportunity is most visible. Today, doing a clean domain migration on a managed platform typically requires either a backend that knows how to redirect or a separately deployed redirect service; putting a staging URL behind a password typically requires an authentication add-on. In Sōzu 2.0, these become knobs at the proxy. The plumbing exists; what remains is to expose those knobs in the Clever Cloud console — as a checkbox on a domain, or a one-click toggle for preview environments. That is the no-code traffic-control surface we want to build next.

5. Operations as the customer benefit

A rewrite this deep only ships safely if the fleet keeps moving underneath it. Day-to-day operations got a lot of attention in 2.0.

sozu listener {http,https,tcp} update is a new field-masked patch verb that tunes non-bind-only listener settings on a running proxy without cycling sockets — H/2 flood thresholds, SNI binding, ALPN preference, idle timeouts, HSTS, custom answers. CVE mitigations can now be tightened under attack without cycling listener sockets. Active backend health checks run inside the existing mio event loop (no async runtime, no extra threads) with HTTP/1.1 and HTTP/2 probes, jittered intervals, and a fail-open path that routes through Normal-status backends whose retry policy allows it. systemd integration (closes #228) now does the right thing: Type=notify units, READY=1 only after the initial workers spawn and the saved state replays, STOPPING=1 on graceful shutdown, MAINPID=<new> across hot upgrades.

Releases themselves changed shape. Pushing a tag now produces ten pre-built tarballs (three Linux targets crossed with up to four crypto providers), signed keyless via sigstore (cosign + GitHub OIDC), with SLSA build provenance and a SOURCE.txt corresponding-source pointer satisfying AGPL §6 / LGPL §4 — closing the gap noted in #1089. ACME fullchain.pem files now load cleanly even when the client emitted the leaf at the start (Certbot, lego, acme.sh); a six-year-old worker-auto-restart binary race (#515) is fixed by pinning the original inode through /proc/self/fd. The LoadState IPC verb stays forward-compatible with sozu-command-lib 1.1.1 clients, so the ecosystem of integrations does not break on the upgrade.

At Clever Cloud's scale, the cost of an operational incident isn't a ticket — it is compounding latency for thousands of applications, and the engineers' time we owe to building the next thing. Sōzu 2.0 is the proxy that is quiet to operate, and that quietness is what customers experience as uptime. It's also what makes Sōzu credible as something you can run on your own infrastructure: signed binaries, hot reloads, ACME quirks ironed out, systemd integration done properly.

6. Crypto that's ready for tomorrow

The TLS stack got a quieter but equally important rework (#1191). Sōzu now supports four pluggable crypto providers for rustls — crypto-ring (the default), crypto-aws-lc-rs, crypto-openssl, and fips (which implies aws-lc-rs in FIPS mode). All four are exercised by CI, and the precedence chain fips > ring > aws-lc-rs > openssl resolves the active provider deterministically when several features are enabled together.

What we are most happy about, though, is the default groups_list: X25519MLKEM768 is now the first-preference key-exchange group where the provider supports it. That is the post-quantum hybrid being standardised through the IETF (draft-ietf-tls-ecdhe-mlkem) and already registered in the IANA TLS registry; what it means in practice is that an X25519-only client and a PQ-capable client both negotiate the most robust mutually supported exchange, with no operator action.

When the post-quantum migration becomes a regulatory requirement — on a timeline the industry is still debating — the groundwork on Clever Cloud will already be in place: every TLS 1.3 client that offers the hybrid negotiates it today, with no operator action. We made the choice quietly, and we made it the default.

From reverse proxy to programmable edge

Sōzu has always been an infrastructure load balancer: well beyond HTTP, it also balances raw TCP, with a zero-copy forwarding path via splice(2) on Linux for TCP listeners. With 2.0 it moves closer to an API gateway and becomes the substrate of a programmable edge — and "programmable" is the operative word. Each capability described above (HTTP/2 by default, anti-abuse controls, observability, traffic policies, crypto agility, operational quietness) is a knob. The next year of Clever Cloud's roadmap is about exposing those knobs as product features: through the console, through the API, through the workflows you already use to deploy your applications.

This is what we mean when we say Sōzu 2.0 is a first step of something greater. Two-point-zero is not the destination — it is the platform we now build on top of. Managed HTTP/2 everywhere is the first building block. The next is a console where you toggle HSTS, password-protect a preview environment, or redirect a migrated domain. The destination — a fully programmable edge with policy primitives you can compose — is what we are building toward over the coming release cycle.

Two more pieces are already on the bench. First, a UDP load-balancing layer — in the spirit of IPVS, but with Sōzu's hot-reload model — paired with TCP health checks that probe the liveness of the UDP backends; this cements the infrastructure-load-balancer role further. Second, HTTPS-reachable backends, which firm up upstream connectivity and open the road to the API gateway.

Sōzu is open source under AGPL-3.0 (the command library is LGPL-3.0). The 2.0 release binaries are signed via sigstore and ship SLSA provenance; if you operate your own edge, this release is yours to use, audit, and extend. The code, the issue tracker, and the conversations live at github.com/sozu-proxy/sozu.

Thank you to the contributors who made this release happen — and to everyone running Sōzu in production, whose feedback shapes where it goes next.

References

Standards and specifications

• RFC 6797 — HTTP Strict Transport Security (HSTS). https://datatracker.ietf.org/doc/html/rfc6797
• RFC 7540 — Hypertext Transfer Protocol Version 2 (HTTP/2). Now obsoleted by RFC 9113, but §9.1.1 on connection coalescing remains the citation reused by RFC 9113. https://datatracker.ietf.org/doc/html/rfc7540
• RFC 9113 — HTTP/2 (current). §5 streams, §6 frames, §6.8 GOAWAY, §7 error codes, §8.1 HTTP semantics. https://datatracker.ietf.org/doc/html/rfc9113
• RFC 9218 — Extensible Prioritization Scheme for HTTP. https://datatracker.ietf.org/doc/html/rfc9218
• draft-ietf-tls-ecdhe-mlkem — Hybrid key exchange in TLS 1.3: X25519MLKEM768 (IETF Internet-Draft, IANA-registered; the post-quantum hybrid Sōzu prefers by default). https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-mlkem

CVEs

• CVE-2019-9512 — HTTP/2 Ping Flood. https://nvd.nist.gov/vuln/detail/CVE-2019-9512
• CVE-2019-9515 — HTTP/2 Settings Flood. https://nvd.nist.gov/vuln/detail/CVE-2019-9515
• CVE-2019-9518 — HTTP/2 Empty Frames Flood. https://nvd.nist.gov/vuln/detail/CVE-2019-9518
• CVE-2021-42574 — Trojan Source (bidirectional override). https://nvd.nist.gov/vuln/detail/CVE-2021-42574
• CVE-2023-44487 — HTTP/2 Rapid Reset. https://nvd.nist.gov/vuln/detail/CVE-2023-44487
• CVE-2024-27316 — HTTP/2 CONTINUATION Flood. https://nvd.nist.gov/vuln/detail/CVE-2024-27316
• CVE-2025-8671 — MadeYouReset (HTTP/2). https://nvd.nist.gov/vuln/detail/CVE-2025-8671

Further reading

• Cloudflare Learning Center — What is HSTS?. Accessible primer on HSTS, the max-age / includeSubDomains / preload semantics, and the HSTS preload list policy. https://www.cloudflare.com/learning/ssl/what-is-hsts/
• Cloudflare — HTTP/2 Rapid Reset: deconstructing the record-breaking attack. The canonical write-up of the October 2023 coordinated disclosure, including attack mechanics and the 398 M rps peak captured live. https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• HAProxy Technologies — HAProxy is Not Affected by the HTTP/2 Rapid Reset Attack (CVE-2023-44487). HAProxy's structural argument for why their stream lifecycle naturally absorbs Rapid Reset; a useful contrast against Sōzu's flood-counter approach. https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-http-2-rapid-reset-attack-cve-2023-44487
• Cloudflare blog — Post-quantum series. Multi-year coverage by Bas Westerbaan and colleagues on PQ key exchange and hybrid groups; lineage of the X25519MLKEM768 hybrid Sōzu now negotiates by default. https://blog.cloudflare.com/tag/post-quantum/