Hoppscotch on GKE Autopilot

Hoppscotch is an open-source, Postman-style API development platform for designing, sending, and inspecting HTTP, GraphQL, and WebSocket requests from the browser. This module deploys the self-hosted Hoppscotch frontend as a stateless single-page app 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 Hoppscotch 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 Hoppscotch costs on RAD, and how that compares

Hoppscotch on RAD's GKE module costs about US$24 a month in your own project, plus a 40-credit (US$4) module fee once per deployment. If you only need it sometimes, see "Pause it for free" below to stop paying without losing your setup. Hoppscotch also ships as a Cloud Run module, which is the lower-cost option here (about US$17/month) because it scales to zero between requests instead of holding a cluster allocation — see the Cloud Run guide unless you already run GKE Autopilot for other apps.

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.00)	36 credits (10% lower)
Build time	A few credits per build	The same
Google Cloud running cost	Billed by Google to your own billing account, about US$24.04 a month for the default configuration (table below)	Metered hourly in credits; RAD publishes 55 credits a day
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, less on a 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, 0.5x vCPU / 0.5 GiB	US$18.04
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	about US$24.04

How it compares

No official hosted SaaS exists for the self-hosted Hoppscotch frontend to compare against — Postman's own cloud plans are a different, closed-source product — so the honest comparison is a bare server.
Hoppscotch's frontend is light (1 vCPU, 0.5 GiB), so even a cheaper/smaller VPS tier than the ones below would run it; for reference, a Hetzner CPX22 or DigitalOcean 2 vCPU/4 GB droplet runs about $24/month and a GCP Compute Engine e2-standard-2 about $49/month.
What RAD adds over a bare VPS is managed TLS, IAM-scoped access, Secret Manager and monitoring — this module has no database to patch, so the gap is mostly about identity and observability rather than database administration.

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

If Hoppscotch runs in a project RAD manages for you and you expect to come back to it — a break between courses, a seasonal lull, or simply not knowing yet whether you'll need it next month — this is the better option, and it costs almost nothing.

Deleting a RAD-managed project unlinks its billing first, then asks Google to delete the project outright: Google's own 30-day recoverable soft delete. Unlike deleting Hoppscotch as a single module, this does not tear down the GKE pod, networking and storage 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 build time for a typical chain of deployments.

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 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. Hoppscotch keeps little of its own server-side state (collections and environments are mostly in the browser), so for a default install there is little to lose.

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

In your own project, or once the 30-day window above has passed, the fallback is to delete Hoppscotch outright and redeploy it later.

What a redeploy costs: the module fee again, plus the builds — roughly the module fee shown above plus 3–6 credits of build time.
When it's worth it: deleting saves money only once Hoppscotch would otherwise sit unused for about 6 days or more in your own project (under a day in a RAD-managed one, since GKE's managed daily rate is comparatively high for this app). Most of the running cost here is the shared GKE cluster management fee and NAT, so deleting Hoppscotch alone saves only its own pod's share if other apps share the cluster.
Keep data first. Nightly backups are written to a bucket inside the deployment, and that bucket is deleted with it — copy the latest backup out (to Google Drive, or a bucket you keep) 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 list prices from the Cloud Billing Catalog API; RAD fees and the daily-credit estimate from radmodules.dev/pricing; Google Cloud: delete and restore projects for the pause/restore mechanism. Prices change; check each source before relying on a figure.

1. Overview

Hoppscotch runs as a static single-page web app (served by Caddy) in a Deployment on GKE Autopilot. It is deliberately stateless — no database, no cache, no persistent storage — so the deployment wires together a small set of Google Cloud services:

Capability	Google Cloud service	Notes
Compute	GKE Autopilot	Static SPA pods on port 3000; horizontally autoscaled; min 1 replica
Container image	Artifact Registry + Cloud Build	Thin custom build `FROM hoppscotch/hoppscotch-frontend`, mirrored into Artifact Registry
Ingress	Cloud Load Balancing	External LoadBalancer Service with a reserved static IP by default
Secrets	Secret Manager	None app-specific — Hoppscotch requires no secrets
Observability	Cloud Logging & Monitoring	Pod logs, GKE metrics, optional uptime check and alerts

Services that are deliberately not used: Cloud SQL (database_type = "NONE", enforced by a plan-time guard), Cloud Storage (no buckets), and Redis (off by default; the static frontend has no server-side rate-limiting or queue to back).

Sensible defaults worth knowing up front:

