Giant Swarm

What Is Giant Swarm?

Picture a platform engineering team at a mid-sized European manufacturer. It has a handful of engineers, a growing list of applications that need to run reliably around the clock, and no appetite to hire a dedicated Kubernetes SRE function. The team could adopt AWS EKS and build its own operations layer on top, or it could hand the entire operational burden to a specialist. Giant Swarm exists for the second option, and its customer list — adidas, Vaillant, and Vodafone among them — suggests plenty of teams have chosen it.

Three founders — Timo Derstappen, Henning Lange, and Oliver Thylmann — started the company in Cologne in 2014. The trio grew the company out of their earlier experience running Adcloud, an ad exchange that processed thousands of transactions per second and consumed roughly a third of engineering time just keeping infrastructure alive. That frustration became the founding premise: build the Kubernetes operations layer once, run it properly, and sell it as a managed service rather than making every company reinvent it.

What sets Giant Swarm apart from AWS EKS or Google GKE is where the platform actually runs. Rather than hosting your workloads on Giant Swarm's own infrastructure, the company deploys and operates Kubernetes clusters inside your own AWS, Azure, or on-premises account. You keep the cloud bill and the data; Giant Swarm keeps the pager.

Key Features

Runs Inside Your Own Cloud Account

This is the architectural decision that shapes everything else about Giant Swarm. Clusters run in your AWS or Azure account, or on your own bare-metal infrastructure, with Giant Swarm's control plane and SRE team operating them remotely. For our hypothetical manufacturer, that means sensitive production data and application workloads never sit inside a third-party's shared environment — a meaningful distinction for anyone with strict data residency requirements.

24/7 Site Reliability Engineering

Giant Swarm's core commercial promise is operational: round-the-clock monitoring, incident response, and a documented escalation path. First-line support runs through a dedicated Slack channel during business hours (08:00–18:00 CET), with issues that need deeper expertise escalated to a rotating on-call engineer. The company backs this with a 99.95% uptime SLA written into contracts, a figure worth holding vendors to rather than accepting at face value.

A Pre-Integrated CNCF Stack

Rather than leaving customers to choose and wire together networking, policy, GitOps, and autoscaling tooling, Giant Swarm ships a curated, opinionated stack. It bundles Cilium for networking, Kyverno for policy enforcement, Flux for GitOps deployment, and Karpenter for autoscaling. For a platform team that would otherwise spend months evaluating and integrating these tools individually, the pre-integration is a genuine time saver — provided the opinionated choices fit your existing workflows.

Fully-Managed vs Expert-Supported

Giant Swarm offers two delivery models. Fully-Managed hands day-to-day operations entirely to Giant Swarm's SRE team. Expert-Supported keeps your own engineers in control of daily operations, with Giant Swarm providing architecture guidance and escalation support rather than direct production access. Organisations with strict internal policies against third-party production access will find the second model the more realistic starting point.

Observability, Security, and Edge Add-Ons

Beyond core Kubernetes management, Giant Swarm bundles self-hosted observability with fixed pricing rather than per-GB ingestion costs. It also ships security tooling built around Pod Security Standards and CIS benchmarks, plus edge/IIoT capabilities for smart-factory and edge-to-cloud workloads. An AI infrastructure component adds GPU scheduling and holds CNCF AI-Conformance certification, reflecting where a lot of platform engineering demand has shifted recently.

A Public Engineering Handbook

Giant Swarm publishes its internal engineering handbook and support process documentation openly, alongside a full technical reference at docs.giantswarm.io. Prospective customers can read exactly how the support escalation model works, how SLOs are calculated, and how the platform teams organise themselves before ever talking to sales. That level of transparency is unusual for an infrastructure vendor and gives procurement teams something concrete to evaluate ahead of a paid trial.

Pricing

Giant Swarm publishes no price list, and there is no free tier or self-serve trial. Every engagement begins with a conversation about cluster count, delivery model, and support requirements before a quote materialises. This is a real barrier for smaller teams that want to test the waters before committing budget. It also stands in sharp contrast to AWS EKS or Google GKE, where a developer can spin up a small cluster on a personal card within minutes.

