Uplint
uplint dispatch --read google-cloud-storage-support
TITLEThree Clouds, One API: Uplint Now Stores Files in Google Cloudvalidated
DATE2026-08-01
AUTHORUplint Engineering
TYPEengineering
TAGS#GCP #Google Cloud Storage #GCS #S3 #storage #bring-your-own-storage #multi-cloud #file-contexts
READ6 min

Three Clouds, One API: Uplint Now Stores Files in Google Cloud

Bring Your Own Bucket now covers Google Cloud Storage too. GCP-native teams get the same trust layer, storing straight into their own GCS buckets - and it took almost no new code, because GCS speaks S3.

Uplint EngineeringAugust 1, 20266 min

A few weeks ago Uplint's Bring Your Own Bucket promise meant AWS. Then it meant AWS or Azure. Today it means AWS, Azure, or Google Cloud - your accepted files land in your cloud storage, under your credentials, whichever of the three you run on.

Google Cloud Storage is now a first-class storage provider in Uplint.

The teams that were waiting

Plenty of teams live on Google Cloud and nowhere else. A data team already running BigQuery, Pub/Sub, and Cloud Run doesn't want its file intake to be the one workload that drags AWS or Azure into the org chart - a second vendor review, a second set of keys to rotate, data sitting outside the boundary they already justified to security. For them, "just use S3" was never a small ask.

Storage should follow your infrastructure. So GCP users can now point Uplint straight at a GCS bucket they own.

What shipped

A storage bucket in Uplint carries a provider - now one of aws_s3, azure_blob, or gcs. GCS buckets authenticate with an HMAC key (an access key + secret), the same shape as S3 credentials:

# Add a Google Cloud Storage bucket
curl -X POST https://api.uplint.dev/api/v1/tenants/tnt_9f8e7d6c/storage-configs \
  -H "Authorization: Bearer ul_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Insurance Claims",
    "provider": "gcs",
    "access_key_id": "GOOG1EXAMPLEACCESSKEY",
    "secret_access_key": "your-gcs-hmac-secret",
    "default_bucket": "acme-insurance-claims",
    "base_path": "file-service/"
  }'

You create the HMAC key in the Google Cloud console under Cloud Storage → Settings → Interoperability. No region to pick, no extra fields. In the dashboard, the Add Bucket dialog now has a third provider option - choose Google Cloud Storage, paste the access key, secret, and bucket, and you're done.

And because a tenant can register many buckets, you can genuinely mix all three clouds: claims in a GCS bucket in your compliance region, avatars in S3, exports in Azure - all behind the same single Uplint API call.

The part we're quietly proud of: almost no new code

Here's the fun bit. Google Cloud Storage exposes an S3-interoperable XML API at storage.googleapis.com. It speaks the same protocol S3 does. Uplint's storage layer was already an abstraction with exactly one AWS implementation - a thin adapter over the S3 API.

So supporting GCS didn't mean writing a new adapter at all. It meant pointing the existing S3 adapter at the GCS endpoint and handing it your HMAC key. Uploads, downloads, deletes, metadata - all the same code path. Even signed download URLs work unchanged: on S3 they're pre-signed URLs, on GCS they're the same signature scheme against storage.googleapis.com. One small factory branch, and GCS came along for free.

That's the payoff of having built a real storage abstraction the first time. Adding Azure meant one genuine new adapter (a different API and auth model). Adding GCS meant reusing the S3 one.

There was exactly one sharp edge worth mentioning: newer AWS SDK versions started attaching default integrity checksums to every request, which GCS's S3-compatible endpoint rejects. We turn that behavior off for custom endpoints, so GCS uploads sail through while native S3 is untouched.

The routing model is identical

If you've used Uplint's multi-bucket routing, none of this changes it. Provider is orthogonal to routing. Every file context resolves to a bucket the same way - its bound bucket if active, otherwise your tenant default - and Uplint records which bucket and provider each file was written to. Re-point a context from S3 to GCS tomorrow and only new uploads follow; every existing file stays readable from exactly where it landed. You can run a tenant that's part S3, part Azure, part GCS, mid-migration, and nothing breaks.

Backward compatible, as always

Nothing to do if you're already on S3 or Azure. A config with no provider is treated as aws_s3; existing buckets, credentials, and files keep working untouched. There's no migration and no flag to flip. You opt into Google Cloud the moment you add a GCS bucket - and not a second before.

Getting started

Open Storage in the dashboard, click Add Bucket, and choose Google Cloud Storage. You'll need three things from the Google Cloud console: a bucket name, and an HMAC access key + secret (Cloud Storage → Settings → Interoperability). Paste them in and route a context to your new bucket.

Three clouds, one API, the same trust layer in front of every file. Bring whichever bucket you've got.

Found this useful? Share it with your team.