Set up a free OpenShift home lab

Before any of the other guides are useful, you need a cluster you can break safely. OpenShift Local (formerly CodeReady Containers, still called crc on the command line) runs a single-node OpenShift cluster on your own machine — free, disposable, and perfect for learning.

Watch on YouTube ↗

What you’ll need

• A machine with at least 4 physical CPU cores, 16 GB RAM, and 35 GB free disk.
• A free Red Hat account (for the pull secret).
• Admin rights to install a local hypervisor.

Install and start

1. Download OpenShift Local and grab your pull secret from console.redhat.com/openshift/create/local.

2. Run the one-time setup, which prepares the hypervisor and system bundle:

   crc setup

3. Set a couple of sensible resource limits before the first start, so they apply on the initial boot:

   crc config set cpus 6
   crc config set memory 16384

4. Start the cluster. You’ll be prompted for the pull secret on the first run:

   crc start

Tip

Set cpus and memory before crc start, not after. Config changes only take effect on the next full cluster boot, so setting them first saves you a restart.

Log in

Once crc start finishes, it prints the login details. You can retrieve them again at any time:

crc console --credentials

That prints ready-to-paste oc login commands for both the developer and kubeadmin users. To open the web console in your browser:

crc console

Console URL

oc whoami --show-console
# https://console-openshift-console.apps-crc.testing

API URL

oc whoami --show-server
# https://api.crc.testing:6443

Admin password

cat ~/.crc/machines/crc/kubeadmin-password

Everyday commands

crc status      # is the cluster up, and how much resource is it using?
crc stop        # shut it down cleanly (keeps state)
crc delete      # tear it down completely for a fresh start

Caution

This is a single-node cluster: control plane and worker on the same VM. It’s ideal for learning and for following these guides, but it is not a production topology — don’t use it to reason about high availability or multi-node behaviour.

Next

With a working cluster, the natural next step is understanding why your first real workload might refuse to start — which almost always comes down to Security Context Constraints. That’s the next guide.