Am 28. Oktober 2026 wurde aus dem Projekt, das als WAF++ gestartet ist, Wombat.

Das ist kein Pivot. Nichts wurde übernommen, nichts abgespalten, kein Strategiedeck war beteiligt. Die Controls, der Code, die Lizenzen, das Governance-Modell und die Menschen — es sind dieselben, die elf Monate zuvor in einer Hotelbar über Cloud-Architektur diskutiert haben.

Geändert hat sich das, was die Community hundertmal am Tag laut sagen muss: der Name.

Wo das angefangen hat

Es war der Abend vor der Cloud Native Conference 2025. Tim, Sebastian und ich saßen in einer Hotelbar mit zu wenig Steckdosen und zu viel Gesprächsstoff — Cloud-Architektur, Souveränität, Provider-Lock-in und die unangenehme Erkenntnis, dass die „Best Practices”, an die wir uns alle halten sollten, meistens eine Produkt-Roadmap mit einem Diagramm obendrauf waren.

Die Lücke war offensichtlich: Jeder Hyperscaler hat ein Well-Architected Framework. Keines davon ist neutral. Keines gehört den Menschen, die die Architekturen tatsächlich bauen. Ein offenes, engineering-getriebenes, von der Community getragenes Gegenstück gab es nicht.

Zwei Wochen später kam Artem dazu — und passenderweise war er es auch, der den ersten Namen gefunden hat.

Unsere Open-Source-Idee war nie „ein PDF veröffentlichen und hoffen, dass es zitiert wird”. Sondern: Die Kriterien selbst müssen öffentlich, zitierbar, forkbar und diskutierbar sein. Jeder Control soll etwas sein, auf das man im Audit zeigen kann, dem man in einem Pull Request widersprechen kann — und das man öffentlich verbessern kann.

Was wir tatsächlich gebaut haben

Zwischen dieser Bar und diesem Beitrag ist eine Menge passiert:

• Februar 2026 — Marketing-Website und Antora-Dokumentation gehen live.
• 12. Mai 2026 — Version 1.0 des Frameworks und der Tooling-Suite erscheint, einen Tag vor der Cloud Native Conference 2026 in Frankfurt.
• Juli 2026 — die Agentic-Säule kommt dazu; das Framework hat jetzt acht Säulen.
• Heute — Framework v1.1, WOMBATpass v1.1.0, mehr als 100 Controls, das PASS-Scoring-Modell und Governance über öffentliche RFCs.

Das Tooling ist mitgewachsen. WOMBATpass ist CLI, Dashboard und Server, dazu eine GitHub Action und ein MCP-Server. Es parst Terraform und AWS CDK statisch, bewertet die Controls und erzeugt auditfähige Evidenz — ohne Cloud-Zugangsdaten.

Der Teil von Open Source, den wir falsch hatten

Jetzt kommt der unangenehme Teil: Unsere Lizenzen waren von Tag eins offen. Apache 2.0 für den Code, CC BY 4.0 für die Dokumentation. Auch die Governance war offen — jede wesentliche Entscheidung läuft durch ein öffentliches RFC, mit Begründung.

Und trotzdem war etwas kaputt.

Denn Offenheit ist nicht nur eine LICENSE-Datei. Sie ist auch die Frage, ob Menschen dich finden, deinen Namen aussprechen und dich ohne Fußnote zitieren können. Und „WAF++” ist an allen drei Punkten gescheitert:

• Im Security-Kontext bedeutet WAF längst Web Application Firewall. Jede einzelne Vorstellung begann mit einer Korrektur.
• Das „++” überlebt nicht — nicht in Suchmaschinen, nicht in URLs, nicht im Flur einer Konferenz. Es ist eine Programmier-Referenz, für die sich unser Publikum nie angemeldet hat.
• In freier Wildbahn tauchte das Projekt als WAF++, WAF2p, waf2p und WAFpass auf — teilweise im selben Satz.

Eine Community kann keinen Namen besitzen, den sie erst erklären muss. Also haben wir den Namen wie jeden anderen Defekt behandelt: gefixt.

Open Source ist keine Lizenz, die man anhängt. Es ist ein Name, den Menschen tragen können.

Warum ein Wombat?

Weil er baut. Er gräbt Tunnel, hält sie instand und verbindet Dinge, die sonst getrennt bleiben — und das unterirdisch, ohne Applaus zu brauchen. Das beschreibt Architekturarbeit ziemlich gut. Und ein Community-Projekt.

Außerdem ist es praktisch: Ein Tier lässt sich in jeder Sprache aussprechen, in jeder Suchmaschine finden und mit keinem Firewall-Produkt verwechseln.

Wombat ist kein zweites Projekt neben WAF++. Es ist WAF++ — mit einem Namen, der funktioniert. Das Ankündigungsbild sagt es besser, als ich es kann: die neue Stimme von WAF++.

Was sich ändert — die Kurzfassung

• Projekt und Framework: WAF++ → Wombat
• Tooling: WAFpass → WOMBATpass (CLI, Dashboard, Server, GitHub Action, MCP-Server)
• Kommando: wombat
• Website: www.wombat-gov.dev
• Installer: wombat-cli.dev

Zwei Bezeichner bleiben nicht stehen, sondern ziehen mit um. Die Antora-Dokumentation wird gemeinsam mit dem Framework umbenannt — mit Fallback-Routing, damit bestehende Links unter /docs/wafpp/1.1.0/ weiter auflösen, statt ins Leere zu laufen. Und die beiden Python-Pakete werden unter dem neuen Namen erneut auf PyPI veröffentlicht. Bis diese Migration durch ist, funktionieren die aktuellen Pfade und Pakete unverändert weiter.

Was sich nicht ändert

Die Dinge, auf die es ankommt — und die kein Rename anfassen kann:

• Governance. RFC-getrieben, öffentlich, mit Begründung. Keine stillen Updates, kein Anbieter, der hinter verschlossenen Türen entscheidet.
• Lizenzen. Code unter Apache 2.0, Dokumentation unter CC BY 4.0.
• Neutralität. Kein Hyperscaler, kein einzelnes Unternehmen, kein Upsell.
• Die Substanz. Acht Säulen, 100+ Controls, das PASS-Scoring-Modell, der Evidenzpfad.
• Die Menschen. Dasselbe Team, inzwischen mit mehr Beitragenden, als wir zählen können — und genau darum geht es.

