Passbolt on GKE Autopilot

Passbolt (Community Edition) is a free, open-source, team-oriented password manager with GPG-based encryption and per-user/group credential sharing — AGPL-3.0 licensed, ~6k GitHub stars. It occupies a different niche from this catalog's Vaultwarden module: Vaultwarden is a personal/Bitwarden-compatible vault, while Passbolt is built around organization-wide GPG-encrypted credential sharing between users and groups. This module deploys the official passbolt/passbolt image on GKE Autopilot on top of the App_GKE foundation, which provisions and manages the shared Google Cloud and Kubernetes infrastructure.

This guide focuses on the cloud services Passbolt uses and how to explore and operate them from the Google Cloud Console and the command line. For the mechanics that are common to every GKE application — Workload Identity, ingress, autoscaling, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls, backups, and the deployment lifecycle — refer to the App_GKE foundation guide rather than repeating them here.

---

What Passbolt costs on RAD, and how that compares

For a team of ten, Passbolt on RAD's GKE Autopilot module costs about US$110 a month with no per-user licence. GKE suits a Passbolt that must stay up, scale across pods, or run beside other Kubernetes workloads. For the lowest cost, the Cloud Run module runs the same Passbolt for about US$84 a month. Figures are as at 8 October 2026; sources are listed at the end of this section.

If you only need it occasionally — studying for a certification, a demo, a seasonal business — a RAD-managed project can be deleted and restored within 30 days for a few credits, so that US$110 becomes a few dollars a month instead. See Pause it for free, below.

What you pay on RAD

	In a Google Cloud project you own	In a project RAD manages for you
