Skip to main content

Platform Overview

Platform Overview​

Styrmin is an application platform that manages the full lifecycle of your infrastructure automation stack β€” Infrahub, Ansible, Grafana, Prometheus, and the tooling around them β€” as one system, not one application at a time.

For the framing of why that matters and how it compares to ArgoCD, Flux, and manual Helm, see Why Styrmin?. This page focuses on how the platform works and the vocabulary you'll see across the docs, the GraphQL API, the SDK, and the CLI.

What the platform does​

Once Styrmin is running on a Kubernetes cluster and you've loaded a driver for an application, three things fundamentally change:

  1. Deploying applications becomes simple. Pick a driver, an environment, and a version β€” Styrmin handles the Kubernetes-specific configuration (storage classes, ingress, version mapping). No need to learn each chart's value schema.
  2. Operating them becomes safe and repeatable. Day-2 operations (backups, upgrades, restores) run through driver-defined procedures. The "right way" to back up Neo4j or to upgrade Infrahub is encoded in the driver, not in a tribal-knowledge runbook.
  3. The full stack can be managed as one system. Group applications into environments. Back up an environment in a single operation. Clone an environment β€” production data and all β€” to test upgrades safely. Connectivity between applications is environment-aware, so a cloned environment is self-contained.

Kubernetes is the underlying infrastructure layer. You will not interact with kubectl to run day-to-day operations β€” though you can, and Styrmin does not change how applications expose their APIs or accept traffic from external systems.

How the pieces fit together​

   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”   GraphQL   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”    recorded intent     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ CLI / UI β”‚ ──────────► β”‚ Server β”‚ ─────────────────────► β”‚ Agent β”‚
β”‚ / SDK β”‚ β”‚ (Python) β”‚ Prefect flows + β”‚ (in β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”˜ StyrminDeployment β”‚ clusterβ”‚
β”‚ CRD β”‚ ) β”‚
β–Ό β””β”€β”€β”€β”¬β”€β”€β”€β”€β”˜
PostgreSQL β”‚
β–Ό
Kubernetes
resources
  • The server owns the database and the public GraphQL API. It is the source of truth for what should be running.
  • The agent runs inside the target cluster. It picks up recorded intent (Prefect flows and StyrminDeployment CRDs) and reconciles the cluster to match. There is one agent per cluster.
  • A status reporter inside the agent continuously posts observed pod and deployment state back to the server, so the API and UI always reflect what is actually running.
  • The CLI (styrminctl), the SDK (styrmin-sdk), and the frontend are all clients of the same GraphQL API.

For the prescriptive principles behind this design, see the Styrmin Constitution.

Core concepts​

The vocabulary below is canonical: these terms show up unchanged in the GraphQL schema, the SDK, the CLI, the UI, and the rest of these docs.

Application Driver​

An Application Driver is a versioned specification that tells Styrmin how to deploy, configure, back up, and upgrade a given application. One driver per application; without one, Styrmin doesn't know how to handle the app.

Read more in What is an Application Driver?.

Cluster​

A Cluster is a Kubernetes cluster that Styrmin manages. Cluster-level settings (storage classes, ingress, …) are configured once and inherited by every application deployed on it.

Styrmin currently supports one cluster at a time; multi-cluster is on the roadmap.

Environment​

An Environment is a named slice of a cluster β€” dev, staging, prod, team-a. Environments group applications that share a lifecycle and a backup storage location. Backup, upgrade, and clone operations can target an entire environment at once.

Cluster ─┬─ Environment "dev"      ─── Deployment "infrahub-dev"
β”‚ └─ Deployment "semaphore-dev"
└─ Environment "staging" ─── Deployment "infrahub-staging"

Deployment​

A Deployment is an application deployed in a specific environment.

User actions and hooks​

Drivers attach Python actions to lifecycle hooks β€” pre/core/post slots for setup, upgrade, backup, etc. Actions run inside Prefect flows on the agent, and have access to a set of built-in primitives (stop_component, start_component, execute_commands, upgrade_deployment_version, …). This is how Styrmin encodes a real-world upgrade procedure β€” stop workers, run migrations, restart, verify β€” as a repeatable, driver-defined sequence rather than a human-executed runbook.

What you'll do next​