Und die Geschichte wird nicht umgeschrieben. Ältere Artikel in diesem Blog behalten den Namen „WAF++”, weil das Projekt damals so hieß. Das zu ändern wäre Revisionismus — kein Rebranding.

Wie es weitergeht

Der Name war das Letzte, das noch eine Erklärung brauchte. Alles andere steht: ein offenes Framework, funktionierendes Tooling, öffentliche Governance und ein Release-Tempo, das wir halten können.

Was jetzt kommt, ist weniger glamourös und wichtiger: mehr Controls, mehr Working Groups, mehr echte Architekturen, die öffentlich reviewed werden — und mehr Menschen, die den Namen des Projekts sagen können, ohne einen Nebensatz anzuhängen.

Also — ausprobieren, kaputt machen, mitdiskutieren:

curl -fsSL https://wombat-cli.dev/install.sh | sh
pip install wafpass-core

Das Framework findest du unter www.wombat-gov.dev, den Quellcode auf GitHub, und jede Entscheidung beginnt als RFC, den jeder aufmachen kann.

WAF++ war nie eine schlechte Idee. Es war eine gute Idee mit einem Namen, der ständig im Weg stand.

Willkommen im Bau.

On 28 October 2026, the project that started as WAF++ became Wombat.

This is not a pivot. Nothing was acquired, nothing was forked away, no strategy deck was involved. The controls, the code, the licenses, the governance model and the people are the same people who were arguing about cloud architecture in a hotel bar eleven months earlier.

What changed is the thing the community has to say out loud a hundred times a day: its name.

Where this started

It was the evening before Cloud Native Conference 2025. Tim, Sebastian and I were sitting in a hotel bar with too little power and too much to talk about — cloud architecture, sovereignty, provider lock-in, and the uncomfortable realization that the “best practices” we were all supposed to follow were mostly someone’s product roadmap with a diagram on top.

The gap was obvious: every hyperscaler has a Well-Architected Framework. None of them is neutral. None of them is owned by the people who actually build the architectures. There was no open, engineering-first, community-driven counterpart.

Two weeks later Artem joined, and — fittingly — he was also the one who came up with the first name.

Our open-source idea was never “publish a PDF and hope people cite it”. It was that the criteria themselves must be public, citable, forkable and contestable. Every control should be something you can point at in an audit, disagree with in a pull request, and improve in public.

What we actually built

A lot has happened between that bar and this post:

• February 2026 — the marketing site and the Antora documentation went live.
• 12 May 2026 — version 1.0 of the framework and of the tooling shipped, one day before Cloud Native Conference 2026 in Frankfurt.
• July 2026 — the Agentic pillar landed, taking the framework to eight pillars.
• Today — framework v1.1, WOMBATpass v1.1.0, more than 100 controls, the PASS scoring model, and governance through public RFCs.

The tooling grew with it. WOMBATpass is a CLI, a dashboard and a server, plus a GitHub Action and an MCP server. It parses Terraform and AWS CDK statically, evaluates the controls, and produces auditor-ready evidence — without needing cloud credentials.

The part of open source we got wrong

Here is the uncomfortable bit: our licenses were open from day one. Apache 2.0 for the code, CC BY 4.0 for the documentation. Our governance was open, too — every significant decision goes through a public RFC, with the reasoning attached.

And still, something was broken.

Because openness is not only a LICENSE file. It is also whether people can find you, say your name, and cite you without a footnote. And “WAF++” failed all three:

• In security conversations, WAF already means Web Application Firewall. Every single introduction started with a correction.
• The ”++” does not survive search engines, URLs, or a conference hallway. It is a programming reference that most of our audience never signed up for.
• In the wild, the project appeared as WAF++, WAF2p, waf2p and WAFpass — sometimes within the same sentence.

A community cannot own a name it has to explain first. So we treated the name like any other defect: we fixed it.

Open source is not a license you attach. It is a name people can carry.

Why a wombat?

Because it is a builder. It digs tunnels, maintains them, and connects things that would otherwise stay apart — and it does that underground, without needing applause. That is a fairly accurate description of architecture work and of a community project.

It is also practical: an animal is pronounceable in every language, findable in every search engine, and impossible to confuse with a firewall.

Wombat is not a second project next to WAF++. It is WAF++ — with a name that works. The announcement image says it better than I can: the new voice of WAF++.

What changes — the short version

• Project and framework: WAF++ → Wombat
• Tooling: WAFpass → WOMBATpass (CLI, dashboard, server, GitHub Action, MCP server)
• Command: wombat
• Website: www.wombat-gov.dev
• Installers: wombat-cli.dev

Two identifiers are migrating as well, rather than being frozen. The Antora documentation gets renamed along with the framework — with fallback routing, so existing links under /docs/wafpp/1.1.0/ keep resolving instead of breaking. And the two Python packages are being re-uploaded to PyPI under the new name. Until that migration lands, the current paths and packages keep working exactly as before.

What does not change

The things that matter, and that no rename can touch:

• Governance. RFC-driven, public, with reasoning attached. No silent updates, no vendor deciding behind closed doors.
• Licenses. Code under Apache 2.0, documentation under CC BY 4.0.
• Neutrality. No hyperscaler, no single company, no upsell.
• The substance. Eight pillars, 100+ controls, the PASS scoring model, the evidence trail.
• The people. The same team, now with more contributors than we can keep track of — which is exactly the point.

And the history is not rewritten. Older articles on this blog keep the name “WAF++”, because that is what the project was called when they were written. Removing that would be revisionism, not a rebrand.

Where we go from here

The name was the last thing that still required an explanation. Everything else is in place: an open framework, working tooling, public governance, and a release cadence that we can keep.

What comes next is less glamorous and more important: more controls, more working groups, more real architectures reviewed in public, and more people who can say the project’s name without adding a clause.

So — try it, break it, argue with it:

curl -fsSL https://wombat-cli.dev/install.sh | sh
pip install wafpass-core

The framework lives at www.wombat-gov.dev, the source on GitHub, and every decision starts as an RFC that anyone can open.

WAF++ was never a bad idea. It was a good idea with a name that kept getting in the way.

Welcome to the burrow.

I hear it everywhere. And it’s wrong.

