Compendium

Configuration-Management State DSLs Family Index

11 min read

Configuration-Management State DSLs Family Index

type: language-family-index family: config-management languages_catalogued: 25 tags: [language-reference, family-index, config-management, puppet, chef, ansible, saltstack, cfengine, nixos, talos]

Configuration-Management State DSLs — Family Index

Family overview

Configuration-management state DSLs are the class of declarative, client-side languages used to describe “what this server should look like” — the intended state of files, packages, services, users, network config, and other host-level resources, evaluated against the live system by an agent that drives convergence. The lineage starts with CFEngine 1 (Mark Burgess, 1993), originally a sysadmin tool to keep a heterogeneous Unix fleet consistent, and was reformulated under Burgess’s promise theory (CFEngine 3, 2008+) — the cleanest theoretical foundation in the family, where every resource is a “voluntary promise” of state that an autonomous agent attempts to keep. CFEngine never won the mainstream because its policy syntax was austere and steep, but it set the conceptual frame everyone else inherited: declarative, idempotent, convergent, agent-driven.

The 2005–2015 decade was the genre’s heyday — the DevOps movement demanded reproducible “infrastructure as code” on growing fleets of long-lived VMs (the “pets” half of pets-vs-cattle), and four projects fought to define how. Puppet (Luke Kanies, 2005) introduced an external Ruby-hosted DSL with a resource-graph model and a master/agent architecture; Chef (Adam Jacob, 2009) responded with a Ruby-internal DSL of “recipes” and “cookbooks” that traded declarative purity for programmer ergonomics; Salt (Thomas Hatch, 2011) built a ZeroMQ-driven event bus with YAML+Jinja state files (.sls); and Ansible (Michael DeHaan, 2012) won the long tail by being agentless — pure SSH + YAML playbooks + the Jinja2 templating layer for variable interpolation. Each had a corporate parent: Puppet → Perforce (2022), Chef → Progress Software (2020), SaltStack → VMware (2020) → Broadcom (2023), Ansible → Red Hat (2015) → IBM (2019).

By 2026 the genre is in slow decline. Containers, Kubernetes, and immutable infrastructure absorbed most of the use case: instead of mutating a long-lived server toward a desired state, you build a fresh image, ship it, and discard it. What survives is (a) Ansible for ad-hoc orchestration and small-fleet operations, where its agentless model and YAML readability remain unmatched, (b) NixOS modules for users who want full system declarative-from-scratch with mathematical purity, (c) Talos Linux machine config as the modern endpoint — a single YAML document describing an immutable, K8s-native node — and (d) niche traditionalists keeping CFEngine, OpenVox (the post-fork Puppet community), and various Ruby/Python alternatives alive.

The 2024–2025 stretch produced two visible inflection events: Perforce’s November 2024 announcement that new Puppet binaries would move to a private, EULA-gated repository — effectively closing the “open” part of Puppet — triggered the OpenVox fork (initiated by the Vox Pupuli community, first public release 2025-01-21), and Progress Software’s October 2024 announcement that Chef Infra Server (Open Source) would reach end-of-life in November 2026, pushing customers to the proprietary Chef 360 SaaS. SaltStack’s commercial future also collapsed under Broadcom’s VMware acquisition, with VMware Tanzu Salt rebranded to VCF SaltStack and the open-source community discussing soft-fork strategies. The era of “every server has Puppet on it” is essentially over.

In our deep library

None of these DSLs has a standalone deep-library note; they are all small DSLs hosted on top of more general languages catalogued elsewhere.

Cross-reference:

  • build-devops — covers build-time graph DSLs (Make, Bazel, Buck) and CI/CD declarative DSLs (GitHub Actions, GitLab CI). Distinct from this family — those describe build/deploy pipelines, not host state.
  • config-and-dsl — covers IaC infrastructure DSLs (Terraform/HCL, Pulumi, Crossplane) and config formats (Nix, Dhall, YAML, Starlark). Also distinct — those describe cloud-resource topology, not in-host state. NixOS modules straddle both notes.
  • api-description — Kubernetes manifests and CRD schemas live there as YAML-with-OpenAPI; the modern “K8s-native config” pattern overlaps Talos and Helmsman.
  • python — host language for Ansible, Pyinfra, SaltStack, Mgmt’s metaprogramming.
  • ruby — host language for Chef recipes, Itamae, Bolt task plans, rspec-puppet, InSpec.
  • bash — the language that came before all of this; still the fallback when config-management feels too heavy.

