Chef: Infrastructure Automation Guide

By Kokil Thapa | Last reviewed: September 2026

Your servers drift the moment someone SSHs in and edits a config by hand. Chef: Infrastructure Automation Guide material exists because that drift breaks deployments, audits, and incident response. Chef Infra turns server state into versioned Ruby cookbooks that a client applies on a schedule. If you already use Terraform for infrastructure as code, Chef handles what Terraform leaves on the box: packages, users, services, and application runtime settings. This guide walks through a practical Chef workflow you can run on Ubuntu 22/24 hosts that serve PHP, Laravel, and WordPress stacks.

What is Chef and how does infrastructure automation with Chef work?

Chef is a configuration management platform built around resources, recipes, and cookbooks. You declare what a node should look like; the Chef Infra Client reads that code and brings the machine into compliance. The model is declarative at the recipe level and imperative at the resource level, which gives you fine control without shell-script spaghetti.

At runtime, Ohai collects node attributes—hostname, platform, memory, network interfaces—and merges them with cookbook defaults and role overrides. The client builds a resource collection, compares current state to desired state, and runs only the actions needed. That idempotent loop is the same principle covered in idempotent infrastructure principles, and it is why Chef fits long-lived VPS and bare-metal fleets.

Three deployment shapes matter in 2026:

• Chef Infra Server — central API, node objects, environment pins, and role assignments. Best for teams above a handful of nodes.
• chef-zero / local mode — no server; the client reads cookbooks from disk. Fine for learning and small fleets.
• Policyfiles — modern workflow that locks cookbook versions into a single policy archive. Prefer this over legacy Berkshelf + environments when starting fresh.

Chef does not replace your entire stack. Pair it with Terraform for cloud objects, Packer for golden images, and GitLab CI for pipeline gates. On sister sites I maintain with Deployer 7, Chef-style discipline—everything in Git, nothing manual on prod—mirrors what build pipeline automation best practices preach, even when the actual config tool is Ansible or shell plus CI.

How do you install Chef Workstation and bootstrap your first node?

Start on a Linux or macOS admin machine. Install Chef Workstation, which bundles chef, knife, Cookstyle, Test Kitchen, and InSpec. Official packages live on the Progress Chef download site; verify checksums before install.

Install Chef Workstation on Ubuntu

wget https://packages.chef.io/files/stable/chef-workstation/latest/ubuntu/24.04/chef-workstation_amd64.deb
sudo dpkg -i chef-workstation_amd64.deb
chef -v
knife -v

Create a cookbook repo skeleton:

chef generate repo infra-chef
cd infra-chef
chef generate cookbook cookbooks/base_server
chef generate cookbook cookbooks/laravel_app

Bootstrap a node with knife

Bootstrapping installs the Chef Infra Client and registers the node against your Chef Server. Replace placeholders with your values.

knife bootstrap 203.0.113.10 \
  -x deploy \
  --sudo \
  --node-name web01.prod \
  --run-list 'recipe[base_server]' \
  --ssh-verify-host-key never

For policyfile-first workflows, export a locked policy and apply it during bootstrap:

cd cookbooks/base_server
chef install
chef export base-prod --archive-policyfile
knife bootstrap 203.0.113.10 -x deploy --sudo \
  --policy-name base-prod \
  --policy-group production

On a real client project hosting Laravel 12 on Ubuntu 24.04, I treat bootstrap like a contract. The node must land with PHP 8.3 FPM, Redis, UFW rules, and log rotation before Deployer ever runs. That ordering prevents the classic “app deploy succeeded but PHP extension missing” failure mode described in Linux system administration support work.

How do you write Chef cookbooks and recipes for production servers?

A cookbook is a reusable unit. A recipe is a Ruby file listing resources. A resource maps to a concrete system item—package, service, template, user, and hundreds more.

Example: base PHP-FPM recipe for Laravel

This recipe installs PHP 8.3, enables FPM, and templates a pool file. Adjust version pins to match your app; Laravel 13 needs PHP 8.3 or higher.

# cookbooks/laravel_app/recipes/php_fpm.rb
package 'php8.3-fpm' do
  action :install
