Bring your own cloud

CLANKER.NET runs in your accounts. What runs there is the factory — a host, your engineers’ pods behind a reverse proxy, and the coordination server where engineers and their agents hand off work — for whatever repository you are building, never a product of ours (clankerengineer is a separate, hosted sister product and is not installed in a customer’s cloud). There is no hosted control plane, no vendor-held cloud credential, and nothing to revoke on our side because we were never granted anything.

This page is the trust model: the bill of materials you need before writing a host spec, what lives in your state, the shared-responsibility split, and the limits. A compliance program (SOC 2 / ISO / GDPR) is not carried here; it belongs to whichever product sells it.

Where everything lives

flowchart LR
  subgraph ours["Ours — public, pinned by SHA"]
    code["the engine · the reusable workflow · the base image"]
  end
  subgraph yours["Yours"]
    ci["your repository's CI<br/>your token, your permissions"]
    accounts["your cloud, DNS and edge,<br/>private network, state service"]
    host["your host<br/>pods · reverse proxy · coordination server"]
  end
  code -- "checked out at the SHA you pinned" --> ci
  ci -- "creates and converges" --> accounts
  ci -- "over ssh" --> host
  host x--x code

The arrow from us to you is source code you can read. There is no arrow back.

Bill of materials

What the host owner must already have. A prospect who cannot hold a DNS zone at the supported DNS and edge provider is not a factory prospect.

Everything above is referenced by name. The names resolve in your secrets store; the values never enter a file in either repository.

What we hold

Nothing.

• No cloud credential of yours. The reusable workflow runs in your repository’s CI, with your state backend’s token (or your S3 keys), reading your stack’s config or your secrets store. Our repository is a workflow definition and an engine; it executes under your permissions.
• No inbound path. Nothing on our side calls your host, your tunnel or your pods. Health probes run on your runner and report to your job summary.
• No telemetry. The engine emits no usage record to us; there is no crossing whose schema could carry one.
• No secret in an output. The host publishes exactly four values — serverIp, tunnelId, tailscaleHostname, hostSpec — none secret.

Revocation is unilateral and total: delete the caller workflow, or stop pinning our SHA. Running hosts and pods are unaffected; we could not update them anyway. A vendor that cannot be locked out has an unfalsifiable claim; this one can be locked out by removing one file.

What we DO control: the code your runner executes. Pin the reusable workflow to a 40-character SHA (your dependency bot bumps it), never a floating tag, and read the diff. That is the one crossing, and it is reviewable in git.

What is in your state

Infrastructure state necessarily holds host secrets, because the resources are made of them: the tunnel’s credential, the ssh key resource (public half). The control is who holds the backend and the decryption key, not “no secrets in state”:

Not in state, by design:

• The host’s root private key — it lives in the secrets store; the first host-up mints the pair on your runner and stores it there. No one hands a private key to anyone.
• The coordination server’s secrets (the GitHub App’s private key, the broker key). They travel runner → host over ssh, one file each that only the server’s own user can read, per converge.
• Any env.secrets value. Those flow runner → pod env file per provision.
• Any private-network client. The runner exchanges it for a tagged, one-use join key; only the key reaches the host, over ssh, never in the host’s first-boot data (which any process on the box can read).

Per-pod DNS records are not state at all — they are tagged writes (managed-by=factory/<host>), so many engineers provisioning at once never contend for one stack. Only host records are state, and the coordination server’s is protected.

Boundary contract

Every crossing between our repository and your accounts, with direction and payload:

There is no crossing from your accounts to ours. Customer data that never crosses in either direction: repository contents, env values, database rows, private-network device lists, DNS records, logs.

Shared responsibility

The uncomfortable row is intrusion detection. An appliance the vendor cannot observe is an appliance whose breach the vendor learns about from the customer; the answer to “what do you do when I report one” is: ship a fix under the disclosure row, and nothing else, because nothing else is possible.

Keeping agents off your trunk

The host enforces no branch rule, so by default a pod’s agent may push to any branch its installation token may write, including the default one. To land agent work through review instead, make it your repository’s rule, not ours:

1. A ruleset on the default branch only (~DEFAULT_BRANCH) that requires a pull request and your checks.
2. Tell the agents, in the repository’s own CLAUDE.md / AGENTS.md, to push a branch (say agent/<task>) and open the pull request; the ruleset is what makes that binding, the text is what makes it the easy path.

This is a recipe over GitHub’s own controls; the factory neither applies nor checks it.

Limits

What the factory does not do. Each is a fact about the engine as it stands, stated so that a host owner can plan around it; none is a promise.

Want us to run it for you? Talk to us: [email protected].