Sold by
Chef PAYG
Progress Chef accelerates your DevSecOps journey, modernizes the continuous delivery of secure applications and infrastructure, and enables you to define Policy as Code to confidently manage your entire fleet.
Reviews (100)
Bongisiwe S.
Streamlined DevOps with Quick Deployment and Security
Reviewed on Jul 11, 2026
Review provided by G2
What do you like best about the product?
I like that Progress Chef simplifies a DevOps engineer's work by deploying VMs seamlessly and quickly, which helps application teams not worry about deployments. It saves a lot of time since deployment can be done with API calls and agents installed, and you just need to run the pipeline. The process is also secure.
What do you dislike about the product?
We need more features that include AI as the world and business is moving to AIOps.
What problems is the product solving and how is that benefiting you?
I use Progress Chef to deploy and maintain infrastructure quicker and easier. It simplifies a DevOps engineer's work by making deployments seamless and secure. It saves time by allowing deployment with API calls and pipelines.
Information Technology and Services
Streamlines Task Management with Ease
Reviewed on Jul 08, 2026
Review provided by G2
What do you like best about the product?
I use Progress Chef to manage and streamline workflows, and I really like the task tracking and the dashboard view. It makes it easy to see progress at a glance and quickly check what's done or still pending. These features help me stay organized and focused by allowing me to see what needs attention and track progress efficiently, saving me time. Additionally, the initial setup of Progress Chef was quite straightforward, and it didn't take long to get familiar with the platform and start using it effectively.
What do you dislike about the product?
It works well overall but when there are many tasks, it can take a bit more time to go through everything. A slightly quicker way to filter or find specific items would make it even better.
What problems is the product solving and how is that benefiting you?
I use Progress Chef to streamline workflows, track tasks, and ensure projects stay on schedule. It keeps me organized, prevents missing tasks, and saves time with a dashboard view to quickly check progress.
Anonymous
Powerful Automation with a Steep Learning Curve
Reviewed on Jul 08, 2026
Review provided by G2
What do you like best about the product?
I like Progress Chef's ability to automate infrastructure management while ensuring consistency across all servers. Instead of configuring systems manually, I define the desired state in code, and Chef applies it automatically, reducing downtime and improving consistency. Once it's properly implemented, it becomes a powerful and reliable tool for automating infrastructure at scale. After migrating from Puppet, we have found Chef to offer a more flexible and maintainable automation platform.
What do you dislike about the product?
One area where Progress Chef could be improved is its learning curve, it takes more time to understand concepts. Debugging issues are challenging, setting up and managing Chef servers are complex for smaller environments.
What problems is the product solving and how is that benefiting you?
I use Progress Chef to manage servers, reducing downtime and improving consistency. It automates infrastructure management, allowing me to define desired states in code while ensuring consistency across servers.
Anonymous
User-Friendly UI with Detailed Error Tracking
Reviewed on Jul 08, 2026
Review provided by G2
What do you like best about the product?
I find the UI of Progress Chef to be user-friendly, which really helps in displaying all the servers it supports. It shows the errors in detail for servers that are failing, and you can track back to when the failure started, which is incredibly useful. Every morning, I conduct check-ins to see which servers need attention or have been decommissioned, and this tool assists in alerting the VM owners effectively.
What do you dislike about the product?
None so far as we only use it for observability nothing much
What problems is the product solving and how is that benefiting you?
I use Progress Chef for observability, checking health status, identifying server issues, and alerting VM owners about failures. Its user-friendly UI shows supported servers and detailed errors, helping me track problems back to their start.
Nomzamo X.
Efficient Automation Tool with a Learning Curve
Reviewed on Jul 06, 2026
Review provided by G2
What do you like best about the product?
I like Progress Chef's ability to automate infrastructure management and maintain consistent server configuration across environments. It reduces manual work, it's reliable, and saves time.
What do you dislike about the product?
Learning can be a challenge. Improved documentation would make it easier. I think a more step-by-step guide for beginners and clear troubleshooting documentation for common errors would help.
What problems is the product solving and how is that benefiting you?
I use Progress Chef to automate and configure servers, eliminating manual setup errors and maintaining consistent configurations. It's reliable, reduces manual work, and saves time.
Judith Mologadi M.
Simplifies Automation and Boosts Consistency Across Environments
Reviewed on Jul 06, 2026
Review provided by G2
What do you like best about the product?
It simplifies automation,improves consistency and reduce manual effort in managing our environments
What do you dislike about the product?
The initial setup and troubleshooting can be complex for new users
What problems is the product solving and how is that benefiting you?
Progress chef helps automate infrastructure and configuration management,reducing manual effort,improving consistency and enabling faster,more reliable deployment
Kwazikonke M.
Exceptional Monitoring and Compliance Tool
Reviewed on Jul 01, 2026
Review provided by G2
What do you like best about the product?
I like Progress Chef for its visibility and monitoring capabilities. It allows us to easily track Chef-managed VMs, verify they are checking in successfully, and quickly identify systems that require attention. It helps us see which VMs are healthy, failing, missing, or checking in as expected, and when a system stops reporting, we can identify and investigate it immediately.
What do you dislike about the product?
Nothing
What problems is the product solving and how is that benefiting you?
I use Progress Chef to monitor and track VMs, ensuring regular check-ins and compliance. It solves the challenge of monitoring managed VMs and provides visibility to quickly identify systems needing attention, helping maintain our infrastructure standards.
G Srivastava
Agent setup and complexity have limited automation benefits but have reduced manual patching work
Reviewed on Jun 18, 2026
Review provided by PeerSpot
What is our primary use case?
We used Chef, the automation tool, as an Infrastructure as Code tool for configuration deployment, such as deploying patches on numerous servers, first on the development box, then on QA, and then on production. That was the main use case for us in the initial stage of using Chef. We then started using Chef for configuration changes. We deployed all those things on the workstation, pushed the recipes from the workstation to the Chef server, and the Chef client pulled from the Chef server, so that is how all the configurations got matched.
Before using Chef, we patched our servers manually or with shell scripts. Suppose we had 100 servers in our development area and needed to patch them all in a day or a week. We would run those shell scripts and wait for their outputs while going on each server to find out what patches had already been applied and if the server had been rebooted. That was a very long-running task for us. With the help of Chef, we configured all those nodes as Chef clients and matched or configured all those nodes by subscribing them to the Chef server. We changed the configuration file with the help of a recipe and pushed those recipes from the workstation to the Chef server. Chef clients started comparing their configuration files from their client to the server. That is how they started to patch themselves and make changes to their configuration files. This was the main use case for us when we started to use this automation tool.
After that, suppose we had 10 servers currently and 10 new servers. We had an application to deploy and the application team requested 10 servers with those many tools, users, configurations, and server hardlink compliance. We simply wrote those recipes in the workstation and pushed those recipes to the Chef server. Chef Client and Ohai were already installed on all 10 servers, and they simply compared their configuration files from Chef client to Chef server. As soon as there was a difference in the configuration, the Chef client pulled all those configurations and automatically deployed all those configurations on those nodes. That is how easy it was for us to deliver the servers or the configurations in a faster manner with the help of Chef.
For SAP servers, we needed to make many changes in files such as sysctl.conf on the Linux server. Suppose we had a brand new server delivered to us from a cloud platform, and we needed to make all those changes so that it could have all the security-related features or changes on the server. Instead of manually doing those changes on all those SAP servers, we could simply write a Chef recipe once and it would be applied on all those SAP servers. That is how it benefited us.
When I used Chef in my previous organization five years ago, it was on-prem servers.
We had not used any other solution before using Chef. We were using all those tasks with shell scripts only. After using Chef, we found other configuration management tools, such as Ansible and Terraform, which we found better, and then we switched from Chef to Ansible.
What is most valuable?
The main use case is the Infrastructure as Code. We can simply change any system configuration, whether it is related to changes of any port number of any files, or we can use package installation. We can help with user and group management. If we need to deploy any application, security hardening is the main tool. For the SAP servers, we need to update many codes, files, programs, and features on the server. With the help of Chef, we can just change those things in a recipe, and those recipes are going to be pulled by all those systems, changing themselves in a minute. Security and compliance hardening are also features we find very useful.
The manual work has been reduced with the help of this automation. We do not need to have 15 or 20 engineers to do those tasks manually. We only need two or three people to write those recipes and upload them on the Chef server. Once the configuration tool pulls those changes from the Chef server, it automatically deploys all those changes. It has reduced our manpower and our costs.
For example, suppose we have 20 servers to patch in this cycle and we need to deliver them in a week. Earlier we used to have six or seven engineers to patch all those 20 servers because it was a manual task. They had to log in on those servers and review if the patches had been correctly deployed. They also needed to validate the changes performed before or after the reboot of the servers. That was a lengthy task and they had to manage all those screenshots and comparisons of those screenshots. With the help of Chef automation tool, we simply deployed the recipe on the workstation and it got uploaded to the workstation, and all those 10 servers and 15 servers pulled the patches from the Chef server. With the help of Chef Client and Ohai, they patched themselves, and we simply clicked another recipe to reboot the servers. That is how only two or three engineers are required to patch those 20 servers. The number of engineers has been reduced and the timing has also been reduced by 10 to 12 hours for each server.
Chef is stable. If we have a large number of servers, it is stable.
What needs improvement?
There are other automation tools, configuration management tools in the market, which offer many good functionalities compared to Chef. For Chef, we need to install those agents, the Chef client, on all those nodes. That is another heinous task to perform on those nodes. Compared with other tools, they do not require any agent; they simply push configurations to all the clients. Chef needs to improve on this agent installation on all those nodes.
I would say that the agent configuration is required, and we need to manage the workstation, the Chef server, and then the Chef client. These two or three things are very difficult. It is a time-taking task compared with other configuration management tools.
They need to compete with other tools, such as Ansible or Terraform. They should work on their agent part. If they can remove the agent installation on the nodes and combine both the Chef server and workstation into one server, that will provide a significant benefit in cost for the clients. They should aim for an agentless architecture rather than an agent-based architecture, which will help other customers.
That is a very difficult thing because I have stopped using Chef. If you have very good developers who are skilled in Ruby language and can write codes in the Chef recipe, then those developers should start using Chef.
For how long have I used the solution?
I have been working in my current field for 10 plus years.
What do I think about the stability of the solution?
Chef is stable. If we have a large number of servers, it is stable.
What do I think about the scalability of the solution?
Chef can be scaled. It is very good in scalability, and we just need to configure the client nodes and it will start adding them, and those clients will start pulling the information from the Chef server. It is highly scalable and we have not faced any issues when using Chef in terms of scalability.
How are customer service and support?
Since we used the free version, the license cost was zero. We have not used the paid version, so we have not had the option to create a ticket for support. However, the developer option or community support is good on Chef, and Chef codes, which are in Ruby language, are easily available on Chef Supermarket, so we found them very useful.
Which solution did I use previously and why did I switch?
We had not used any other solution before using Chef. We were using all those tasks with shell scripts only. After using Chef, we found other configuration management tools, such as Ansible and Terraform, which we found better, and then we switched from Chef to Ansible.
There was another tool called Puppet, but Puppet and Chef are both pull-based configuration tools, and Puppet has a limitation of 25 nodes to perform. That is why we went with Chef.
How was the initial setup?
We simply downloaded Chef from their website, chef.io, and deployed it on the workstation to start using it.
What's my experience with pricing, setup cost, and licensing?
The licensing cost is zero for Chef if you are using the free version. They have developed other versions, such as SaaS-based and self-managed. For the SaaS-based version, it is $59 per node per year. I think it can be costly considering the advantages and disadvantages of Chef. Anyone can start using the free version or the zero-cost license with no upfront cost required, but the setup requires a cost. We need to set up a workstation server and a Chef server, so there will be costs for those two servers regardless of whether they are deployed on-prem or on the cloud.
Which other solutions did I evaluate?
There are other automation tools, configuration management tools in the market, which offer many good functionalities compared to Chef. For Chef, we need to install those agents, the Chef client, on all those nodes. That is another heinous task to perform on those nodes. Compared with other tools, they do not require any agent; they simply push configurations to all the clients. Chef needs to improve on this agent installation on all those nodes.
I would say that the agent configuration is required, and we need to manage the workstation, the Chef server, and then the Chef client. These two or three things are very difficult. It is a time-taking task compared with other configuration management tools.
They need to compete with other tools, such as Ansible or Terraform. They should work on their agent part. If they can remove the agent installation on the nodes and combine both the Chef server and workstation into one server, that will provide a significant benefit in cost for the clients. They should aim for an agentless architecture rather than an agent-based architecture, which will help other customers.
That is a very difficult thing because I have stopped using Chef. If you have very good developers who are skilled in Ruby language and can write codes in the Chef recipe, then those developers should start using Chef.
What other advice do I have?
After using Chef, we found other configuration management tools, such as Ansible and Terraform, which we found better, and then we switched from Chef to Ansible.
There was another tool called Puppet, but Puppet and Chef are both pull-based configuration tools, and Puppet has a limitation of 25 nodes to perform. That is why we went with Chef.
I chose that number because the other automation tools, the other configuration tools are far better. I would give them nine or ten, for example, Ansible. They are not agent-based tools; they simply push configurations, and there is no need to install these tools or the clients on the nodes. Other tools are much better than Chef these days. I would rate this review as five out of ten.
FedirPlotnikov
Automated configuration has standardized my servers but now requires careful resource planning
Reviewed on May 30, 2026
Review from a verified AWS customer
What is our primary use case?
My main use case for Chef is configuration management to set up systems, provision software, and keep configurations up to date.
I create Chef recipes for setup and install needed software from a clean Linux installation to set up server roles, which is a specific example of how I use Chef to manage and provision software while keeping configurations up to date.
What is most valuable?
The best features Chef offers include configuration management and server-client setup, along with the ability to coordinate with Chef servers to keep servers up to date automatically and remove any configuration drift from the system automatically.
Chef handles configuration drift automatically by having Chef client contact Chef server, retrieve needed recipes and variables set up for a specific server, verify the current server state with the required state and configuration, and automatically make changes if needed.
Chef has created much faster procedures for system setup and rollout of infrastructure in my organization, as well as for scaling and ensuring that all servers are configured identically. It has removed the possibility of human error from configuration. Plus, it ensures that all servers for specific roles have an identical setup, which makes debugging much easier, along with performance optimization and security measures.
What needs improvement?
I do not have anything in mind at this time for how Chef could be improved.
For how long have I used the solution?
I have been using Chef for approximately five years.
What do I think about the scalability of the solution?
I chose a rating of seven because Chef is a great tool, but sometimes resource consumption is quite large, and it requires server-side setup, which is not required but should be considered if you are using server-client plus server. Server size actually depends on the number of clients, and you need to consider this during your setup.
What other advice do I have?
My advice to others looking into using Chef is to be ready to learn Ruby at least on a basic level. I have never used AI in Chef. I gave this product a rating of seven.
Which deployment model are you using for this solution?
Hybrid Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
TariqSiddiqui
Automated large-scale server configuration has saved time but still needs a simpler learning path
Reviewed on Dec 18, 2025
Review from a verified AWS customer
What is our primary use case?
My main use case for Chef was around provisioning and configuration management for our application servers.
I can give you a specific example of how I used Chef for configuration management on our application servers: we provisioned our servers using Terraform, and once the servers were provisioned, there were a bunch of things that we installed on our application servers through Chef, such as NGINX, security packages, and other custom utilities.
What is most valuable?
The best features Chef offers make the management of large-scale infrastructure easy, and the development around custom resources was also something useful. Most configuration management tools offer the same kind of features, but Chef is better at handling large-scale infrastructure.
Chef has impacted my organization positively because most of our infrastructure configuration management depended on it. If Chef is not working, we are blocked at many fronts, including not being able to provision services or our application servers, making it a critical part of our whole ecosystem.
Chef benefited my organization by definitely reducing time because we were provisioning tens of thousands of servers. Anytime we built the server using Terraform, we never had to worry about the configuration management part since it would run as our pipeline, making it a really significant time-saver for us.
The custom resources helped my team specifically because we had a bunch of custom things that we used to do on our application servers, and that is where we used Chef's custom resources to build on that.
What needs improvement?
Chef has a very steep learning curve, especially for beginners. I felt that way when I started with Chef because there is too much to learn, and compared to Ansible, which has an easier learning curve, Chef can be confusing.
The learning curve is something that should be focused on for improvement. Chef could be made a little simpler so that someone with basic coding knowledge should be able to pick up Chef and write recipes.
I have noticed that needing to know Ruby for developing custom resources or custom recipes is another area for improvement. Ruby is easy to pick up, but in today's IT scenario, languages like Python and GoLang are more frequently used.
For how long have I used the solution?
I have used Chef in my previous company for almost four to four and a half years.
What do I think about the stability of the solution?
Chef is very stable. We have rarely had any outages on our Chef servers.
What do I think about the scalability of the solution?
We are running Chef in the cloud as a single server, and we are not currently looking into its scalability because most of the work is done by the clients on our application servers.
How are customer service and support?
I have never used Chef's customer support because we have mostly fixed our issues through code changes on our end.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
At Coupa, we have been very Chef-oriented or Chef-centric from the beginning, so we have not used any other configuration management tool.
What was our ROI?
I have seen a return on investment with Chef because we definitely need fewer employees to manage infrastructure. In today's scenario, no one is doing configuration management manually anymore.
What other advice do I have?
My advice to others looking into using Chef is that it is a good tool for implementing it across large-scale infrastructure. If you are planning to manage tens of thousands of servers, Chef is one of the better choices.
I am not sure how Chef is going to keep up with the adoption of containers across the industry since many companies are moving to containerized workloads, and I am curious how Chef will be implemented in those scenarios.
I would rate this review a 7 out of 10.
Which deployment model are you using for this solution?
Public Cloud