Compute
Integrations and adapters
Adapters come in three kinds with different permissions: ones that read your input, ones that write your results, and ones that speak another product's wire protocol.
Three kinds of adapter, three different grants
Adapters are not interchangeable, and the difference is what they are allowed to do.
- Input adapters read. They resolve a location, freeze a snapshot, and never write anything back.
- Output adapters write. They hold a time-bounded delivery authority and commit results to a new location.
- Wire adapters speak another product's protocol, so a client you already have can talk to Compute without being rewritten.
Register the narrowest one that does your job. An input adapter with write permission is a grant nobody asked for.
Every adapter states its own evidence
Each released adapter declares one compatibility level, backed by a versioned conformance matrix. The level alone is not a claim you can plan against.
Read the matrix before you commit. It states the tested upstream version, the fields, the lifecycle, the errors and the limits that were actually measured.
A product described as compatible without a named level and a published matrix is a marketing sentence, not evidence.
Related administration lives elsewhere
Connecting an adapter is not the same as granting credentials or paying for what it moves. Those are separate families with separate authority.
- Credentials and federation — how a secret reference or a federated grant is admitted.
- Cost allocation — how the work an adapter feeds is attributed and billed.
Pages in this group
- Compatibility levels — the four levels and what each matrix must state.
- Amazon S3 — object storage input and result delivery.
- Cloudflare R2 — the measured subset, signed URLs and checksums.
- Google Cloud Storage — generation binding, federation and region constraints.
- Azure Blob Storage — blob identity, scoped identity or an admitted signature.