Secrets

Secrets is a provider-neutral workspace capability for inventory and reviewed supplied-value distribution. Connections enroll provider resources, which may link to HQ repositories as optional context. A destination identifies its connection, resource, scope, and secret name. It does not require a repository. GitHub Actions and Cloudflare Workers are installed adapters with distinct private-input and activation contracts. An unavailable or unconfigured adapter is not a connected integration.

Metadata inventory is workspace-authorized and never returns stored values. Supplied-value distribution, reviewed scope cleanup, and the first-class browser workspace build on this boundary; metadata inventory does not establish that any secret has been synchronized. Durable managed-value custody remains a separate feature, not a prerequisite for inventory or transient distribution.

Browser workflow

Open Secrets in the sidebar or a repository's Secrets section. Choose an installed connection, resource, and scope to read a bounded page of names and timestamps. Scope and inventory pagination are explicit; filtering searches the displayed page only. A failed refresh preserves previously observed names alongside the error and observation time. Owner-only connection enrollment selects approved resources through an ordinary Save/Cancel form; provider credentials are never entered into that form.

Saving a connection changes which approved credential and resources HQ may use, not the provider's permissions or stored secret values. Disabling it blocks provider reads and new secret changes through that connection. It does not revoke the provider token, delete secrets or undo changes already sent to the provider; saved connection metadata and operation receipts remain inspectable.

Set up provider access

An Owner opens Provider access to manage workspace-owned authentication. Choose Add provider access, name the credential, select its resource allowlist, set the local-time HQ cutoff, and decide whether to allow reviewed writes. Selecting resources narrows HQ's use of the token; it does not create upstream permissions. The cutoff must not exceed the provider token's own expiry. Review the exact settings and affected connections before entering a replacement token through the private input. Ordinary scope edits can retain the existing token. Expired, retired, or inaccessible credentials require replacement input.

Credential reviews have their own URLs. Private input is not restored by a reload, and checking an already-applied review never compares a replacement token. After an interrupted request, use Check review status on that same review before trying again. An applied receipt confirms the reviewed change, not the equality of two competing supplied tokens. Connect resources then opens ordinary connection enrollment with the chosen provider preselected.

Use Verify read access for one allowed resource and its scope: GitHub repository or environment, or Cloudflare Worker. The result states what metadata was readable and when. It does not test write permission, cover unselected resources, read stored secret values, or prove runtime usability. A credential marked Configured has storage and cutoff information, not a healthy-provider attestation. Provider-specific verification is available only through installed adapters.

Review retirement shows the saved scope and dependent connections before a separate confirmation. Retirement removes usable token ciphertext from HQ and disables its connections; it does not revoke the upstream token, erase backups, or recall submitted work. Changing or retiring credentials advances dependent connection revisions, invalidating earlier prepared operations instead of giving them replacement authority. Historical receipts retain their uncertainty. Restoring a retired credential requires a new token and does not automatically re-enable its connections.

Distribute a supplied value

1. Choose Distribute supplied value or Supply a new secret, then select exact destinations. Change scope also identifies an original source that remains in place. Preparation reads metadata and any required public keys without writing provider state.
2. Supply the value through the dedicated browser input. GitHub destinations require Seal value and prepare final review before confirmation. Cloudflare-only reviews skip sealing. Mixed reviews keep the same value in the read-only input until you confirm execution. Plaintext is never placed in React state, the query cache, browser storage, or ordinary commands. Textarea input uses LF line endings; private-file CLI input preserves original UTF-8 bytes when line endings matter.
3. Review and confirm the captured destination writes independently of supplying the value. Cloudflare confirmation includes the immediate deployment effect. The field clears when execution begins or input fails; owned transient buffers clear when execution ends. Receipts update after each indexed destination. Interrupted responses require inspection of the same review; pending destinations require renewed confirmation, and submitted destinations are never automatically replayed. GitHub retained-input recovery prepares a distinct linked review. Cloudflare requires a deliberately supplied value for a new distribution because HQ retains none.
4. For a scope change, prepare an optional source-removal review only after destination evidence is confirmed. Inspect its exact source and destination evidence, then explicitly confirm deletion. Uncertain acceptance remains uncertain after a later absent-name observation.

