What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Short answer: Build the environment in this order: prepare an x86_64 Ubuntu 20.04 or 22.04 VPS with working DNS, NTP, and HTTP/HTTPS access; install Chef Infra Server and run chef-server-ctl reconfigure; create an administrator and organization; install Chef Workstation on a separate administration machine; then use knife bootstrap over SSH (or WinRM) to install Chef Infra Client and register each node.

Important lifecycle warning: Progress Chef documents that “Chef Infra Server is deprecated and will reach end-of-life status in November 2026.” A new production deployment should therefore include a migration or replacement checkpoint rather than assuming the server will be supported indefinitely.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

What you are building

Chef uses three distinct roles. The Chef Infra Server stores cookbooks, policies, node objects, environments, and authentication data. The Chef Workstation is the control plane where you run knife, create and test cookbooks, and manage keys. A Chef Infra Client node is any physical, virtual, or cloud device maintained by an instance of Chef Infra Client.

Component Where it runs Purpose Required trust material
Chef Infra Server Ubuntu VPS Central API, cookbook storage, node registration, policy and search data Server TLS certificates and administrator/organization data
Chef Workstation Your administration computer or a secured management VM knife, cookbook authoring, Test Kitchen, Cookstyle, InSpec and related tools Administrator or user PEM plus organization key
Chef Infra Client Each managed server or VM Downloads policy and cookbooks, converges resources, and reports results Validator or user-based bootstrap credentials, then a client identity

A single VPS can be adequate for a laboratory or proof of concept. A production design needs backups, monitoring, tested recovery, DNS redundancy, access controls, and a plan for the announced November 2026 server end of life.

Prerequisites and support boundary

Supported server platform

  • Use an x86_64 Ubuntu 20.04 or Ubuntu 22.04 installation. The cited Chef server support matrix does not establish support for every Ubuntu release or for ARM images.
  • Give the VPS a stable hostname and a resolvable fully qualified domain name (FQDN), or use a stable IP address where your design permits it. The name must resolve correctly from the workstation and from nodes that contact the server.
  • Synchronize the server, workstation, and nodes with NTP. Clock drift can break TLS validation and signed requests even when passwords and keys are correct.
  • Permit the Chef server traffic required by the installation, including inbound TCP ports 80 and 443. Keep SSH access available for administration, and apply your provider firewall and Ubuntu firewall policy without blocking required Chef traffic.

Network and access checklist

  • An SSH account with sudo or root access on the Chef server VPS.
  • An SSH account with root privileges, or sudo that can become root, on every node you will bootstrap.
  • DNS records or a tested IP path from workstation to server and from node to server.
  • A way to transfer the administrator, organization, and client trust files securely. Never place PEM keys in a public repository or paste them into tickets or chat.
  • A staging node on which to test the first bootstrap before enrolling production systems.

Choose sizing from workload, not a universal number

Chef’s installation material does not publish one CPU, memory, or storage recommendation that fits every VPS. Size for the number of nodes, cookbook and search complexity, backup frequency, log and data retention, and any indexing load. Measure a staging run, leave headroom for reconfiguration and backups, and revisit the choice as the node population grows.

Prepare the Ubuntu VPS

  1. Set the hostname and DNS. Choose a name such as chef.example.net, set it with your provider or hostnamectl, and create an A/AAAA record that resolves to the VPS. From the workstation, verify the same name resolves to the expected address before installing Chef.
  2. Update the base system. Apply your normal Ubuntu security updates and reboot if the kernel or core services require it. Do not remove packages required by the provider’s management agent before confirming how you will recover the VPS.
  3. Enable time synchronization. On systems using systemd time synchronization, sudo timedatectl set-ntp true enables it. Confirm that the reported time and synchronization state are correct; repeat the check on the workstation and each node.
  4. Open only the necessary ports. If you use UFW, an example is sudo ufw allow 22/tcp, sudo ufw allow 80/tcp, and sudo ufw allow 443/tcp, followed by your organization’s normal UFW enablement and review. Apply equivalent rules in the VPS provider firewall. Restrict SSH to trusted source addresses where practical.
  5. Test reachability. From the workstation, resolve the FQDN and test TCP connectivity to ports 80 and 443. From a prospective node, test the same HTTPS path. A successful ping alone does not prove that the Chef API is reachable.

Install Chef Infra Server

Obtain and copy the server package

Download the current Chef Infra Server package that matches the supported Ubuntu architecture from Chef’s official distribution channel. Copy the Ubuntu .deb to the VPS, for example with an authenticated file-transfer method, and place it in /tmp or another administrator-only directory. Verify the package name and checksum using the release information supplied with the download before installing it.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Install the package and configure services

  1. Install the package with a command such as sudo dpkg -i /tmp/chef-server-core-<version>.deb.
  2. Run sudo chef-server-ctl reconfigure. Chef notes that the server’s collection of services makes this operation take several minutes. Wait for it to finish instead of interrupting it because the terminal appears idle.
  3. Review the command output for failures. If dpkg reports missing dependencies, resolve the Ubuntu package dependency problem, rerun the package installation, and then run chef-server-ctl reconfigure again.