Tier 3 family table

Language / DSLFirst appearedOriginTypeStatus (2026)URL
CFEngine policy language1993 (CFE 1), 2008 (CFE 3 / promise theory)Mark Burgess (Univ. Oslo → Northern.tech)Host-state DSL (declarative, promise-theory)Active; CFEngine 3.27 LTS (2026-01-09); 18-month LTS cadencehttps://docs.cfengine.com/
Puppet manifest language (Puppet DSL)~2005Luke Kanies (Reductive Labs → Puppet Labs → Perforce 2022)Host-state DSL (resource-graph)Active commercially; Puppet Enterprise 2025.10.0 (2026-Q1); OSS effectively closed Nov 2024 — see OpenVoxhttps://www.puppet.com/docs/puppet/8/puppet_index.html
OpenVox2025-01-21 (first public release)Vox Pupuli community fork (Betadots, ATIX, et al.)Host-state DSL (Puppet-compatible)Active; community-maintained successor to OSS Puppet after Perforce’s 2024 EULA change; supports v7 + v8 brancheshttps://voxpupuli.org/
Chef recipes / Cookbooks~2009Adam Jacob, Opscode → Chef → Progress Software (2020)Host-state DSL (Ruby-internal)Mixed; Chef Infra Client 19 LTS (2025), but Chef Infra Server (OSS) EOL Nov 2026, migration to proprietary Chef 360 SaaShttps://docs.chef.io/
Ansible YAML playbooks2012Michael DeHaan → AnsibleWorks → Red Hat (2015) → IBM (2019)Host-state + orchestration DSL (agentless, YAML)Very active; ansible-core 2.19.x current (Jan 2026), 2.18 maintenance, ~6-month major cadencehttps://docs.ansible.com/
Ansible Jinja2 template DSL2008 (Jinja2), heavy use in Ansible 2012+Armin Ronacher (Pocoo)Templating overlay (string-interpolation DSL)Active; effectively a sub-language inside every Ansible playbookhttps://jinja.palletsprojects.com/
SaltStack states (.sls) / Salt YAML+Jinja~2011Thomas Hatch → SaltStack → VMware (2020) → Broadcom (2023)Host-state DSL (YAML + Jinja, with pillar)Uncertain; commercial Tanzu Salt rebranded VCF SaltStack under Broadcom; community-fork discussion ongoing 2025–2026https://docs.saltproject.io/
Salt reactor / orchestrate~2013SaltStackOrchestration DSL (event-reaction)Maintenance; tied to Salt’s overall trajectoryhttps://docs.saltproject.io/en/latest/topics/reactor/
Bcfg22004Argonne National LaboratoryHost-state DSL (XML-based)Legacy; academic origins, minimal commitshttp://bcfg2.org/
Quattor PAN~2003 (CERN-driven)EU/CERN research-computing collaborationsHost-state DSL (typed, hierarchical)Niche; still used in HEP/research-computing fleetshttps://quattor.org/
Rudder language~2011Normation (rudder-project)Host-state DSL (CFEngine + Rudder UI)Active; commercial + community editionshttps://www.rudder.io/
NixOS modules (Nix DSL for system config)2007 (NixOS 0.10)Eelco Dolstra (PhD thesis → NixOS community)Immutable-system DSL (purely functional)Very active; canonical “declarative full-system” answer; cap on adoption due to learning curvehttps://nixos.org/manual/nixos/stable/
Mgmt (mcl language)2013–2015 (project), Sep 2025 = “10 years of mgmt”James Shubin (Red Hat)Reactive host-state DSL (event-driven, closed-loop)Active, niche; CfgMgmtCamp 2025 talks; ongoing development through 2026https://github.com/purpleidea/mgmt
Pyinfra2017Nick Westbury (Fizzadar)Host-state + orchestration DSL (Python-native)Active; pyinfra 3.8.0 (May 2026) — full semver, security fixes, API decouplinghttps://pyinfra.com/
Itamae2014Ryota Arai (Cookpad alumni)Host-state DSL (Ruby-native, simpler than Chef)Active in Japanese-language Ruby ops community; modest global footprinthttps://itamae.kitchen/
Bolt task plans2018Puppet (now Perforce)Orchestration DSL (Puppet-language plans, ad-hoc + agentless)Active; under same Perforce umbrella as Puppet OSShttps://www.puppet.com/docs/bolt/
Chef InSpec compliance language2016Chef → Progress SoftwareCompliance/testing DSL (Ruby-internal)Active; Progress’s continued OSS investment; integrated into Chef 360https://docs.chef.io/inspec/
rspec-puppet~2010Tim Sharpe + communityTesting DSL (RSpec-on-Puppet manifests)Active; standard for Puppet/OpenVox module unit testshttps://rspec-puppet.com/
Foreman / Katello smart-class parameters~2009 (Foreman)Foreman community + Red HatVariable-management overlay on PuppetActive; standard frontend for Puppet/OpenVox in Red Hat shopshttps://theforeman.org/
Spinnaker pipelines DSL2015Netflix + GoogleOrchestration DSL (CD pipelines, JSON/YAML)Maintenance; usage shrinking against Argo CD / GitHub Actions / Tektonhttps://spinnaker.io/docs/reference/pipeline/
OpenTelemetry Collector YAML2019OpenTelemetry CNCF projectAdjacent observability config DSL (receivers/processors/exporters)Very active; the de facto observability-config schemahttps://opentelemetry.io/docs/collector/configuration/
Helmsman (declarative Helm)2017Praqma → communityK8s-config DSL (TOML/YAML over Helm releases)Active but niche vs Argo CD ApplicationSetshttps://github.com/Praqma/helmsman
Steampipe HCL queries2021TurbotAdjacent — SQL-over-cloud-state via HCL plugin configActive; included for adjacency, not state-managementhttps://steampipe.io/docs
Devbox (jetpack.io)2022Jetify (formerly jetpack.io)Dev-environment DSL (Nix-backed JSON)Active; modern Nix wrapper for per-project shellshttps://www.jetify.com/devbox/docs/
Devenv (cachix)2022Domen Kožar / CachixDev-environment DSL (Nix-flake-based)Active; sibling to Devboxhttps://devenv.sh/
Talos Linux machine config2018 (Talos), v1.0 2022, v1.10 2025Sidero Labs (Andrew Rynhard)Immutable-system DSL (single YAML doc per node)Very active; v1.10.x current (May 2025), v1.11+ in developmenthttps://www.talos.dev/v1.10/reference/configuration/

