Strapi Common — Shared Application Configuration

Strapi_Common is the shared application layer for Strapi. It is not deployed on its own; instead it supplies the Strapi-specific configuration that both Strapi_GKE and Strapi_CloudRun build on, so the two platform variants behave identically where it matters. 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 Strapi, see the platform guides (Strapi_GKE, Strapi_CloudRun) and the foundation guides (App_GKE, App_CloudRun, App_Common).

---

1. What this layer provides

Area	Provided by Strapi_Common	Where it surfaces
Cryptographic secrets	Generates and stores five Strapi secrets in Secret Manager	Injected automatically as env vars at runtime
Container image	Defines a two-stage Node.js 20 build (node:20-alpine) with the Strapi admin panel pre-compiled	container_image output of the platform deployment
Database engine	Fixes Cloud SQL for PostgreSQL 15 as the required engine	§Database in the platform guides
Database bootstrap	Defines the first-deploy job that creates the database, user, and grants (including CREATEDB)	initialization_jobs output
Object storage	Declares the Cloud Storage uploads bucket (strapi-uploads suffix)	storage_buckets output
Core settings	Sets NODE_ENV = "production", Strapi port, proxy config, and optional Redis env vars	Application behaviour in the platform guides
Health checks	Supplies the default startup (/_health, 30-second delay, 30 failure threshold) and liveness (/_health, 15-second delay) probe configuration	§Observability in the platform guides

---

2. Cryptographic secrets in Secret Manager

Strapi requires five distinct cryptographic values that must remain stable across restarts, scaling events, and version upgrades. All five are generated automatically on first deploy and stored in Secret Manager — they are never set in plain text.

Secret (env var)	Purpose
APP_KEYS	Four 32-character keys (comma-joined) that sign Strapi session cookies
ADMIN_JWT_SECRET	Signs admin panel JWT tokens
JWT_SECRET	Signs user-facing API JWT tokens
API_TOKEN_SALT	Hashes generated API tokens
TRANSFER_TOKEN_SALT	Hashes data transfer tokens

Retrieve a secret after deployment:

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

These secrets must never be rotated or regenerated after first deploy. Changing any of them immediately invalidates all active user sessions and API tokens — every logged-in user is signed out and every API integration fails with 401 errors until tokens are regenerated by all consumers. The database password is generated and managed separately by the foundation; its secret name is reported in the platform deployment outputs (database_password_secret). See App_Common for the shared secret and Workload Identity model.

---

3. Database engine and bootstrap

Strapi requires PostgreSQL; the engine is fixed and MySQL is not supported. On the first deployment a one-shot db-init job connects to Cloud SQL through the Auth Proxy and idempotently:

1. Waits for PostgreSQL to accept connections (full connection test, not just a ping).
2. Creates the application user with the generated password (or updates the password if the user already exists).
3. Grants the CREATEDB privilege — required by Strapi's Knex-based migration system, which creates and drops databases during certain operations.
4. Creates the application database owned by the application user (or adopts it if it already exists).
5. Grants full privileges on the database and its public schema.
6. Signals the Cloud SQL Auth Proxy sidecar to shut down cleanly.

The job is safe to re-run. Inspect the database directly with:

gcloud sql connect <instance-name> --user=<db-user> --project "$PROJECT"

The instance, database, and user names are in the platform deployment outputs.

---

4. Core application settings

Strapi_Common establishes the baseline Strapi environment:

• Node environment — NODE_ENV = "production" so Strapi serves compiled assets and disables development-only middleware.
• Container port — Strapi's HTTP server listens on port 1337 by default. The Cloud Run variant overrides this to 8080 to align with Cloud Run's standard port.
• Proxy trust — proxy: true is hardcoded in config/server.js so Strapi correctly reads X-Forwarded-Proto and X-Forwarded-For headers behind the Cloud Run and GKE load balancers.
• GCS upload provider — config/plugins.js detects GCS_BUCKET_NAME and enables @strapi-community/strapi-provider-upload-google-cloud-storage automatically. GCS_BUCKET_NAME and GCS_BASE_URL are injected by the platform modules.
• Email delivery (optional) — if SMTP_HOST is set in environment_variables, config/plugins.js enables the nodemailer email provider automatically.
• Redis (optional) — when enable_redis = true, ENABLE_REDIS, REDIS_HOST, REDIS_PORT, and REDIS_PASSWORD are injected. If redis_host is left empty and NFS is enabled, the NFS host IP is resolved at container startup via strapi-entrypoint.sh. The Redis plugin gates on REDIS_HOST being set rather than on ENABLE_REDIS.

---

5. Health probe behaviour

The default probes target Strapi's /_health endpoint, which returns HTTP 200 only when the application and database connection are fully initialised.

• Startup probe — HTTP /_health, 30-second initial delay, 10-second period, 30 failure threshold — providing up to ~330 seconds of grace time during first-boot database initialisation and admin panel compilation.
• Liveness probe — HTTP /_health, 15-second initial delay, 30-second period, 3 failure threshold — restarts unhealthy containers promptly in steady state.

Both GKE and Cloud Run variants use HTTP probes directly against /_health, since there is no HTTP-to-HTTPS redirect issue for Strapi (unlike PHP applications that redirect plain HTTP).

---

6. Object storage

A dedicated Cloud Storage bucket with the suffix strapi-uploads is declared here and provisioned by the foundation, which also grants the workload service account access. GCS_BUCKET_NAME and GCS_BASE_URL are injected automatically by the platform modules, wiring Strapi's media library to this bucket without any manual configuration. List it with:

gcloud storage buckets list --project "$PROJECT"

---

7. Container image

Strapi_Common defines a two-stage build on node:20-alpine:

• Build stage — installs all npm dependencies, compiles the Strapi admin panel (npm run build), and produces build artefacts.
• Runtime stage — installs production-only dependencies, copies source files and build artefacts, removes macOS extended attribute files, creates the public/uploads directory required by Strapi at runtime, and sets the node user for least-privilege operation. Uses tini as PID 1 for correct signal handling.

The vips-dev library is included to satisfy the sharp npm package, which Strapi uses for image processing in the media library. The strapi-entrypoint.sh script resolves the $(NFS_SERVER_IP) placeholder in REDIS_HOST before starting Strapi.

---

For the Strapi-specific, user-facing configuration (variables by group, outputs, and how to explore each service from the Console and CLI), see the platform guides: Strapi_GKE and Strapi_CloudRun.