No database, ever — and it is enforced. database_type = "NONE" and enable_cloudsql_volume = false. A plan-time precondition (validation.tf) fails the plan if database_type is set to anything other than NONE, so an operator cannot accidentally provision an unused Cloud SQL instance. Hoppscotch keeps all state in browser local storage.
The frontend-only image is used on purpose. The all-in-one hoppscotch/hoppscotch image bundles a NestJS backend that exit(1)s without a DATABASE_URL. This module uses hoppscotch/hoppscotch-frontend, which serves the SPA on port 3000 with no backend requirement.
HOPPSCOTCH_VERSION, not APP_VERSION, pins the image. A custom build sets an app-specific HOPPSCOTCH_VERSION ARG so the Foundation's injected APP_VERSION does not overwrite the tag; application_version = "latest" resolves to a pinned, known-good tag at build time.
A LoadBalancer with a reserved static IP is the default. service_type = "LoadBalancer" and reserve_static_ip = true, so the external address survives redeploys.
Minimum 1 replica is maintained (min_instance_count = 1; GKE does not support scale-to-zero), keeping the SPA always reachable. max_instance_count = 3 by default and is safe to raise — there is no shared state to coordinate.
A stateless Deployment, not a StatefulSet. workload_type is unset (resolves to Deployment) and stateful_pvc_enabled is unset; the SPA needs no per-pod volume.
session_affinity = "None". The static bundle is identical on every pod, so sticky routing is unnecessary.
No secrets and no storage buckets are provisioned 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 Hoppscotch workload

Hoppscotch pods are scheduled on Autopilot, which bills for the CPU/memory the pods actually request. Horizontal Pod Autoscaling sizes the Deployment between the minimum (1) and maximum replica counts. The container listens on port 3000 and answers GET / with the app UI (HTTP 200).

Console: Kubernetes Engine → Workloads → select the Hoppscotch workload to see pods and events. Kubernetes Engine → Services & Ingress shows the external IP.

CLI:

kubectl get pods,svc,hpa -n "$NAMESPACE"
kubectl logs -n "$NAMESPACE" deploy/<service-name> --tail=100
kubectl describe hpa -n "$NAMESPACE"          # current vs target utilisation

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

B. Container image — Artifact Registry & Cloud Build

Because container_image_source = "custom", the image is built by Cloud Build from the thin Dockerfile (FROM hoppscotch/hoppscotch-frontend:${HOPPSCOTCH_VERSION}) and pushed to Artifact Registry (image mirroring is on by default). Custom/mirrored images are pulled with imagePullPolicy=Always on GKE so a rebuilt tag is never served stale from a node cache.

Console: Artifact Registry → Repositories; Cloud Build → History.

CLI:

gcloud builds list --project "$PROJECT" --region "$REGION" --limit 5
gcloud artifacts docker images list \
  "$REGION-docker.pkg.dev/$PROJECT/<repo>" --project "$PROJECT" \
  --include-tags --filter="package~hoppscotch"
# Confirm the image the running pod actually pulled:
kubectl get deploy -n "$NAMESPACE" -o jsonpath='{.items[0].spec.template.spec.containers[0].image}'

C. Secret Manager

Hoppscotch provisions no application secrets — secret_ids is empty, so no Secret Store CSI volumes are mounted for this module. You can still map your own env-var-to-secret references through secret_environment_variables if you extend the deployment, but nothing is required.

Console: Security → Secret Manager.

CLI:

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

See App_GKE for the Secret Store CSI integration and rotation.

D. Networking & ingress

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

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

CLI:

kubectl get svc -n "$NAMESPACE"                       # EXTERNAL-IP of the LoadBalancer
gcloud compute addresses list --project "$PROJECT"

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

E. Cloud Logging & Monitoring

Pod stdout/stderr flow to Cloud Logging; GKE metrics flow to Cloud Monitoring. Optional uptime checks (against the LoadBalancer host) and alert policies are available.

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. Hoppscotch Application Behaviour

No first-deploy database setup. There is no db-init job, no Cloud SQL instance, and no schema. Pods serve a static bundle immediately.
No server-side persistence. Collections, environments, request history, and settings live in browser local storage on each user's machine. Rolling pods, scaling, or redeploying loses no user data — there is none on the server to lose. Because the SPA is stateless, the default RollingUpdate strategy is safe (no shared NFS/DB lock to deadlock on).
No immutable keys. With no secrets and no database, there is no cryptographic material that could corrupt stored data if changed.
Health path. Startup and liveness probes target the root /, which returns the app UI (HTTP 200) as soon as Caddy binds port 3000 — typically within seconds. A failing probe almost always means the image tag is invalid, not that a backend is unreachable.
No first-run admin account. The self-hosted frontend has no login or user management of its own; browse to the LoadBalancer IP and start building requests. (Team workspaces, which require the backend + database, are intentionally out of scope for this module.)
Scaling is unconstrained. With no shared queue or database, any number of pods run independently — raise max_instance_count freely as a throughput ceiling.

Verify the running workload:

kubectl get deploy,pods -n "$NAMESPACE"
EXTERNAL_IP=$(kubectl get svc -n "$NAMESPACE" -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')
curl -sS -o /dev/null -w '%{http_code}\n' "http://$EXTERNAL_IP/"

4. Configuration Variables

Variables are grouped exactly as they appear on the deployment platform. Only settings specific to or notable for Hoppscotch 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.