The self-hosted control plane
for your entire stack.

Declarative workflows, pluggable integrations, and surfaces that extend every edge — on your infrastructure, under your control.

Get started Star on GitHub

bash

$ yggdrasil init
✓ Postgres provisioned
✓ core engine up
✓ adapters registered
control plane ready. next: yggdrasil apply -f workflow.yaml

A catalog shows your systems. Yggdrasil operates them.

Not a pretty layer over your infra. The control plane that actually executes — declarative, versioned and auditable.

What it is

Four capabilities, one control plane.

Everything is a manifest. Everything is versioned. Everything runs on your infra.

Manifest-first

Describe workflows, integrations and teams as versioned manifests. apply, diff, rollback — real GitOps, with history and dry-run.

Workflow execution

Dispatch and track runs (run, ops, logs). Reactors respond to your domain events. The engine does the work — it doesn't just draw the diagram.

Pluggable integrations

Installable adapters in a family → type → instance model. yggdrasil install <repo> and the new system talks to every other one.

Surfaces on every edge

Extend any integration — or the core engine itself — with a new edge: a dashboard, an API, an MCP server, a bot. It doesn't have to be a UI.

How it works

Manifests go in. The real world moves.

The CLI drives; the core engine holds the authority; adapters touch your systems; surfaces extend the edges.

you CLI / Manifests apply · run · install

authority Core engine versioned manifests · runs · auth

runtime Integration adapters HTTP · or message queue

your world Your systems cloud · payments · observability

Self-hosted by design. yggdrasil init brings up Postgres, the core engine and adapters on your cluster. Nothing leaves your boundary.

Explicit contract. Every adapter publishes what it can do — capabilities, schemas and version. The core validates before it executes.

Transport your way. HTTP by default; a message queue when you need one. Same adapter, no rewrite.

Integrations

Connect everything. Compose like Lego.

Each integration is an independent adapter in a family → type → instance model. It declares what it can do, installs with one command, and swaps providers without touching your workflow — AWS for GCP, and the YAML stays the same.

$ yggdrasil install dakasa-yggdrasil/integration-grafana

Cloud & Infra

AWSsecrets · resources

GCPsecret manager

Kubernetesworkloads

Observability

Grafanadashboards

Lokilogs (LogQL)

Prometheusmetrics

Payments

Stripeglobal billing

EFI PixPix / BACEN

NFe.iofiscal invoices

Communication & Workforce

Slackreactors · notify

Google Workspacedirectory

GitHubrepos · deploy

Data & Platform

database-adminpostgres-plane

schema-migrationsgoose

secrets-managementaws · gcp

RabbitMQtopology · runtime

yggdrasil-selfthe core via API

Missing yours? The integration contract is public and there's an official template — yggdrasil new integration <name> and you've got an adapter running.

Surfaces

Extend every edge of the platform.

A surface is an edge — an extension that plugs into an integration, or into the core engine itself. It's how Yggdrasil grows new reach. And it doesn't have to be a UI.

Any shape

A dashboard, an API, an MCP server, a bot, a webhook edge. The form is free — what's fixed are the invariants it has to hold.

Attaches anywhere

Extend a specific integration's reach, or hang a brand-new edge directly off the core engine. Same contract either way.

Invariants, not chrome

Auth via the platform session (never re-implemented), backend-agnostic, multi-tenant, federable, and no business authority.

$ yggdrasil new surface acme-ops --owner acme

Scaffold from the official template and the surface is born wired into the platform — authenticated, multi-tenant and federable. No re-implementing auth, no hardcoded cloud.

The command line

One binary. The entire lifecycle.

No clicking through ten screens. From bootstrap to rollback, all in the CLI — scriptable, versionable, auditable.

init · login --totp — bring it up and authenticate (with MFA)
apply · diff · get · describe — manifests
run · ops · logs — execution and observation
rollback · delete — undo safely
install · new — integrations and surfaces
update — the CLI updates itself

~/infra

$ yggdrasil login --server https://cp.acme.dev --totp 481920
✓ session active as giovanni

$ yggdrasil apply -f onboarding.yaml --dry-run
~ workflow/onboarding  v3 → v4  (no effects)

$ yggdrasil run onboarding --input user=ana
▸ run r-9f2a dispatched

$ yggdrasil ops get r-9f2a
● succeeded  · 6 steps · 2.1s

Why Yggdrasil

More than a service catalog.

Cataloging your systems is half the problem — the other half is operating them, safely and with history. That's where a control plane comes in.

Capability	Yggdrasil	Catalog / portal	Closed SaaS
Self-hosted, your data on your boundary	✓	✓	✗
Executes workflows (not just catalogs)	✓	partial	varies
Integration runtime (installs adapters)	✓	✗	✗
Surfaces on every edge	✓	plugins	✗
Declarative manifests + versioning	✓	partial	✗
Full-lifecycle CLI	✓	✗	✗
Permissive license (Apache-2.0)	✓	varies	✗

Sovereignty

Runs on your Kubernetes, your VPC, your Postgres. No customer data ever crosses a third party's boundary.

No lock-in

Apache-2.0, no per-seat billing. The contract is open; you extend it without asking anyone for permission.

Scales with you

From a local init to a multi-team control plane with queues, reactors, dozens of integrations and surfaces.

Bring up your control plane in one command.

No sign-up. No credit card. Just your cluster and the CLI.

get started

$ yggdrasil init        # standalone
$ yggdrasil init --server https://cp.acme.dev   # connect

Read the docs Download the CLI

The self-hosted control planefor your entire stack.