Operations provides paginated history and addressable review URLs, including linked recovery and source-removal reviews. Navigation guards protect unsaved input and in-progress operations. Review expiry and execution-lease controls use a local visibility-aware clock, not HTTP polling; the server remains authoritative. HQ push notifications refresh recorded reviews and receipts through the same authorized commands. Provider names and timestamps are observations, never a comparison of secret values or proof of runtime usability.

Provider capabilities

Adapters own resource identity, scope discovery, name validation and normalization, limits, inventory, private input requirements, activation effects, and supported evidence. The common contract preserves case-sensitive names and accepts unknown creation, update, and version metadata. Reviews may contain destinations from separate connections; each destination retains its own provider-specific outcome and recovery state.

GitHub Actions supports repository and environment scopes, uppercase secret identity, timestamp metadata, and client-sealed input. Cloudflare Workers supports case-sensitive text bindings, unknown per-secret timestamps, a whole-Worker deployment precondition, and private transient execution input. Cloudflare's account-level Secrets Store is a separate resource and custody integration, not an implicit HQ vault. See Cloudflare's Worker Secrets API and Worker secret configuration.

Cloudflare Workers Secrets

In Provider access, choose Cloudflare Workers, enter the exact account ID and allowed Worker names, and review the credential's cutoff and write setting. Supply a dedicated API token privately; never import a broad machine administration token. Cloudflare documents Workers Scripts Read for metadata and Workers Scripts Write for secret mutation. HQ's Worker allowlist narrows its own behavior, not the token's upstream permissions. Read permissions and write permissions are separate from HQ membership.

Verify one Worker, then choose Connect resources and enroll the Workers you need. No HQ repository is required. Inventory preserves exact case, reports omitted cryptographic bindings, and labels unavailable timestamps honestly. The adapter reads the exact Worker's immutable ID through the beta Worker metadata API; unavailable or changed identity fails closed. It does not download Worker source or enumerate the account's fleet.

Before a write, expand Worker deployment affected and inspect the account, Worker, serving deployment, and version. The adapter requires one version serving all traffic, rejects replacement of a non-text binding, and checks identity and deployment again before submission. Every accepted secret PUT or DELETE creates and activates a new deployment, including a PUT of an unchanged value. Metadata preflight is not provider-side compare-and-swap and cannot prevent another client racing the request. A deployment token describes the whole Worker, not an individual secret revision or a comparison of stored values.

Each review permits one binding per Worker, including any original source. Multiple destinations on the same Worker and same-Worker renames are rejected because the first mutation would invalidate the others' captured deployment. Use independently reviewed operations when changing another binding. Source removal is a separate deployment operation and remains blocked if any captured Worker deployment changes. Gradual-deployment reads do not claim identical bindings across versions; mutations require resolving the gradual deployment first.

Cloudflare accepts supplied UTF-8 text through HQ during the explicitly confirmed execution request. HQ stages no plaintext, ciphertext, or hash of that value. Nonempty input is bounded to 5 KiB. A reload or failed execution clears browser input; a mixed-provider review cannot compare a replacement value with an already sealed GitHub payload. Keep the value available in a trusted source and inspect partial receipts before deciding what to supply again. Clearing owned buffers is not guaranteed erasure of JavaScript strings or copied process memory.

Trusted-client Cloudflare execution

Prepare and inspect the review, then accept its exact fingerprint with secrets_apply. Run one Cloudflare destination using secret-run-input --workspace <id> --review <id> --fingerprint <reviewed-fingerprint> --destination <zero-based-index> with exactly one owner-only file/stdin --input or inherited --environment-variable name. The stdio-only secrets_run_supply tool takes the same metadata and a variable name, never its value. A mixed review uses secret-input for GitHub-sealed destinations before acceptance and private execution for each Cloudflare destination afterward. File input preserves valid UTF-8 bytes, including BOM, CRLF and trailing newlines.

The dedicated POST /api/secrets/transient-input?workspaceId=<id>&reviewId=<id>&destinationIndex=<index> endpoint requires the accepted fingerprint in If-Match and a bounded {"version":1,"value":"<private input>"} envelope. Authority, actor, review, expiry and execution state are checked before body consumption and again before submission. A destination already beyond pending returns inputConsumed:false without reading or comparing another value. Ordinary secrets_run cannot supply Cloudflare input. Hosted MCP cannot read a client's private environment.

