Spoolman on GKE Autopilot

Spoolman is a free, open-source inventory and usage tracker for 3D-printing filament spools — vendors, materials, remaining weight, cost per spool, and per-print consumption. It ships as a single-process Python/FastAPI backend with a bundled static Vue/Quasar frontend. This module deploys Spoolman 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 Spoolman uses and how to explore and operate them from the Google Cloud Console and the command line. For the mechanics 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 Spoolman costs on RAD, and how that compares

Spoolman on RAD's GKE Autopilot module costs about US$91.31 a month in a Google Cloud project you own, with the module fee charged once in RAD credits. GKE suits Spoolman that needs to sit beside other Kubernetes workloads; for the lowest cost, the Cloud Run module runs the same Spoolman for about US$67.80 a month instead. If you only need Spoolman occasionally — between print jobs, or while trying it out — a RAD-managed project can be deleted and restored within 30 days for a handful of credits (under US$1) instead of paying for it to sit idle. See Pause it for free, below. Figures are as at 8 October 2026; sources are listed at the end of this section.

What you pay on RAD

	In a Google Cloud project you own	In a project RAD manages for you
Module fee, once per deployment	40 credits (US$4 at the top-up price)	36 credits (10% lower)
Build time	About 3-6 credits per build	The same
Google Cloud running cost	Billed by Google to your own billing account, about US$91.31 a month for the default configuration (table below)	Metered hourly in credits; RAD publishes 87 credits a day, about 2,610 a month
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 and network are shared by every application in the project, so a second application does not add a second set of them.

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

Resource (module default)	Per month
GKE Autopilot pod, 1x vCPU / 0.5 GiB	US$34.29
Cloud SQL for PostgreSQL, 1 vCPU / 3.75 GB, zonal, 10 GB SSD	US$51.02
Cloud NAT and networking	US$5.00
Cloud Storage (add-ons, backups)	US$1.00
GKE cluster management fee	shared across every GKE app in the project; $0 if this is your only cluster, else ~73
Total	US$91.31

How it compares

• Spoolman has no commercial hosted SaaS of its own — it is distributed only as self-hosted, Docker-first open-source software for 3D-printing workshops to run themselves.
• A self-managed comparison: Hetzner CPX22 (2 vCPU/4GB) runs about $24/month, a DigitalOcean 2 vCPU/4GB Droplet is the same $24/month, and a GCP Compute Engine e2-standard-2 (2 vCPU/8GB) is about $49/month — all considerably more machine than Spoolman's 1 vCPU / 0.5 GiB footprint needs; a $5-6/month shared-vCPU micro instance from any of the same providers would run it comfortably, plus the admin's own time for backups, security patches and upgrades that RAD's managed Cloud SQL, Secret Manager and monitoring cover for you.
• Most of RAD's own-project running cost here is the managed PostgreSQL instance and the shared GKE cluster management fee, not Spoolman's own pod — the database would be needed on a bare VPS too, just unmanaged there.

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

If Spoolman runs in a project RAD manages for you, deleting the whole project unlinks its billing first, then asks Google to delete the project outright — Google's own 30-day recoverable soft delete. Unlike deleting one module, this does not tear down Cloud SQL, the cluster or the compute resource one by one: the whole project simply stops, and nothing is charged while it waits, because billing is already unlinked.

Restoring, within 30 days and only by the project's owner, 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. This costs only a handful of credits (under US$1) in total for a typical 2-3-deployment chain.

What this needs: you must own the project (not one RAD only manages billing for), you must restore it yourself within 30 days — after that Google deletes it for good — and restoring is admitted like creating a new project, so your purchased credit balance must still clear the tier's floor (100 credits for the sandbox tier most study/demo use fits). Google says most services are fully working again within 36 hours of a restore.

One real gap: nightly backups are written to a bucket inside the project, and that bucket has Cloud Storage's soft-delete explicitly turned off, 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 customised Spoolman's data and want to keep it, copy a backup out (to Google Drive, or a bucket outside the project) before deleting. For a default install with nothing irreplaceable in it, this does not matter.

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

In your own project, or once the 30-day restore window has passed, the alternative is to delete Spoolman outright and redeploy it later. A redeploy costs the module fee again, plus the builds — roughly 45 credits (about US$4.50) in your own project, or 41 credits in a RAD-managed one.

Deleting saves money only once Spoolman would otherwise sit unused long enough to clear that redeploy cost against its own daily running cost — against the own-project total above (about US$3.04 a day), that works out to about 2 days or more, or about 1 days or more in a RAD-managed one (87 credits a day). Most of the running cost here is the database and the shared cluster fee; they stop only when nothing else in the project uses them, so deleting Spoolman while something else shares the project saves only this app's own compute part.

Keep data first: nightly backups go 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.

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 Billing Catalog API list prices; radmodules.dev/pricing for RAD's own fees and daily-credit estimates; Delete and restore projects for the pause/restore mechanics. No currently-verified commercial hosted SaaS exists for Spoolman, so no competitor price is named.

1. Overview

Spoolman runs as a single Python/FastAPI pod — there is no separate frontend workload; the Vue/Quasar UI is bundled and served from the same process. The deployment wires together a minimal set of Google Cloud services:

