> ## Documentation Index > Fetch the complete documentation index at: https://help.the-meridian.ai/llms.txt > Use this file to discover all available pages before exploring further. # Environments 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 | Type | For | | - | - | | **Production** | The environment merchants use. Created with the app. Every plan | | **Development** | A copy for work in progress. Opt-in. Every plan | | **Staging** | A copy for pre-release verification. Opt-in. Enterprise only | 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](/secrets#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](/mcp-server) server at `mcp.the-meridian.ai` accesses production-platform apps only. See [Credentials and environment](/sdk-credentials) 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](/default-domain)), plus any [custom domain](/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](/deployment#release-command). **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](/autoscaling)). * A **request timeout**. **Data and services** * A managed [database](/database), enabled per environment. * The runtime add-ons: [Redis](/redis), [Scheduler](/scheduler), [object storage](/storage), [CDN](/cdn). * Its own [secrets and variables](/secrets), which override any set at app level. ## 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](/secrets#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](/app-settings). Developer databases for local work are a different thing entirely: per-developer, reached through the [CLI](/cli), never shared with a teammate. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.