Set up the workforce.
Keep the model bill at zero.

1. Choose your infrastructure

The Terraform/OpenTofu loadout installs the workforce on Kubernetes; it does not sell or create the underlying server. Start with one of these paths:

1. Use an existing conformant Kubernetes cluster you already operate.
2. Create a managed Kubernetes cluster through a cloud provider.
3. Rent a VPS or dedicated server and use the provider-neutral K3S bootstrap lane after its launch validation is complete.

The existing-cluster path is implemented now. The greenfield VPS-to-K3S path is part of the product launch target, but will not be represented as shipped until clean-machine, reboot, persistent-storage, backup, and full workforce canary checks pass.

Whichever path you choose needs persistent ReadWriteOnce storage, a working kubectl context, suitable network egress, and enough CPU and memory for the enabled roles. You remain responsible for the hosting account, server, firewall, backups, and updates.

Use GitLab.com or a reachable self-managed GitLab instance. Create eight scoped identities, one per role, so implementation, review, security, and release authority can remain separate. Install Terraform 1.6+ or a compatible OpenTofu release and Python 3.10+ on the operator machine.

2. Use the free models by role

“Best” depends on the job. The loadout uses a coordination primary, a tool-oriented worker primary, and a shared fallback chain rather than sending every task to one model.

Ranking and access are separate checks. A model can rank well and still be excluded if the available route is paid. For that reason, paid GLM variants are not in the shipped configuration. Provider catalogs remain authoritative.

3. Create provider keys

You do not need every provider to start. Configure only routes your account can use without paid inference, then add another free provider when you want fallback continuity.

Store keys in the supplied Git-ignored, role-specific secret files. Never commit keys, place them in Terraform variables/state, reuse GitLab tokens across roles, or paste them into support messages.

4. Install the agent contract

The Kubernetes resources alone are not the workforce. The package installs role-specific AGENTS.md and SOUL.md policies, model routes, allowed toolsets, workforce routing data, and curated portable skills.

After deployment, verify the expected skills and tools inside each role. Personal OpenCode configuration, private endpoints, retained sessions, local MCP servers, and customer data are not package assets.

5. Verify access before deployment

1. Confirm each exact model ID appears for your account and is eligible for free use. A key alone does not prove that.
2. Run a bounded no-tool prompt and record the actual provider/model response without logging the credential.
3. Confirm the route supports the context size and tool behavior required by its role.
4. Remove any route that requests billing, cannot identify the configured model, or fails the bounded check.

6. Deploy through the guarded workflow

1. Configure the environment and pin an immutable Hermes image digest.
2. Run repository policy checks, formatting, initialization, and validation.
3. Stage namespaces first, then bootstrap unique role secrets outside Terraform.
4. Create and inspect a fresh saved plan. Apply that exact plan only after review.
5. Verify StatefulSets, Services, PVCs, NetworkPolicies, role configuration, and authenticated health endpoints.

7. Run a disposable canary

Create a low-risk GitLab issue in a test repository. Give it a narrow scope, explicit acceptance criteria, and no customer data. Confirm that the assigned role claims it, loads the packaged GitLab workflow skills, uses the intended provider/model, invokes the required tools, creates reviewable evidence, and stops at the configured human gate.

Repeat the canary after changing a model, provider, credential, Hermes image, permissions, skill, or fallback order. Free quotas and catalogs can change, so route verification is ongoing operations—not a one-time promise.

What the guide does not promise

The package will include a supported Kubernetes bootstrap path, but not the VPS account or hosting fees. It also does not include GitLab accounts, model credits, unlimited quotas, unattended correctness, or a completion-time guarantee. Self-hosting keeps deployment control with you, but prompts sent to configured model providers leave your cluster under those providers’ terms.

The current product deploys Hermes through the supplied Terraform/OpenTofu Kubernetes module. Runtime experiments are not customer prerequisites or advertised features until separately validated and released.