“We have to get out of AWS.” “Azure is a security risk.” “As long as we’re with a US hyperscaler, we’re not sovereign.” I encounter these statements in architecture reviews, in compliance discussions, at conferences. They sound decisive. They feel right.

And they’re still wrong.

Not because the desire for independence is misguided. That desire is legitimate and important. But because exit and sovereignty are two completely different things — which our industry constantly conflates.

“Those who don’t know what they have cannot know what they depend on. And those who don’t know that don’t make sovereign decisions — no matter where they migrate.”

WAF++ Sovereign Pillar · SOV-010

Exit without visibility is not a step toward sovereignty. It is a step toward a new dependency — one that you now have to operate yourself, without the managed-service depth of a hyperscaler, without dedicated teams, and without the infrastructure expertise these companies have built up over decades.

What really happens during an exit

Let’s be concrete. Technically, an exit is possible — that’s undisputed. Kubernetes runs everywhere. Terraform abstracts providers. The open-source ecosystem with OpenStack, Ceph, and Cilium is mature.

But when you exit RDS, someone has to operate PostgreSQL HA themselves. Failover, backups, security patches — who does that at 3am? When you exit S3, you need an object storage team. When you exit CloudFront, you build your own CDN logic. When you exit IAM, you need your own PKI.

These are not theoretical problems. They are operational realities that become visible exactly when something breaks — and usually too late.

From the field: A European government agency worked for 3 years on an AWS exit. Afterward, they found that 60% of the original compliance requirements were still not met by the new on-premises solution. The problem was never the provider. It was the missing governance framework — which was still missing after the exit.

That’s not an isolated case. It’s the pattern. Without inventory, without controls, and without documented dependencies, you trade one known dependency for several unknown ones. That’s not more sovereignty — that’s more complexity with less oversight.

Sovereignty is not a question of the provider. It is a question of visibility.

What sovereignty really means

Here is the thesis that WAF++ represents — and it’s uncomfortable because it means more work than a migration project:

Sovereignty is a continuous system property, not a destination.

It doesn’t arise from canceling a contract. It arises from knowing at any point in time what you have, why you use it, how you depend on it — and how you can get out if you must.

That means: Inventory — every resource, every dependency, every proprietary service documented. Controls — governance requirements defined as YAML, machine-checked, versioned. Portability as a decision — not every workload must be portable, but every decision about it must be conscious. And public transparency — decisions, votes, and roadmap changes visible to everyone.

When all of this is in place, you are sovereign. Regardless of whether you run on AWS, Azure, GCP, Hetzner, or your own hardware.

And yes: that’s harder than an exit. An exit ends. Governance never ends. But that is exactly the point — sovereignty is not a project. It is an attitude.

When exit is still the right answer

WAF++ does not fundamentally reject exit. There are legitimate scenarios:

Exit makes sense when data localization laws explicitly exclude US companies as processors. When the organization has the operational maturity to permanently self-operate managed services. When a complete cost-benefit analysis supports the move.

Exit is the wrong answer when it happens as a reaction to a headline. When no inventory exists. When no dedicated platform team is standing by. And when exit serves as a substitute for governance — as if a provider change were the same as a governance framework.

The decisive question is not: “Where do we run?” The question is: “Do we know what we’re doing — and can we prove it?”

What this has to do with the Cloud Native Conference

On May 13th in Frankfurt, this exact question will land on stage. The panel discussion “Does sovereignty eat cloud-native for breakfast?” brings two positions head to head: the cloud-native enthusiast who says innovation needs the big hyperscalers, and the exit advocate who says their path was without alternative.

WAF++ is neither side. We are the framework that enables the community to answer this question for themselves — with evidence, not ideology.

In the Deep Dive (14:20) we’ll show live: What does a WAF++ control look like? How does Terraform run as a policy engine? How does an organization get from “no idea where we stand” to “fully auditable” in 90 days — without migrating a single workload?

If that interests you: come by. Bring your hardest questions.

Ich höre es überall. Und es stimmt nicht.

„Wir müssen aus AWS raus.” „Azure ist ein Sicherheitsrisiko.” „Solange wir bei einem US-Hyperscaler sind, sind wir nicht souverän.” Diese Sätze begegnen mir in Architecture Reviews, in Compliance-Gesprächen, auf Konferenzen. Sie klingen entschlossen. Sie fühlen sich richtig an.

Und sie sind trotzdem falsch.

Nicht weil der Wunsch nach Unabhängigkeit falsch wäre. Der ist richtig und wichtig. Sondern weil Exit und Souveränität zwei völlig verschiedene Dinge sind — die in unserer Branche ständig verwechselt werden.

„Wer nicht weiß, was er hat, kann nicht wissen, wovon er abhängig ist. Und wer das nicht weiß, trifft keine souveräne Entscheidung — egal wohin er migriert.”

WAF++ Sovereign Pillar · SOV-010

Exit ohne Sichtbarkeit ist kein Schritt in Richtung Souveränität. Es ist ein Schritt in Richtung einer neuen Abhängigkeit — die man diesmal selbst betreiben muss, ohne die Managed-Service-Tiefe eines Hyperscalers, ohne dedizierte Teams und ohne die Infrastruktur-Expertise, die sich diese Unternehmen über Jahrzehnte aufgebaut haben.

Was beim Exit wirklich passiert

Seien wir konkret. Technisch ist Exit möglich — das ist unbestritten. Kubernetes läuft überall. Terraform abstrahiert Anbieter. Das Open-Source-Ökosystem mit OpenStack, Ceph und Cilium ist ausgereift.

Aber wenn du aus RDS aussteigst, muss jemand PostgreSQL-HA selbst betreiben. Failover, Backups, Security-Patches — wer macht das um 3 Uhr nachts? Wenn du aus S3 aussteigst, brauchst du ein Objektspeicher-Team. Wenn du aus CloudFront aussteigst, baust du eigene CDN-Logik. Wenn du aus IAM aussteigst, brauchst du eine eigene PKI.

Das sind keine theoretischen Probleme. Das sind operative Realitäten, die genau dann sichtbar werden, wenn etwas kaputtgeht — und dann meistens zu spät.

Aus der Praxis: Eine europäische Behörde arbeitete 3 Jahre an einem AWS-Exit. Danach stellte sie fest: 60 % der ursprünglichen Compliance-Anforderungen waren durch die neue On-Premises-Lösung immer noch nicht erfüllt. Das Problem war nie der Anbieter. Es war das fehlende Governance-Framework — das auch nach dem Exit fehlte.

