Loading content
Chef is an infrastructure automation and configuration management technology that models system configuration as code using a Ruby-based DSL. It organizes policies into cookbooks and recipes, enabling idempotent, repeatable provisioning across servers and cloud instances. Chef integrates with cloud providers, secrets and compliance systems to automate config…
Use this profile to understand the building block briefly, place it in the model, and open related building blocks.
Technical building block: can be automated, integrated, or operated.
Concrete cog in the system that works inside larger relationships.
Chef automates infrastructure by describing system state as code and enforcing it repeatedly across servers and cloud instances.
Chef grew out of the need to manage server and deployment configuration reproducibly and to correct drift automatically. Adam Jacob first built the tool for his consulting work; it was announced in 2009 and, with Jesse Robbins, Barry Steinglass, Nathen Haneysmith, and Joshua Timberman, was turned into a product at the new company Opscode. The early project name was "marionette".
Chef works like a desired-state machine built around cookbooks and recipes. A client reads a cookbook whose recipes describe resources such as packages, services, or files. On each run, Chef checks a node's current state, compares it with the target, and brings divergent resources back into the desired state. Repeated runs therefore converge instead of compounding changes.
Chef keeps system configuration documented, deployable, and verifiable as code.
Cookbooks bundle related policies and make them manageable as a reusable unit.
Recipes describe concrete configuration steps and how individual resources should be handled.
Resources represent states such as packages, services, files, or user accounts.
Multiple runs should produce the same desired state without unnecessary side effects.
Chef is useful when many servers or cloud instances must receive the same configuration, for example during provisioning, deployment, or compliance enforcement. It reduces manual drift and makes changes traceable. The trade-off is ongoing maintenance of cookbooks, the Ruby DSL, and the operational logic around client/server, secrets, and error handling; for small, rarely changing setups, that overhead may outweigh the benefit.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.