Technical Architecture Support at a tech vendor with 10,001+ employees
Real User
Top 10
Dec 13, 2025
I would add that Ruby is a domain-specific language in the Chef dialect, which is a learning curve, but so is Terraform and so is Ansible. The only feedback would be if they could come up with an interface in a language such as Java or Python that is even more ubiquitous than Chef or Ansible are themselves, then I think someone with a good configuration system would be on to something. To improve Chef, making an interface with another language such as Python or Java that is well understood, as capable as Ruby, and even more widely adopted would demystify it a bit. Other things would be the need to use Cinc if you want to use the open-source version because Progress Software's policy on copyright is confusing for new users and it puts a barrier in the way to adoption because many small, medium enterprises, startups, and non-profits who might want to use Chef would find the whole Cinc versus Chef situation confusing and the fact that there is not an easy path to install Chef and then go to a paid version without having to change from Cinc to Chef or Chef to Cinc. Other than making the need for Cinc go away by finding a compromise policy and making an interface, whether optional or as the default, in a language that is even more ubiquitous than Ruby, the only things I could see would be a curated open-source approach.
One thing that Chef needs to improve on is making it available in as many languages as possible. There should be a focus on how to make it understandable, not just to infrastructure people, but also to those working in monitoring. How can we ensure that it is part of their daily input? That is something that still has a small missing link. We are almost there, but it can help us achieve outcomes in the future in terms of objectives, not just workflows and visibility. How can we make real-time interactive dashboards more available? Look at what kind of tools can be integrated with them, not just working with the ones like Chef Kitchen and Habitat, but trying to make it even more flexible than what we have right now. On support, I think there should be more focus on how we can achieve AI automations in answering questions for beginners and addressing deep concerns without general manual management.
DevOps Engineer at a tech vendor with 501-1,000 employees
Real User
Nov 16, 2023
I did not like the solution. It is an old technology. Compared to Ansible, it just doesn't hold up because we need to deploy a client to each of the services we need to manage, which makes the automation much harder.
DevOps Engineer at a manufacturing company with 1,001-5,000 employees
Real User
Sep 18, 2023
In terms of improvement, Chef could get better by being more widely available, adapting to different needs, and providing better documentation. There is also an issue with shared resources like cookbooks lacking context, which could lead to problems when multiple companies use them. Chef should aim for wider availability, better flexibility, clearer documentation, and improved management of shared resources to prevent conflicts. Many companies are now moving to Ansible, so I would recommend better documentation, easier customer use, and simpler integration. I have concerns about the complexity of migrating to different servers and would prefer a simpler process.
Engineer II at a transportation company with 10,001+ employees
Real User
Dec 11, 2018
There is a slight barrier to entry if you are used to using Ansible, since it is Ruby-based. However, it is just a different product and requires you to acclimate yourself, just like any other product would.
Senior Operations Engineer at a retailer with 10,001+ employees
Real User
Dec 11, 2018
The compatibility with the different platforms that we are using needs improvement. We are mainly a Linux shop, but for a lot of ancillary Windows services that we were bringing in from vendors of third-party customers and things that we are using for the supply chain that we were running, Chef did not necessarily fit across the board for what we are doing there. In-house, the product has been pretty functional for us. I would like them to add database specific items, configuration items, and migration tools. Not necessarily on the builder side or the actual setup of the system, but more of a migration package for your different database sets, such as MongoDB, your extenders, etc. I want to see how that would function with a transition out to AWS for Aurora services and any of the RDBMS packages. If there was something that was automated rather than through the package of the database system itself, this might aid us for a lot of DR stuff, resiliency, multi-region, etc. Especially when consolidating from a lot of on-premise stuff to cloud services, this functionality might improve our rate of deployment.
DevOps Director at a tech vendor with 501-1,000 employees
MSP
Dec 11, 2018
Right now, we are moving towards a container department with Docker and Kubernetes, so I'm not sure if Chef has features to support containers. I haven't really researched it yet, but if they can improve their software to support Docker containers, it would be for the best.
I would rate this solution a nine because our use case and whatever we need is there. Ten out of ten is perfect. We have to go to IOD and stuff so they should consider things like this to make it a ten.
They could provide more features, so the recipes could be developed in a simpler and faster way. There is still a lot of room for improvement, providing better functionalities when creating recipes. We would also like more recipes. This is key for us.
One of the biggest things that I miss is in Chef 11 and earlier, organizations were able to be managed directly through the Chef control command line utility. Now, while we prefer to interact directly with the database, there is still some value in being able to have access to the command line utility. While that functionality is still present and in the documentation, it has been broken since Chef 12. We are now looking at Chef 14, and they already have Chef 15 in the pipeline, but there appears to be no effort to fix this functionality, which is definitely broken, provides a false positive for a result when you perform the operation, and doesn't work. It would be nice to have an update to Chef Zero, such that it was more geared toward containers. Before Docker took hold, there was something called Chef Zero Vagrant, which was a plugin for Vagrant which would provision your developer's local copies of their environment for local testing. This was great for the technology, but we haven't seen an evolution of it now that the containerization technology has moved forward.
The time that it takes in terms of integration. Cloud integration is comparatively easy, but when it comes to two-link based integrations - like trying to integrate it with any monitoring tools, or maybe some other ticketing tools - it takes longer. That is because most of the out-of-the-box integration of the APIs needs some revisiting. They should make it into a larger toolset. I would also like to see more analytics and reporting features. Currently, the analytics and reporting features are limited. I'll have to start building my own custom solution with Power BI or Tableau or something like that. If it came with built-in analytics and reporting features that would be great.
Senior DevOps Engineer at a tech services company with 1,001-5,000 employees
MSP
Jul 1, 2018
In my presentation to SAP engineering, Ansible was chosen over Chef by all the admins for one reason: simplicity. If only Chef were easier to use and code, it would be used much more widely by the community.
Chef, is the leader in DevOps, driving collaboration through code to automate infrastructure, security, compliance and applications. Chef provides a single path to production making it faster and safer to add value to applications and meet the demands of the customer. Deployed broadly in production by the Global 5000 and used by more than half of the Fortune 500, Chef develops 100 percent of its software as open source under the Apache 2.0 license with no restrictions on its use. Chef...
I would add that Ruby is a domain-specific language in the Chef dialect, which is a learning curve, but so is Terraform and so is Ansible. The only feedback would be if they could come up with an interface in a language such as Java or Python that is even more ubiquitous than Chef or Ansible are themselves, then I think someone with a good configuration system would be on to something. To improve Chef, making an interface with another language such as Python or Java that is well understood, as capable as Ruby, and even more widely adopted would demystify it a bit. Other things would be the need to use Cinc if you want to use the open-source version because Progress Software's policy on copyright is confusing for new users and it puts a barrier in the way to adoption because many small, medium enterprises, startups, and non-profits who might want to use Chef would find the whole Cinc versus Chef situation confusing and the fact that there is not an easy path to install Chef and then go to a paid version without having to change from Cinc to Chef or Chef to Cinc. Other than making the need for Cinc go away by finding a compromise policy and making an interface, whether optional or as the default, in a language that is even more ubiquitous than Ruby, the only things I could see would be a curated open-source approach.
One thing that Chef needs to improve on is making it available in as many languages as possible. There should be a focus on how to make it understandable, not just to infrastructure people, but also to those working in monitoring. How can we ensure that it is part of their daily input? That is something that still has a small missing link. We are almost there, but it can help us achieve outcomes in the future in terms of objectives, not just workflows and visibility. How can we make real-time interactive dashboards more available? Look at what kind of tools can be integrated with them, not just working with the ones like Chef Kitchen and Habitat, but trying to make it even more flexible than what we have right now. On support, I think there should be more focus on how we can achieve AI automations in answering questions for beginners and addressing deep concerns without general manual management.
Chef does not support the containerized things of Chef products. In the future, Chef could develop a docker container or docker images.
I did not like the solution. It is an old technology. Compared to Ansible, it just doesn't hold up because we need to deploy a client to each of the services we need to manage, which makes the automation much harder.
In terms of improvement, Chef could get better by being more widely available, adapting to different needs, and providing better documentation. There is also an issue with shared resources like cookbooks lacking context, which could lead to problems when multiple companies use them. Chef should aim for wider availability, better flexibility, clearer documentation, and improved management of shared resources to prevent conflicts. Many companies are now moving to Ansible, so I would recommend better documentation, easier customer use, and simpler integration. I have concerns about the complexity of migrating to different servers and would prefer a simpler process.
The solution could improve in managing role-based access. This would be helpful.
Support and pricing for Chef could be improved.
Third-party innovations need improvement, and I would like to see more integration with other platforms.
There is a slight barrier to entry if you are used to using Ansible, since it is Ruby-based. However, it is just a different product and requires you to acclimate yourself, just like any other product would.
The agent on the server sometimes acts finicky.
The compatibility with the different platforms that we are using needs improvement. We are mainly a Linux shop, but for a lot of ancillary Windows services that we were bringing in from vendors of third-party customers and things that we are using for the supply chain that we were running, Chef did not necessarily fit across the board for what we are doing there. In-house, the product has been pretty functional for us. I would like them to add database specific items, configuration items, and migration tools. Not necessarily on the builder side or the actual setup of the system, but more of a migration package for your different database sets, such as MongoDB, your extenders, etc. I want to see how that would function with a transition out to AWS for Aurora services and any of the RDBMS packages. If there was something that was automated rather than through the package of the database system itself, this might aid us for a lot of DR stuff, resiliency, multi-region, etc. Especially when consolidating from a lot of on-premise stuff to cloud services, this functionality might improve our rate of deployment.
I would like to see more security features for Chef and more automation.
Right now, we are moving towards a container department with Docker and Kubernetes, so I'm not sure if Chef has features to support containers. I haven't really researched it yet, but if they can improve their software to support Docker containers, it would be for the best.
I would rate this solution a nine because our use case and whatever we need is there. Ten out of ten is perfect. We have to go to IOD and stuff so they should consider things like this to make it a ten.
The AWS monitoring, AWS X-Ray, and some other features could be improved.
Since we are heading to IoT, this product should consider anything related to this.
They could provide more features, so the recipes could be developed in a simpler and faster way. There is still a lot of room for improvement, providing better functionalities when creating recipes. We would also like more recipes. This is key for us.
One of the biggest things that I miss is in Chef 11 and earlier, organizations were able to be managed directly through the Chef control command line utility. Now, while we prefer to interact directly with the database, there is still some value in being able to have access to the command line utility. While that functionality is still present and in the documentation, it has been broken since Chef 12. We are now looking at Chef 14, and they already have Chef 15 in the pipeline, but there appears to be no effort to fix this functionality, which is definitely broken, provides a false positive for a result when you perform the operation, and doesn't work. It would be nice to have an update to Chef Zero, such that it was more geared toward containers. Before Docker took hold, there was something called Chef Zero Vagrant, which was a plugin for Vagrant which would provision your developer's local copies of their environment for local testing. This was great for the technology, but we haven't seen an evolution of it now that the containerization technology has moved forward.
The time that it takes in terms of integration. Cloud integration is comparatively easy, but when it comes to two-link based integrations - like trying to integrate it with any monitoring tools, or maybe some other ticketing tools - it takes longer. That is because most of the out-of-the-box integration of the APIs needs some revisiting. They should make it into a larger toolset. I would also like to see more analytics and reporting features. Currently, the analytics and reporting features are limited. I'll have to start building my own custom solution with Power BI or Tableau or something like that. If it came with built-in analytics and reporting features that would be great.
In my presentation to SAP engineering, Ansible was chosen over Chef by all the admins for one reason: simplicity. If only Chef were easier to use and code, it would be used much more widely by the community.