Install the conductor in a minute.

1. Requirements

• git, on PATH.
• A launcher — claude (Claude Code) by default; opencode or codex optionally.
• gh and/or glab, already authenticated for the repositories you want worked.
• A Ironway account with access to the projects this host will serve.
• Optional: TeamClaude (several Claude accounts pooled), Tower (swarms), tmux.

Would rather not run agents on your own computer? One command gives a project a cloud machine of its own: conductor host new, in step 5 and the cloud guide.

3. First run

conductor init writes ~/.switchyard-conductor/config.json, signs you in through the browser if it finds no credential, offers the projects you can reach, and finishes by running doctor.

conductor init && conductor doctor

A passing doctor names every resolved fact about the host — the launcher it found, the forge CLIs, the projects, the spend caps — and prints no secret. Then start it:

conductor serve

5. Run as a service

macOS: a launchd plist in ~/Library/LaunchAgents. Linux: a systemd user unit. Both run conductor serve behind a doctor preflight and restart it on failure; the conductor's repository ships both files.

Or on a machine of its own, in one command

With OpenTofu installed and a Hetzner Cloud account, this makes the machine, waits while it installs itself, and ends in its setup questions in the same terminal:

conductor host new widget-1

It asks which of your Ironway projects the machine works, unless --project my-workspace/my-project names one. It finds your ssh key itself, including one in 1Password, and prints which it used.

• Nothing is cloned and nothing is compiled. The machine installs this same published binary, checks its SHA-256, and runs conductor host bootstrap, which it carries inside it. The service it sets up updates on the release channel.
• The setup questions come from conductor host setup on the machine: the Claude token from claude setup-token, a GitHub sign-in, the Ironway sign-in, each project's verify command, then one teamclaude login per Claude Max account. It asks only for what it cannot find, so running it again resumes.
• The Hetzner token is never saved. Use a Hetzner project that holds only these machines, because a token reaches every server in its project. The command reads an exported HCLOUD_TOKEN, then hetzner_token_command from your config, then 1Password, and otherwise asks with the input hidden.
• Fewer questions: with the 1Password CLI installed, it reads items named Hetzner, Claude, GitHub and Ironway from a vault called Ironway; onepassword_vault names another. Or put CLAUDE_CODE_OAUTH_TOKEN, IRONWAY_API_TOKEN and GH_TOKEN in a file on your own machine and add --env that-file. Either way they travel only over ssh, never into the machine's definition or a log. A browser approval per Claude Max account is the one thing neither can answer.
• Its own GitHub account: give each machine a GitHub account of its own with write access to its repositories, so its work is attributed to it and it has its own API budget. The cloud guide shows how.
• Afterwards: conductor tunnel ops@<address> opens its dashboard here, conductor host list names what you made, and conductor host destroy widget-1 removes it.

Repeat --project to put several projects on one machine, or add --tower, --roundhouse <url> or --teamclaude=false. The cloud guide walks every step and every problem a real host has hit.

7. Credentials

The conductor looks for a Ironway token in this order:

1. IRONWAY_API_TOKEN (or the older SWITCHYARD_API_TOKEN) in the environment.
2. The conductor's own tokens.json, written by conductor login.
3. switchyard-mcp's tokens.json — one browser login serves both tools.

Two rules hold whatever you configure: the config is never printed — not by the binary, not by its diagnostics — and a credential never sits in it: every secret is a reference to a sealed store, and the loader refuses one written inline. Configuration has every setting.