cdist

cdist is a free, open-source configuration management system for applying a desired state to computers. It uses shell scripts and cdist types, which the project says produce idempotent results regardless of the order in which types are called. Its push model lets one or more source computers connect to target hosts over SSH and apply configuration; targets do not need an agent, an extra open port, or a connection back to the source. A target needs a POSIX-compatible shell and an SSH server. The source needs a POSIX-like shell, Python 3.5 or later, and an SSH client. The project lists a small core, standard types, parallel execution, and operation without a central server. Types provide an extension mechanism kept separate from the core. Installation is documented from Git or as a Python package using pip. Supported systems listed by the project include Linux distributions, BSD systems, Mac OS X, and XenServer. Manuals are available in HTML and man-page formats. Community help is offered through Matrix and IRC, and commercial support can be requested from ungleich. The listed platforms are Linux, macOS, and self-hosted.

cdist centers configuration around SSH push, shell scripts, and types, without requiring a central server. Check that source and target machines meet the stated requirements before adopting it.

cdist suits administrators who want to configure Linux or macOS hosts from a source computer over SSH. It may also suit teams that prefer shell scripts and types, and can meet its source and target requirements.

cdist is an open-source configuration-management system for administrators who want to define machine state in shell scripts and push it over SSH. It is strongest for lean, agentless environments where POSIX tooling is already familiar; its shell-first model is less suitable for teams seeking a more abstract or centrally managed workflow.

Overview

cdist runs from one or more source computers and connects outward to target hosts, rather than requiring managed machines to call a controller. Targets need a POSIX-compatible shell and an SSH server, with no agent, additional listening port, or return route to the source. That keeps the managed-host footprint small and avoids opening inbound access for configuration callbacks.

The source side still has requirements: a POSIX-like shell, Python 3.5 or later, and an SSH client. Administrators write shell scripts and use cdist types to describe the desired target state. The project says type results are idempotent and do not depend on the order in which types are invoked, an important property for repeatable runs. The trade-off is clear: cdist fits teams comfortable treating shell and reusable types as their configuration language, not teams that want to avoid shell scripting.

Key features

• Types and extensibility: Types are cdist’s extension mechanism, with the core kept separate from type definitions. Standard types provide reusable building blocks, while community-maintained contrib types have their own manuals. This separation supports customization without changing the core, provided your team is willing to maintain its type library.
• SSH push transport: SSH carries remote communication, and the push architecture means targets never need to connect back to the source. It is a sensible design for restricted networks and hosts where installing an agent is undesirable.
• Agentless, serverless operation: The project highlights a small core, parallel execution, and no central server. You can run cdist from any suitable computer, which reduces fixed infrastructure but leaves orchestration responsibility with your source hosts and operating practices.
• Repeatable policy: Idempotent types are intended to converge systems on the same result across repeated application. That makes cdist appropriate for policy-as-code and patch-management routines where rerunning configuration should not introduce ordering surprises.
• Installation and verification: Installation is documented from Git or with pip install cdist. The guide also explains how to verify signed source archives with GPG and supplies a signing public key, a useful safeguard for teams that control their software supply chain.
• Documentation and support: Manuals are provided in HTML and man-page formats, including material for contrib types. Community help is available through a Matrix room and IRC channel, while commercial support can be requested from ungleich.

Pricing

cdist costs free under its open-source model. There are no paid plans or stated usage limits, and there is no free trial because the software is already free. This suits individuals, small operations, and enterprises that can operate a self-managed tool without a vendor subscription. The price does not remove the operational cost of maintaining source hosts, shell scripts, types, SSH access, and internal support processes.

Platforms

cdist is available for Linux, macOS, and self-hosted deployments. The supported-systems list includes Alpine Linux, Archlinux, CentOS, Debian, Devuan, Fedora, Gentoo, Red Hat, Ubuntu, FreeBSD, NetBSD, OpenBSD, Mac OS X, and XenServer. Source computers must meet the POSIX-shell, Python 3.5-or-later, and SSH-client requirements, while targets need a POSIX-like shell and SSH server.

Who it's for

Choose cdist when you want agentless configuration pushed over an existing SSH relationship, need no central server, and have administrators who can build and review shell-based types. Its architecture can serve anything from a small deployment to an enterprise-grade environment, especially where lean target hosts and controlled inbound connectivity matter.

Look elsewhere if your organization depends on a graphical control plane, a broad vendor-managed service, or a configuration language deliberately separated from shell scripting. cdist’s flexibility comes with responsibility for designing types, securing SSH, and running the source side.

Pros and cons

Pros

• No agent or central server: targets require only a POSIX-compatible shell and SSH server, reducing host-side dependencies and fixed infrastructure.
• SSH push model: targets do not need a callback path to the source, which suits networks that restrict inbound connections.
• Idempotent, extensible types: reusable types support repeatable policy and separate local extensions from the small core.
• Open-source pricing: the software is free with no stated seat, quota, or usage cap.

Cons

• Shell-centric workflow: teams must be comfortable writing shell scripts and maintaining cdist types rather than relying on another configuration abstraction.
• Source-host prerequisites: every source needs a POSIX-like shell, Python 3.5 or later, and an SSH client, so the controller environment is not dependency-free.
• Self-managed operations: without a central server or paid plan, scheduling, governance, access control, and ongoing type maintenance remain your responsibility.

Alternatives

Quattor is another free, Linux and self-hosted open-source option when its Apache 2.0 and EU DataGrid licensing model suits your organization.

Salt is worth choosing when you need a free open-source tool spanning Linux, macOS, Windows, self-hosted, and API environments.

CFEngine fits readers who want a free Community Edition, a trial, and a possible enterprise tier with broader deployment options.

config.XO is the better direction for a hosted web/API workflow with a free tier capped at one workspace, one administrator, one cloud connection, one hypervisor, three managed systems, and one API key.

Google Cloud VM Manager suits teams managing cloud VMs that prefer an agent-based Google Cloud service with a free tier and usage billing beyond it.

LCFG is a free GPL alternative for Linux and self-hosted deployments.

pyinfra is a free MIT-licensed option for teams already standardized on Python 3.10 or newer across its listed platforms.

Rudder is the alternative to consider when you want open-source software alongside a freemium product and web-based management options.

Verdict

cdist is a strong choice for shell-proficient administrators who want free, agentless, SSH-based configuration with no central server and repeatable types. Choose it for a lean push architecture and minimal target requirements; look elsewhere when your team needs a richer management plane, less shell-centric authoring, or vendor-operated orchestration.