--- title: Environments | Runware Docs url: https://runware.ai/docs/serverless/environments description: Run the same app id once per environment, each copy with its own configuration, secrets and workers, under one organization and one bill. relatedDocuments: - https://runware.ai/docs/serverless/core-concepts - https://runware.ai/docs/serverless/secrets - https://runware.ai/docs/serverless/compute-and-scaling --- ## Introduction An environment is **a named place inside your organization where apps run**. The same app id can run in several of them, and each copy keeps its own configuration, its own versions, its own workers and its own secrets. Every organization has `production`, and **a request that names no environment addresses it**. Nothing you have deployed so far moved: it is already there. ```bash GET /v1/apps # production GET /v1/apps?environment=staging # the staging copies ``` ## One id, one copy per environment The app id is the name of the application. **The environment chooses which copy a request reaches**, and the two are separate apps from there on: separate versions, separate workers, separate environment variables, separate secret attachments. A copy is created where you first deploy it and **never moves**. Promoting what you tested is deploying the same source into another environment, which builds there. Deleting one copy leaves the others untouched. > [!NOTE] > Because a copy is its own app, an app id that runs in two environments **counts as two apps** everywhere you see a tally, and a cursor from a page of one environment is not valid in another. ## What an environment holds
Scoped to the environmentShared by the organization
Apps, their versions, workers and environment variablesThe API key you authenticate with
Secrets, and the attachments that expose themThe GPU types you can deploy on
Worker and GPU caps, and the monthly budgetThe source archives a deploy builds from
**A secret of the same name in another environment is a different secret.** There is no copy operation, because the API never returns a stored value: creating the same name in a second environment means sending the value again. ## Caps and the monthly budget An environment carries **a cap on the workers it holds and a cap on their GPUs**. Both are checked whenever a request adds capacity, so creating an app, deploying, resuming a stopped one and raising a worker count all go through them. They do not bound autoscaling: what is already running keeps scaling inside its own `maxWorkers`. The count an environment is judged against is **what its other apps hold**, each the larger of its live workers and its keep-warm floor, plus what the request starts. A request that would cross a cap is refused and changes nothing. Lowering a cap below what already runs refuses the next deploy rather than stopping anything. **The monthly budget is a pay-as-you-go cap for the calendar month**, which resets on the 1st at 00:00 UTC. Percentages you choose send an email as the spend passes them, each at most once per month. Where `pauseAtBudget` is on, reaching the budget stops the environment's apps and refuses invocations until the budget is raised past the spend or the month turns. > [!WARNING] > Spend is read from settlement, so it **trails live usage by a few minutes**, and a worker's final adjustment by longer. A budget is a cap on what gets billed, not a switch that trips the instant a GPU starts. ## Organization defaults Every cap and the access setting have **an organization default that an environment inherits while it sets nothing of its own**. An environment reports both: the value set on it, and under `resolved` the value actually in force. Changing a default reaches every environment that inherits that field at once, and **it does not roll what is already running**. ```bash GET /v1/environment-defaults PUT /v1/environment-defaults ``` ## Creating and deleting A name is **1 to 63 characters**: lowercase letters, digits, hyphens, underscores and periods, starting with a letter or a digit. A name no live environment holds is free, including the name of one you deleted. **An environment is deleted only once it is empty**, with no live app and no secret left in it. `production` is never deleted, and a deleted app's history still names the environment it ran in. ## Where to go next - [Core concepts](https://runware.ai/docs/serverless/core-concepts) for the nouns an environment holds - [Secrets](https://runware.ai/docs/serverless/secrets) for what changes when the same name lives in two places - [Compute and scaling](https://runware.ai/docs/serverless/compute-and-scaling) for the worker settings a cap is checked against - [Errors](https://runware.ai/docs/serverless/errors#environment-cap-reached) for the answers a cap and a pause give