Soulful configuration management for the next generation

Everything to run your infrastructure — in one platform: a web UI, LDAP/OIDC sign-in, RBAC, audit, an API and MCP, certificate rotation. Describe the desired state — Soul Stack brings all your souls to it, in pull and in push.

Quick Start →Try it online

typed building blocks
one file, zero runtime
by DevOps, for DevOps
mTLS + RBAC + audit in the box

services/web/destiny/main.ymldestiny

# desired state, not a script
apply:
  - module: core.pkg
    name: nginx
    state: present
  - module: core.file
    path: /etc/nginx/nginx.conf
    template: nginx.conf.tmpl
    vars:
      workers: {{ soulprint.cpu.count }}
  - module: core.service
    name: nginx
    state: started
    enabled: true

Souls3/4 online

web-01service=nginxrunning
db-01service=postgresrunning
cache-01service=redisrunning
app-02service=nginxapplying

core.pkg nginx → changed=truecore.file /etc/nginx/nginx.conf → changed=truecore.service nginx (started) → changed=trueapp-02: reconcile ✓ · 3 changed

All included

A complete platform, not a pile of scripts

Identity, access, observability and an API are built into the core — not assembled from a zoo of tools. This set usually comes from 5–7 separate products; here it ships out of the box.

Web UIOperator UI compiled into Keeper, at /ui
LDAP/OIDC sign-inSSO and corporate directories
RBACRoles and rights down to the resource
AuditAn action log — out of the box
APIgRPC and OpenAPI over the whole control-plane
MCPA server for AI agents
Certificate rotationmTLS renews with no downtime
Secrets · VaultIntegration and masking in logs

Why it is built this way

Five decisions Soul Stack stands on

Behind each decision is a specific pain it removes: scattered tools instead of a platform, arbitrary code in config, vendor lock in the add-ons, a runtime on the host.

security-first

mTLS + RBAC + audit built in

Keeper↔Soul transport is gRPC over mTLS. RBAC, an audit log and Vault integration are part of the core, not a paid add-on. Secrets are masked on output and never hit logs in the clear.

data, not code

A typed template engine

Expressions are CEL (not Turing-complete, no side effects); files render through Go text/template in strict mode. You cannot execute arbitrary code from config — config stays config.

isolation + any license

Modules-as-plugins are processes

A custom module is a separate binary over gRPC-stdio: a crashing plugin never takes the agent down, and its author picks its license. The core is BSL; the extension ecosystem is free.

one model

Pull and push — one module set

The same binary applies a Destiny both as a daemon (pull) and as a one-shot over SSH (push, no agent on the host). One implementation instead of two incompatible branches.

zero runtime

One Go binary on the host

The soul agent is a static binary. Managed hosts need no Python, no Ruby, no interpreter: core modules are native Go inside the binary. Less on the host means less drift and less attack surface.

Not mockups — this is the actual web UI

The operator web UI is compiled into Keeper and served at /ui. No separate observability product to deploy.

Soul Stack cluster overview: transport, incarnations, self-health — **Cluster overview.** Pull/push transport, covens, incarnations and self-health (keeper · redis · postgres · vault) — on one screen.

A Soul Stack run with an honest reconcile log — **Honest reconcile.** Every Destiny step — core.repo → core.pkg → core.file → core.service — with changed=true/false per host.

Orchestration, live

Reconcile right in your browser

A control-plane mini-simulation running entirely client-side: Keeper plans an incarnation, resolves secrets, renders the Destiny and brings a new node to its desired state — with an honest log.

Souls

3/3 online

web-01 service=nginxrunning

db-01 service=postgresrunning

cache-01 service=redisrunning

Reconcile log

app-02

Click “Provision node” — Keeper renders the Destiny and brings the node to its desired state.

Open the full demo →

An honest comparison

Soul Stack vs. traditional tools

Let’s compare architecture families. Mature tools carry their own trade-offs — here’s where Soul Stack took a different path.

	Push over SSH	Agent + master	Soul Stack
Runtime on host	an interpreter is required	a resident agent + language runtime	one Go binary, no interpreter
Type safety	general-purpose text templating	DSL/templates in a general-purpose language	CEL + text/template (strict) — no code execution
Transport	SSH	a custom bus / HTTPS, often a private CA	gRPC over mTLS
Delivery model	push only	mostly pull	pull and push — one module set
RBAC · audit · web UI	assembled from third-party tools	separate add-ons on top	built into the core — out of the box
Control node	stateful	stateful master + a separate database	stateless cluster (PG + Redis)

A per-family breakdown, scale figures and a “how to choose” section live in the documentation.

The model

Open core · fair-code

The product is never crippled to sell tiers: the source is open and auditable, and revenue comes from services and managed offerings on top of the open core.

Core and web UI

BSL 1.1 — source-available

keeper · soul · soulctl · soul-lint and the core modules under BSL 1.1: the source is open and available. Every release turns Apache 2.0 after two years. The exact terms of use are in the license.

SDK and plugins

Apache 2.0 — from day one

Write and ship your own modules under any license, with no strings attached from the start. The extension ecosystem belongs to the community, not to a vendor.

How it is licensed →

Put your infrastructure in order

From legacy to unified infrastructure in a couple of steps. A web UI, access, RBAC, audit and an API — in one platform, out of the box. Start small and grow without a rewrite.

Quick Start →See the demo