Customer bundle storage

By default, Flitz keeps your bundles in its own storage. With customer bundle storage, your organization connects a bucket it owns — in Google Cloud Storage, Amazon S3, or Azure Blob Storage — and every bundle it publishes is uploaded to that bucket and downloaded from it directly:

• No bundle passes through Flitz. flitz publish uploads the .flitz straight to your bucket, and the loader downloads it straight from there. Flitz only hands out short-lived URLs to your storage.
• Flitz holds no secret for your storage. Your cloud trusts Flitz's Google Cloud service account, and Flitz gets short-lived credentials from that trust each time it needs them. Remove the grant in your cloud and Flitz's access ends.
• Flitz never reads a stored bundle. It uses its access only to sign upload and download URLs, check that a bundle exists, and delete one. Signing a download URL requires read permission on the object, so the access would allow a read; Flitz commits never to use it.

Only the bundle moves. The publish record — its app and track, versions, name, comment, and who published it — and the landing page stay with Flitz.

What changes for your team

Nothing in day-to-day use. Publishing, sharing, opening, and deleting work as they do with Flitz's storage, and no host needs a rebuild.

• Links stay the same. Every link — landing page, deeplink, QR code, track link — points at Flitz, as before; none shows your bucket.
• Opening a build goes to Flitz first. Flitz checks download access, checks that the bundle exists in your storage — its metadata, never its contents — and redirects the loader to a short-lived signed URL at your storage. The loader downloads the bundle from there.
• Deleting a publish, or an app being removed for good 30 days after its delete, deletes its bundles from your bucket. If that fails — for example because you revoked Flitz's access — the publish is deleted anyway and its links stop working; the leftover object is yours to delete.
• Teammates' devices download from your storage directly, so its endpoint must stay reachable over HTTPS from wherever they are — see What breaks it.

How it is set up

The connection has a few fixed rules:

• One bucket per organization, used only by Flitz. It holds the bundles of every app in your organization, and the access you grant covers the whole bucket. There are no per-app buckets and no folders inside a shared bucket.
• Changing it is not self-service. Connecting an organization that already has publishes, or moving to another bucket or provider, is arranged with Flitz by hand, and publishes stored before the change may stop opening.
• Amazon S3 itself only. S3-compatible stores, such as Cloudflare R2 or MinIO, are not supported.
• Your own encryption keys work on every provider.

Grant Flitz access

Flitz gives you the values these steps use:

• <flitz-service-account> — the email of Flitz's Google Cloud service account;
• <flitz-service-account-id> — that service account's unique ID;
• <organization-audience> — the audience that names your organization, for Amazon S3 and Azure.

gcloud iam roles create flitzBundles --project=<project> \
  --title="Flitz bundles" \
  --permissions=storage.objects.create,storage.objects.get,storage.objects.delete
gcloud storage buckets add-iam-policy-binding gs://<bucket> \
  --member=serviceAccount:<flitz-service-account> \
  --role=projects/<project>/roles/flitzBundles

What breaks it

Teammates' devices and your developers' machines reach your storage directly, over HTTPS. Any of these stops publishes or downloads:

• an S3 bucket name with dots;
• a bucket policy that allows only certain IP ranges or VPC endpoints;
• an S3 policy that caps the age of request signatures below one hour;
• an Azure storage firewall or private endpoint;
• a Google Cloud VPC Service Controls perimeter;
• Google Cloud domain-restricted sharing without an exception for Flitz's service account.

When something fails

Neither the portal nor flitz status shows whether the connection works.

• A publish fails when the connection breaks — say a bucket policy changed — with the CLI's usual service error, which does not name your storage. The publish stays pending, then abandoned. Ask your cloud admin to check the grant, or contact support.
• A download fails with Download failed: HTTP 404 when the bundle was deleted from your bucket outside Flitz, and an error that does not name your storage when Flitz's access no longer works. When a network or firewall blocks your storage, the loader shows its usual download error; Flitz cannot see that case. See Loader troubleshooting.

Audit trail

• Every download through a Flitz-signed URL appears in your storage's access logs under Flitz's identity, with the teammate's device as its source address.
• Flitz's own requests to your storage are checks that a bundle exists and deletions — never a read of a bundle.

To end Flitz's access, remove the grant or the trust in your cloud at any time. New publishes and downloads then fail as described above, and deleting a publish leaves its bundle in your bucket.