localred on a Mac
localred is Infrared on your Mac: one k3s node in a container machine of Apple's container framework, running Infrared, Gitea and Argo CD, at https://*.localred.laptop with certificates from your Mac's own certificate authority. It is the same Infrared that runs on GKE and EKS, for trying it out, for building Changes on your own machine, and for working while away from a cluster. ir local builds and drives it.
:::note Who can run it today
During 0.1, ir local up builds a stack from the localred recipe and Infrared's source, which darkshift shares with design partners and the engineers working with us. Book a call to get set up.
:::
Before you start
- An Apple silicon Mac on macOS 26, with about 10 GB of free memory: 8 GB for the node, and 2 GB for the image builder while it builds.
- Apple's
containerfrom Homebrew, andcrane,helm,kubectl,jq, Go and Node.js 22 or later. - The
irCLI, the localred recipe and Infrared's source, from darkshift. - Optionally,
irsigned in to a control plane, such as the hosted one, so the stack's metrics show there.
Bring a stack up
ir local up
ir local up brings a stack up from nothing, or finishes one, and each step runs only if it isn't done yet:
- The Mac. Checks the tools and starts Apple's container services. Makes your Mac's certificate authority once, which you trust once in the login keychain;
irtells you how. - The node. Builds the node image, creates the container machine and points every name under the stack's domain at it in your Mac's DNS.
- The cluster. Starts k3s, writes the kubeconfig context named after the stack, and runs a registry on the node.
- Infrared. Builds or copies the images, installs the chart, runs the setup wizard's steps, and waits until every Application is Synced and Healthy. The root user gets a password
irnever keeps;irsaves an API token in~/.localred/<stack>/ir-config.yamlinstead. - Products. Creates the Products the recipe ships, with their repos in the stack's Gitea, so Infrared builds and releases them.
- Telemetry. Connects the stack's metrics to the control plane
ir loginis signed in to, with nothing to set up. See Metrics in your control plane.
Then open it, signed in:
ir --config ~/.localred/localred/ir-config.yaml open
Useful options:
| Option | What it does |
|---|---|
ir local up <stack> | A second stack beside the first, such as localred-2. |
--cpus, --memory | The node's size, such as --memory 8G. |
--images-from <stack> | Copies the images from another stack's registry instead of building them. |
--model-key-file <file> | Sets the platform org's Anthropic API key from that file, so agents can build Changes. |
--license <file> | Installs a license from darkshift. Without one, the stack runs its 48-hour trial (Licensing). |
--pool | Runs the stack's agent steps in VMs on your Mac. See Agent steps on your Mac. |
--no-products, --no-telemetry | Leaves out those steps. |
ir local status lists your stacks, and ir local stop, ir local start and ir local down <stack> stop, start and remove one.
Metrics in your control plane
A stack has no metrics stack of its own. When ir is signed in to a control plane, ir local up mints a telemetry token through it for the platform <your GitHub login>-<stack>, keeps the token in a Secret in the stack, never printed, and connects the stack's metrics to that control plane. The stack's agent steps, their tokens and cost, and Infrared's own metrics then land in that control plane's metrics store, labelled with the stack's platform name and nothing that identifies a person. Platform admins read agent use by platform with GET /api/v1/usage?by=platform. ir local down revokes the token.
Not signed in, or the control plane refuses: ir local up says why and goes on, and the stack comes up all the same.
Agent steps on your Mac
With --pool, a Change's agent steps run in VMs of Apple's container framework on your Mac, leased by the node agent:
ir local up --pool --model-key-file <file>
ir local pool run localred
Without it, agent steps run as Jobs on the stack's node, and spend the same model key either way. ir local work <product>#<n> instead builds an issue with your own Claude Code as Infrared's builder role, and the stack's change flow then reviews and merges it.