What is Yggy?¶
Modern infrastructure spans several clouds, private data centres and edge sites, each with its own configuration language, protocols and security policy. Keeping connectivity coherent across that landscape is where most of the effort goes — and where documentation quietly falls out of step with reality.
Yggy inverts the order. You write an abstract connectivity descriptor that says what should be able to talk to what, and under which constraints. That descriptor becomes the source of truth, and Yggy renders it into the platform-specific configuration each provider needs.
The Yggy philosophy
The descriptor IS the documentation. The documentation IS the action.
What Yggy gives you¶
-
Descriptor-driven model
Network resources, security policy and connectivity intent expressed as abstract objects, independent of any single provider.
-
One model, many platforms
A single vocabulary for Azure VNets and NSGs, Google VPC and firewalls, Palo Alto, and OpenShift OVN network policies.
-
Intent-based
State the outcome you need — reachability, isolation, availability — and let the system work out the configuration that satisfies it.
-
Auditable by construction
Every change is a versioned change to the descriptor, so it is traceable and reversible rather than reconstructed after the fact.
-
Pluggable providers
New infrastructure types arrive as provider modules. The core model does not change when the estate does.
-
Built to be integrated
A modular Quarkus API designed to sit behind Kratix, Humanitec, Backstage, Terraform and similar orchestration tooling.
How it fits together¶
The descriptor is submitted, validated against the model, resolved against the infrastructure it targets, and then translated per provider. Change flow follows a single change through each of those stages.
Principles¶
- Declarative over imperative — describe what you want, not how to configure it.
- Infrastructure independence — one descriptor is designed to hold across Azure, GCP, Palo Alto and OVN.
- Single source of truth — the descriptor stays current because it is the configuration.
- Full auditability — every change is versioned, traceable and rollback-ready.
- Pluggable architecture — add providers without touching the core.
Where to go next¶
-
Understanding Yggy
Why Yggy? — the problem, and the case for declaring connectivity.
Core concepts — descriptors, intent, topology.
-
Model objects
Infrastructure model v1 — targets, landing zones, zones, subnets.
Infrastructure model v2 — the domain and perimeter model being introduced.
Application model v1 — components, dependencies, services.
-
System design
Architecture — services, storage and integration points.
Change flow — from submission to deployed configuration.
What this release contains
These pages describe the architecture Yggy is built towards. The published code is the v1 codebase in aud/: the model and data libraries, one provider integration (Azure network security groups), and two Quarkus services. No orchestrator integrations ship yet. See the scope note on Architecture for detail.
Start with the problem¶
Ten minutes on why declarative connectivity is worth the change of habit is the fastest way to judge whether Yggy fits your estate.