Das ist kein Einzelfall. Es ist das Muster. Ohne Inventar, ohne Controls und ohne dokumentierte Abhängigkeiten tauscht man eine bekannte Abhängigkeit gegen mehrere unbekannte. Das ist nicht mehr Souveränität — das ist mehr Komplexität mit weniger Überblick.

Souveränität ist keine Frage des Anbieters. Es ist eine Frage der Sichtbarkeit.

Was Souveränität wirklich bedeutet

Hier ist die These, die WAF++ vertritt — und sie ist unbequem, weil sie mehr Arbeit bedeutet als ein Migrations-Projekt:

Souveränität ist eine kontinuierliche Systemeigenschaft, keine Destination.

Sie entsteht nicht dadurch, dass du einen Vertrag kündigst. Sie entsteht dadurch, dass du zu jedem Zeitpunkt weißt, was du hast, warum du es nutzt, wie du davon abhängig bist — und wie du rauskommst, wenn du musst.

Das bedeutet: Inventar — jede Ressource, jede Abhängigkeit, jeder proprietäre Dienst dokumentiert. Controls — Governance-Anforderungen als YAML definiert, maschinell geprüft, versioniert. Portabilität als Entscheidung — nicht jeder Workload muss portierbar sein, aber jede Entscheidung darüber muss bewusst sein. Und öffentliche Transparenz — Entscheidungen, Votes, Roadmap-Änderungen sichtbar für alle.

Wenn das alles vorhanden ist, bist du souverän. Egal ob du bei AWS, Azure, GCP, Hetzner oder auf eigener Hardware läufst.

Und ja: Das ist anstrengender als ein Exit. Ein Exit endet. Governance endet nie. Aber genau das ist der Punkt — Souveränität ist kein Projekt. Es ist eine Haltung.

Wann Exit trotzdem richtig ist

WAF++ lehnt Exit nicht grundsätzlich ab. Es gibt legitime Szenarien:

Exit macht Sinn, wenn Datenlokalisierungsgesetze US-Unternehmen als Processor explizit ausschließen. Wenn die eigene Organisation die operative Reife hat, Managed Services dauerhaft selbst zu betreiben. Wenn eine vollständige Kosten-Nutzen-Analyse das unterstützt.

Exit ist die falsche Antwort, wenn er als Reaktion auf eine Schlagzeile passiert. Wenn kein Inventar existiert. Wenn kein dediziertes Plattform-Team bereitsteht. Und wenn Exit als Ersatz für Governance dient — als wäre ein Anbieter-Wechsel dasselbe wie ein Governance-Framework.

Die entscheidende Frage ist nicht: „Wo laufen wir?” Die Frage ist: „Wissen wir, was wir tun — und können wir es beweisen?”

Was das mit der Cloud Native Conference zu tun hat

Am 13. Mai in Frankfurt wird genau diese Frage auf der Bühne landen. Das Streitgespräch „Frisst Souveränität Cloud-Native zum Frühstück?” bringt zwei Positionen direkt gegeneinander: Den Cloud-Native-Enthusiasten, der sagt, Innovation braucht die großen Hyperscaler. Den Aussteiger, der sagt, sein Weg war alternativlos.

WAF++ ist keine der beiden Seiten. Wir sind das Framework, das die Community in die Lage versetzt, diese Frage für sich selbst zu beantworten — mit Evidence, nicht mit Ideologie.

Im Deep Dive (14:20) zeigen wir live: Wie sieht ein WAF++ Control aus? Wie läuft Terraform als Policy-Engine? Wie kommt eine Organisation in 90 Tagen von „keine Ahnung wo wir stehen” zu „vollständig auditierbar” — ohne einen einzigen Workload zu migrieren?

Wenn dich das interessiert: Komm vorbei. Bring deine schwersten Fragen mit.

WAF++ was built for exactly that moment.

The Gap the Big Frameworks Leave Open

AWS Well-Architected, Azure CAF, GCP Framework — these are genuinely useful tools. They provide concrete, product-aligned guidance within their own ecosystems. But they share a structural limitation: they are built by vendors, for vendors. Vendor-neutrality, exit capability, regulatory sovereignty — these concerns are either absent or treated as afterthoughts.

CNCF gets closer. Its governance model, working group structure, and commitment to open standards make it the spiritual ancestor of WAF++. But CNCF does not offer a single, consistent assessment framework. There is no scoring model. No evidence-based audit trail. No way to take a platform team through a structured review that ends with traceable, defensible decisions.

Traceability instead of gut feeling. Criteria instead of buzzwords.

That is the gap WAF++ fills. Not by replacing AWS WA or CNCF — but by sitting above them as a vendor-neutral assessment lens. A way to structure decisions, document trade-offs, and make governance an engineering artifact, not a slide deck.

Seven Pillars, Two Live, One Vision

WAF++ structures cloud architecture evaluation across seven pillars: Security, Cost Optimization, Performance Efficiency, Reliability, Operational Excellence, Sustainability, and Sovereign. Each pillar is designed to ask the questions that provider frameworks skip — including guidance on evidence artifacts, scoring logic, and regulatory alignment.

As of today, two pillars are fully active:

• Pillar 2 — Cost Optimization: FinOps principles, cost transparency, budget guardrails, and right-sizing guidance.
• Pillar 7 — Sovereign: Data sovereignty, vendor lock-in, exit capability, and regulatory compliance. The pillar that no major provider framework treats as first-class.

The remaining five pillars are planned and in varying stages of design. The project is intentionally lean: ship what is real, not what looks complete on a roadmap slide.

The governance model is documented. The Antora-based technical documentation is partially built. And on May 12th — one day before the Cloud Native Conference 2026 in Frankfurt — WAF++ version 1 of both the marketing platform and the documentation goes live.

Static-First, Deterministic, and Deliberately Constrained

One of the more interesting engineering decisions in WAF++ is the platform itself. The website and documentation are built on a strict static-first architecture: Jekyll for the public web, Antora for technical documentation, GitHub Pages for hosting. No runtime API dependencies. No plugin magic. No dynamic rendering.