Capability	Google Cloud service	Notes
Compute	GKE Autopilot	Prebuilt ghcr.io/donkie/spoolman image, 1 vCPU / 512Mi by default
Database	Cloud SQL for PostgreSQL 15	Required — this module standardises on Postgres (Spoolman upstream also supports MySQL/SQLite/CockroachDB)
Object storage	None	Spoolman keeps all state in Postgres; no GCS bucket is provisioned
Cache	None	Spoolman has no Redis/cache integration
Secrets	Secret Manager	Only the auto-generated database password — Spoolman has no admin/API-key bootstrap secret of its own
Ingress	Cloud Load Balancing	External LoadBalancer by default

Sensible defaults worth knowing up front:

• PostgreSQL 15 is the only supported engine in this module. database_type is fixed by Spoolman_Common; Spoolman upstream also supports MySQL and CockroachDB via env vars, but this module does not expose that choice.
• No custom build. container_image_source = "prebuilt" deploys ghcr.io/donkie/spoolman directly — there is no Dockerfile, no Cloud Build step.
• No init job. The Foundation auto-creates the Postgres role and database; Spoolman runs its own Alembic migrations automatically on every container start.
• No application secrets. Spoolman ships with no authentication at all — whoever can reach the Service has full read/write access to the inventory. There is no login gate to bootstrap and nothing generated in Secret Manager beyond the database password. If that is not acceptable, put the service behind IAP (enable_iap = true) or a Cloud Armor IP allowlist.
• service_type = "LoadBalancer" by default. Spoolman is a browser-driven web UI, so the Service is externally reachable out of the box.
• reserve_static_ip = false by default. Spoolman bakes no self-referencing URL into boot-time config (only SPOOLMAN_CORS_ORIGIN matters, and only for cross-domain access), so this module conserves the project's often-tight static-IP quota by not reserving one.
• Connections use the cloud-sql-proxy sidecar's loopback, not TCP. Spoolman's SQLAlchemy layer builds its connection via URL.create() (a structured object, not string concatenation), so 127.0.0.1 passes through cleanly with no URL-parsing issue and no TLS/sslmode configuration needed.

---

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 Spoolman workload

Spoolman runs as a single Deployment/pod on Autopilot, which bills for the CPU/memory the pod actually requests.

• Console: Kubernetes Engine → Workloads → select the Spoolman workload for 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 scaling are managed.

B. Cloud SQL for PostgreSQL 15

Spoolman stores all inventory data (spools, filaments, vendors, usage history) in a managed Cloud SQL for PostgreSQL 15 instance. The pod reaches it privately through the Cloud SQL Auth Proxy sidecar over loopback; no public IP is exposed. There is no initialization job — Spoolman applies its own schema migrations on every boot.

• 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"

The instance name, database, user, and password secret are in the Outputs. See App_GKE for the connection model, backups, and password rotation.

C. Secret Manager

Only the auto-generated database password lives in Secret Manager — Spoolman has no admin account or API key of its own to bootstrap.

• Console: Security → Secret Manager.
• CLI:

  gcloud secrets list --project "$PROJECT" --filter="name~spoolman"
  gcloud secrets versions access latest --secret=<db-password-secret> --project "$PROJECT"

D. Networking & ingress

The Service is reachable at its external LoadBalancer IP by default (service_type = "LoadBalancer", reserve_static_ip = false so the IP is ephemeral unless changed).

• Console: Kubernetes Engine → Services & Ingress.
• CLI:

  kubectl get svc -n "$NAMESPACE" -o wide

See App_GKE for custom domains, CDN, and Cloud Armor.

E. Cloud Logging & Monitoring

Container logs flow to Cloud Logging; GKE and Cloud SQL metrics flow to Cloud Monitoring, with optional uptime checks and alert policies.

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

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

---

3. Spoolman Application Behaviour

• No first-deploy database setup job. Unlike most application modules in this catalogue, Spoolman needs no db-init job — the Foundation creates the Postgres role and database, and Spoolman's own Alembic migrations run automatically on every container start (including the very first boot).
• No authentication. There is no login page, no admin account, and no API key gate. Anyone who can reach the Service can view and modify the entire inventory. Decide your access-control approach (IAP, Cloud Armor allowlist, or accept public read/write) before exposing the LoadBalancer IP.
• Health path. /api/health is public and unauthenticated, returning a 200/OK JSON status once the server (and its DB connection) is up. Both the startup and liveness probes target this path.
• Database engine locked to Postgres. Spoolman's own SPOOLMAN_DB_TYPE environment variable selects the engine; this module always sets it to postgres. Never unset it via environment_variables — without it, Spoolman silently falls back to a throwaway container-local SQLite file with no error at all.
• Inspect Cloud SQL connectivity:

  kubectl exec -n "$NAMESPACE" deploy/<service-name> -- env | grep -i spoolman_db

---

4. Configuration Variables

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

Group 3 — Application Identity

