A tennis tournament is an awkward customer for an IT department. The audience arrives when the match starts. The deadline does not negotiate. In Chef’s historical account of IBM’s event infrastructure, the team supporting sites for Wimbledon and the US Open treated continuous availability as the test of every technical decision. Individual cloud locations could be taken out of service while the website stayed up. Behind the spectacle sat a rather less glamorous achievement: machines configured well enough to be trusted.
Chef helped IBM automate that work. The attraction was repeatability. A deployment should leave the system in an expected state, without merely exchanging the work of installing software for the work of hunting down failed installations. For anyone who has watched a supposedly identical server develop a personality, this is an appealing ambition.
- The job: configure infrastructure, check compliance and coordinate operational changes.
- The method: write the intended state as code, apply it, then keep testing.
- The buyer: enterprise operations and security teams managing mixed environments.
- The catch: the rules still need owners, tests and maintenance.
The consultants who wrote themselves out of repetition
Before there was Progress Chef, there was a consultancy called HJK Solutions. Adam Jacob later described the starting point as a consulting company having trouble scaling. That is a familiar professional-services predicament: every new client brings revenue, and another claim on somebody’s time. The knowledge lives in people; the work keeps asking those people to show up.
Jacob created Chef there. Jesse Robbins’s account names Jacob, Barry Steinglass and Nathan Haneysmith alongside himself as the four people who set out to build the business in 2008. Steinglass was writing checks for payroll. Haneysmith was keeping clients covered. Some business-plan meetings took place in Seattle’s Cal Anderson Park. Opscode was incorporated on September 12, Robbins’s birthday. It is a charmingly economical origin story: one date, two reasons to buy cake.
The company eventually adopted its product’s name in 2013. The community was part of the commercial logic, too. Jacob wrote that many customers encountered Chef through its open-source community before dealing with the company. Engineers could solve a problem, develop confidence in the tool and arrive at the sales conversation with experience already in hand. The product had done some of the introduction.
A recipe is a promise you can test
Chef’s kitchen vocabulary is useful once you get past the joke. A recipe describes the state you want: a package installed, a file configured, a service running. Related instructions live in a cookbook. Chef Infra applies those declarations to systems. On subsequent runs, it can bring a machine back toward that defined state when configuration has drifted.
Consider an illustrative case: an approved service configuration changes during an urgent repair. A person might remember to restore it later. A policy can specify the required configuration and let automation enforce it. The distinction matters because the urgent repair and the forgotten restoration may be performed by different people, on different shifts, with different ideas about what “temporary” means.
Define. Apply. Check. Repeat.
Chef InSpec gives security and compliance requirements executable tests. It can inspect what is actually present rather than rely on a document saying what ought to be present. Chef’s compliance offerings add prepared content for benchmarks including CIS and DISA STIG. A benchmark is a starting point, however; an organization still has to decide which controls apply and how to handle exceptions.
Habitat tackles a different problem: packaging applications with the dependencies and lifecycle behavior they need to run consistently. Automate provides visibility into configuration and compliance work. Chef 360 brings node management, declarative state management and job orchestration into a control plane, with Courier handling operational jobs. These names describe separate responsibilities. A compliance test does not itself become an application package, and a dashboard does not automatically repair a machine.
The fleet speaks several languages
A revealing detail in SAP’s historical Chef case study is its operating-system mix. The DevOps Center of Excellence managed approximately 10,000 nodes; about 70 percent were Windows servers. This was hardly a pristine fleet of identical Linux boxes. The team had used Bash, PowerShell, Python and other scripts before moving deployments toward a common Chef language.
The case describes a self-service portal through which developers could request machines and more complex environments. It also describes testing and repairing systems to preserve policy as developers made changes. Standardization here did not mean every development team wanted the same thing. It meant the infrastructure group could offer varied services through repeatable machinery.
Facebook’s older case study supplies the other half of the argument. Its cfengine2 setup had become difficult to integrate and test as configurations multiplied. Chef appealed for its flexibility. Production engineer Phil Dibowitz singled out that freedom to adapt the tool. The failure came in the existing operating model: growing complexity made the old approach harder to use.
“For us, the reason that Chef was so attractive was its incredible flexibility.”
Phil Dibowitz / Facebook production engineer
Chef sits among configuration and operations tools such as Ansible, Puppet and Salt. Its current pitch emphasizes continuing state enforcement, compliance and execution governance. The boundaries are porous: Chef 360 can execute existing Ansible playbooks through an interpreter. That lets a team consider Chef as a coordinating layer while retaining useful automation it has already written. In its March 2026 explanation, Chef argues for moving execution authority into centrally governed workflows. That is a positioning claim, not proof that every competing deployment lacks governance.
The bill, and the fine print
Chef makes money from enterprise subscriptions, supported distributions, hosted offerings and services. Its published Chef 360 plans list Business at $59 per node per year and Enterprise at $189; Enterprise Plus requires a custom quote. At those listed rates, 1,000 nodes imply $59,000 or $189,000 annually before negotiated terms or additional costs. That arithmetic is a planning example, not a customer invoice. Buyers also need to examine job allowances, support and the capabilities included in each plan.
$59Business
$189Enterprise
The business had attracted substantial venture backing before Progress bought it. Chef announced $32 million in Series D funding in 2013 and $40 million in Series E in 2015. Progress completed the acquisition in October 2020 for $220 million in cash. At the time of the deal announcement, Progress described Chef as having more than $70 million in annual recurring revenue. Those numbers belong to that transaction period.
The open-source story needs equal care. Chef’s project source code and its official software distributions have different terms. Apache 2.0 source licensing does not turn every supported production download into a free entitlement. Current licensing documentation distinguishes Free, Trial and Commercial tiers. Teams selecting the tool should budget for the distribution and support they will actually use.
Chef’s licensed-download migration notice also contains a useful confession. It recalls customers failing to update endpoints during an earlier move away from Bintray, resulting in broken automation and failed installs. The newer transition uses phased schedules and migration guidance. The copying lesson is prosaic and valuable: an automated installer has dependencies too. An old download URL can spoil an otherwise perfectly good recipe.
The next recipe still needs a taste test
As of October 2026, Chef is managing a platform transition. Its supported-versions page schedules Chef Infra Server 15.x to reach end of life on November 30, 2026, naming Chef 360 as the replacement. Automate’s deprecation is scheduled for November 1, 2026, with end of life a year later. Existing customers therefore have a migration decision alongside their ordinary configuration work.
AI has entered the kitchen as well. Chef opened Opsmith alpha access in February 2026 with Bash generation and Linux sandbox testing. Current documentation describes Bash or PowerShell scripts, sandbox validation and execution on enrolled nodes, with approval available through the workflow. The product page still marks some broader generation features as coming soon. A demo can show a direction without settling every deployment question.
The interesting continuity is the test. Generating instructions faster increases the importance of knowing whether those instructions are suitable. A sandbox and a review step give an operator places to inspect the result before the fleet receives it. They remain dependent on meaningful test conditions and a reviewer who understands the intended change.
Start with the rule everyone keeps forgetting
For a reader considering this approach, a sensible first move is one recurring configuration requirement on a small, representative set of systems. Define the intended state, write a check, review the change and measure what happens across repeated runs. Expand after the policy behaves as expected. This is an editorial recommendation drawn from the method, rather than a promise about implementation time.
The approach needs supported platforms, usable connectivity, clear ownership and people able to maintain the automation. Where the policy is disputed, the test is incomplete or legitimate exceptions are ignored, repetition can spread the wrong decision efficiently. Chef’s most portable idea is to make operational knowledge inspectable. Write down what the machine should do in a form that people can review and software can test. Then give the rule a responsible owner.