This is not a cost-cutting measure — it is a philosophical choice. Every build is reproducible. Every page is auditable. GitHub contributor data is fetched at build time and cached as local JSON. SEO metadata is defined explicitly in frontmatter on every article, never inferred from theme defaults.

The principle runs throughout: explicit configuration over implicit magic. It is the same principle that drives the governance framework itself — if you cannot show your work, your decision is not traceable.

Multilingual support (English and German) follows the same logic. No i18n plugin that adds build complexity and unpredictable caching. Instead: a clean parallel structure under /de/ that gives full SEO control and deterministic output on every build.

YAML as a Control Language

The governance framework at the heart of WAF++ is defined declaratively in YAML. Each control has an ID, a pillar, a severity level, and a set of typed checks that can be validated by a policy engine — currently Terraform.

id: SOV-010
pillar: sovereign
severity: high
type: [governance, configuration]
checks:
  - id: tf.region_pinned
    engine: terraform

This is what separates WAF++ from a collection of best-practice documents. The controls are machine-checkable. Evidence types are typed — architecture diagrams, IaC, config exports. The engine abstraction means you can validate against multiple tools without rewriting the control definition.

The community governance model mirrors this transparency: a Technical Steering Committee, Maintainer teams, Working Groups, and an RFC process. Every decision is documented publicly. Every role has a defined term and clear responsibilities.

Cloud Native Conference 2026 · Frankfurt · May 13, 2026

Frankfurt Is a Starting Line, Not a Finish

The Cloud Native Conference 2026 in Frankfurt — May 13th — lands one day after the WAF++ v1 release. That timing is not accidental. The conference is the first major moment for WAF++ to meet the community it was built for: platform engineers, cloud architects, and the teams who actually have to make governance decisions at scale.

The goal is not to arrive with a polished product and a demo. The goal is to arrive with something real, open, and ready for review. The pillars are not finished — and that is the point. WAF++ is designed to be built in public, shaped by the people who use it.

“If you think governance is someone else’s problem, you haven’t been the one explaining a $400,000 egress bill to a CFO.”

Between now and May 12th, the team is focused on three things: finalizing the v1 documentation structure in Antora, completing the Sovereign pillar reference content, and hardening the governance YAML controls to the point where they can be used as a real audit baseline.

If you are attending Cloud Native Conference 2026 in Frankfurt, the WAF++ team will be there. Not with a vendor booth and branded swag — but with working software, open RFCs, and a genuine interest in hearing what problems you are actually trying to solve.

The Cloud Isn’t Getting Simpler

Multi-cloud is not a future state anymore — it is operational reality for most organizations above a certain size. And as the environment grows more complex, the gap between “we have a framework” and “we can trace our decisions” grows wider.

Regulatory pressure is accelerating this. GDPR was a starting point. DORA, NIS2, and the evolving landscape of data residency requirements are making sovereignty a first-class technical concern — not just a legal one. ISO 27001 and NIST provide strong compliance foundations, but they were not designed for day-to-day cloud architecture decisions.

WAF++ is not a compliance tool. It is an engineering tool that makes compliance tractable. It gives platform teams the shared language, scoring model, and evidence framework to answer the hard questions before an auditor asks them.

Everything Is in the Open

WAF++ is open source. The framework, the controls, the governance model, and the platform are all public. Contributions are not just welcome — they are the point. Working Groups are forming around each pillar. The RFC process is live.

If you have operated cloud infrastructure at scale, dealt with a vendor lock-in situation, tried to explain cost anomalies to non-technical stakeholders, or built a platform that needed to be compliant across multiple regulatory regimes — you have knowledge that belongs in WAF++.

Website: waf2p.dev Repository: github.com/waf2p Documentation: Live May 12, 2026 Cloud Native Conference 2026, Frankfurt — May 13, 2026

WAF++ is an open-source initiative operating under the Maintainer model, with a strategic orientation toward Foundation or CNCF-adjacent structures. Code: Apache 2.0 · Documentation & Content: CC BY 4.0

WAF++ wurde für genau diesen Moment gebaut.

Die Lücke, die die großen Frameworks offenlassen

AWS Well-Architected, Azure CAF, GCP Framework — das sind echte, nützliche Werkzeuge. Sie bieten konkrete, produktnahe Orientierung innerhalb ihrer eigenen Ökosysteme. Aber sie teilen eine strukturelle Einschränkung: Sie wurden von Herstellern für Hersteller gebaut. Vendor-Neutralität, Exit-Fähigkeit, regulatorische Souveränität — diese Themen fehlen entweder ganz oder werden als Randnotiz behandelt.

CNCF kommt dem näher. Das Governance-Modell, die Working-Group-Struktur und das Bekenntnis zu offenen Standards machen CNCF zum geistigen Vorläufer von WAF++. Aber CNCF bietet kein einheitliches, konsistentes Assessment-Framework. Es gibt kein Scoring-Modell. Keine nachvollziehbare Beweiskette. Keinen strukturierten Review-Prozess, der mit nachweisbaren, verteidigbaren Entscheidungen endet.

Nachvollziehbarkeit statt Bauchgefühl. Kriterien statt Buzzwords.

Das ist die Lücke, die WAF++ schließt. Nicht indem es AWS WA oder CNCF ersetzt — sondern indem es als vendor-neutrale Assessment-Schicht darüber liegt. Ein Werkzeug, um Entscheidungen zu strukturieren, Trade-offs zu dokumentieren und Governance zu einem Engineering-Artefakt zu machen — nicht zu einer PowerPoint-Folie.

Sieben Säulen, zwei aktiv, eine Vision

WAF++ strukturiert die Bewertung von Cloud-Architekturen über sieben Säulen: Security, Cost Optimization, Performance Efficiency, Reliability, Operational Excellence, Sustainability und Sovereign. Jede Säule ist darauf ausgelegt, die Fragen zu stellen, die Provider-Frameworks überspringen — inklusive Guidance zu Evidence-Artefakten, Scoring-Logik und regulatorischer Ausrichtung.

Aktuell sind zwei Säulen vollständig aktiv:

• Säule 2 — Cost Optimization: FinOps-Prinzipien, Kostentransparenz, Budget-Guardrails und Right-Sizing-Empfehlungen.
• Säule 7 — Sovereign: Datensouveränität, Vendor-Lock-in, Exit-Fähigkeit und regulatorische Compliance. Die Säule, die kein großes Provider-Framework als erstklassiges Thema behandelt.

