> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Google Cloud Storage
description: >-
  Bind each object to its generation number, use an approved credential reference or admitted
  federation, and check the region constraint before a result is committed.
route: /docs/compute/integrations/google-cloud-storage
page_id: docs-compute-integrations-google-cloud-storage
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Administrators connecting Compute to Cloud Storage buckets they already own
voice: D
reader_question: How do I read from and deliver to Cloud Storage without sharing a key?
primary_action: Register a destination for results
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-integrations-google-cloud-storage-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## What this adapter states

Read these eleven facts off the adapter's descriptor and its published conformance matrix before you register anything.

| Fact | Where you read it |
| --- | --- |
| Provider product | Google Cloud Storage |
| Tested upstream version | The matrix names the exact API version tested |
| Supported direction | Input, output, or both, as declared on the descriptor |
| Credential mode | A stored credential reference, or an admitted federation grant |
| Input snapshot binding | The object generation, plus a `version_id` and `content_sha256` |
| Formats | The formats the workflow declares, listed on its descriptor |
| Output commit mode | Written once to a new partition, verified, then committed |
| Unsupported fields | Named explicitly in the matrix, not left out |
| Limits | Measured size, count and rate bounds in the matrix |
| Expiry | The federated or signed authority's lifetime and who renews it |
| Compatibility level | One of the four named levels, with a matrix version |

## Bind the generation, not the name

An object name is not an identity. The same name can hold different bytes tomorrow, and a run pinned to a name would silently read something else.

Pin the object generation instead. The snapshot then carries that generation alongside its `version_id` and `content_sha256`, and the run reads exactly those bytes for its whole life.

For a set of objects, pin a manifest listing each object and its generation, and snapshot the manifest. Check the values on your quote and again on the result's provenance record.

## Choose federation or customer-side staging

You have two ways to grant access, and they suit different situations.

- **Admitted federation.** Your account admits a short-lived federated grant, so no long-lived secret is stored anywhere. Prefer this where your policy allows it.
- **Customer-side staging.** You copy the input into a bucket you have prepared for this purpose, and grant read on that prefix only.

Staging is the right answer when the source bucket is shared, broadly readable, or owned by a team that cannot narrow its grant. See [how credentials and federation are admitted](/docs/compute/security/credentials-and-federation) before you choose.

Either way, your request carries a `credential_ref` rather than a secret. Never put a literal key in a request, a configuration file or a command line.

## Confirm the tested format

Match the format the workflow declares, exactly as its descriptor states it. A format that merely opens in your own tooling is not the same as a tested format.

The workflow descriptor also states its maximum item count, and your quote repeats it. Read that number from the quote rather than assuming one.

If your data does not fit the tested format, convert it before registering, not during the run.

## Check the region constraint

Region is a constraint decided by your account policy, not a preference you set on the request.

Confirm the bucket's location is one your policy admits before you register it. A bucket in an inadmissible location refuses at admission, not at delivery, so you will find out before work is charged.

Multi-region and dual-region buckets are locations too. Check them against the same policy rather than treating them as neutral.

## Verify the result commit

A delivery finishes in stages. Bytes are written, the write is verified, and only then is it committed.

Many grants can create an object and cannot finalize one. Use the destination family's `test` operation and confirm it reaches a committed state before real work depends on it.

`WRITTEN_UNVERIFIED` is not done. It means the bytes exist and nothing has confirmed them yet.

## Confirm success

Both resources read back as `VERIFIED`, both tests pass, and a real job's delivery reaches `COMMITTED` and then `CUSTOMER_ACKNOWLEDGED`.

If a delivery fails, read its reason and its next action together. `AUTHORITY_EXPIRED` means renew the authority and retry; the result itself is not lost.

Keep the receipt reference the apply returned. Quote it to support, and never send a key, a signed URL or a project identifier.

[Register a destination for results](/docs/compute/configure/destinations)