PhpMyAdmin on GKE Autopilot

phpMyAdmin is the most popular open-source (GPLv2) web tool for administering MySQL and MariaDB databases over the browser — browse and edit tables, run SQL, manage users, and import/export data. This module deploys phpMyAdmin 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 phpMyAdmin 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, and the deployment lifecycle — refer to the App_GKE foundation guide rather than repeating them here.

1. Overview

phpMyAdmin runs as a stateless PHP + Apache web workload on GKE Autopilot. It is one of the lightest deployments in this repository — it wires together only the services it truly needs:

Capability	Google Cloud service	Notes
Compute	GKE Autopilot	PHP/Apache pods, autoscaled; bills for requested CPU/memory
Database	None provisioned	phpMyAdmin has no database of its own; it connects to an external MySQL/MariaDB server you point it at
Object storage	None	Stateless — no GCS bucket is created
Cache	Redis (optional, off)	Only for rate-limiting/bot-detection on public deployments; not required
Secrets	None generated	phpMyAdmin holds no secret; users log in with the target MySQL server's own credentials
Container image	Artifact Registry	Thin custom build `FROM phpmyadmin/phpmyadmin`, mirrored and tag-pinned
Ingress	Cloud Load Balancing	External LoadBalancer Service by default; optional custom domain + managed certificate

Sensible defaults worth knowing up front:

No database is provisioned for phpMyAdmin. database_type = "NONE" is fixed and enforced by a plan-time validation guard. phpMyAdmin is a client — it administers a MySQL server that lives elsewhere (the platform Cloud SQL private IP, another Cloud SQL instance, or any reachable MySQL/MariaDB host). Nothing here creates that server.
The MySQL target is selected by env vars, not code. PMA_ARBITRARY = "1" (the default) shows a server-input box on the login page so users type any host. Set pma_host (and PMA_ARBITRARY = "0") to pin a single server.
No secrets are generated. There is no encryption key, JWT secret, or app password to protect. Authentication is against the target database's own accounts (cookie auth).
Stateless Deployment, minimum 1 replica. workload_type defaults to a Deployment (not a StatefulSet — there is no per-pod state) and GKE keeps at least one replica running (no scale-to-zero) so the console is always reachable.
Exposed via an external LoadBalancer (service_type = "LoadBalancer"). Because phpMyAdmin is a powerful database administration tool, seriously consider fronting it with IAP (via Ingress) or restricting the LoadBalancer before exposing it to the internet.
NFS and Redis are disabled by default. phpMyAdmin keeps no state; enable Redis only for abuse protection on a public deployment.
The container listens on port 80 (Apache apache2-foreground).

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

phpMyAdmin pods are scheduled on Autopilot, which bills for the CPU/memory the pods request. Horizontal Pod Autoscaling sizes the Deployment between the minimum and maximum replica counts. The container listens on port 80.

Console: Kubernetes Engine → Workloads → select the phpMyAdmin 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
# Confirm the MySQL-target env vars injected into the running pod:
kubectl exec -n "$NAMESPACE" deploy/<service-name> -- env | grep PMA_

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

B. The target MySQL/MariaDB server (external)

phpMyAdmin does not provision a database — it connects to one you already have. That target is selected via pma_host / pma_port (fixed) or PMA_ARBITRARY = "1" (user types the host at login). A common pattern is to point phpMyAdmin at the platform's shared Cloud SQL private IP:

Console: SQL → select the instance to find its private IP and connection name.

CLI:

# Find a MySQL instance's private IP to use as pma_host:
gcloud sql instances list --project "$PROJECT" --filter="databaseVersion~MYSQL"
gcloud sql instances describe <instance-name> --project "$PROJECT" \
  --format='value(ipAddresses[0].ipAddress)'

Pods reach a private-IP MySQL server directly over the cluster's VPC networking (no Auth Proxy sidecar is needed — enable_cloudsql_volume is false for phpMyAdmin because it does not use the platform's own Cloud SQL integration). Users authenticate at the phpMyAdmin login page with that database's own MySQL accounts.

C. Cloud Storage

Not used. phpMyAdmin is stateless and declares no GCS bucket. Import/export in the phpMyAdmin UI streams files through the browser, not to GCS.

D. Redis (optional abuse protection)

Redis is disabled by default (enable_redis = false). It is only relevant if you enable phpMyAdmin's rate-limiting/bot-detection on a public deployment. When left off, phpMyAdmin functions fully — Redis is not required for normal operation.

CLI (only if enabled):

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

E. Secret Manager

No secrets are generated by this module. phpMyAdmin holds no encryption key, JWT secret, or application password — login is against the target MySQL server's own credentials, entered at the phpMyAdmin login page and never stored. You may still add your own secret_environment_variables, which the foundation materialises via the Secret Store CSI integration.

Console: Security → Secret Manager.

CLI:

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

See App_GKE for the Secret Store CSI integration.

F. 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 can be reserved so the address survives redeploys. IAP (via Ingress) can gate access with Google sign-in — strongly recommended for a database admin tool.

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

CLI:

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

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

G. Cloud Logging & Monitoring

Pod stdout/stderr flow to Cloud Logging; GKE metrics flow to Cloud Monitoring. Optional uptime checks 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. PhpMyAdmin Application Behaviour

No first-deploy database setup. There is no db-init job and no schema to create — phpMyAdmin has no database of its own. The pod is ready as soon as Apache/PHP starts.
No migrations, no immutable keys. phpMyAdmin stores nothing between restarts, so there is no schema to migrate and no cryptographic key that can corrupt on redeploy. Rolling updates and version bumps are low-risk.
Stateless Deployment. workload_type resolves to a Deployment and stateful_pvc_enabled is off — there is no per-pod state to preserve. A rolling update is safe because pods share no volume or lock.
Cookie-based login. Users log in at the phpMyAdmin page with the target MySQL server's own username and password; the session lives in a short-lived cookie. phpMyAdmin never persists those credentials, and there is no phpMyAdmin "admin account" to create post-deploy.
MySQL target selection. Verify the injected PMA_* env vars on the running pod:
```
kubectl exec -n "$NAMESPACE" deploy/<service-name> -- env | grep PMA_
```
With PMA_ARBITRARY = "1", the login page shows a server field; with a fixed pma_host, users only see username/password for that one server.
Health path. Startup, liveness, and readiness probes target / — Apache serves the login page there with a 200 once PHP is up. First boot is fast; no long migration window is needed.
Security posture. phpMyAdmin exposes full database administration to anyone who can reach the LoadBalancer and holds valid MySQL credentials. Gate it with IAP or restrict the Service, and set PMA_ARBITRARY = "0" with a fixed pma_host if users should only reach one server.

4. Configuration Variables

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