Cloud Storage Buckets
What does zop.dev create for Cloud Storage Buckets?
zop.dev manages Cloud Storage buckets via its provisioning API's bucket resource type with 4 controls: storage_class, versioning, access_control, and prevent_public_access. Bucket names are globally unique and location is permanent. Moving a bucket's region means a new bucket and a copy of every object.
| Field | Value |
|---|---|
| Cloud | gcp |
Cloud Storage provides durable object storage on GCP. zop.dev manages buckets through its provisioning API with safe-by-default access controls.
Buckets through the provisioner’s bucket type
Cloud Storage buckets via the provisioning API’s bucket resource type.
Storage class, versioning, and access control
storage_class, versioning, access_control, prevent_public_access.Buckets on request, plus five from observability
On GCP, buckets are created on request through the bucket resource type; five more GCS buckets are created automatically by the observability stack.
Safe by default, public by exception
prevent_public_access is the setting that matters most and costs least. With it enforced, no
ACL mistake, no over-broad IAM binding, no copy-pasted policy can make objects world-readable.
That is the platform-level guarantee that the classic leaked-bucket incident cannot happen here.
Combined with access_control, the posture is: private is the invariant, and anything meant
to be public (static assets, downloads) belongs in a bucket explicitly designed for it, not in
an exception to a data bucket’s policy.
Versioning keeps what you deleted
Turning on versioning changes what deletion means: overwritten and deleted objects persist
as noncurrent versions, recoverable at will, and billed at full storage rates until removed.
A bucket with versioning and no lifecycle rules retains every version of every object forever,
which for frequently-rewritten data means storage costs several multiples of the visible data
size. Versioning is the right default for anything valuable; pairing it with lifecycle
expiration of old versions is what keeps it from becoming a silent cost multiplier.
Name and location are forever
Bucket names are globally unique across all of Google Cloud (the name is a claim in a shared
namespace), and a bucket’s location is fixed at creation. There is no move operation: changing
region means creating a second bucket and copying every object across, paying egress on the
way. storage_class sets the default cost/access trade for new objects and is the one big
setting that can evolve later. Name and location deserve the naming-scheme treatment; class
can be revisited.
Buckets you did not ask for
Not every bucket in the project arrives through this resource type. The 5 GCS buckets the observability stack creates for its own components arrive through that stack’s provisioning instead.