end

template '/etc/php/8.3/fpm/pool.d/app.conf' do
  source 'app.conf.erb'
  owner 'root'
  group 'root'
  mode '0644'
  variables(
    app_user: node['laravel']['user'],
    memory_limit: node['laravel']['memory_limit']
  )
  notifies :restart, 'service[php8.3-fpm]', :delayed
end

service 'php8.3-fpm' do
  action [:enable, :start]
end

Pair it with attributes in attributes/default.rb:

default['laravel']['user'] = 'deploy'
default['laravel']['memory_limit'] = '256M'
default['laravel']['docroot'] = '/var/www/app/current/public'

Use a role or policy group to compose recipes:

# roles/web.json (legacy) — prefer Policyfile run lists
{
  "name": "web",
  "run_list": [
    "recipe[base_server::firewall]",
    "recipe[base_server::users]",
    "recipe[laravel_app::php_fpm]",
    "recipe[laravel_app::nginx_site]"
  ]
}

Wrap repeated patterns in custom resources. If you configure ten similar vhosts across legal-tech portals, one resource beats ten copy-pasted recipe blocks. Keep secrets out of Git; load passwords from Chef Vault, HashiCorp Vault, or cloud secret stores via node data bags populated at bootstrap.

Validate JSON policy files and attribute hashes early. A quick pass through a JSON formatter and validator catches trailing commas before CI wastes ten minutes on a Kitchen run.

Chef vs Ansible vs Puppet: which configuration tool fits your team?

Teams often pick Chef when they want Ruby-native extensibility, strong enterprise support, and a mature compliance story with InSpec. Ansible wins on agentless SSH simplicity. Puppet excels at large declarative catalogs with strict ordering.

Read the fuller breakdown in Ansible vs Puppet vs Chef vs Salt. My default for a five-node Laravel fleet in Nepal is still often Ansible or plain GitLab CI plus Deployer, because the team can read YAML on day one. Chef earns its place when compliance audits, heterogeneous OS mixes, or policy-driven rollouts justify the agent footprint and Ruby skill investment.

How do you test Chef cookbooks before touching production?

Untested cookbooks are production incidents waiting for a maintenance window. Use Test Kitchen to spin up ephemeral VMs or containers, apply your cookbook, and verify with InSpec assertions.

Test Kitchen workflow

1. Define a Kitchen.yml driver — Docker for speed, Vagrant or cloud for fidelity.
2. Point the suite at your cookbook and run list.
3. Run kitchen converge to apply recipes.
4. Run kitchen verify to execute InSpec profiles.
5. Destroy the instance or integrate the job into GitLab CI.

# Kitchen.yml excerpt
---
driver:
  name: dokken
  chef_version: 18

provisioner:
  name: chef_infra
  product_name: chef
  install_strategy: always

platforms:
  - name: ubuntu-24.04

suites:
  - name: default
    run_list:
      - recipe[laravel_app::php_fpm]
    verifier:
      name: inspec

# test/integration/default/default_test.rb
describe package('php8.3-fpm') do
  it { should be_installed }
end

describe service('php8.3-fpm') do
  it { should be_enabled }
  it { should be_running }
end

Run Cookstyle locally and in CI to enforce Ruby style:

cookstyle cookbooks/
kitchen test

This mirrors the testing mindset in testing infrastructure code with Terratest, but for OS-level resources instead of cloud APIs. Wire Kitchen into the same pipeline that runs build automation jobs so cookbook merges cannot skip verification.

External references worth bookmarking: the official Chef documentation for resource syntax, and the Chef Infra Client repository when you need to understand client behaviour at the source level.

How do you operate Chef safely in production web stacks?

Production Chef is less about writing recipes and more about change control. Pin cookbook versions, segregate environments, and treat the Chef Server API like production infrastructure.

Operational checklist

• Run the client every 15–30 minutes via systemd timer or cron, not only on deploy day.
• Upload cookbooks through CI after Kitchen passes; block manual knife cookbook upload on prod.
• Separate staging and production policy groups; promote by bumping the policy revision, not editing live nodes.
• Log to Chef Automate or ship JSON reports to your SIEM if compliance requires it.
• Keep handler cookbooks for Slack or email alerts when convergence fails twice in a row.

