Configuring environment variables
Environment variables carry configuration and credentials into your service at runtime. This page covers per-service values, shared environment groups, platform-provided variables and build-time behaviour.
Every Muerte Cloud service reads its configuration from environment variables — database URLs, API keys, feature flags, ports. Values are injected into both the build and the runtime process, with sensitive values encrypted at rest and never printed to logs.
Adding environment variables#
Open the service's Environment tab and add entries one by one, or paste a .env file and Muerte Cloud will parse it:
DATABASE_URL=postgres://user:pass@host:5432/app
REDIS_URL=redis://cache.internal:6379
STRIPE_SECRET_KEY=sk_live_...
LOG_LEVEL=infoNames are case-sensitive and must match [A-Z_][A-Z0-9_]*. Values can contain any UTF-8; wrap them in quotes if they include spaces or shell metacharacters.
Generated values
Muerte Cloud can generate a strong random value for any variable — useful for session secrets, JWT keys and webhook signing secrets. The value is created once, stored encrypted and never shown again after the first reveal.
Environment groups#
An environment group is a named bundle of variables that you link to one or more services. Update the group once and every linked service redeploys with the new values — no copy-pasting between staging and production.
Resolution order
When a service starts, variables are resolved in this order — later entries override earlier ones:
- 1Platform-providedBuilt-in variables injected by Muerte Cloud (see below).
- 2Linked environment groupsMerged top-down in the order they're attached to the service.
- 3Service-level variablesValues set on the service itself. Always win over any group.
Platform-provided variables#
Muerte Cloud injects a small set of read-only variables into every deploy. You can reference them from your app but not overwrite them.
| Field | Description |
|---|---|
| PORT | The port your web service must bind to. Defaults to 8080. |
| MUERTE_SERVICE_ID | Stable identifier of the current service, e.g. srv-01H9…. |
| MUERTE_SERVICE_NAME | Human-readable service name from the dashboard. |
| MUERTE_SERVICE_TYPE | One of web, static, private, worker or cron. |
| MUERTE_INSTANCE_ID | Unique per running instance. Changes on every deploy and restart. |
| MUERTE_GIT_COMMIT | Full SHA of the commit that produced this release. |
| MUERTE_GIT_BRANCH | Tracked branch name for this service. |
| MUERTE_EXTERNAL_URL | Public https URL of the service, if any. |
Build-time vs runtime#
Environment variables are available in both stages, but the two stages run in separate sandboxes:
| Field | Description |
|---|---|
| Build | The build container sees every variable. Frameworks like Next.js and Vite can bake NEXT_PUBLIC_/VITE_ values straight into the bundle. |
| Runtime | The runtime instance sees the same values, plus platform-provided variables. Any edit after build requires a fresh deploy to reach the client bundle. |
NEXT_PUBLIC_, VITE_ or a similar public marker ends up in JavaScript shipped to browsers. Never put real secrets there — keep server-only keys unprefixed so they stay on the instance.Reading values in your code#
Standard language APIs work unchanged:
const dbUrl = process.env.DATABASE_URL;
const port = Number(process.env.PORT ?? 8080);import os
db_url = os.environ["DATABASE_URL"]
port = int(os.getenv("PORT", "8080"))dbURL := os.Getenv("DATABASE_URL")
port := cmp.Or(os.Getenv("PORT"), "8080")