SaltStack Reviews

The most valuable features are:

• Setting configurations options dynamically for servers
• Pulling information about all computers

We are able to control updates on servers to streamline the process

There is still development for states and pillars. The software is open-source so it allows for extreme customizability. If there is something that you think could be improved, you can code it. Our company is currently working on a few projects to help improve and support SaltStack. I would like to see more training on how to use the many different options. There is a lot of of information to go over and it’s hard to keep it all straight. Other than that, if you put the time learning SaltStack, it is a pretty easy and very powerful tool.

We used this solution for a year and a half..

We have not had issues with stability.

We have had no scalability issues so far.

I don’t have experience with their support, but I heard they are helpful. There is a IRC chat that you can join to get help from your peers.

I was not a part of the setup, but from what I have read, it is pretty simple.

The software is open source. One has to pay for support.

Read the documentation to learn as much as you can.

• Remote execution.
• SaltStack being so fast makes it very convenient and practical; allows me to get information about my servers in no time.

SaltStack allows me to answer user requests in a very efficient manner.

I guess the only downside of SaltStack is the limited user base, which leads to poorer documentation because of the lower use.

On a features side, maybe some more security around the API would be good, so it can be used as a central automation tool.

I haven't kept up with latest releases for a while, though, so don't quote me on that.

I have used it for two years.

I have not encountered any stability issues.

I have not encountered any scalability issues.

It's open source and the community is very helpful as usual.

I previously used multiple solutions combined; harder to manage. Salt is easy to use and manage.

Initial setup was straightforward; worked out of the box .

It's open source.

Before choosing this product, I evaluated Puppet and Ansible.

Just install it and use it for remote execution at first. You'll see how powerful it is.

The most valuable feature is Salt Cloud due to its ability to tie into VMware, as well as Salt Orchestration, because it allows us to script the process of setting up an entire infrastructure.

This product has saved us time in standing up new servers, as well as allowed us to automate the deployment of these servers and the applications that run on them.

• Documentation can be hard to find and examples aren't as detailed. In Salt, you can use modules in an SLS file, as well as via command line. A lot of the time, the official documentation only has a command line example and you've got to dig around through third-party sites to find examples of using modules in an SLS file. It can also be difficult to find documentation on Jinja templating through Salt’s website, as well. Basic examples are given but anything more complex is lacking.
• Salt Cloud Windows support isn't that mature.
• Salt Orchestration lacks logging when states are nested.

I have used it for 1.5 years.

Occasionally minions would time out and not return a response, although the Salt state would still run. Increasing the timeout helped, but this is more of a design concern than an overall stability issue.

So far no issues with scalability were encountered.

I haven't utilized technical support. The forums seem to be somewhat helpful in suggesting workarounds to issues caused by lack of features, but more detailed steps on implementing those workarounds would be helpful (e.g., setting a static IP on Windows VMs setup with Salt Cloud).

I've used Puppet at a previous job. Salt is the tool that was in place at my current job.

Salt is open source.

The product was already in use.

Define the scope of what you need a configuration management tool to use and then look at all available options and the potential drawbacks of those options. Nothing can beat hiring a sys admin with experience in different technologies.

• Interoperability between operating systems with the ability to perform mass automation with triggering
• Integration with many vendors

These features are valuable because I need them to complete the work assigned to me.

The GUI is clunky and hard to use. It could be more user friendly.

• The UI can get complicated very quickly when you start using SaltStack for a large number of machines (100+).
• The organization of the buttons / layout can make it difficult to search for the machine you are looking for. Even with the search function, it's difficult to determine the exact state in the correct order
• The UI should be organized in a more tree-like structure, starting from the initial state (root) with corresponding states being added after (node).

I have used it for six months.

I have not encountered any stability issues.

I have not encountered any scalability issues.

I recommend SaltStack because, for SysOps or DevOps users, automation is a key part of getting your product out and allows for faster time to market.

The ability to programmatically describe the desired state of a single, or an entire fleet of servers, on-premises, and in a cloud environment.

SaltStack gave us very useful automation tools that allowed us to standardize our environment, move at a much faster pace through repeatable deployments, and self-documentation of our infrastructure.

It allows us to describe the desired state of our entire fleet of servers through simple to understand syntax and templates all available at a single place.

This is great for things like documenting what a single machine or a group of machine does and how they are configured. It is also good in the event that one of them is lost and a new one needs to be provisioned quickly.

Instead of setting it up by hand, we end up telling it "you are this type of machine" and SaltStack will take care of ensuring that the machine becomes what is expected.