After an interruption, inspect the same review before anything else. The execution receipt records accepted, rejected, not-sent or indeterminate outcomes separately from observed name presence. Metadata reconciliation never replays a write or turns uncertain acceptance into certainty. There is no Cloudflare retained-input recovery; a deliberate new distribution requires supplying the value again.

Enrollment and reads

An owner enrolls a connection with a display name, provider kind, installed provider reference, and explicitly selected resource IDs. The adapter validates resource enrollment against its credential scope. For GitHub, each selected resource is an enrolled HQ repository whose full name must also appear in the credential's approved names. Saving enrollment changes HQ metadata only and records immutable repository attribution in Activity, including removed links. It does not create a provider resource, change a secret, or grant provider permissions. Changing provider kind requires a separate connection.

Use the shared secrets_connections, secrets_providers, secrets_connection_save, secrets_scopes, and secrets_inventory commands through the HTTP API, CLI, HTTP MCP, or stdio MCP. Inspect exact fields with npm run cli -- schema <command>. Inventory selects a target with resourceId and a typed scope; scope discovery returns the adapter's default scope and a bounded page of additional scopes. Provider-reference listing and enrollment require owner administration. Workspace readers may read metadata; source publishers and activity Reporters cannot. The separate secrets:write capability remains owner-only, including its live SQL authority guard.

GitHub inventory resolves the selected repository's numeric identity and, for environment scopes, the exact environment's identity. Names containing spaces, slashes, or percent signs are encoded once as opaque path segments. A renamed resource, changed HQ enrollment, revoked workspace access, expired credential, or changed credential scope invalidates the read. Read access is not proof that a write will be accepted.

Pages contain at most 30 environments or secret names and timestamps. Callers select a page explicitly; the server does not crawl automatically. GitHub's nextPage indicates more data, while truncated distinguishes exhaustion of its 100-page bound from completion. Cloudflare returns a bounded binding list that HQ slices into explicit pages. Pagination is not a transactional provider snapshot; refresh after concurrent changes. Permission failures, rate limits, missing resources, invalid responses, and interrupted reads are errors, not empty inventories. Metadata confirms neither the value nor its runtime usability.

GitHub credential boundary

Owner-managed provider access uses the encrypted credential boundary below. A deployment can also install GITHUB_SECRET_CREDENTIALS as a private Worker secret containing a catalog keyed by opaque provider reference. A descriptor contains workspaceId, name, positive revision, token, UTC expiresAt, explicit repositoryNames, and writable. Keep tokens out of source, normal commands, command arguments, logs, and screenshots. Catalog responses omit the token. Missing, malformed, expired, or wrong-workspace descriptors fail closed. Changing the credential, expiry, scope, or revision changes its bound identity. Deployment-managed references remain visibly separate in the UI; the reserved managed- prefix is never resolved through a deployment catalog, including after retirement or key loss.

Use a dedicated fine-grained GitHub credential for selected repositories. Repository secret metadata requires Actions Secrets read permission; writes require its write permission. Environment secrets use Environments permissions. HQ's writable declaration narrows its own behavior and does not create GitHub authority. Do not install the local broad GitHub CLI credential or reuse the fleet collector token. Consult GitHub's Actions Secrets REST contract when provisioning. The client pins API version 2022-11-28, a fixed GitHub API origin, and disallows redirects. Provider error bodies are never copied into routine errors.

The additive 0015_secrets_inventory.sql migration creates secret_connections, separate from scheduled collection sources, after the workspace push migration. Enrollment writes transactionally publish workspace metadata and Activity notifications; Secrets caches also follow access and operation changes. Preserve this table, notification triggers, Activity attribution, and the private credential catalog independently during recovery. Restoring D1 alone does not restore GitHub credentials or roll back provider effects.

Encrypted provider credential custody

UI-managed credentials are provider authentication tokens, not reusable destination-secret values. The additive 0025_provider_credentials.sql migration stores authenticated AES-256-GCM ciphertext in a dedicated private table. Encryption binds each row to its workspace, credential identity, provider, revision, name, cutoff and resource/write scope. An independent private PROVIDER_CREDENTIAL_KEYS Worker binding contains a versioned keyring:

{"version":1,"activeKeyId":"key-one","keys":[{"id":"key-one","key":"<canonical base64 of 32 cryptographically random bytes>"}]}

