You can build a complete Chef environment on an x86_64 Ubuntu 20.04 or 22.04 VPS by installing Chef Infra Server, configuring Chef Workstation with administrator and organization keys, then using knife bootstrap over SSH (or WinRM) to register client nodes. Progress Chef currently marks Chef Infra Server as deprecated and says it will reach end-of-life in November 2026, so treat a new deployment as a lab, proof of concept, or temporary platform unless you already have a documented migration plan.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Decide whether an Ubuntu VPS is the right target
The server platform covered by Chef’s current installation documentation is x86_64 Ubuntu 20.04 or Ubuntu 22.04. A resolvable fully qualified domain name (FQDN) or stable IP address, network time synchronization, and reachable HTTP and HTTPS ports are prerequisites. A VPS provider is suitable when it gives you a persistent address, reverse and forward DNS control, snapshots or backups, and a firewall you can configure precisely.
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Chef does not publish one universal CPU, memory, or storage size for every installation. Select capacity from the number of nodes, cookbook and role complexity, search and indexing activity, backup retention, and log volume. Start with the provider’s normal small production tier for a staging test, measure a complete converge, and increase resources before onboarding production nodes. Do not mistake a successful installation on a tiny test VPS for a sizing recommendation.
| Requirement | What to verify before installing |
|---|---|
| Operating system | x86_64 Ubuntu 20.04 or 22.04 |
| Name and address | An FQDN or stable IP that resolves to the server from the workstation and client networks |
| Time | NTP or another reliable time-synchronization service on server, workstation, and nodes |
| Network | HTTP (80) and HTTPS (443) allowed where Chef’s prerequisites require them; SSH must also be reachable for a normal bootstrap |
| Administration | Provider console or recovery access, a sudo-capable account, and a tested backup path |
Prepare the VPS safely
- Deploy the supported Ubuntu image in the VPS provider’s console. Choose x86_64 rather than an ARM image unless the current Chef support matrix explicitly lists your architecture.
- Set a stable hostname, such as
chef.example.net, and create matching forward DNS. Test resolution from the workstation and every network that will runchef-client. If reverse DNS is available, set it to the same name. - Enable NTP. Clock drift can invalidate TLS certificates and authentication signatures even when every key is correct. Confirm that the server reports synchronized time before creating users or organizations.
- Apply the provider’s SSH hardening: use a named administrative account, key-based login, and a restricted root-login policy appropriate to your recovery process. Keep console access available while testing changes.
- Configure the VPS firewall and any provider security group. Permit only the required management and Chef traffic. Chef’s prerequisites call out ports 80 and 443; permit SSH from the workstation or administration network for bootstrapping, and do not expose a database or internal management port publicly.
- Update the operating system and reboot if the kernel or security updates require it. Recheck the hostname, DNS, NTP status, and firewall after the reboot.
Record the exact hostname, public or private address, Ubuntu release, and firewall rules in your deployment notes. Those details are needed when a later bootstrap fails before it even reaches Chef authentication.
Install Chef Infra Server
Obtain and transfer the package
Download the Chef-provided server package that supports your Ubuntu release and architecture. Transfer the Ubuntu .deb to the VPS, preferably over an authenticated administrative channel, and verify the file before installation using the checksum or signature information supplied with the package.
Install the package and configure services
- Place the package in a temporary directory on the server, for example
/tmp/chef-server-core-<version>.deb. - Install it with
sudo dpkg -i /tmp/chef-server-core-<version>.deb. Ifdpkgreports missing dependencies, resolve them with the package manager, then rerun the installation rather than ignoring the error. - Run
sudo chef-server-ctl reconfigure. Chef’s server is a composition of several services, so this step can take several minutes. Keep the terminal connected until it completes and read any error output. - Check the service status with the
chef-server-ctlstatus commands documented for your package version. A completed reconfigure is not a substitute for checking that all required services are running and that the FQDN resolves locally and remotely.
Create the administrator and protect its private key
Create an administrator account and write its private key to an absolute path that only the administrator can read:
sudo chef-server-ctl user-create USER_NAME FIRST_NAME LAST_NAME EMAIL 'PASSWORD' --filename /absolute/path/admin.pem
Replace the placeholders with your own values. Use a long, unique password and store admin.pem in an encrypted password or secrets-management system. The key is a trust anchor: anyone who obtains it can administer the Chef server. Do not commit it to a cookbook repository, paste it into a ticket, or leave it in a world-readable home directory. Make an encrypted backup and verify that you can recover it before removing the original temporary copy.
Create an organization and lay out the workstation keys
Chef separates the human administrator from an organization (also called an organization or Chef organization in the server tooling). Use the administrator key to create or administer the organization through the current Chef server workflow, then download or generate the organization credentials required by your bootstrap method. The exact organization identifier and key filename are part of your own configuration, so record them alongside the server FQDN.
On the workstation, create a private directory named .chef in the account that will run knife. Place the administrator user key and organization key there, for example:
Free tools Windows power users keep installed
One-click scans. No signup required.
~/.chef/admin.pemfor the administrator user key.~/.chef/<organization>-validator.pemwhen using the normal organization-validator bootstrap flow.- A
knife.rbconfiguration that names the server URL, organization, user, and key paths.
Restrict the directory and PEM files to the workstation account (for example, mode 700 on the directory and mode 600 on each key). If you use a separate automation account, give it only the keys and permissions it needs. Never send PEM files to a client node unless the bootstrap design explicitly requires a short-lived copy.
Install Chef Workstation on Ubuntu or Debian
Chef Workstation is the control plane for this setup. It bundles Chef Infra Client, Chef InSpec, Chef Habitat, knife, Test Kitchen, Cookstyle, and other cookbook authoring and testing tools.
- Download the current supported Chef Workstation Debian package for your architecture. The filename follows the pattern
chef-workstation_<WORKSTATION_VERSION>-1_amd64.deb. - Install it with
sudo dpkg -i chef-workstation_<WORKSTATION_VERSION>-1_amd64.deb. Resolve dependencies with your distribution package manager if the installer reports any. - Open a new shell if the installer changed your
PATH, then verify the toolchain withchef -v. The output should identify Chef Workstation and the bundled Chef Infra Client version. - Copy the administrator and organization PEM files into the workstation’s
.chefdirectory and complete theknife.rbsettings for your server FQDN, organization, user, and key. Keep the configuration in a private location and test that the workstation can resolve the server before attempting a node bootstrap.
Use this machine for cookbook development, linting, testing, uploads, node searches, and bootstraps. Avoid administering the server by copying private keys among several laptops; a dedicated workstation or controlled automation host gives you a clearer audit boundary.
Bootstrap the first Chef client node
Confirm the node before connecting
The target node can be another VPS, a physical server, or a cloud instance. Confirm its IP address or FQDN, operating-system support, SSH reachability, and credentials for an account that can obtain root privileges. Check that the node’s clock is synchronized and that outbound HTTPS access to the Chef server works. A node is any physical, virtual, or cloud device configured and maintained by an instance of Chef Infra Client.
Run a standard SSH bootstrap
From the workstation, run:
knife bootstrap <ADDRESS> -U <USERNAME> --sudo --chef-license-key <LICENSE>
Replace <ADDRESS> with the node’s FQDN or IP, <USERNAME> with the SSH account, and <LICENSE> with the current license or authentication option required by the Chef Client release you selected. Knife connects over SSH by default, installs Chef Infra Client, writes first-boot configuration, runs chef-client, and registers the node with Chef Infra Server over HTTPS. Follow the prompts for the SSH password or key and inspect the complete first-run output.
When the run succeeds, the node appears in the organization and its first converged state is visible from the workstation. Immediately perform a harmless search or node inspection with knife, then check the server’s node and client records. Do not declare success solely because the installer copied files; registration and a completed first run are the useful milestones.
Use WinRM when SSH is not the transport
Knife also supports WinRM bootstrapping for Windows targets. Select the WinRM transport and credentials documented for your Workstation release, ensure the target firewall permits the required WinRM endpoint, and apply the same checks for DNS, time, privilege, server reachability, and key handling. The server-side registration and first-run expectations are the same even though the transport differs.
Recommended Free Tools
Choose the bootstrap trust model
| Model | How it authenticates the new node | Important configuration | When to choose it |
|---|---|---|---|
| Organization-validator flow | The organization validator PEM authenticates a newly created node during the normal bootstrap. | Keep the validator key available to knife, protect it like any private key, and make sure the organization name and key path match knife.rb. |
Useful for the conventional first-boot process and environments that still manage validator credentials centrally. |
| Validatorless flow | A user PEM authenticates the bootstrap instead of the organization validator. | Remove the validator-key reference, supply the user key, and include --node-name. Follow the current Workstation authentication syntax. |
Useful when you want node creation tied to a specific user identity and do not want a validator key on the bootstrap host. |
Do not mix the two models halfway through a run. A validatorless attempt that still points to a validator key can fail with confusing authentication or node-name errors. Whichever model you choose, retain an audit record of who owns the key and how it is rotated.
Handle certificates and first-run files
For an on-premises or privately addressed server whose certificate is not already trusted by the workstation, fetch the server certificate with knife ssl fetch and review the fetched certificate before trusting it. A certificate copied without verification can turn a connectivity fix into a man-in-the-middle vulnerability.
During bootstrap, client configuration files can be copied from the workstation to the node. Treat every copied client.d file and PEM as sensitive, confirm ownership and permissions after transfer, and remove temporary material that the node does not need after its first run. If TLS verification fails, check the server name in the certificate, DNS resolution, system clocks, and the trust files before changing verification settings.
Check compatibility before adding more nodes
Chef’s current bootstrap documentation states that Chef Infra Client 19 or later requires Chef Workstation 26 or later. Pin and document the Workstation and Client versions as a pair, run chef -v on the workstation, and perform a controlled bootstrap in staging before a production rollout. Older combinations may be valid only when the live compatibility documentation says they are supported; do not infer compatibility from a package that happens to install.
| Version decision | Action |
|---|---|
| Client 19 or newer | Use Workstation 26 or newer, verify both versions, and test bootstrap behavior in staging. |
| Older client line | Check the current compatibility matrix, pin the matching workstation release, and document why the older line is retained. |
| Mixed fleet | Keep separate, tested workstation environments or automation images so one upgrade does not silently change every bootstrap. |
Troubleshoot the failures that stop first runs
DNS or connection errors
- If the workstation cannot resolve the server, correct forward DNS or use a deliberately stable address while DNS is repaired. Ensure the node resolves the same server name used in its Chef configuration.
- If the TCP connection is refused or times out, inspect both the VPS firewall and provider security group. Ports 80 and 443 are required by the server prerequisites, and SSH must be allowed from the workstation for the default bootstrap.
- If SSH authentication fails, test a normal SSH login with the same account and key, then verify that the account can run sudo without an interactive policy that blocks knife.
TLS, certificate, or clock errors
- Compare the server name in the URL with the certificate’s names. A raw IP can fail when the certificate was issued only for the FQDN.
- Check NTP status on all three roles: server, workstation, and node. Correct time before regenerating keys or certificates.
- Use
knife ssl fetchonly after confirming that you reached the intended server, and keep the fetched trust data private.
Authentication and key errors
- Confirm that the PEM file exists at the path in
knife.rb, is readable by the invoking account, and has not been truncated. - For validatorless bootstrap, remove the validator reference and supply
--node-name. For validator flow, verify the organization name and validator key pair. - If an administrator or validator key may have leaked, revoke or replace it through the server’s documented user or organization process and update every workstation that used it.
Package or first-run errors
- Read the complete output from
dpkg,chef-server-ctl reconfigure, and the node’s firstchef-clientrun. Resolve package dependencies instead of repeatedly rerunning a broken install. - Check disk space, service status, hostname resolution, and outbound HTTPS from the node. A successful SSH copy does not prove that the node can reach the server.
- Destroy and recreate a disposable staging node when testing a changed bootstrap recipe; repeated partial registrations can hide whether the current key and configuration are actually correct.
Operate the installation as a temporary platform
Back up the server data, organization credentials, administrator keys, and workstation configuration according to your security policy. Test restoration rather than assuming a VPS snapshot is sufficient. Monitor disk usage, service health, certificate expiry, failed client runs, and backup completion. Keep server, workstation, and node versions pinned in infrastructure documentation.
Because Chef Infra Server has an announced end-of-life, establish a migration or replacement checkpoint before committing production workloads. Inventory cookbooks, roles, environments, secrets, node identities, scheduled client runs, and integrations; identify an alternative control plane or supported successor; and rehearse exporting the configuration and rebuilding a representative node. A single-server VPS is reasonable for a lab or proof of concept, but production use needs provider backups, DNS redundancy appropriate to the workload, monitoring, and a tested exit plan.
Quick Recap
Installation checklist
- Supported x86_64 Ubuntu 20.04 or 22.04 image selected.
- Stable FQDN or IP resolves from workstation and nodes.
- NTP synchronization confirmed on server, workstation, and clients.
- HTTP/HTTPS and SSH firewall paths tested.
- Chef server package installed and
chef-server-ctl reconfigurecompleted. - Administrator created and
admin.pemencrypted, backed up, and removed from temporary locations. - Organization created and required PEM files placed in a protected workstation
.chefdirectory. - Workstation package installed and
chef -vverified. - Bootstrap trust model selected: validator or validatorless.
- First node completed a Chef Client run and appears in the organization.
- Workstation and Client versions meet the documented compatibility line.
- Backups, monitoring, and a migration checkpoint are documented.
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.
