Env & Secrets

This article lists the environment variables and secrets used by Creative Job Hub, where they belong (client vs server), and recommended operational practices for secure storage and rotation.

Typical environment variables

Place the non-secret variables used by the frontend in your build environment (CI) so they are baked into the production bundle:

• VITE_MAPBOX_STYLE_URL — Mapbox style URL for light theme (example: mapbox://styles/mapbox/light-v11).
• VITE_MAPBOX_STYLE_URL_DARK — Mapbox style URL for dark theme.

These variables let you control default map styles at build time. :contentReference[oaicite:0]{index=0}

Other non-secret environment variables you may want in CI/production:

• NODE_ENV=production (build)
• REACT_APP_FEATURE_FLAGS / custom flags if used by your deployment process

Secrets (server-side only)

Always keep secrets server-side. Examples of secrets your backend must hold:

• Mapbox secret token (sk.*) — Only needed for server-side operations such as private geocoding, static image generation, or any Mapbox API calls that must be authenticated with a secret. The repo demonstrates geocoding being done by a server function (so secret usage stays server-side). :contentReference[oaicite:1]{index=1}
• Payment provider secret (e.g., Stripe secret key) — Used for charging cards and payment webhooks. The project includes stripe as a dependency and payment flows in the app; these secrets must be stored and used server-side. :contentReference[oaicite:2]{index=2}
• Push provider credentials (APNs / FCM) — Private keys/certs for push notifications; keep them on the server or in the push provider console.
• Sentry DSN / monitoring credentials — Keep DSN if used only in server code or keep public DSN for client if used; treat the server auth token or admin keys as secrets. The project uses @sentry/react, so review how you expose Sentry DSNs in your stack. :contentReference[oaicite:3]{index=3}

Recommendation: Never embed sk.* tokens or other secret keys in frontend bundles. The Jobs Map docs explicitly state no client-side secrets should be exposed. :contentReference[oaicite:4]{index=4}

Secret storage & operational policies

• Secrets manager: Use a managed secrets store (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault).
• Least privilege: Generate service accounts with minimal scope and rotate keys regularly.
• Rotation & rollback: Define a rotation schedule and a tested rollback plan if a secret rotation fails.
• Audit: Log who requested or rotated secrets and keep an audit trail.
• Provisioning: Inject secrets into CI/CD pipelines and serverless function environments at build/runtime — do not check secrets into source control.

How to expose configuration safely to the frontend

• Expose only non-secret public tokens to the frontend (for example, Mapbox pk.* public token for client-side tile rendering). Configure per-tenant public tokens in the admin UI (Integrations) rather than baking tenant secrets into the app. :contentReference[oaicite:5]{index=5}

Checklist

• [ ] All secret tokens stored in a secrets manager.
• [ ] Secret rotation policy defined and documented.
• [ ] Serverless functions and backend services use secrets from the secret manager (not environment variables in repo).
• [ ] Frontend only receives public tokens (e.g., pk.* Mapbox tokens).

Updated on: 10/01/2026