Die verbleibenden fünf Säulen sind geplant und befinden sich in unterschiedlichen Design-Phasen. Das Projekt ist bewusst lean ausgerichtet: Liefern, was real ist — nicht, was auf einer Roadmap-Folie vollständig wirkt.

Das Governance-Modell ist dokumentiert. Die Antora-basierte technische Dokumentation ist teilweise fertig. Und am 12. Mai — einen Tag vor der Cloud Native Conference 2026 in Frankfurt — geht WAF++ Version 1 live: sowohl die Marketing-Plattform als auch die Dokumentation.

Static-First, deterministisch und bewusst begrenzt

Eine der interessanteren Engineering-Entscheidungen bei WAF++ betrifft die Plattform selbst. Website und Dokumentation basieren auf einer konsequenten Static-First-Architektur: Jekyll für das öffentliche Web, Antora für die technische Dokumentation, GitHub Pages für das Hosting. Keine Runtime-API-Abhängigkeiten. Kein Plugin-Magie. Kein dynamisches Rendering.

Das ist keine Kostensparmaßnahme — es ist eine bewusste philosophische Entscheidung. Jeder Build ist reproduzierbar. Jede Seite ist auditierbar. GitHub-Contributor-Daten werden zur Build-Zeit abgerufen und als lokales JSON gecacht. SEO-Metadaten werden in jedem Artikel explizit im Frontmatter definiert — niemals vom Theme-Standard abgeleitet.

Das Prinzip zieht sich durch das gesamte Projekt: explizite Konfiguration statt impliziter Magie. Dasselbe Prinzip, das das Governance-Framework antreibt — wer seine Arbeit nicht zeigen kann, dessen Entscheidung ist nicht nachvollziehbar.

Die mehrsprachige Unterstützung (Englisch und Deutsch) folgt derselben Logik. Kein i18n-Plugin, das Build-Komplexität und unvorhersehbares Caching erzeugt. Stattdessen: eine saubere Parallelstruktur unter /de/, die volle SEO-Kontrolle und deterministischen Output bei jedem Build liefert.

YAML als Steuerungssprache

Das Governance-Framework im Kern von WAF++ ist deklarativ in YAML definiert. Jedes Control hat eine ID, eine Säule, einen Schweregrad und eine Menge typisierter Checks, die von einer Policy-Engine validiert werden können — aktuell Terraform.

id: SOV-010
pillar: sovereign
severity: high
type: [governance, configuration]
checks:
  - id: tf.region_pinned
    engine: terraform

Das ist es, was WAF++ von einer Sammlung von Best-Practice-Dokumenten unterscheidet. Die Controls sind maschinell prüfbar. Evidence-Typen sind typisiert — Architekturdiagramme, IaC, Config-Exports. Die Engine-Abstraktion ermöglicht die Validierung gegen mehrere Tools, ohne die Control-Definition neu schreiben zu müssen.

Das Community-Governance-Modell spiegelt diese Transparenz wider: ein Technical Steering Committee, Maintainer-Teams, Working Groups und ein RFC-Prozess. Jede Entscheidung ist öffentlich dokumentiert. Jede Rolle hat eine definierte Amtszeit und klare Verantwortlichkeiten.

Cloud Native Conference 2026 · Frankfurt · 13. Mai 2026

Frankfurt ist eine Startlinie, kein Ziel

Die Cloud Native Conference 2026 in Frankfurt — 13. Mai — fällt einen Tag nach dem WAF++ v1-Release. Dieses Timing ist kein Zufall. Die Konferenz ist der erste große Moment, bei dem WAF++ auf die Community trifft, für die es gebaut wurde: Platform Engineers, Cloud-Architekten und die Teams, die Governance-Entscheidungen im großen Maßstab tatsächlich treffen müssen.

Das Ziel ist nicht, mit einem polierten Produkt und einer Demo anzureisen. Das Ziel ist, mit etwas Echtem, Offenem und Review-bereitem anzukommen. Die Säulen sind nicht fertig — und das ist der Punkt. WAF++ ist darauf ausgelegt, öffentlich gebaut und von den Menschen geformt zu werden, die es nutzen.

„Wer glaubt, Governance sei das Problem von jemand anderem, war noch nie derjenige, der einer CFO eine 400.000-Dollar-Egress-Rechnung erklären musste.”

Bis zum 12. Mai konzentriert sich das Team auf drei Dinge: die v1-Dokumentationsstruktur in Antora finalisieren, die Sovereign-Säulen-Referenzinhalte vervollständigen und die Governance-YAML-Controls so weit härten, dass sie als echte Audit-Baseline eingesetzt werden können.

Wer die Cloud Native Conference 2026 in Frankfurt besucht, wird das WAF++-Team dort antreffen. Nicht mit einem Vendor-Stand und gebrandeten Werbeartikeln — sondern mit funktionierender Software, offenen RFCs und echtem Interesse daran, zu hören, welche Probleme ihr tatsächlich lösen müsst.

Die Cloud wird nicht einfacher

Multi-Cloud ist kein Zukunftsszenario mehr — es ist operative Realität für die meisten Organisationen ab einer bestimmten Größe. Und je komplexer das Umfeld wird, desto größer wird die Lücke zwischen „wir haben ein Framework” und „wir können unsere Entscheidungen nachvollziehen”.

Der regulatorische Druck beschleunigt das. DSGVO war ein Anfang. DORA, NIS2 und die sich weiterentwickelnde Landschaft von Datenlokalisierungsanforderungen machen Souveränität zu einem erstklassigen technischen Anliegen — nicht nur zu einem rechtlichen. ISO 27001 und NIST bieten solide Compliance-Grundlagen, wurden aber nicht für alltägliche Cloud-Architekturentscheidungen konzipiert.

WAF++ ist kein Compliance-Tool. Es ist ein Engineering-Werkzeug, das Compliance handhabbar macht. Es gibt Platform-Teams die gemeinsame Sprache, das Scoring-Modell und das Evidence-Framework, um die schwierigen Fragen zu beantworten, bevor ein Auditor sie stellt.

Alles ist offen

WAF++ ist Open Source. Das Framework, die Controls, das Governance-Modell und die Plattform sind alle öffentlich. Beiträge sind nicht nur willkommen — sie sind der eigentliche Punkt. Working Groups bilden sich rund um jede Säule. Der RFC-Prozess ist live.