The deployment operator must generate the key with a cryptographic random source, protect its input from logs and command arguments, and independently back it up before enabling UI setup. Install it through the reviewed deployment's private secret workflow, not a public configuration field. Neither a public artifact nor ordinary commands contain these keys. For keyring rotation, retain old keys while their rows or intended recovery exports still require them, choose a new active key, and explicitly save or rotate each active credential to re-encrypt it. Removing a still-needed key makes its rows unusable. The UI can retire an inaccessible credential without decrypting it.

The shared provider_credentials_list, provider_credential_plan, provider_credential_review, provider_credential_verify, and provider_credential_apply commands expose bounded metadata only. They require a live Owner and both read and administration authority for a machine client. Plans bind the original subject and exact client credential, membership revision, credential revision, settings, linked connection revisions, and expiry. A private replacement is accepted only through POST /api/provider-credentials/input?workspaceId=<id>&planId=<id>, with the reviewed fingerprint in If-Match and a bounded {"version":1,"token":"<private input>"} envelope. Never put that envelope in an ordinary command or MCP argument.

Trusted CLI clients use credential-input --workspace <id> --review <plan-id> --fingerprint <reviewed-fingerprint> with exactly one owner-only file/stdin --input or inherited --environment-variable name. The stdio-only provider_credential_supply tool accepts the same metadata and a variable name, never its value. Hosted MCP exposes metadata operations but cannot read a client's environment. Private input is read only after the exact review is checked. An already-applied review returns submitted:false without reading or comparing that input. Tokens are printable ASCII without whitespace or trailing newlines; they are not silently trimmed. Request failures return safe uncertainty without provider payloads or token values.

Protect database exports as private credential ciphertext and keep their decryption keys separately recoverable. A database restoration can restore a previously retired row or old authorization state; reconcile upstream revocations and HQ authority before reopening access. Encryption does not protect against a compromised executing Worker that has the key, a compromised served client, or wholesale rollback of a trusted database. Clearing owned byte buffers and DOM fields is not guaranteed erasure of JavaScript strings or copied process memory. Local development has an isolated owner identity and must use synthetic or deliberately isolated test credentials.

GitHub client-side encryption contract

GitHub does not reveal stored Actions secret values. Supplied values must come from a trusted client, not a metadata read. The GitHub browser and Node input adapters use maintained Libsodium sealed boxes with GitHub's public key, preserving UTF-8 bytes and trailing newlines. Only sealed ciphertext may cross HQ's dedicated GitHub input boundary; ordinary commands must never carry plaintext or ciphertext. The claim that HQ receives no plaintext applies to this adapter, not to every provider. Persistent managed-value custody is a separate feature and security decision, not implied by inventory or transient delivery staging.

The encryption dependency loads lazily in trusted clients. It is not imported by Worker execution: its dynamic WebAssembly initialization was rejected by the Workers runtime in a controlled test. Browser CSP permits WebAssembly using wasm-unsafe-eval while retaining the prohibition on JavaScript string evaluation, inline scripts, third-party scripts, and external connections. Automated Node and real-browser round trips check byte preservation; the browser test also checks that JavaScript string evaluation is blocked under the production policy. See GitHub's encryption guidance and the CSP distinction between WebAssembly and JavaScript evaluation.

Input buffers owned by the sealing helper are cleared on completion. This is not guaranteed erasure of browser strings, copied process memory, or input retained by callers. A compromised served client or browser extension can observe input; client-side sealing is not a claim of protection from compromised client code. No value reveal is available.

Reviewed private input

secrets_draft captures explicitly selected destinations, optional source context, provider identities and public input requirements without changing provider state. The review binds its actor and credential, membership and connection revisions, repository revisions, names, metadata, public keys, and expiry. Alias connections cannot select the same provider destination twice. secrets_review and paginated secrets_history return metadata only; repository history uses immutable captured attribution. A draft has no executable provider effect, and source context never authorizes deletion.

The dedicated POST /api/secrets/input?workspaceId=<id>&reviewId=<id> boundary requires the draft fingerprint in If-Match, JSON content type, and a versioned private envelope. The trusted client seals one supplied value for each reviewed GitHub public key and sends {"version":1,"items":[{"destinationIndex":0,"ciphertext":"<sealed-base64>"}]}. Mixed reviews include only sealed destinations, retaining their original indexes. Cloudflare-only reviews are ready for confirmation without uploading staged input. Never pass a private envelope to an ordinary command or MCP tool. Authority and review state are checked before body consumption and again before finalization. The body has a fixed deadline and byte ceiling. Finalization atomically binds exact ciphertexts to an immutable fingerprint and audits metadata without input material. Byte-identical upload retries return the existing review; different input cannot replace an accepted upload.