Chef complements application deploy tools. Deployer swaps Laravel releases; Chef keeps PHP-FPM pools, opcache settings, and system users stable underneath. That split appears across projects like Adventure Third Pole Trek and the notary sister sites on shared EC2, where Laravel Envoy handles app tasks while baseline OS config stays scripted.

For immutable layers, bake a Packer image with baseline hardening, then let Chef finish node-specific tuning. See immutable infrastructure with Packer for the image half of that pattern. If you are Kubernetes-heavy, platform teams sometimes prefer Crossplane for cloud APIs while Chef still configures worker AMIs.

Cost reality for Nepal SMBs: a managed Chef Server or Automate licence can exceed Rs 15,000/month (~USD 110) before cloud fees. Chef Solo and policyfile archives on object storage reduce that to software labour only. Price the Ruby maintenance hours honestly when comparing against Ansible, which many agencies already know from Ansible roles work.

When convergence breaks after a PHP upgrade, check Ohai output first, then run chef-client -l info once manually. Nine times out of ten the failure is a template variable missing after you renamed a node attribute. Document attribute contracts the same way you document API payloads on API development engagements.

Security basics still apply. Restrict sudo on bootstrap users, rotate validator keys, and firewall the Chef Server API to admin IPs. Pair automated config with vulnerability management automation so package resources bump OpenSSL and curl without waiting for a quarterly ticket.

Need a human review of your fleet? Support and maintenance covers the same Ubuntu, MySQL 8.4, and PHP-FPM stacks Chef manages. For greenfield platforms, enterprise application development includes IaC choices during architecture, not after launch.

Key Takeaways

• Model servers as cookbooks under Git; never treat SSH edits as the source of truth.
• Prefer Policyfiles over legacy environment pins when starting a new Chef repo in 2026.
• Run Test Kitchen and InSpec on every merge before any cookbook touches staging nodes.
• Use Chef for continuous drift correction; pair it with Terraform for cloud provisioning.
• Compare agent overhead against Ansible push runs—small teams may trade Ruby power for YAML speed.
• Promote policy revisions through staging groups, and roll back by redeploying the last known-good archive.

People Also Ask

Is Chef still maintained and relevant in 2026?

Yes. Progress Software maintains Chef Infra, Workstation, and InSpec. Enterprise fleets still rely on pull-based convergence and compliance profiles. Community cookbooks on the Supermarket remain active, though many greenfield teams also evaluate Ansible or cloud-native tooling.

Do I need a Chef Server for a small VPS fleet?

Not necessarily. Policyfile archives stored in S3-compatible object storage plus periodic chef-client runs can serve five to twenty nodes. Add a Chef Server when you need granular ACLs, search indexes across nodes, and central reporting at scale.

Can Chef manage Windows and Linux in the same org?

Chef Infra supports both platforms with separate cookbooks and Ohai plugins. Mixed fleets were Chef’s historical strength. Verify each resource exists on the target OS, and split cookbooks rather than branching every recipe with heavy if platform? logic.

How does Chef relate to GitOps?

GitOps usually means declarative Kubernetes manifests reconciled by a controller. Chef applies the same reconcile idea to VMs and bare metal. Read GitOps for infrastructure vs application to decide where Chef fits beside Argo CD or Flux.

Ship repeatable servers, not one-off fixes

A solid Chef: Infrastructure Automation Guide workflow turns your baseline Ubuntu image into a tested, promotable policy archive. Start with one cookbook—PHP-FPM, Nginx, UFW—and prove convergence in Kitchen before you bootstrap production. Layer in compliance scans, CI uploads, and staging groups as the fleet grows. If you want help mapping Chef, Ansible, or Deployer into one pipeline for a Laravel or legal-tech platform, contact us or browse the Notary Kathmandu deployment story for a real multi-site example. More background lives on the about page and in zero-downtime infrastructure updates for the Terraform side of the same problem.