Wer Cloud-Infrastruktur im großen Maßstab betrieben hat, mit einer Vendor-Lock-in-Situation konfrontiert war, Kostenanomalen gegenüber nicht-technischen Stakeholdern erklären musste oder eine Plattform gebaut hat, die über mehrere regulatorische Regime hinweg compliant sein musste — der hat Wissen, das in WAF++ gehört.

Website: waf2p.dev Repository: github.com/waf2p Dokumentation: Live ab 12. Mai 2026 Cloud Native Conference 2026, Frankfurt — 13. Mai 2026

WAF++ ist eine Open-Source-Initiative, die nach dem Maintainer-Modell operiert und strategisch auf eine Foundation- oder CNCF-nahe Struktur ausgerichtet ist. Code: Apache 2.0 · Dokumentation & Inhalte: CC BY 4.0

Tim, Sebastian, and I were sitting in that typical hotel bar atmosphere: too loud, too expensive, not enough power outlets. But the tech talk started up the way it always does: cloud architecture, sovereignty, provider lock-in, best practices that aren’t really best practices — the kind of nerd conversation you can only have after 10pm with people who get it.

And somewhere — somewhere between “why does nobody do this properly?” and “this really should be better…” — something suddenly became clear to us:

1. There is no Well-Architected Framework that is truly open, community-driven, and grounded in practice.
2. None that actually listens to cloud practitioners.
3. None that reflects the reality of our day-to-day work.

In that moment, WAF++ was born — maybe not the name yet, but definitely the idea. And no, not from a corporate workshop or an “Architecture Steering Board” — but from a spontaneous bar session full of ideas, discussions, and honest technical frustration. A mix of “we could…”, “we should…”, and “okay, let’s actually do this.”

Day 1 After the Idea — CNC 2025

The next day, Cloud Native Conference 2025 kicked off. We played Mario Kart, attended a lot of talks — including our own — and worked through security topics and sovereignty discussions… but the word we’d been missing the night before never really came up, because it simply didn’t exist yet. Each of us had our own presentation, all technically solid, but the issue of the missing framework wouldn’t let us go.

(C) by Manuel Emme Fotografie / Vogel IT / Cloud Native Conference

That evening, at the CNC party, the conversations continued. My company even picked up a Rockstar Award for an architecture implementation — which didn’t make the evening any less nerdy. We stood there, between music, networking, and bad lighting, and kept talking about how the cloud world needs exactly this kind of framework. It turned into a long night, with early flights and breakfast options clearly not designed for people running on two hours of sleep.

The Weeks After — The Official Start

In the two weeks following the conference we kept the conversation going intensively and made a decision: we’re starting as a team of four.

Artem — who later also came up with the name — completes the founding team.

I asked him, and he was in immediately. So we planned. One session means a virtual marathon meeting of four to five hours on Saturdays. Since the kickoff we’ve had eight of those sessions already. All following the same pattern: plan, geek out, laugh. Lots of laughing. Fun matters to us. Just as much as the idea that WAF++ is being built by the community, for the community.

Today — 2026, One Hundred Days Before CNC 2026

And now? Welcome to 2026. We are roughly 100 days from Cloud Native Conference 2026 — and we have:

• the whitepaper finished
• a survey on its way
• more and more conference sessions being confirmed
• and recently: our own Antora documentation area

WAF++ is growing. The community can grow. The idea is alive.

And: you can be part of it right now.

Have a look around the site. Leave a like. Drop a comment, a suggestion — or even a PR if you want to really dive in. We will see you on 12.05.2026 in Frankfurt at Cloud Native Conference 2026. And maybe another idea will start there too — somewhere between tech talk, a drink, and an overheating laptop.

Tim, Sebastian und ich saßen in dieser typischen Hotelbar‑Atmosphäre: zu laut, zu teuer, zu wenig Steckdosen. Trotzdem begann das Fachsimpeln wie immer: Cloud‑Architektur, Souveränität, Provider‑Lock‑in, Best Practices, die eigentlich gar keine sind… eben der normale Nerd‑Talk, den man nach 22 Uhr nur mit Gleichgesinnten führen kann.

Und irgendwann — irgendwo zwischen „Warum macht das eigentlich niemand richtig?“ und „Das müsste doch besser gehen…“ — wurde uns plötzlich etwas klar:

1. Es gibt kein Well‑Architected Framework, das wirklich offen, community‑getrieben und praxisnah ist.
2. Keins, das Cloud‑Nerds zuhört.
3. Keins, das unseren Alltag abbildet.

In diesem Moment war WAF++ geboren — vielleicht noch nicht der Name, aber definitiv die Idee. Und nein, nicht aus einem Corporate‑Workshop oder einem „Architecture Steering Board“, sondern aus einer spontanen Bar‑Session voller Ideen, Diskussionen und ehrlicher technischer Frustration. Eine Mischung aus „wir könnten…“, „wir sollten…“ und „okay, lass uns das jetzt wirklich machen“.

Tag 1 nach der Idee — CNC 2025

Am nächsten Tag startete die Cloud Native Conference 2025. Wir haben Mario Kart gespielt, waren in vielen Vorträgen - auch unsere eigenen, haben uns durch Security‑Themen und Souveränitäts‑Diskussionen gehört… aber das Wort, das uns am Vorabend so gefehlt hatte, fiel eigentlich nie — weil es schlicht noch nicht existierte. Jeder von uns hatte eine eigene Präsentation, alle natürlich technisch sauber, aber die Sache mit dem fehlenden Framework ließ uns nicht los.

(C) by Manuel Emme Fotografie / Vogel IT / Cloud Native Conference

Am Abend, bei der CNC‑Party, ging es weiter. Nebenbei bekam meine Firma sogar einen Rockstar Award für eine architektonische Umsetzung — was den Abend nicht weniger nerdig machte. Wir standen da, zwischen Musik, Networking und schlechten Lichtverhältnissen, und redeten weiter darüber, dass die Cloud‑Welt genau dieses Framework braucht. Es wurde eine lange Nacht, mit frühen Flügen und Frühstücksoptionen, die eindeutig nicht für Menschen gemacht sind, die zwei Stunden oder Schlaf hatten.

Die Wochen danach — der offizielle Start

