Bring your own cloud

CLANKERNET runs in your accounts from day one. What runs there is the factory — a host, Traefik-fronted developer containers and the GitFWD coordination gateway, 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 (plan D25). 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 bill of materials you need before writing a host spec, an honest account of what lives in your state, the shared-responsibility split, and the v1 limits with the task that lifts each.

This page is the canonical home of the trust model (plan D21): BYOC is this product’s shape, so the boundary contract, the state-custody table and the shared-responsibility split live here and nowhere else — the Clanker product’s enterprise plan, where an earlier draft of the same model once lived, has been deleted and points at nothing. The compliance program that surrounded that draft (SOC 2 / ISO / GDPR sections) is not carried; it belongs to whichever product sells it.

Bill of materials

What the host owner must already have. A prospect who cannot hold a Cloudflare account is not a factory prospect; say so in the first call.

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

What we hold

Nothing.

• No cloud credential of yours. The reusable workflow runs in your repository’s Actions, with your PULUMI_ACCESS_TOKEN (or your S3 keys), reading your stack’s config or ESC environment. clankerlabs/CLANKERNET is a workflow definition and a composite action; it executes under your permissions.
• No inbound path. Nothing on our side calls your host, your tunnel or your containers. 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 a stack output. tests/no-secret-outputs.test.ts (lands with the host engine, plan T021) pins that the host program exports only serverIp, tunnelId, tailscaleHostname, and hostSpec (which is non-secret by construction).

Revocation is unilateral and total: delete the caller workflow, or stop pinning our SHA. Running hosts and containers 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 and the composite action to a 40-character SHA (Dependabot’s github-actions ecosystem bumps it), never @v1, and read the diff. That is the one crossing, and it is reviewable in git.

What is in your state

Pulumi state necessarily holds host secrets, because the resources are made of them: the tunnel’s credential, the Tailscale pre-auth key delivered at converge, the hcloud 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 root private key — it lives in the secrets provider (compute.sshKeyFrom.privateKey, plan D19) and the program consumes it as an input, never as a tls.PrivateKey resource. factory host up mints the pair on your runner the first time and stores it there; no one hands a private key to anyone.
• The gateway’s secrets (OAuth app, coordination-repo token, bridge key). They travel runner → host over SSH into a 0600 root env file per converge and are never Pulumi inputs, never in cloud-init.
• Any env.secrets value. Those flow runner → container env file (0600) per provision and are never Pulumi inputs.
• Any Tailscale OAuth client. The runner exchanges it for a tagged, one-use pre-auth key; only the key reaches the host, over SSH, never in cloud-init (cloud-init metadata is readable by any process on the box).

Per-container DNS records are not Pulumi resources at all — they are idempotent API writes tagged managed-by=factory/<host>, so N provisions never contend for one stack. Only host records are resources, and the gateway record is { protect: true }.

Boundary contract

Every crossing between the CLANKERNET repository (ours) and your accounts (yours), 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, Tailscale 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.

v1 limitations

Each names the task that lifts it. Until then it is a fact, not a roadmap.