Get Puppet Enterprise First 10 nodes are free!
Try it now
Request a demo
Automate IT and infrastructure, manage complex workflows, and mitigate risk at scale.
Try the full-featured Puppet Enterprise for free on 10 nodes.
Puppet Comply Find and prevent compliance failures
Compliance Enforcement Modules Remediate to stay in compliance
Continuous Delivery for Puppet Enterprise Build, test, and deploy infrastructure as code faster and easier
Content & Modules Pre-built scripts to automate common tasks
CentOS EOL Here’s how to secure your CentOS infrastructure – even after EOL.
Find thousands of component modules built by the community and guidance on using them in your own infrastructure.
Visit Puppet Forge >>
Open Source PuppetPerfect for individuals and small infrastructure
BoltAutomate tasks in orchestration workflows
See all open source projects >>
Contribute to open source projects >>
Stephen P. Potter
In your search for IT automation and configuration management tools, you're going to see a few common names, including SaltStack. But if you're looking for SaltStack alternatives, that means you're either looking to move away from SaltStack or you're looking to compare it against some of its competitors.
If you’re looking for SaltStack alternatives, or a comparison of Puppet vs. SaltStack capabilities, you shouldn't make the choice without doing your research. You're in the right place to compare SaltStack for automation and config management. We’ll walk you through the differences in features and overall purpose to help you make a smart choice.
Table of Contents:
Alternatives to SaltStack include Puppet, Ansible, Chef, Terraform, and others. Factors to consider when choosing a SaltStack alternative include scalability, compatibility, integration, compliance, and specific use cases.
Common SaltStack alternatives for automation, configuration management, and infrastructure as code (IaC) include:
Both Puppet and SaltStack offer server configuration and automation. While Puppet is known for scalability and visibility for many automation-related tasks, Salt is focused on remote execution based on pre-defined commands.
Puppet Enterprise was designed to use declarative language to manage desired state configurations. It works seamlessly across different environments (on premises, cloud, and hybrid cloud) to help automate, configure, manage compliance, and more.
SaltStack, also known and referred to as Salt, was created as an imperative configuration tool. Once you tell SaltStack how to change the state of your infrastructure, it will execute on those instructions.
To work with Puppet, you primarily work with Puppet DSL, a simplified Ruby-based language, which allows for full Ruby syntax but does not require any previous knowledge of Ruby. As a way to separate "data" (configuration options) from "logic," Hiera supports the use of YAML.
For a small minority of highly advanced users, new features and functions can be added using Ruby. However, most users will not need to add additional functions for the day-to-day workings of Puppet.
To work with Salt, the base languages are YAML and the Jinja2 templating system. Alternatively, you can replace YAML with JSON, and replace Jinja2 with Mako or Wempy, or write everything in straight Python. Salt isn't necessarily easy because of YAML – it also immediately requires another templating language, and there's lots of different options, so it can be confusing if different people choose different options.
Salt does a lot with YAML and their own Python-based ESL. With Puppet, you can be functional with YAML from the start — there are not a whole lot of other languages that you need to learn with Puppet.
Puppet offers visibility into changes made to an environment, offering insight that no other configuration management tool can match. The ability to ensure that a deployment will run smoothly is just one of the ways that Puppet differentiates itself from SaltStack.
Puppet’s nodes are end devices — a server, a desktop, or a laptop, for instance. Puppet’s agents run on a node.
Salt’s minions also run on a node. Salt is focused on individual state management. Its primary use case is state management, which is like Puppet, but implemented differently. For example, Salt uses resource specific terminology, such as pkg.installed and user.created to define the state of an individual resource.
Puppet, on the other hand, is attuned to both state management and resource management. Puppet uses a consistent grammar across most resource types that abstracts the resource specific action. For example, package and user are required to be “present” or “absent” and highlights the expected end state.
Salt's state definition files can often be difficult to understand due to a complex set of defaults, state options, and resource declarations. Salt definitions start with an "ID Declaration", which according to the Salt documentation can be "arbitrary," may contain many different states, and must be "unique across the entire state tree," but "duplicate declarations will be ignored." This particularly can lead to unexpected end states and difficulty in troubleshooting due to the silent ignoring.
Puppet's similar concept is a "class," which may not be duplicated. Classes contain resources, which define a unique state for that resource. Unlike Salt, Puppet avoids resource conflicts by precompiling a catalog of changes. This compilation will immediately error out and notify the user of any duplicates detected, ensuring the final state is explicitly known. This makes troubleshooting much easier whenever there might be an issue.
Puppet primarily uses a pull model. With the pull model, agents periodically check in with the primary server to get their state definition, then execute the appropriate commands to align their current state with the state definition. This state definition can be a new state definition (known as an intentional change) or it can be a drift remediation (known as a corrective change), but in both cases, it uses the same state definition.
Salt primarily uses a push model based off the ZeroMQ library. In this model, the Salt master pushes a model definition out to the minions and the minions then use selectors to determine which parts of the model they need to enforce to achieve a state. Salt’s use of the ZeroMQ event bus provides it the ability to react immediately to changes in the state of a managed resource but requires the additional creation of “beacons” to identify a change that is happening and “reactors” to define the actions necessary to return the resource to the proper state. These beacons and reactors, while doing the same fundamental work as a state definition, are separate from the state files and require additional coding and configurations.
Since Puppet’s open source debut in 2005, it has gained a large and active community that regularly provides support to other Puppet users. With an active Slack channel and resources found on the Puppet Forge, the benefit of longevity in the market is community dedication and expertise.
SaltStack was founded in 2011 and its community is still growing and active — operating primarily on GitHub and its own community pages on the SaltStack site.
Both declarative/desired state and procedural/task-based capabilities – tell Puppet what you want, and Puppet will figure out how to get there OR bring your own scripts in any language
Primarily desired state with limited ability to integrate existing scripting and tooling
Client/Server OR Agentless, Primarily Pull
Client/Server with ZeroMQ Event Bus Push & limited Agentless capability
GUI in Puppet Enterprise with visibility to events & config details
Primarily command line, multiple unsupported open source GUIs, VMware Aria Config limited function GUI
Built to scale with your automation needs
Complex setup requiring much manual configuration, including creation of separate state, identification, and remediation codes
A bustling dev community and thousands of modules on the Forge (including many supported by Puppet)
Active, growing community but no external, centralized module repository
Hands-On Labs or 60 Day limited trial
Designed to scale for enterprise automation
Designed to scale
Puppet DSL and some YAML for all modules. Ruby might be needed to add some new functions.
YAML and Jinja2 Templates, Python required for building new modules. Optional JSON, Mako, or Wempy
AWS, Azure, GCP + more
SSL or SSH/WinRM
Deciding on a configuration management platform comes down to the way it will be used, the specific features that your organization needs, and the needs of the team that will be using the software every day.
The main question you need to ask when choosing Puppet vs. Salt is: What are you focusing on first and foremost?
If you need to support your growing and changing organization with a tool that is built to scale, you can try out Puppet Enterprise for free. Seeing how Puppet Enterprise works in your real-world environment can help you make the best decision for your needs:
Try Puppet Enterprise for Free
Principal Sales Engineer, Puppet by Perforce
Stephen is a Principal Sales Engineer at Puppet by Perforce. His years of experience in the Puppet ecosystem and decades in IT operations include roles as sysadmin, engineer, and architect for Unix, Linux, Virtualization, and Cloud technologies.