The CLI's secret-input command reads an explicitly selected owner-only UTF-8 file, piped stdin, or named inherited environment variable after checking the review. For example, use npm run cli -- secret-input --workspace <id> --review <id> --environment-variable DEPLOY_VALUE; DEPLOY_VALUE is a variable name, not its value. Choose exactly one input source and inspect secret-input --help for the file and stdin forms. Whitespace and trailing newlines are preserved. The local stdio MCP tool secrets_supply takes the same workspace and review IDs plus environmentVariable; it resolves only that explicitly named inherited variable in the trusted client process. Hosted MCP exposes reviews and public input requirements but cannot read client files or environment variables. No value or ciphertext belongs in tool arguments or results.

An already finalized review returns submitted: false without reading or comparing a new value. A lost upload response requires inspection of the same review, not a replacement draft or blind resubmission. Neither input acceptance nor this recovery status proves which plaintext GitHub stores. Provider execution and source cleanup require their own reviewed stages.

secrets_cancel cancels only unaccepted work and removes its staged input. The separate secret_payloads table holds GitHub-sealed ciphertext, not plaintext or a value HQ can decrypt. Inputs become unusable at their recorded expiry; bounded minute maintenance deletes expired staging independently of collection. Cleanup failure emits hq.secrets.cleanup.interrupted and does not prevent the collection attempt. Expiry is not guaranteed physical deletion at an exact instant, and protected database backups may retain ciphertext after live deletion. Review history and repository-linked audit entries are preserved. Install 0016_secret_reviews.sql after inventory, and retain compatible notification triggers, receipts, expiry enforcement, and cleanup when recovering the Worker. SQL recovery does not restore credentials or undo provider effects.

Durable destination execution

secrets_apply requires the finalized fingerprint and original privileged actor. It atomically accepts the exact review and creates pending destination receipts without contacting the provider. secrets_run requires that fingerprint and an explicit destinationIndex for a staged GitHub destination; Cloudflare uses the private execution boundary described above. Both paths share the same execution service and may execute that pending destination once, never another destination or a previously submitted write. Browser, CLI, and MCP use these contracts. Inspect the review after an interrupted response. Repeating acceptance or an indexed execution request cannot overwrite a completed receipt or replay a submitted write.

Each execution request claims a bounded workspace lease, rereads the exact provider resource, scope identity, key and metadata, and rechecks live authority before durably marking submission. Changes detected before submission stop that destination. GitHub's documented mutation contract has no cross-scope transaction or metadata compare-and-swap parameter: these preflight checks cannot prevent an external writer racing the request, and lease fencing cannot recall an in-flight upstream request.

Receipts record provider acceptance separately from observed name presence. An accepted PUT followed by observed metadata does not prove plaintext equality, runtime usability, or synchronization. secrets_reconcile observes one exact destination without writing provider state. A previously uncertain write remains uncertain even when its name is present. An accepted response remains recorded if subsequent metadata reads fail. Lost execution leases settle unsent preparation as not sent and submitted work as indeterminate; submitted work is never automatically replayed. A provider response that cannot be durably recorded also remains indeterminate.

Successful accepted-and-observed destinations discard their sealed staging. Other payloads retain their original expiry for separately reviewed recovery. Cancellation of an accepted intent, replay, and source removal are not authorized by the distribution commands; source context in a review is not a deletion instruction. Apply 0017_secret_operations.sql after the private-input migration and preserve receipts, leases, and notification triggers in recovery builds. Database recovery does not undo upstream effects.

Reviewed retained-input recovery

secrets_recovery_plan prepares one exact GitHub destination with newReviewId and an explicit acknowledgePossibleOverwrite: true. Cloudflare destinations have no retained input and cannot use this workflow. Recovery preparation does not send a provider write. The fresh review binds the original fingerprint and receipt revision, the same provider resource/scope/key identities, freshly observed destination metadata, and the exact retained encrypted input. It retains the original input expiry instead of restarting the custody clock. The ordinary apply and indexed run commands require confirmation of the new fingerprint before any replay.

