Skip to main content
An environment is one running copy of your app: its own Cloud Run service, its own URL, its own configuration, its own database and add-ons. Everything hosting does (deploys, logs, metrics, secrets) is scoped to one.

​
Types

Production is created with the app. The others are opt-in: pick them in Hosting the first time you need them. That provisions a separate service, domain, database and secrets, scaled to zero when idle. An environment’s type is fixed when it is created. Updating its settings does not let you turn Development or Staging into Production, or change Production into another type.

​
Bringing a build forward

A build moves through your environments in order, without being rebuilt:
  • Lite and Pro: Development, then Production.
  • Enterprise: Development, then Staging, then Production. A build can’t skip Staging.
An app that has a Staging environment always goes through it, whatever the plan, so Development shows Bring to staging and Staging shows Bring to production. With only Development and Production, Development shows Bring to production. Development and Staging have a Bring to staging or Bring to production button. It takes the build that environment is running and deploys that same image to the next environment, which keeps its own settings, secrets, database and add-ons. Bringing a build to production needs the hosting.promote permission. If the next environment doesn’t exist yet, the button creates it first. Its database is set up before anything deploys, so the deployment shows as waiting until the database is ready, then starts on its own. A new environment starts with no secrets of its own. Values set for All environments apply to it, but values set Only for another environment do not: add any the app needs before it serves traffic. The confirm dialog lists the keys set only for the source environment that the target will not have. Environment-scoped variables, databases, and add-ons belong to that environment. Promoting a build does not copy configuration across environments. App-level variables and managed app credentials can be shared across environments. See Scope and precedence.

​
App environments and platform staging

An app’s Staging environment is a deployment target within the Meridian platform you use. It does not switch your app to Meridian’s separate staging platform. Meridian injects MERIDIAN_API_URL for the platform hosting your app. When testing against the Meridian staging platform from local development or another host, set it to https://staging.the-meridian.ai/staging and use that platform’s app credentials. The SDK appends /api/public to this root. The Meridian MCP server at mcp.the-meridian.ai accesses production-platform apps only. See Credentials and environment for the automatically injected variables and manual overrides.

​
What an environment holds

Placement and addressing
  • A region, chosen when the environment is created.
  • A base URL, which is the platform domain Meridian provisions (see Default domain), plus any custom domain you attach.
  • A container port and a health check path, which is the path Meridian calls to decide whether a new revision is healthy.
  • An optional release command, run once per deploy before the new revision is created. Usually your database migrations. See Deployment.
Capacity
  • CPU and memory per instance. When you leave them unset, production runs at its hosting size (1 vCPU and 512 MiB on Lite and Pro, 2 vCPU and 1 GiB with Medium, 2 vCPU and 2 GiB with Large) and staging and development run at 1 vCPU and 512 MiB. A value you set is kept, lowered to the plan’s ceiling if it is above it.
  • Minimum and maximum instances, and concurrency (see Autoscaling).
  • A request timeout.
Data and services

​
Configuration takes effect on deploy

Changing your variables and secrets, the health check path or the release command updates the environment’s desired state; the running revision changes when you next deploy. The dashboard shows Changes apply on the next deploy. until a deploy starts. The Shopify credentials, a rotated API key and a rotated webhook signing secret work the same way. See When changes take effect. Capacity is different. A change to the container port, CPU, memory, instances, concurrency or timeout reaches the live service shortly after you save it, with no deploy. Add-ons too: once Redis, Scheduler, storage or CDN finishes provisioning, Meridian updates the live revision with the new connection variables, so enabling one does not need a redeploy. An environment that has not been deployed yet picks both up with its first deploy.

​
Deleting one

Deleting a staging or development environment removes it for good, with everything it holds: its Cloud Run service and release job, its domains and routing, its database and add-ons, its secrets and variables, and its deployment history. It’s the one hosting action that takes data with it, and it can’t be undone. The production environment can’t be deleted on its own. Its database holds your merchants’ data, so it only goes with the app: to remove production, delete the app.
Developer databases for local work are a different thing entirely: per-developer, reached through the CLI, never shared with a teammate.
Last modified on October 7, 2026