Notable threads

  • The 2024–2025 Puppet OSS rupture and the OpenVox fork. In November 2024, Perforce announced that Puppet’s official binaries would move to a “private, hardened, controlled location” — free for up to 25 nodes but EULA- and subscription-gated above that, with new development happening behind the gate while the original Apache-2.0 source repos were left frozen. The community read this as effective closed-sourcing. Vox Pupuli, the long-time community maintainer of ~200 Puppet modules, kicked off the OpenVox fork in earnest in January 2025, with the first public release on 2025-01-21 and at least eight subsequent releases through mid-2025. OpenVox is wire-compatible with OSS Puppet 7 and 8, so existing manifests continue to work. As of 2026 OpenVox is the de facto OSS continuation; Puppet under Perforce is increasingly a commercial-only product.

  • Ansible’s win, and its slow stagnation. Ansible is, by a wide margin, the most-used config-management tool of 2026 — its agentless model (just SSH + Python) plus YAML readability made it the lingua franca of “I need to configure 50 boxes by Friday.” Red Hat’s strategic focus has shifted to commercial Ansible Automation Platform (AAP) and the Ansible Lightspeed AI assistant, and feature velocity in ansible-core has visibly slowed: ~6-month majors (2.18 in 2025-H2, 2.19 in early 2026, 2.20 mid-2026, 2.21 RCs underway), with most newness landing in collections rather than core. Still active, still pragmatic, but no longer the locus of innovation it was 2014–2018.

  • Chef’s quiet sunset. Progress Software’s 2024 announcement that Chef Infra Server (Open Source) will reach end-of-life in November 2026 pushes the OSS user base toward proprietary Chef 360 SaaS or third-party server reimplementations. Chef Infra Client 19 (released as long-term-supported in 2025) keeps the agent side viable for at least three more years, and InSpec (compliance) remains an active OSS investment. But the “Chef as the daily config-management tool” story is essentially closing; Progress’s revenue thesis is now compliance + the Chef 360 unified platform, not stateful infra.

  • The CFEngine purist tradition. CFEngine never won the mainstream — its policy syntax is austere and steep — but it remains the cleanest theoretical foundation in the family thanks to promise theory, Mark Burgess’s reformulation in which every resource is a “voluntary promise” of state that autonomous agents attempt to keep. The project ships consistently: 3.24 LTS (2024), 3.25 / 3.26 (non-LTS, 2025), and 3.27 LTS released 2026-01-09 with a 3-year support window. Active in regulated/banking/telco shops where the rest of the industry’s churn is unwelcome.

  • NixOS as the technically-correct answer. NixOS modules express the entire system — packages, services, users, kernel parameters, network config — as a single Nix expression evaluated to produce an immutable system generation, with atomic rollback. It is, formally, the most rigorous answer to “declarative full-system configuration.” Its adoption is capped by the learning curve and the famously sharp edges of the Nix language itself; estimates put serious NixOS adoption around the low-single-digit-percent of the technical market. Devbox and Devenv (both 2022+) wrap Nix for the per-project dev-shell case and have higher casual uptake than NixOS proper.

  • Talos Linux as the modern endpoint. Talos is the “Kubernetes ate config management” thesis embodied: a minimal, immutable Linux distribution where the entire node — kernel cmdline, network, disks, kubelet, etcd, certificates — is described in a single YAML machine-config document, applied via talosctl, with no shell, no package manager, and no SSH. The 1.10 line (current as of mid-2025, with patches into 2026) added UserVolumeConfig for declarative user disks, dropped cgroupsv1 in non-container mode, and moved UEFI to systemd-boot only. It is the conceptual successor to Puppet/Chef/Salt for the Kubernetes era — declarative, but one level higher than the OS package: the machine itself is the unit of declaration.

  • Pyinfra as the lightweight alternative. Pyinfra (Nick Westbury / Fizzadar, 2017) replaces Ansible’s “YAML + Jinja + Python” sandwich with just Python: deploys are Python files that call typed operation functions, executed in parallel over SSH with no agent. v3.8.0 (2026-05) adopted full semver, decoupled the core API from click, and added security hardening around shell quoting. Modest absolute adoption, but vocal users — especially among teams who already write Python and find Ansible’s templating/conditional model awkward at scale.

  • Where SaltStack went. Salt was the technical dark horse of the genre — ZeroMQ event bus, reactor system, masterless mode — but the commercial trajectory collapsed: VMware acquired SaltStack in 2020, Broadcom acquired VMware in 2023, and the resulting product is now VCF SaltStack under Broadcom’s VCF Business Unit, supported on existing contracts through October 2028. Open-source velocity slowed visibly; community discussion of a soft-fork (merging open PRs, providing community builds) ran through 2025 without resolution. Salt is functionally still maintained, but is no longer where new investment goes.

  • Mgmt as the reactive contrarian. James Shubin’s mgmt (with its mcl language) argues that the rest of the family got it wrong by being convergent on a schedule — every 30 minutes the agent re-evaluates and patches. mgmt is event-driven and closed-loop: resources subscribe to system signals (inotify, dbus, network events) and react in real-time. After 10 years (Sept 2025 marked the project’s anniversary blog post), it’s still niche but technically interesting, and continues to pick up at CfgMgmtCamp talks.

Citations

Graph View