Filebrowser Common — Shared Application Configuration

Filebrowser_Common is the shared application layer for File Browser. It is not deployed on its own; instead it supplies the Filebrowser-specific configuration that Filebrowser_GKE builds on. It previously served a Cloud Run variant as well, which was retired in September 2026 — see the note below. End users never configure this layer directly — it has no deployment UI inputs of its own — but understanding what it provides explains the defaults you see in the platform docs.

For the infrastructure that actually provisions and runs Filebrowser, see the platform guide (Filebrowser_GKE) and the foundation guides (App_GKE, App_Common).

Filebrowser is GKE-only as of September 2026. File Browser stores its users, settings and share links in an embedded bbolt database, which holds an exclusive lock for the entire life of the process. Cloud Run keeps a warm revision alive even after traffic moves off it, so the outgoing revision never released that lock and every later revision failed to start — the service could be deployed once and never updated. GKE is unaffected: a StatefulSet stops the old pod before starting the new one.

---

1. What this layer provides

Area	Provided by Filebrowser_Common	Where it surfaces
Cryptographic secrets	None. Filebrowser stores its users and the initial admin credential inside its own embedded SQLite database; no Secret Manager env vars are generated	secret_ids / secret_values outputs are intentionally empty
Container image	Thin-wraps the official filebrowser/filebrowser image via a two-line Dockerfile; built with Cloud Build (Kaniko) and mirrored into Artifact Registry	container_image output of the platform deployment
Database engine	Fixes database_type = "NONE" — Filebrowser uses an embedded SQLite file, not Cloud SQL	§Persistence in the platform guides
Database bootstrap	None. No db-init job is injected; initialization_jobs is empty unless the operator supplies custom jobs	initialization_jobs output
Object storage	Declares one Cloud Storage bucket (suffix storage) that holds the persistent /database mount (the SQLite DB)	storage_buckets output
Core settings	Sets FB_DATABASE = /database/filebrowser.db and FB_ROOT = /srv, and pins the container to port 80	Application behaviour in the platform guides
Health checks	Supplies the default startup/liveness probe targeting /health	§Observability in the platform guides

---

2. Secrets — none

Filebrowser needs no secret environment variables. Unlike database-backed applications, it keeps its user table, settings, and share links inside its own embedded SQLite database (/database/filebrowser.db). The initial credential is the well-known admin / admin login, which the operator must change through the web UI on first access.

Consequently the Common layer's secret_ids and secret_values outputs are intentionally empty maps, and both variants wire them through unchanged (module_secret_env_vars = secret_ids, module_explicit_secret_values = secret_values). There is no encryption key or JWT secret to preserve across redeploys — the only durable state is the SQLite file on the /database volume (see §5).

---

3. Container image and build

The custom image is a two-line thin wrapper over the upstream Filebrowser release so the Foundation can mirror it into Artifact Registry:

ARG FILEBROWSER_VERSION=v2.32.0
FROM filebrowser/filebrowser:${FILEBROWSER_VERSION}

• App-specific build ARG. The Dockerfile reads FILEBROWSER_VERSION, not the generic APP_VERSION the Foundation injects (which would force latest). When application_version = "latest", Common resolves the build arg to the pinned v2.32.0; otherwise it passes the requested tag through. This keeps a latest deployment reproducible instead of chasing a moving upstream tag.
• Cloud Build (Kaniko). The image is built via cloudbuild.yaml using the Kaniko executor and pushed to the deployment's shared Artifact Registry repository, then used by the Cloud Run service / GKE workload.
• No custom entrypoint. The upstream image's own entrypoint launches the Filebrowser Go server directly; there is no wrapper script to remap variables.

---

4. Database initialization — none

Filebrowser manages its own storage and requires no database initialization. No db-init job is injected, and database_type is fixed to NONE. The initialization_jobs input is honoured only if the operator supplies custom jobs (for example, to seed files into the served tree) — otherwise it stays empty.

On first start the Filebrowser binary creates its SQLite database at FB_DATABASE = /database/filebrowser.db if the file does not yet exist, seeds the default admin/admin user, and begins serving the file tree rooted at FB_ROOT = /srv.

---

5. Object storage and persistence

A single Cloud Storage bucket (name suffix storage) is declared here and provisioned by the Foundation, which also grants the workload service account access. It is mounted into the container at /database, which is where the embedded SQLite database lives — so users, settings, and share links survive restarts and scale-to-zero.

• Cloud Run always mounts this bucket as a GCS FUSE volume at /database (enable_gcs_storage_volume = true).
• GKE mounts the same bucket as a GCS FUSE volume unless a StatefulSet block PVC is used at the same path (stateful_pvc_enabled = true), in which case Common sets enable_gcs_storage_volume = false to avoid a double-mount conflict — the PVC then provides /database instead.

The bucket location is left empty so the Foundation resolves it to the auto-discovered deployment region (coalesce(bucket.location, region)), which avoids force-replacing the immutable-location bucket on a cross-region re-apply.

List the bucket with:

gcloud storage buckets list --project "$PROJECT" --filter="name~storage"

---

6. Core application settings

Filebrowser_Common establishes the baseline environment so the application comes up correctly on first boot:

• FB_DATABASE = /database/filebrowser.db — points the embedded SQLite database at the persistent /database mount.
• FB_ROOT = /srv — the file tree Filebrowser serves and manages.
• Container port 80 — Filebrowser's default HTTP/1.1 listener (matches container_port).
• First login — admin / admin; change it in the web UI immediately.

Additional non-secret variables supplied via environment_variables are merged on top of these defaults.

---

7. Health probe behaviour

The default startup and liveness probes target /health — Filebrowser's unauthenticated health endpoint, which returns 200 once the server is listening. Because there is no database migration or first-run schema step, the server becomes ready quickly; the startup probe uses a 15-second initial delay with a 10-retry window, and the liveness probe uses a 30-second delay.

---

For the Filebrowser-specific, user-facing configuration (variables by group, outputs, and how to explore each service from the Console and CLI), see the platform guide: Filebrowser_GKE.

Related guides

• Filebrowser on GKE Autopilot — this configuration deployed on GKE.