Configuration & secrets

Configuration on managed.dev is layered. A site defines defaults; each environment inherits them and can override what it needs. Secrets work the same way — defined once, scoped per environment — so staging can point at a sandbox payment key while production uses the live one, without touching code.

Inheritance & override precedence

An environment doesn’t start from nothing. It inherits the site’s configuration, then applies its own overrides on top. The effective value for any setting is resolved most-specific-wins:

Precedence (highest wins)

environment override  →  site default  →  platform default

So if the site sets the performance tier and a preview overrides it, the preview uses its override; every environment that doesn’t override inherits the site’s value. This is what makes it safe to dial production up and leave previews lean.

The Configuration panel for a preview environment, showing inherited site values (greyed, with an “inherited” label) alongside two overridden settings highlighted with an “override” badge.

Switchable configuration

Several runtime properties are configuration you switch per environment, not code you redeploy:

• Security tier — the WAF and rate-limiting posture in front of the environment. Run production strict and a preview relaxed for testing.
• Performance tier — the runtime resources and caching profile the environment gets.
• PHP version — the FrankenPHP runtime’s PHP version.

PHP version switching is on the roadmap

Per-environment PHP-version switching is designed but not yet generally available. Today the FrankenPHP runtime version is managed for you; in-dashboard switching is coming.

Secrets & environment variables

Secrets are environment-scoped — a secret set on production is independent from the same-named secret on staging or a preview. That separation is the point: test environments hold test credentials, production holds production credentials, and nothing leaks across.

Dashboard

Open the environment’s Configuration → Secrets panel, add a key/value, and save. Secrets are write-only after creation — you can replace a value but not read it back in the UI.

The Secrets panel for the production environment, listing secret keys with masked values, last-updated timestamps, and per-row “Replace” and “Delete” actions.

CLI

Set a secret on production

mf secrets set STRIPE_SECRET_KEY --site acme-store --env production
# value is read from a prompt, never echoed

API

Set an environment secret

curl -X PUT https://api.managed.dev/v1/sites/site_01J7.../environments/env_01J8.../secrets \
  -H "Authorization: Bearer mfk_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "key": "STRIPE_SECRET_KEY", "value": "sk_live_..." }'

See the cache & secrets API reference for the full surface and the secrets:write scope.

Secrets are reveal-once

A secret’s value is never returned after it’s written. Store it in your own secret manager too if you need it again — managed.dev keeps it for the runtime, not for you to read back.

Where to manage it

The same configuration is reachable from three surfaces. Pick whichever fits your workflow.

Capability	Dashboard	mf CLI	API
Set / override config	yes	yes	PATCH config
Set environment secrets	yes	yes	secrets:write
View inherited vs overridden	yes	yes	yes
Switch security / performance tier	yes	yes	yes
Switch PHP version	Roadmap	Roadmap	Roadmap

Note

The mf CLI and the public API are in developer preview. The dashboard is the generally available surface today; the CLI and API columns reflect the current design.

Next steps

Cache & secrets API referenceManage environment secrets and cache settings programmatically.

Security overviewWhat the security tier controls — WAF, rate limiting, Patchstack, and more.