Speed Through ZeroMQ
SaltStack (now called Salt Open) was designed to address the speed problem of Puppet and Chef. Its key innovation: instead of HTTP polling every 30 minutes, Salt uses ZeroMQ — a high-performance asynchronous messaging library — to maintain persistent connections between the Salt Master and Salt Minions (its term for agents).
This means you can push a command to 10,000 servers and get results back in seconds, not minutes — targeting a group of minions by name pattern with a single command, ranging from a one-off remote command to installing a package to applying the full configuration state fleet-wide. Salt calls this remote execution.
Salt States vs. Salt Grains
Salt's configuration code is called States (written in YAML with Jinja2 templating). Similar to Ansible's notify/handler relationship, a Salt state file declares resources — a package to install, a service to keep running, a config file to manage — and wires dependencies between them (a config change watch-triggers a service restart; a service requires its package be installed first).
Grains are facts about a minion (OS type, CPU count, IP address, custom tags) that Salt collects automatically and makes available in templates. This is equivalent to Puppet's Facter or Chef's Ohai.
Salt's Agentless Mode (SSH)
Salt also supports an agentless mode called salt-ssh, which connects over standard SSH without requiring a Minion daemon. This makes it operationally similar to Ansible for environments where installing agents is not permitted.
Key Point: Salt's ZeroMQ architecture makes it the fastest of the three legacy tools for real-time operations, but it also means the Master/Minion connection is stateful — if the Master goes down, minions cannot receive updates. Salt's hybrid model (agent for speed, SSH for agentless fallback) makes it the most architecturally flexible of the three legacy tools.