Variable	Default	Description
application_name	spoolman	Base name for resources. Do not change after first deploy.
application_display_name	Spoolman	Human-readable name.
application_version	latest	Image tag pulled from ghcr.io/donkie/spoolman. Genuinely prebuilt — no Dockerfile/build-arg pinning concerns.

Group 4 — Container & Scale

Variable	Default	Description
deploy_application	true	Set false to provision infrastructure only.
container_image_source	prebuilt	Forwarded to the Foundation — required, or the default "custom" silently triggers a Kaniko build attempt with no Dockerfile.
container_port	8000	Spoolman's default listen port.
container_resources	{ cpu_limit = "1000m", memory_limit = "512Mi" }	Ample for a single-tenant filament tracker.
min_instance_count / max_instance_count	0 / 1	Scale-to-zero is safe — Spoolman has no background work.

Group 16 — Database

Variable	Default	Description
db_host_env_var_name	SPOOLMAN_DB_HOST	Aliases the Foundation's DB_HOST (127.0.0.1 via the cloud-sql-proxy sidecar on GKE).
db_user_env_var_name	SPOOLMAN_DB_USERNAME	Aliases DB_USER.
db_password_env_var_name	SPOOLMAN_DB_PASSWORD	Aliases DB_PASSWORD.
db_name_env_var_name	SPOOLMAN_DB_NAME	Aliases DB_NAME.
db_port_env_var_name	SPOOLMAN_DB_PORT	Aliases DB_PORT.
application_database_name / application_database_user	spoolman / spoolman	Immutable after first deploy.

Group 14 — Storage & Filesystem

Variable	Default	Description
create_cloud_storage	false	No GCS bucket needed — all state lives in Cloud SQL.
enable_nfs	false	No shared filesystem needed.

Group 19 — Networking

Variable	Default	Description
service_type	LoadBalancer	Spoolman is a browser-driven web UI, exposed externally by default.
reserve_static_ip	false	Conserves the project's static-IP quota; Spoolman bakes no self-referencing URL into boot-time config.

Group 10 — Probes & Lifecycle

Variable	Default	Description
startup_probe_config	HTTP /api/health, 10s delay	Public, unauthenticated.
health_check_config	HTTP /api/health, 30s period	Public, unauthenticated.

All other inputs (CI/CD, backups, VPC-SC, Cloud Armor, IAP, Redis, stateful PVCs) are inherited from App_GKE with standard behaviour — Spoolman uses none of them by default.

---

5. Outputs

Output	Description
service_name	Kubernetes Service name.
namespace	Kubernetes namespace.
service_cluster_ip	Internal ClusterIP.
service_external_ip	External LoadBalancer IP.
service_url	Full URL of the deployed workload.
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 / port.
storage_buckets	Always empty — Spoolman needs no GCS bucket.
container_image / container_registry	Deployed image and Artifact Registry repo (when mirroring is enabled).
monitoring_enabled	Monitoring status.
initialization_jobs	Always empty — Spoolman needs no init job.
kubernetes_ready	Whether the workload reports ready.
deployment_id / tenant_id / resource_prefix	Naming identifiers.
project_id / project_number	Project identifiers.
vpc_sc_enabled / vpc_sc_perimeter_name / vpc_sc_dry_run_mode	VPC-SC status.
audit_logging_enabled / artifact_registry_cmek_enabled	Audit logging and CMEK status.

---

6. Configuration Pitfalls & Sensible Defaults

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

Setting	Sensible value	Risk	Consequence if wrong
No authentication (built-in)	Front with IAP or Cloud Armor if needed	Critical	Anyone who can reach the Service can read and modify the entire filament inventory — there is no login gate to disable.
SPOOLMAN_DB_TYPE (auto-injected postgres)	Never unset via environment_variables	Critical	Unsetting it silently falls back to a throwaway container-local SQLite file — no error, and all data is lost on every pod restart.
application_database_name / application_database_user	Set once	Critical	Immutable after first deploy; renaming recreates the DB/user and destroys all data.
container_image_source	prebuilt (do not override to custom)	Critical	Setting "custom" triggers a Kaniko build attempt against a module with no Dockerfile — the build fails outright.
service_type	LoadBalancer (default)	High	Switching to ClusterIP makes the service unreachable from a browser without kubectl port-forward or a separate ingress.
SPOOLMAN_DB_QUERY	Leave empty unless troubleshooting	Medium	Escape hatch for a TCP + sslmode fallback — only needed if the loopback connection path is ever found unreliable; not required for normal operation.
reserve_static_ip	false (default)	Low	Set true only if you need a stable IP for DNS/firewall allowlisting — the project's static-IP quota is limited and shared across the tenant.
min_instance_count	0 (default)	Low	Spoolman has no background work, so scale-to-zero is safe.

---

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

Related guides

• Hands-on lab: Spoolman on GKE Autopilot — deploy it step by step, with the console screens and commands at each stage.
• Spoolman on Google Cloud Run — the same application on Cloud Run, for when you need the other deployment target.
• Spoolman Common — Shared Application Configuration — the configuration shared by both deployment targets.
• Deployed alongside Grocy on GKE Autopilot, Mealie on GKE Autopilot, Homebox on GKE Autopilot, Wallos on GKE Autopilot in the Home & Life Management solution.