In den zwei Wochen nach der Konferenz haben wir uns intensiv ausgetauscht und entschieden: Wir starten zu viert.

Artem — der später auch die Idee für den Namen hatte — komplettiert das Gründerteam.

Ich hab ihn gefragt, und er war sofort dabei. Also haben wir geplant. Eine Session basiert auf einem virtuellen Marathon‑Meeting von vier bis fünf Stunden an Samstagen. Seit dem Kick‑off hatten wir bereits acht dieser Sessions. Alle nach dem gleichen Muster: planen, fachsimpeln, lachen. Viel lachen. Spaß ist uns wichtig. Genau wie der Gedanke, dass WAF++ von der Community für die Community entsteht.

Heute — 2026, Hundert Tage vor der CNC 2026

Und jetzt? Willkommen im Jahr 2026. Wir sind rund 100 Tage vor der Cloud Native Conference 2026 — und wir haben:

das Whitepaper fertig eine Umfrage auf dem Weg (URL) immer mehr Konferenz‑Sessions, die gerade bestätigt werden und seit Kurzem: unseren eigenen Antora‑Dokumentationsbereich

WAF++ wächst. Die Community kann wachsen. Die Idee lebt.

Und: Du kannst jetzt Teil davon werden.

Schau dich hier auf der Seite gerne um. Lass ein Like da. Hinterlass einen Kommentar, einen Vorschlag — oder sogar einen PR, wenn du richtig reindroppen willst. Wir sehen uns definitiv am 12.05.2026 in Frankfurt auf der Cloud Native Conference 2026. Und vielleicht beginnt auch dort wieder eine Idee, irgendwo zwischen Fachsimpeln, einem Drink und einem überhitzten Laptop.

Why WAF++?

WAF++ is a community-driven, cloud-agnostic framework aimed at architects, engineers, and organisations building modern cloud architectures without binding themselves to a single vendor. The seven pillars of the framework cover all the relevant areas — from security and operational excellence through to compliance and sovereignty.

As an open project, WAF++ stands for transparency, neutrality, and a strong community that develops building blocks, patterns, and reference architectures together.

The Seven Pillars at a Glance

1. Security — Vendor-independent security principles
2. Cost Optimization — Transparent and traceable cost models
3. Performance Efficiency — Cross-cloud scalability
4. Reliability — Resilience through patterns, not services
5. Operational Excellence — Unified operational processes across all clouds
6. Sustainability — Measurable efficiency and ecological responsibility
7. Compliance, Governance & Data Sovereignty — The European focus

Each pillar is backed by best practices, building blocks, and concrete evaluation criteria.

What Makes WAF++ Different?

While existing frameworks are heavily tailored to their respective cloud providers, WAF++ focuses on what architects actually need: Independent principles, neutral architecture patterns, and a traceable evaluation baseline.

WAF++ is not a vendor’s marketing tool — it is a tool of the community, for the community.

What Comes Next?

The roadmap for version 1.0 is clear: a solid technical foundation, first reference architectures, a public maturity model, and a structured certification path for architects. With growing participation from the cloud native community, a genuine European counterpart to proprietary WAF offerings is taking shape — step by step.

If you are interested in multi-cloud, sovereignty, or modern architecture principles, now is the perfect time to get involved with WAF++. Start a discussion, open an issue — or bring your own idea to the table!

WAF++ is open, vendor-neutral, and evolves with every new voice that joins.

Cloud-Architekturen stehen heute unter enormem Druck: steigende regulatorische Anforderungen, wachsender Bedarf an Multi-Cloud-Flexibilität und der Wunsch nach Unabhängigkeit von einzelnen Anbietern. Während AWS, Azure und GCP ihre eigenen Well-Architected Frameworks anbieten, fehlt bislang ein neutraler, europäisch geprägter Ansatz. Genau hier setzt WAF++ an.

Warum WAF++?

WAF++ ist ein community-getriebenes, cloud-agnostisches Framework, das sich an Architekten, Engineers und Organisationen richtet, die moderne Cloud-Architekturen entwickeln möchten – ohne sich an einen Anbieter zu binden. Die sieben Säulen des Frameworks decken alle relevanten Bereiche ab: von Security über Operational Excellence bis zu Compliance und Souveränität.

Als offenes Projekt steht WAF++ für Transparenz, Neutralität und eine starke Community, die gemeinsam Bausteine, Muster und Referenzarchitekturen entwickelt.

Die sieben Säulen auf einen Blick

1. Security – Anbieterunabhängige Sicherheitsprinzipien
2. Cost Optimization – Transparente und nachvollziehbare Kostenmodelle
3. Performance Efficiency – Cloud-übergreifende Skalierbarkeit
4. Reliability – Resilienz durch Muster statt Services
5. Operational Excellence – Einheitliche Betriebsprozesse über alle Clouds
6. Sustainability – Messbare Effizienz und ökologische Verantwortung
7. Compliance, Governance & Data Sovereignty – Der europäische Schwerpunkt

Jede Säule wird durch Best Practices, Bausteine und konkrete Bewertungskriterien ergänzt.

Was macht WAF++ besonders?

Während bestehende Frameworks stark auf die jeweiligen Cloud-Provider zugeschnitten sind, konzentriert sich WAF++ auf das, was Architekten wirklich brauchen:
Unabhängige Prinzipien, neutrale Architekturmuster und eine nachvollziehbare Bewertungsgrundlage.

WAF++ ist kein Marketingtool eines Anbieters – sondern ein Werkzeug der Community für die Community.

Was kommt als Nächstes?

Die Roadmap für Version 1.0 ist klar: ein technisches Grundgerüst, erste Referenzarchitekturen, ein öffentliches Maturity Model und ein strukturierter Zertifizierungspfad für Architekten.
Mit wachsender Beteiligung aus der Cloud Native Community entsteht Schritt für Schritt ein echtes europäisches Gegenstück zu proprietären WAF-Angeboten.

Wenn du dich für Multi-Cloud, Souveränität oder moderne Architekturprinzipien interessierst, ist jetzt der perfekte Zeitpunkt, bei WAF++ mitzumachen.
Starte eine Diskussion, öffne ein Issue – oder bring eine eigene Idee ein!

WAF++ ist offen, vendor-neutral und entwickelt sich mit jeder neuen Stimme weiter.