The parent receipt keeps its original outcome and links to the recovery review; an earlier indeterminate write is never relabeled as successful. One child review is reserved per parent destination. Repeated preparation of that same child returns its metadata, while competing children cannot both be accepted. Cancelling an unaccepted child discards its staging and releases its reservation. Changes to the parent receipt invalidate an unaccepted or unexecuted recovery review. Recovery chains are bounded to three steps, and no step extends the original input lifetime.

A retained-input review rejects private replacement uploads before consuming their body. Expired or discarded input, changed provider keys, or exhausted recovery chains require a deliberate newly supplied distribution, not a silent replacement or automatic retry. HQ cannot compare that new value to any earlier plaintext. Review all intended destinations when replacing a partly delivered value. Recovery copies can remain in private staging until their original expiry, and protected backups have independent retention. Apply 0018_secret_recovery.sql after destination execution; preserve its reservation links and notification triggers with the review and receipt history during recovery.

Separately reviewed source removal

A distribution with source context never deletes that source automatically. secrets_cleanup_plan requires the distribution fingerprint, a new cleanupId, and explicit acknowledgeNonAtomicMove: true. It follows each destination's bounded retained-input recovery chain to an accepted write with observed metadata. The original source must still have the same identity and comparable metadata version, and every destination must still match its last verified metadata. Unknown versions, changed source or destination metadata, incomplete recovery, and unconfirmed writes prevent review. Presence alone is insufficient. The separate review binds these checks, receipt revisions, the preparing actor and credential, live membership, provider authority, and expiry. It contains no private input and does not extend input retention.

Read the review with secrets_cleanup_review and its paginated history with secrets_cleanup_history. Only secrets_cleanup_apply, with that review's exact fingerprint and original actor, may request removal. It claims the same workspace execution exclusion as distribution, persists intent, repeats the evidence checks, and records a submission marker before a single provider DELETE. Duplicate requests return the existing journal; neither an interrupted request nor a not-sent or rejected result automatically retries deletion. A changed preflight requires a deliberate new review. Each cleanup is separately attributed to the original distribution's captured repository context in Activity.

Deletion acceptance and subsequent source metadata are independent receipt fields. An accepted deletion can still have unavailable metadata evidence or a name observed present after a concurrent writer. An interrupted provider response or failed receipt persistence leaves an indeterminate outcome. secrets_cleanup_reconcile observes the source without deleting it; later absence never upgrades uncertain acceptance. A missing-name response also checks scope readability, because denied access may appear as 404. Expired execution leases preserve submitted uncertainty. Fresh metadata and HQ's lease cannot prevent another provider client from modifying a secret between preflight and deletion. This is a supplied-value scope change, not an atomic move, a read of the source value, or proof that source and destination values match.

Apply 0019_secret_cleanup.sql after retained-input recovery. Preserve the cleanup journal, original distribution and recovery receipts, leases, repository attribution, and notification triggers in recovery builds. Database rollback does not undo a provider deletion, and HQ cannot retrieve a deleted provider value. Keep the supplied value available through an independently trusted source when operating on real secrets.

Resource limits and Free-plan posture

A workspace admits bounded active provider credentials and paginated retirement history. Owner metadata plans expire after five minutes and have a pending-plan cap. Credential values are limited to 2 KiB; private envelopes allow JSON escaping within a separate byte ceiling and have a fifteen-second body deadline. Private clients bound their response wait and receipt size. Credential storage, revision fencing, audit and workspace notifications add D1 work, and read verification adds selected provider requests without a background producer or automatic retry. Encrypted token custody and key recovery are additional storage responsibilities, not a supplied-value vault. Maximum credential or dependency sets have not been benchmarked as Free-plan-compatible CPU or billable D1 work; Paid access does not remove that documentation obligation.

A GitHub repository inventory page performs a repository identity read and one inventory read; an environment page also resolves its environment identity. Each upstream read has a total 15-second deadline covering headers and body, a 1 MiB body ceiling, and no automatic retry. Connection enrollment is bounded to 100 resources and 10 connections per workspace. Enrollment writes bounded HQ metadata and Activity attribution, but does not initiate GitHub reads or a background producer.