It also means that any machine of "this type" will be setup in a consistent manner thus avoiding unexpected surprises that could potentially become the cause of outages.

Each new version seems to bring a new set of bugs to the table and upgrading is risky, especially for a tool at the core of the operations and infrastructure.

A hardened set of tests would be much appreciated.

We have encountered many bugs during upgrades in the past and it seemed to me like those could have been caught by the developers at a much earlier stage then after doing a widespread release.

We have used this solution three years in production

We have encountered several issues when we upgraded to 2015.8. Some of those were eventually fixed by the community and through fixes we submitted to the project.

We have managed a fleet of hundreds of servers without any scalability issues on the horizon.

We have not requested technical support.

We evaluated Chef, CF Engine, and Puppet and we ultimately decided on SaltStack because:

• It is written in Python: Introspecting the code base, committing fixes and improving on the tools were easy for us to do.
• The amount of tools already baked in the product and the extensive list of formulas made available by the community.

The initial setup was simple enough to get started and see the benefits that the solution brings. There are many tutorials available to get someone started.

Unfortunately, our experience is limited to the open-source (community) version. We have no information in regards to the enterprise offering.

We evaluated CF Engine, Chef, Puppet, Capistrano, and Fabric.

Take some time to learn the types of problems it can solve and you will easily see the benefits that it can bring.

Jinja/Python + wide range of embed functions for various platforms and purposes.

Jinja is based on Python, which is a fairly handy and comfortable programming language. They make it simple to create Python-based templates and, when necessary, create functions for actions that are not covered by the Jinja engine.

Centralized administration and orchestration of severs and services.

Support: It's not bad or poor, but there are some issues. On the one hand, it's about development and progress; on the other, there were some issues that took too long to get fixed by the SaltStack team and forced users to invent workarounds.

Documentation: I'd say it's a little bit complicated for beginners, some topics are not clear and so on. So, one will have to massively use search engines when it comes to complex setups and solutions.

I have used it for ~7 months.

I have encountered any stability issues.

I have not encountered any scalability issues.

Technical support is good (4 of 5).

I did not previously use a different solution.

The initial setup was neither straightforward nor complex; it required some effort.

It's OSS.

Before choosing this product, I evaluated Ansible and Puppet.

Be patient and you'll get a great solution.

Agentless application deployment is the main reason for faster setup and easy deployments.

• It doesn't have a GUI to manage VMs.
• Some Python modules had issues which I think will be fixed in newer versions.
• Other configuration management tools, like Chef and Puppet, have a web interface to perform certain tasks on instances where an application is deployed.
• We can scale and schedule based on traffic. If you want to recreate/add a new instance, you can immediately do it from web interface. This was missing on earlier versions we tried.

We have been using this solution for three months as part of a PoC.

I did not encounter any issues with stability.

I did not encounter any issues with scalability.

We used open source community support.

The installation was straightforward, especially the master and minion configuration. This configuration was time saving and led to a faster, automated application deployment.

We didn't go for pricing model, as we chose to do a PoC using an open source version.

We evaluated Ansible.

This product is in good shape now and the community support is vibrant. I learned a lot from them while implementing it.

• Configuration file templating: limits the amount of copy/pasted configuration across services with minor differences
• Near instant orchestration: no waiting to see if a change worked
• Well-formatted and detailed command output and logs: make troubleshooting easy and break/fix recovery fast

Developers and systems engineers could work together more closely.

Salt does not support performing remote actions that require a sudo password with Salt SSH (agentless Salt execution).

Ansible does support this feature.

I have used it for two years.

I have not encountered any stability issues in the last year.

Official documentation and community support are top notch.

We previously used CFEngine 2 and Chef; both solutions have a steep learning curve that requires a ton of domain-specific knowledge. Salt is configured from the ground up in YAML files and Python, so there's less domain-specific knowledge required and no hidden configuration files.

Salt's initial setup took about two days to go from knowing nothing to having a configured Apache Tomcat server serving our content. That's simple in my book. The complexity comes in when you want to add security policies or routing that aren't ordinary for a horizontally scaling web application; that takes some creativity.

Don't pay for it, use the free licensing options unless you don't have the staff to cover your SLAs.

We also looked at CFEngine 3, Chef, Ansible, and Puppet.

Look at Digital Ocean's guide for initially setting up the Salt server (https://www.digitalocean.com/community/tutorials/saltstack-infrastructure-installing-the-salt-master). Group your configurations by logical components, serve any environment/deployment-specific variables from pillar files, and keep templates as simple as possible (put logic for assigning variables in the *.sls files where there's likely to be other logic).