Giant Swarm's target customer, though, is rarely evaluating a five-dollar toy cluster. Enterprises with dozens of production clusters and a genuine SRE staffing gap are the intended buyer. For that segment, custom pricing tied to actual operational scope may well be more sensible than a rigid published tier structure. Budget-conscious teams should still expect to invest real time in procurement before they see a number.

EU Compliance & Privacy

Giant Swarm is headquartered in Cologne, Germany, making it directly subject to GDPR as both a data processor and, in practice, an operator with privileged access to customer clusters. The company holds ISO 27001 certification, a process it has described publicly as taking 21 months to complete — a detail that suggests the certification reflects real process maturity rather than a rushed audit.

Architecture is the stronger compliance story here. Because clusters run inside the customer's own cloud account rather than a shared Giant Swarm environment, data residency ultimately follows whatever region the customer selects for their AWS or Azure account. A German manufacturer running everything in an EU-West region keeps its data inside the EU regardless of where Giant Swarm's own operations staff happen to be. That said, Giant Swarm's SRE team does have operational access to manage those clusters, so organisations should review the access model carefully during procurement rather than assume it is identical to fully air-gapped self-hosting.

Who It's Best For

Giant Swarm's fit depends less on company size than on how much of the Kubernetes operations burden you want to keep in-house.

Platform teams that want Kubernetes operated for them, not just provisioned. If the gap in your organisation is 24/7 operational coverage rather than raw infrastructure access, Giant Swarm's SRE model addresses that directly.

Enterprises with strict data residency requirements that still want a managed experience. Running inside your own cloud account satisfies data sovereignty questions that a shared multi-tenant SaaS control plane cannot.

Manufacturing, retail, and telecom organisations with production-scale Kubernetes needs — the existing customer base in these sectors suggests Giant Swarm has real experience with their specific compliance and reliability demands.

Teams uncomfortable ceding production access entirely should look closely at the Expert-Supported model, which keeps day-to-day control in-house while still buying architectural guidance.

Smaller teams evaluating Kubernetes for the first time, or anyone who wants to test a platform before a procurement cycle, should look elsewhere first. Scaleway Kubernetes Kapsule or STACKIT offer a faster starting point given their published, self-serve pricing.

The Verdict

Giant Swarm answers a specific question well: who operates Kubernetes once you have decided you never want to build an SRE team for it yourself? Running entirely inside a customer's own cloud account is a genuinely strong answer to data sovereignty concerns, and the pre-integrated CNCF stack removes real integration work for platform teams. The lack of published pricing and any free tier will frustrate teams that want to self-serve their way to a decision. Its most recent disclosed funding round dates back a decade, too, leaving the company's current financial position opaque. For enterprises that have already decided managed Kubernetes operations are worth outsourcing, though, Giant Swarm's decade of production experience and EU jurisdiction make it a credible alternative to AWS EKS or Google GKE.

Frequently Asked Questions

Where does Giant Swarm run my Kubernetes workloads?

Inside your own cloud account. Giant Swarm deploys and operates Kubernetes clusters within your AWS, Azure, or on-premises environment rather than a shared multi-tenant platform, so your data and workloads never leave infrastructure you control.

How much does Giant Swarm cost?

No published price list exists. There is no free tier or self-serve trial; every engagement is quoted individually based on cluster count, delivery model (Fully-Managed or Expert-Supported), and support requirements.

What is the difference between Fully-Managed and Expert-Supported?

Fully-Managed hands 24/7 operations to Giant Swarm's SRE team. Expert-Supported keeps your own team operating the clusters day to day, with Giant Swarm providing architecture guidance and escalation support rather than direct production access.

Is Giant Swarm GDPR compliant?

Giant Swarm is headquartered in Cologne, Germany, is ISO 27001 certified, and runs workloads inside your own cloud account. Because Giant Swarm never holds your data in a shared environment, EU customers can keep both infrastructure and data within EU jurisdiction.

How does Giant Swarm compare to AWS EKS or Google GKE?

EKS and GKE are self-service managed control planes you configure and largely operate yourself. Giant Swarm adds a curated, pre-integrated tooling stack and 24/7 SRE operations on top of the underlying cloud, aimed at teams that want a platform run for them rather than a raw managed control plane.

For a self-hostable, open-source-first alternative in the same managed Kubernetes category, see our review of Kubermatic, which takes a different architectural approach to the same multi-cloud problem.