Self-managed engineering project · Public delivery and live GCP inventory verified 24 July 2026
A self-managed hybrid-cloud project that answers one question: how can a local k3s platform gain static delivery and off-site backup without adding unnecessary always-on compute?
The site is static, but the platform still needs a credible release path, encrypted Kubernetes metadata backups, scoped Google Cloud access, and an operational trail. Running a VM, GKE cluster, or Cloud Run service for those needs would add cost and another failure domain.
Firebase Hosting serves the static files; a k3s CronJob collects allowlisted configuration without requesting Secret objects and records only ConfigMap names and keys, then compresses and age-encrypts the archive before uploading it to private Cloud Storage through Workload Identity Federation. Terraform owns cloud controls, while Kustomize owns the Kubernetes workload and RBAC.
The repository contains a repeatable static release and a backup path whose remote object size, encryption boundary, logs, retention, and restore inspection can be checked separately. A read-only GCP inventory on 24 July 2026 confirmed active Firebase, WIF, private storage, monitoring, and snapshot controls with no VM, GKE, Cloud Run, or Cloud SQL runtime. The design avoids always-on application compute while leaving old snapshots, an Artifact Registry repository, and the default network for explicit cleanup review.
The project separates static delivery, private recovery data, cloud identity, and operator-owned restore work while applying Terraform, Kubernetes, Bash, IAM, monitoring, and cost reasoning in context.
The deployment plane moves from Git through the dev-only workflow to Firebase Hosting. The data plane moves from allowlisted k3s configuration through Secret-object exclusion, ConfigMap key-only inventory, compression, age encryption, federated authentication, private Cloud Storage, and structured monitoring. Management and cost controls stay in Terraform.
A sanitized visual of the hybrid-cloud deployment and backup architecture.
Read the diagram notesFirebase Hosting serves the static files; a k3s CronJob collects allowlisted configuration without requesting Secret objects and records only ConfigMap names and keys, then compresses and age-encrypts the archive before uploading it to private Cloud Storage through Workload Identity Federation. Terraform owns cloud controls, while Kustomize owns the Kubernetes workload and RBAC.
Firebase fits a site made of static files, images, JSON, a PDF, and a service worker. It avoids paying for compute whose only job would be to serve already-built assets; the tradeoff is dependence on a managed hosting control plane.
Projected Kubernetes tokens exchange for short-lived Google credentials scoped to the backup or registry task. This avoids distributing a permanent service-account key to the cluster. The tradeoff is an extra issuer, audience, and public-JWKS dependency that must be maintained when signing keys rotate.
Remote-size comparison answers whether the encrypted upload arrived with the expected byte count; decrypt-and-list inspection answers whether the archive can be opened. Keeping those gates separate avoids a misleading backup-success boolean. Application data and restore execution remain manual, separately owned work.
The active site is Firebase Hosting; the former Cloud Run and load-balancer path is historical. This prevents two incompatible architectures from appearing current. The cleanup record preserves the old relationships, but rollback now requires reviewed manual reconstruction and fresh DNS/TLS checks rather than an automatic switch.
The collector excludes Secret objects and ConfigMap values, encrypts the archive before upload, and keeps Cloud Storage private. Workload specifications can still contain literals, so every archive remains sensitive.
Projected Kubernetes tokens are exchanged through Workload Identity Federation for scoped Google credentials, avoiding a permanent service-account key in the cluster while making issuer and JWKS maintenance explicit.
Upload-size comparison, decrypt-and-list inspection, scheduled-job status, storage lifecycle, monitoring, and budget controls provide distinct evidence. None is promoted into a claim that application recovery was completed.
public route: HTTPS 200
www: canonical redirect
active runtime: no VM, GKE, Cloud Run, or Cloud SQL found
federation: one active WIF pool/provider
user-managed service-account keys: none
backup bucket: private, uniform access, versioned, lifecycle managed
archive evidence: encrypted upload and decrypt/list verified
resource restore: not performedChecks shown here are project-specific; no portfolio-wide claim is applied automatically.
Links are limited to public-safe source material and sanitized evidence. Credentials, state, plans, identifiers, private topology, and backup contents are intentionally excluded.
Deployment, identity, storage, and ownership boundaries.
Federated identity, RBAC, encryption, and retained-data risks.
Archive inspection, restore authority, and remaining gaps.
Validation, monitoring, cost checks, and operator handoff.
Automate a disposable restore environment and publish signed restore-drill evidence without exposing cluster or cloud identifiers.