Designing a portable GCS static site
Published: August 13, 2025 · By Invecture Labs Engineering
Google Cloud Storage (GCS) is often overlooked as a primary hosting platform in favor of specialized providers. However, for AI/HPC organizations already operating within GCP, using GCS for documentation and engineering logs provides a "zero-overhead" solution that integrates natively with your existing IAM and CI/CD pipelines.
The Ideal Layout
To ensure portability (making it easy to move between buckets or regions), we follow a strict directory structure that separates concerns between immutable assets and mutable content.
bucket-root/
├── index.html # Main entry
├── assets/ # Immutable (fingerprinted)
│ ├── main.d41d.css
│ └── logo.webp
├── blog/ # Versioned content
│ ├── index.json # Metadata for dynamic loading
│ └── post-name.html
├── sitemap.xml
└── robots.txt
Critical Metadata: Cache-Control
The secret to a "fast" GCS site isn't just the backbone—it's the browser cache. GCS allows you to set the Cache-Control header per object. We recommend these defaults:
- HTML:
public, max-age=3600, must-revalidate(allows for quick rollbacks). - Assets:
public, max-age=31536000, immutable(long-term caching for fingerprinted files).
Infrastructure as Code (Terraform)
Don't click around the console. Define your bucket and its website configuration with Terraform to ensure reproducibility across dev/prod environments.
resource "google_storage_bucket" "static_site" {
name = "www.invecturelabs.com"
location = "US"
storage_class = "STANDARD"
website {
main_page_suffix = "index.html"
not_found_page = "404.html"
}
cors {
origin = ["https://invecturelabs.com"]
method = ["GET", "HEAD"]
response_header = ["*"]
max_age_seconds = 3600
}
}
Conclusion
By treating your GCS bucket like a high-performance filesystem rather than just a "dumping ground" for files, you can achieve sub-100ms TTFB globally without the complexity of a managed hosting provider.