Cloudflare inventory and read verification use five provider GETs to bracket names with Worker identity and deployment checks. Mutation preparation adds one settings read to detect non-text collisions and capacity. Indexed execution uses six preflight reads, at most one write, and five observation reads; metadata reconciliation uses five reads. Settings values are discarded by metadata parsing and never returned or logged. Responses retain the same byte and time bounds as other provider reads.

A maximum-size Cloudflare draft can require 60 external reads, or 66 with source context; source-removal preflight can also capture the source and ten destinations. These explicitly exceed the Workers Free limit of 50 external subrequests per invocation, independently of CPU or D1 work. A Free-targeted deployment would need smaller reviewed batches or a separately designed resumable preparation workflow. Paid deployment does not remove the need to disclose this exceedance. HQ's conservative binding-list/preflight ceiling is 128 total bindings; Cloudflare separately limits variables to 64 on Free and 128 on Paid, with a 5 KB value limit on both. Provider rejection remains authoritative. Each accepted mutation also creates a deployment; request or CPU limits are not a bound on its downstream effects.

These logical limits are not measured CPU, billing-row, or account-spend guarantees. Libsodium encryption runs on the client, outside Worker CPU billing. Inventory CPU and D1 billing work have not been benchmarked against the Free plan. Document measured exceedances before claiming Free compatibility; access to Workers Paid does not remove this obligation or create an exact spending cap.

Review preparation and input finalization are bounded to ten destinations, with at most twenty unexpired staged reviews per workspace. Draft preparation checks a sixty-second elapsed budget before and after each resource capture; an underway capture may finish beyond that window, subject to each provider request's deadline. Exceeding the window does not persist a partial draft or send a provider write. Uploads are bounded to 900 KiB and fifteen seconds of body reading; GitHub's per-value limit is checked independently. Private staging expires after one hour, with a bounded cleanup query on the minute schedule and deletion-trigger notifications. These add D1 reads, writes, and retained ciphertext storage beyond the collector baseline. Cleanup interruption or backups can extend physical ciphertext retention, and neither the staging bounds nor Worker CPU limits enforce an account-wide budget.

Browser and shared CLI/MCP transport use operation-specific client timeouts: fifteen seconds for recorded metadata, seventy-five seconds for provider reads, 135 seconds for preparation, and three minutes for indexed execution or source-removal execution. These are wall-clock response waits, not CPU grants or extensions of review, input, or lease expiry. They cover response bodies and do not retry effects. An outer MCP client or network intermediary may impose a shorter timeout; inspect the same receipt after any interruption rather than assuming cancellation.

Each execution request can issue one provider write, with no automatic retry. GitHub preflight uses up to four metadata/key reads, the write uses one request, and post-write observation uses up to four reads. Indexed reconciliation uses up to four provider reads and no write. A missing-name response requires a successful scope public-key read before recording absence because GitHub can mask missing authorization with a 404; separate reads cannot eliminate an intervening authority change. Each provider request retains its independent fifteen-second deadline. A two-minute workspace lease serializes active Secrets execution; submission requires a twenty-second remaining lease reserve. Slow preflight can stop execution, and lease expiry can leave accepted responses indeterminate if they could not be recorded. The lease is an execution fence, not a CPU, request-billing, storage, or spending limit. Repeated local authority checks add bounded D1 queries proportional to the captured destinations; Free-plan subrequest and D1 work ceilings have not been benchmarked for the maximum-size review.

Recovery preparation uses up to four GitHub reads and stages one retained sealed payload within the existing workspace review capacity. It performs no provider write and does not create a background producer. Recovery depth bounds traversal and retained copies, not the number of independently accepted new distributions or account-wide spending.

Source-removal preparation permits at most twenty unexpired reviews per workspace, checks the original source and at most ten destinations, and traverses at most three recovery links per destination. Each preparation or execution preflight checks a sixty-second elapsed budget between resource captures; a capture already underway may finish beyond that budget, subject to each provider request's own deadline. An expired budget prevents deletion. A GitHub capture uses up to four reads, and execution repeats the captured evidence before at most one DELETE and up to four observation reads. Reconciliation reads only the source. These workflows share the two-minute execution lease and submission reserve; neither a long-running client connection nor Workers Paid removes those application bounds. Maximum-size cleanup adds provider calls and D1 work beyond a single destination execution and is not claimed to fit Free-plan per-invocation limits without measurement.