Create the administrator and retain its private key

Create an administrator account and write its private key to an absolute path that you can later copy to the workstation:

sudo chef-server-ctl user-create USER_NAME FIRST_NAME LAST_NAME EMAIL 'PASSWORD' --filename /absolute/path/admin.pem

Use a long, unique password and protect the resulting admin.pem. The key is a credential, not a configuration sample. Store it outside web roots, set restrictive permissions, and keep an encrypted backup in accordance with your security policy.

Create an organization

An organization is the namespace in which nodes, cookbooks, policies, and environments are administered. Using the administrator identity, create the organization and save its validator key. A typical command is:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

sudo chef-server-ctl org-create ORG_NAME 'Organization Name' --association_user USER_NAME --filename /absolute/path/org-validator.pem

Use a lowercase, stable short name for ORG_NAME. Keep both the administrator key and organization validator key private; the validator is a trust anchor used by the normal first-boot flow.

Install Chef Workstation

Install Workstation on a secured Ubuntu or Debian administration machine, not necessarily on the Chef server. Workstation bundles Chef Infra Client, Chef InSpec, Chef Habitat, knife, Test Kitchen, Cookstyle, and other cookbook tools.

  1. Download the current supported Workstation Debian package for amd64.
  2. Install it with sudo dpkg -i chef-workstation_<WORKSTATION_VERSION>-1_amd64.deb.
  3. Verify the installation with chef -v. Record the Workstation and bundled Chef Client versions in your deployment notes.

If dpkg reports dependencies, correct the operating-system package state and repeat the installation. Do not mix packages from unrelated architectures.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Configure the workstation and its keys

Create the Chef configuration directory

On the workstation, create a private .chef directory in the repository or working directory you will use for this organization:

mkdir -p ~/chef-repo/.chef
chmod 700 ~/chef-repo/.chef