Module fee, once per deployment	110 credits (US$11 at the top-up price)	99 credits (10% lower)
Build time	About 19 credits per build (RAD's average build takes about 19 minutes)	The same
Google Cloud running cost	Billed by Google to your own billing account (table below)	Metered hourly in credits; RAD publishes 99 credits a day, about 2,970 credits a month (about US$297 at the top-up price, US$238 at the Scale plan's rate)
Who owns what	You own the project and its billing; RAD deploys and updates it	RAD owns the project, with guardrails, quotas and budget alerts; you get console access, and a minimum purchased balance is held in reserve

10 credits cost US$1 on a one-off top-up, and less on a monthly plan. In a project RAD manages, the database, file server and network are shared by every application in the project, so a second application does not add a second database.

Default running cost in your own project (us-central1, Google list prices):

Resource (module default)	Per month
GKE Autopilot pod, 1x vCPU / 2 GiB	US$39.68
Cloud SQL for MySQL, 1 vCPU / 3.75 GB, zonal, 10 GB SSD	US$51.02
NFS/cache file server (small VM)	US$13.43
Cloud NAT and networking	US$5
Cloud Storage (add-ons, backups)	US$1
GKE cluster management fee	shared across every GKE app in the project; $0 if this is your only cluster, else ~73
Total	about US$110, or about US$183 without the free tier

• GKE's free tier covers the management fee of one Autopilot or zonal cluster per billing account, so it applies only if this is your only such cluster. Cloud SQL costs the same in africa-south1 (Johannesburg); the pod and VM cost about 10% more there.
• GKE Autopilot does not scale to zero. At least one Passbolt pod always runs, so the cost above is the same whether or not anyone is using it; extra pods are added only under load.
• Avoid Filestore for a small deployment. The module uses a small NFS/cache VM by default. Filestore's smallest instance is 1 TiB, which costs about US$164 a month on its own.

How it compares

• Passbolt sells its own Pro edition as a self-hosted licence: US$4.90 per user per month, billed annually, with a 10-user minimum (passbolt.com/pricing, 8 October 2026) — about US$49/month for a 10-person team. That is a licence fee on top of hosting, adding SSO, LDAP provisioning and tag management to the free Community Edition RAD deploys — it is not a hosted alternative to either RAD figure above.
• A bare VPS running the free Community Edition — Hetzner CPX22 or a DigitalOcean 2 vCPU/4 GB Droplet, both about US$24/month — undercuts RAD's own-project figure above, at the cost of running MySQL, backups and GPG key handling yourself. Passbolt only needs 1 vCPU / 2 GiB, so a smaller/cheaper VPS tier would likely do.
• For a password manager specifically, who can read the backups matters as much as the price: RAD keeps the database and secrets in Cloud SQL and Secret Manager rather than on a server you administer by hand.

Pause it for free: delete a RAD-managed project, restore it when you need it

If Passbolt runs in a project RAD manages for you, you have a second option that goes well beyond scaling to zero: delete the whole project, and restore it within 30 days for close to nothing. This suits occasional use — studying for a certification, a demo environment, a seasonal business — far better than running Passbolt continuously.

• How it works. Deleting a RAD-managed project unlinks its billing first, then asks Google to delete the project. Google does not remove the project immediately: it keeps it, recoverable, for 30 days. Because billing is already unlinked, nothing is charged while it waits. Unlike deleting one module, this does not tear down Cloud SQL, any VM or the GKE cluster one by one — the whole project, and everything in it, simply stops.
• Restoring costs a handful of credits, not a rebuild. Within 30 days, the project's owner can restore it. RAD asks Google to undelete the project and reattaches its billing account, then asks you to run Update on each deployment to confirm everything came back. Because nothing was individually destroyed, that Update finds the same resources already there — it is a check, not a rebuild, and an Update never charges the module fee again. That costs a handful of credits (under US$1) for a typical 2–3-deployment chain, against the 115 credits (US$11.50) a full redeploy costs below.
• So a month of occasional use can cost a few dollars, not US$110. Deploy Passbolt, use it for a while, delete the project. Restore it next time you want it, confirm with Update, and delete it again when you're done. You pay only for the module fee once, the builds, and whatever time Passbolt was actually live.
• What this needs. You must own the project (not a bring-your-own one RAD only manages billing for), and you restore it yourself within the 30 days — after that, Google deletes it for good. Restoring is admitted like creating a new project: your purchased credit balance must still clear the tier's floor (100 credits for the sandbox tier most study and demo use fits). Google says most services are fully working again within 36 hours of a restore.
• One real gap: the backup bucket does not survive. Passbolt's backups are written to a bucket inside the project, and that bucket is not protected by Cloud Storage's soft-delete, so it is very likely gone as soon as you delete the project — even though the project itself is recoverable for 30 days. If you have made changes to Passbolt you want to keep, copy a backup out (to Google Drive, or a bucket outside the project) before you delete, the same as the redeploy workflow below. For a default installation with nothing irreplaceable in it, this does not matter.

Pay only while you use it, the other way: delete and redeploy

GKE Autopilot does not scale to zero between requests. The option above only applies to a RAD-managed project; in your own project, or once the 30-day window has passed, the way to stop paying is to delete the deployment and deploy it again when you need it.

• What a redeploy costs. The module fee again plus the builds: about 115 credits (US$11.50), because RAD recreates the project and shared services before Passbolt. Deleting saves money only once Passbolt would otherwise sit unused for about 4 days or more, both in your own project (about US$3.67 a day) and in a RAD-managed one (99 credits a day).
• Most of the running cost is usually the database and the shared file/cache VM. They stop only when nothing else in the project uses them, so deleting Passbolt while something else shares the project saves only Passbolt's own compute part.
• Keep data first. Backups are written to a bucket inside the deployment and are deleted with it, so copy the latest backup out before deleting if you want to keep it.
• RAD does not recreate a deleted deployment for you; you enter the settings again when you deploy.

Lab sessions and Managed Environments

• Lab sessions, for training. A trainer runs a session for a class. Each participant gets the app in their own Google Cloud project for 15 minutes to 24 hours, within an allowance the trainer sets. Either the trainer funds every place, or each participant pays for their own. Everything is deleted when the session ends and unused credits go back to the trainer.
• Managed Environments, for consultancies. A partner runs the app for a client from a ring-fenced wallet it funds, and settles with the client directly. If the wallet runs low, billing pauses and the data is kept, so nobody receives an unexpected charge. At the end the partner hands the project over and the deployments become the client's own.

Credits can be bought in more than 20 currencies, including XAF, XOF, NGN, GHS, KES and ZAR, by card, bank transfer or mobile money.

Sources (8 October 2026): Google Cloud list prices from the Cloud Billing Catalog API; radmodules.dev/pricing for RAD's own fees and daily-credit estimates; Delete and restore projects for the pause/restore window and what it says about Cloud Storage objects without soft delete; Passbolt pricing.

---

1. Overview

Passbolt runs as a single Apache/PHP pod on GKE Autopilot. The deployment wires together a focused set of Google Cloud services:

Capability	Google Cloud service	Notes
Compute	GKE Autopilot	Apache/PHP pod, port 80, 1 vCPU / 2Gi by default, min_instance_count = 1, max_instance_count = 1
Database	Cloud SQL for MySQL (MYSQL_8_0)	Required — Passbolt is a MySQL-only CakePHP application; discrete DATASOURCES_DEFAULT_* env vars, not a single DSN
Cryptographic state	Two dedicated GCS-Fuse volumes (storage, jwt)	Hold the vendor-self-generated GPG server keypair and JWT keypair — not Terraform-generated secrets
Secrets	Secret Manager	Only the database password is generated by the foundation — Passbolt itself contributes no secret at all (Passbolt_Common's secret_ids output is always empty)
Ingress	Cloud Load Balancing	External LoadBalancer Service by default, optional custom domain + managed certificate

Sensible defaults worth knowing up front:

• MySQL is mandatory. database_type resolves to MYSQL_8_0 (fixed by Passbolt_Common); Passbolt is built on CakePHP with a MySQL-only schema.
• No server-side application secret. Unlike WordPress (multiple salts) or Laravel-family apps (APP_KEY), Passbolt has no Terraform-generated encryption key at all. Its security model is entirely client-side: the browser extension generates a GPG keypair and master password locally during setup. The server's own GPG keypair (for encrypting data to Passbolt) and its JWT keypair (API auth tokens) are both self-generated by the vendor's own entrypoint on first boot and persisted on dedicated GCS-Fuse volumes — not created or rotated by Terraform.
• Two purpose-built GCS-Fuse volumes, not one, and not the whole /etc/passbolt directory. storage mounts narrowly at /etc/passbolt/gpg; jwt mounts narrowly at /etc/passbolt/jwt. Mounting a single volume over all of /etc/passbolt would shadow baked-in config/PHP files (app.php, bootstrap.php, routes.php) that live directly in that directory in the image — the same class of bug this catalog previously hit with Cloudreve.
• GCS Fuse mount options set explicit uid=33/gid=33 — a real GKE-specific bug fix, not a defensive default. Even though the passbolt/passbolt image's top-level container process runs as root, the vendor entrypoint's gpg_gen_key() function actually performs the key-export step as su ... www-data (uid=33/gid=33). GKE's GCS Fuse CSI driver — unlike Cloud Run's own gcsfuse integration — does not default to a writable mount for a non-root UID, so both volumes explicitly set uid=33/gid=33 (plus file-mode=0664/dir-mode=0775) to avoid EACCES on first boot. This was found and fixed live: the same bug class as a uid-1000 Node app hit elsewhere in this catalog on the same day — always verify the actual runtime UID of whatever process writes to a GCS-Fuse-mounted path, not just the image's declared USER.
• HTTPS = "on" is always injected. Passbolt's bootstrap.php has $trustProxy = false hardcoded, so it does not honor X-Forwarded-Proto by default — but it does check the literal env('HTTPS') value directly. Since the GKE LoadBalancer terminates TLS at the edge and forwards plain HTTP to the pod, this static override makes Passbolt generate https:// URLs correctly in emails and absolute links.
• enable_cloudsql_volume defaults to true here — matching Passbolt_Common's own default, and the opposite of Passbolt_CloudRun, whose top-level variable defaults false.
• No first-visit web setup wizard. The only way an admin account exists is via the admin-bootstrap init job, which prints a one-time setup URL to its pod logs (surfaced in Cloud Logging) for the operator to open in a Passbolt-compatible browser extension.
• No Redis. enable_redis = false by default — Passbolt has no Redis integration used by this module.

---

2. Google Cloud Services & How to Explore Them

All commands assume you have run gcloud container clusters get-credentials <cluster> --region <region> --project <project> and that PROJECT, REGION, and NAMESPACE are set. The namespace and other identifiers are reported in the deployment Outputs.

A. GKE Autopilot — the Passbolt workload

• Console: Kubernetes Engine → Workloads → select the Passbolt workload to see pods, revisions, and events. Kubernetes Engine → Services & Ingress shows the external IP.
• CLI:

  kubectl get pods,svc -n "$NAMESPACE"
  kubectl logs -n "$NAMESPACE" deploy/<service-name> --tail=100

See App_GKE for how Autopilot and the workload type (Deployment vs StatefulSet) are managed.

B. Cloud SQL for MySQL

Passbolt stores all application data — users, groups, folders, encrypted password resources, sharing permissions — in a managed Cloud SQL MySQL 8.0 instance. Pods reach it through the Cloud SQL Auth Proxy sidecar over a loopback TCP connection (127.0.0.1) by default (enable_cloudsql_volume = true). The connection uses Passbolt's own discrete env var names (DATASOURCES_DEFAULT_HOST/_USERNAME/_PASSWORD/_DATABASE, confirmed against the vendor's own /passbolt/env.sh), aliased from the Foundation's standard DB_* values by the Application Module.

• Console: SQL → select the instance for connections, backups, flags, and metrics.
• CLI:

  gcloud sql instances list --project "$PROJECT"
  gcloud sql instances describe <instance-name> --project "$PROJECT"
  gcloud sql connect <instance-name> --user=<db-user> --database=<db-name> --project "$PROJECT"

See App_GKE for the connection model, automated backups, and password rotation.

C. Cloud Storage — the GPG and JWT keypair volumes

Two GCS buckets are provisioned by Passbolt_Common and mounted via the GCS Fuse CSI driver: storage at /etc/passbolt/gpg, jwt at /etc/passbolt/jwt, both with explicit uid=33/gid=33 mount options (see Overview). These hold the vendor-self-generated server GPG keypair and JWT keypair, both generated once on first boot and reused on every subsequent boot. Losing either bucket invalidates every credential Passbolt has encrypted server-side and every issued JWT session.

• Console: Cloud Storage → find the two buckets (names include storage and jwt suffixes).
• CLI:

  gsutil ls -p "$PROJECT" | grep passbolt
  gsutil ls gs://<storage-bucket-name>/    # expect serverkey.asc, serverkey_private.asc

D. Secret Manager

Passbolt itself contributes no secret — the only Secret Manager entry related to this deployment is the database password, managed by the Foundation.

• Console: Security → Secret Manager.
• CLI:

  gcloud secrets list --project "$PROJECT" --filter="name~passbolt"

E. Networking & ingress

By default the workload is exposed through an external Cloud Load Balancing IP (service_type = LoadBalancer). A custom domain with a Google-managed certificate can be enabled, and a static IP is reserved by default (reserve_static_ip = true) so the address survives redeploys.

• Console: Network services → Load balancing; VPC network → IP addresses.
• CLI:

  kubectl get svc -n "$NAMESPACE"
  gcloud compute addresses list --project "$PROJECT"

See App_GKE for custom domains, Cloud CDN, and static IP details.

F. Cloud Logging & Monitoring

Pod stdout/stderr flow to Cloud Logging — including the admin-bootstrap init job's one-time setup URL output. GKE and Cloud SQL metrics flow to Cloud Monitoring, with optional uptime checks and alert policies.

• Console: Logging → Logs Explorer; Monitoring → Dashboards / Alerting.
• CLI:

  gcloud logging read 'resource.type="k8s_container" AND resource.labels.namespace_name="'"$NAMESPACE"'"' \
    --project "$PROJECT" --limit 50

---

3. Passbolt Application Behaviour

• The 2-stage initialization job chain, and why the second job is genuinely non-trivial. Passbolt_Common defines two ordered Kubernetes Jobs, both with execute_on_apply = true:

  1. db-init (mysql:8.0-debian) — creates the MySQL role and database (the shared catalog-wide db-init.sh, caching_sha2_password-safe).

  2. admin-bootstrap (passbolt/passbolt:<version>, depends_on_jobs = ["db-init"], mounts the storage and jwt volumes) — registers the initial admin account.

     Kubernetes Jobs invoke a container's command/args directly, bypassing the vendor's own /docker-entrypoint.sh chain entirely — so a bare cake passbolt register_user on a freshly-provisioned container fails with an Internal Error 500, because the GPG server keypair (normally generated during the vendor entrypoint's own boot sequence) doesn't exist yet, and the schema hasn't been installed either. The job instead sources the vendor's own entrypoint functions (/passbolt/entrypoint.sh, /passbolt/env.sh, /passbolt/deprecated_paths.sh), generates/imports the GPG server keypair if missing, generates a self-signed SSL cert if missing, runs the vendor's own install() function (which also handles JWT keypair generation and the database schema install/migrate), and only then runs cake passbolt register_user -u <admin_email> -f <admin_first_name> -l <admin_last_name> -r admin — without the -q/quiet flag, so the one-time setup URL is printed and lands in the job pod's logs. Confirmed against the real vendor /passbolt/entrypoint.sh source. Idempotent: gpg_gen_key/install() no-op once the keys and schema already exist from a prior run.

  On GKE, execute_on_apply = false (if ever set on a custom job) would only stop Terraform from waiting for the job — the underlying Kubernetes Job/pod is still created and scheduled immediately either way. Correctness of the db-init → admin-bootstrap ordering here relies on depends_on_jobs (App_GKE's job dependency system), not on apply-time sequencing.

• No first-visit setup wizard, and a genuinely different bootstrap model from most apps in this catalog. Passbolt requires the client (a browser extension) to generate its own GPG keypair and master password — there is no server-side password to seed and nothing to retrieve from Secret Manager. Retrieve the one-time setup URL instead:

  kubectl get jobs -n "$NAMESPACE"
  kubectl logs -n "$NAMESPACE" job/<admin-bootstrap-job-name> | grep '/setup/start/'

• Health endpoint. GET /healthcheck/status.json returns an unauthenticated 200 with {"header":{"status":"success",...},"body":"OK"} once ready — confirmed via local container testing and live deployment. Both the container-level startup_probe/liveness_probe target this path by default.

• Inspect job execution:

  kubectl get jobs -n "$NAMESPACE"
  kubectl logs -n "$NAMESPACE" job/<job-name>

---

4. Configuration Variables

Variables are grouped exactly as they appear on the deployment platform. Only settings specific to or notable for Passbolt are listed; every other input is inherited from App_GKE with its standard behaviour and defaults.

Group 1 — Project & Identity

Variable	Default	Description
project_id	(required)	Target Google Cloud project.
region	us-central1	Region for the workload and regional resources.

Group 2 — Deployment Environment

Variable	Default	Description
tenant_id	demo	Short suffix that makes resource names unique per environment. Use a distinct value (e.g. gke) from any co-deployed Passbolt_CloudRun (cr) to avoid a naming collision.
support_users	[]	Emails granted project access and monitoring alerts.
resource_labels	{}	Labels applied to all resources.

Group 3 — Application & Database Identity

Variable	Default	Description
application_name	passbolt	Base name for resources. Do not change after first deploy.
application_display_name	Passbolt	Human-readable name shown in the Console.
application_version	latest	passbolt/passbolt image tag.
admin_email	admin@example.com	Email for the admin account registered by admin-bootstrap.
admin_first_name / admin_last_name	Admin / User	Name fields for the initial admin account.
enable_gcs_storage_volume	true	Mounts the storage (GPG) and jwt GCS-Fuse volumes. Keep enabled.

Group 4 — Runtime & Scaling

Variable	Default	Description
container_image_source	prebuilt	Deploys the official image directly; Passbolt only supports the prebuilt image.
cpu_limit	1000m	1 vCPU.
memory_limit	2Gi	Memory limit — PHP 8.x + Apache.
container_port	80	Passbolt (Apache) listens here.
min_instance_count	1	Minimum pod replicas.
max_instance_count	1	Maximum pod replicas.
enable_cloudsql_volume	true	Cloud SQL Auth Proxy sidecar. Passbolt's DATASOURCES_DEFAULT_HOST alias resolves to the sidecar's loopback address when enabled.
enable_image_mirroring	true	Mirrors the Passbolt image into Artifact Registry.

Group 6 — GKE Backend Configuration

Variable	Default	Description
service_type	LoadBalancer	How the Kubernetes Service is exposed.
workload_type	null (resolves to Deployment)	"Deployment" or "StatefulSet".
session_affinity	ClientIP	Session affinity for the Kubernetes Service.
namespace_name	"" (auto-generated)	Kubernetes namespace.

Group 13 — NFS

Variable	Default	Description
enable_nfs	true	Provisions a Filestore volume. Not used by Passbolt's own persistence model — the GPG/JWT keypairs live on dedicated GCS-Fuse volumes and everything else is in MySQL. Harmless generic default.

Group 14 — Cloud Storage

Variable	Default	Description
gcs_volumes	[]	Additional GCS buckets to mount via the GCS Fuse CSI driver, on top of the two Passbolt provisions automatically (storage, jwt).

Group 16 — Database Configuration

Variable	Default	Description
database_type	null (resolves to MYSQL_8_0)	Cloud SQL engine. Passbolt requires MySQL.
application_database_name	passbolt	MySQL database name.
application_database_user	passbolt	MySQL application user.
database_password_length	32	Generated password length (16–64).

Group 11 — Workload Automation

Variable	Default	Description
initialization_jobs	[]	Leave empty for Passbolt_Common's default 2-job chain (db-init → admin-bootstrap). A non-empty list replaces it entirely.
cron_jobs	[]	Passbolt has no platform-scheduled recurring tasks by default.

Group 10 — Observability & Health

Variable	Default	Description
startup_probe / liveness_probe	HTTP /healthcheck/status.json	Container-level probes, passed through Passbolt_Common.
startup_probe_config / health_check_config	Foundation LoadBalancer-level probes	Path "/" by default — distinct from the container-level probes above.
uptime_check_config	{ enabled=false, path="/" }	Cloud Monitoring uptime check.

Group 15 — Redis

Variable	Default	Description
enable_redis	false	Not used by Passbolt. Present for platform compatibility.

Group 19 — Custom Domain, Static IP & Networking

Variable	Default	Description
enable_custom_domain	true	Provision Ingress for custom hostnames.
reserve_static_ip	true	Reserve a stable global static IP — recommended so the service address doesn't shift on redeploy.

Every other input (Module Metadata, Environment Variables & Secrets, CI/CD & GitHub Integration, Custom SQL, IAP & Cloud Armor, StatefulSet Configuration, VPC Service Controls, Reliability Policies) is inherited from App_GKE with its standard behaviour — see App_GKE for the full, group-organized list.

---

5. Outputs

Returned on a successful deployment — the quickest way to locate and explore the running resources.

Output	Description
service_name	Kubernetes Service name.
namespace	Namespace the workload runs in.
service_cluster_ip / service_external_ip	In-cluster ClusterIP / external LoadBalancer IP.
service_url	URL to reach Passbolt.
database_instance_name	Cloud SQL instance name.
database_name / database_user	Application database name / user.
database_password_secret	Secret Manager secret holding the DB password.
database_host / database_port	DB endpoint (127.0.0.1 via the Auth Proxy sidecar) / port.
storage_buckets	The storage (GPG) and jwt GCS buckets.
container_image	Deployed image.
initialization_jobs	Names of the created init jobs (db-init, admin-bootstrap).
kubernetes_ready	Whether the cluster endpoint is available and all workload resources are deployed. false on the first apply of a new inline cluster — a re-run completes the deployment.
deployment_id / tenant_id / resource_prefix	Naming identifiers.
project_id / project_number	Project identifiers.

---

6. Configuration Pitfalls & Sensible Defaults

Risk: Critical (data loss / outage / security) — High (service degraded) — Medium (cost or partial degradation) — Low (minor).

Inherited plan-time validation. This module passes its configuration through the App_GKE foundation engine, which validates values and combinations at plan time. Invalid configuration fails the plan with a clear, named error before any resource is created.

Setting	Sensible value	Risk	Consequence if wrong
database_type	resolves to MYSQL_8_0	Critical	Passbolt's CakePHP schema is MySQL-only — any other engine breaks startup entirely.
enable_gcs_storage_volume	true	Critical	Disabling loses the persistent volumes for the self-generated GPG server keypair and JWT keypair — every credential Passbolt has encrypted server-side, and every issued JWT session, becomes unrecoverable on the next pod restart.
GCS Fuse uid=33/gid=33 mount options	Already set in Passbolt_Common — do not remove if customizing gcs_volumes	Critical	Without them, www-data (the uid the vendor entrypoint's key-generation step actually runs as) gets EACCES: permission denied writing the GPG/JWT key files on first boot, and the pod never becomes genuinely usable even if it reports Ready.
initialization_jobs order (db-init → admin-bootstrap)	Leave [] unless you fully understand the dependency	Critical	The admin-bootstrap job's replication of the vendor's own GPG-key-generation/schema-install sequence is load-bearing — a naive replacement job that just runs cake passbolt register_user directly fails with an Internal Error because the GPG server keypair and schema don't exist yet. On GKE, execute_on_apply=false does NOT delay pod scheduling — only Terraform's wait — so the ordering guarantee comes entirely from depends_on_jobs.
enable_cloudsql_volume	true (this variant's default)	High	The Auth Proxy sidecar is the intended MySQL connectivity path on GKE.
reserve_static_ip	true	Medium	Without a reserved static IP, the external LoadBalancer address can change across redeploys, breaking any bookmarked URL or DNS record pointed at it.
admin_email / admin_first_name / admin_last_name	Set intentionally before first deploy	Medium	These seed the one and only admin account the admin-bootstrap job creates; there is no in-app way to change them after the fact except through Passbolt's own admin UI once logged in.
No admin password to lose track of	—	—	Unlike most apps in this catalog, there is no Secret-Manager-held admin credential to retrieve. If the one-time setup URL is missed and expires, the fix is re-running the admin-bootstrap job (idempotent for the GPG/JWT/schema steps; check Passbolt's own CLI docs for re-issuing a setup link for register_user).

---

For the foundation behaviour referenced throughout — Workload Identity, autoscaling, ingress and certificates, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC-SC, backups, and image mirroring — see App_GKE. Passbolt-specific application configuration shared with the Cloud Run variant is described in Passbolt_Common.

Related guides

• Hands-on lab: Passbolt on GKE Autopilot — deploy it step by step, with the console screens and commands at each stage.
• Passbolt on Google Cloud Run — the same application on Cloud Run, for when you need the other deployment target.
• Passbolt Common — Shared Application Configuration — the configuration shared by both deployment targets.