Copy admin.pem and org-validator.pem into that directory through an encrypted transfer. Set key permissions to owner read/write only, for example chmod 600 ~/chef-repo/.chef/*.pem. If several people administer the organization, issue individual user keys instead of sharing the administrator key.

Generate or edit knife configuration

Run knife configure and answer the prompts for the server URL, user name, key path, and organization. The resulting knife.rb should point to the organization endpoint and the correct PEM file. A minimal pattern looks like this:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
current_dir = File.dirname(__FILE__)
log_level                :info
log_location             STDOUT
node_name                'USER_NAME'
client_key               "#{current_dir}/USER_NAME.pem"
chef_server_url          'https://chef.example.net/organizations/ORG_NAME'
validation_client_name   'ORG_NAME-validator'
validation_key           "#{current_dir}/org-validator.pem"

Replace the example names with your actual values. The administrator’s user key is used for administration; the organization validator is used by the normal validator bootstrap. Keep the configuration and keys in a protected directory, and check that no private key is accidentally committed to source control.

Bootstrap the first Chef client node

Prepare the target node

  • Confirm the node’s IP address or FQDN and ensure it resolves from the workstation.
  • Confirm that SSH is listening and that the chosen account can authenticate with a password or SSH key.
  • Ensure the account can become root. The --sudo option tells knife to use sudo during installation.
  • Verify outbound HTTPS from the node to the Chef server and confirm that its clock is synchronized.

Run knife bootstrap

From the directory containing your knife.rb and PEM files, run:

knife bootstrap <ADDRESS> -U <USERNAME> --sudo --chef-license-key <LICENSE>

Use the address that the node can use to reach the server, the SSH account name, and the license or current authentication option required by the Chef Client release you installed. Run knife bootstrap --help on the installed Workstation if the release uses a different license or authentication flag.

The bootstrap command connects over SSH by default. It installs Chef Infra Client on the target, writes first-boot configuration, starts chef-client, and registers the node with the Chef server over HTTPS. A successful first run should leave a node object and client identity visible to the organization.

Use WinRM when SSH is not the transport

Windows targets or environments that standardize on Windows Remote Management can use the WinRM bootstrap transport. The requirements remain the same: a reachable node name or address, credentials with administrative rights, firewall access, and a Workstation version whose bootstrap options match the installed Client. Consult the installed knife bootstrap help for the exact WinRM flags rather than copying SSH options.

Choose the bootstrap authentication flow

Flow Credential used for first registration Configuration requirements When to choose it
Organization-validator flow The organization validator PEM referenced by validation_client_name and validation_key Validator key must be present and readable on the workstation; the organization name must match the server endpoint Normal first-boot flow for a newly created node
Validatorless flow A user PEM with permission to create or register the node Remove the validator key reference and provide --node-name; use a user identity that the server authorizes Environments that intentionally avoid distributing an organization validator

Validatorless bootstrap is not just a different command-line switch. The validator reference must be removed, a user key must be available, and --node-name is required. Decide which model your security policy permits before running the first bootstrap.

Certificate trust and key handling

For an on-premises or privately signed Chef server certificate, knife ssl fetch can retrieve the server certificate to the workstation’s trusted configuration. Review the certificate and hostname before accepting it; fetching a certificate is not a substitute for validating that you reached the intended server.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

During bootstrap, client configuration files under client.d may be copied from the workstation to the node. Treat those files as sensitive because they can contain server endpoints, identity settings, or paths to credentials. Remove temporary copies and keep the node’s final configuration readable only by the account that runs Chef.

Verify the installation

Check the workstation

  • Run chef -v and record the Client and Workstation versions.
  • Run a harmless knife command against the organization to confirm that the server URL, user name, and PEM path are correct.
  • Confirm that the workstation clock and the Chef server clock agree.

Check the node and first run

After bootstrap, use your organization’s normal knife node list and knife node show NODE_NAME checks to confirm that the node object exists and reports the expected environment and run-list data. On the node, run sudo chef-client for a controlled second convergence and inspect the output for cookbook, certificate, or permission errors.

Confirm server health

On the VPS, use the Chef server control commands supplied with the installed release to inspect service status and logs. Verify that HTTPS is presenting the expected certificate, that the hostname used by clients resolves consistently, and that your backup process includes Chef server data and key material without exposing private keys.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Keep Client and Workstation versions compatible

Chef’s current bootstrap documentation states that Chef Infra Client 19 or later requires Chef Workstation 26 or later. Pin and document the pair you intend to deploy, then verify both ends before a production rollout.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Client line Workstation requirement stated by Chef Action
19 or later Workstation 26 or later Install or upgrade Workstation first, run chef -v, and test a staging bootstrap
Older supported Client combinations Not a single universal pairing Check the live compatibility documentation for the exact release pair and record it in change management

Do not assume that a successful package installation proves compatibility. A controlled bootstrap exercises SSH, the license or authentication flow, certificate trust, server API access, and cookbook execution together.

Troubleshooting by symptom

chef-server-ctl reconfigure appears stuck

Reconfiguration can take several minutes because multiple server services are configured. Wait for completion and inspect the terminal output and server logs before interrupting it. If it exits with an error, correct the named dependency, hostname, certificate, or disk issue and rerun the command.

The server package will not install

Check that the package is the Ubuntu amd64 build and that the VPS is x86_64. Resolve any dpkg dependency errors, then rerun dpkg -i and chef-server-ctl reconfigure. Do not install an ARM package on an x86_64 VPS or vice versa.

knife bootstrap cannot connect

  • For an SSH failure, verify the address, username, SSH key or password, port, and sudo rights. Test a direct SSH login from the same workstation.
  • For an HTTPS failure, verify DNS, ports 80/443, the server certificate name, and the node’s clock.
  • For a timeout, inspect both the VPS provider firewall and Ubuntu firewall; opening a port in only one of them may not be sufficient.

The first run returns an authentication or 401 error

Check that knife.rb points to the correct organization URL, that the organization name matches the validator key, and that the PEM file is readable and unmodified. In a validatorless flow, remove the validator reference, use an authorized user key, and supply --node-name.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The node registers but cookbook convergence fails

Separate registration from cookbook execution. First confirm that the node object and client identity exist. Then inspect the run output for missing cookbooks, an incorrect run list, unavailable dependencies, or a certificate problem. Correct the policy or cookbook issue and run sudo chef-client again on the node.

Versions do not work together

Compare the installed versions from chef -v with the compatibility requirement. In particular, do not pair Client 19 or later with a Workstation older than 26. Upgrade or pin the versions as a tested set, then repeat the staging bootstrap.

Lab deployment versus production deployment

Concern Single-server lab or proof of concept Production posture
Topology One Ubuntu VPS running the server, with a separate workstation Documented architecture with provider redundancy, tested restore procedures, and monitored dependencies
DNS and certificates One stable FQDN and a certificate appropriate for the test scope Managed DNS, certificate renewal ownership, and documented trust distribution
Backups Manual encrypted backup before experiments Scheduled, encrypted backups with retention, restore tests, and protected key escrow
Operations Administrator observes reconfigure and client runs directly Centralized logs, alerting, change control, least-privilege user keys, and a tested rollback path
Lifecycle Acceptable for learning or a temporary evaluation Migration or replacement review scheduled before the November 2026 Chef Infra Server end of life

Pre-production checklist

  • The server runs a supported x86_64 Ubuntu 20.04 or 22.04 release.
  • The FQDN resolves correctly from the workstation and all nodes.
  • NTP is working on the server, workstation, and nodes.
  • Ports 80 and 443 are reachable where Chef requires them, while SSH is restricted appropriately.
  • chef-server-ctl reconfigure completed successfully.
  • An administrator was created and its private key is encrypted, backed up, and not committed to source control.
  • An organization was created and its validator key is protected, or the validatorless procedure is documented.
  • Workstation installation succeeded and chef -v shows the versions you intend to use.
  • The workstation’s .chef directory and PEM permissions have been reviewed.
  • A staging node completed knife bootstrap, registered, and completed a controlled chef-client run.
  • Backups, monitoring, certificate renewal, and the post-November-2026 migration decision have named owners.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.