> ## Documentation Index > Fetch the complete documentation index at: https://docs.poly.ai/llms.txt > Use this file to discover all available pages before exploring further. # Environments > Configure your Live and test environments. An **environment** is where your agent runs. Your project has more than one, so you can build and test a new version without affecting the one your customers are using. Every project has two environments, **Live** and **Sandbox**. [Branches](/environments-and-versions/branches-mode) and [Sub-branches](/environments-and-versions/sub-branches-mode) modes add an additional **Staging** environment. ## Live Live is the version serving your customers. You never edit it directly. Publishing merges your changes onto Live and creates a new version in its history. If something goes wrong, you can roll back to any previous version in one step. See [Rolling back a change](/environments-and-versions/introduction#rolling-back-a-change). Deployments page Live history tab, listing published versions with the current one marked Live ## Sandbox Sandbox is where you build. Every Branch and Sub-branch lives here, whichever mode you are in. Nothing in Sandbox reaches a customer. You test in Sandbox from inside Agent Studio, by running [simulation tests](/testing/simulation-tests) or by talking to your agent over an in-app call or chat. Your API and app connections work here, using the credentials set up for Sandbox, so integrations behave as they would for real. Sandbox has no channel connections. A channel connection is what lets a real phone number or website widget reach your agent, and each one points at a single version. Sandbox can hold many versions at once, so there would be no way to tell which should answer. Staging and Live each run one version, so that is where channel connections live. ## Staging Staging is available in Branches and Sub-branches modes. It is not available in Simple mode, which has no separate Branches to move into it. Staging holds one Branch at a time, which is what lets it have its own channel connections, such as a real phone number. Use it to test a change the way a customer would experience it, before you publish. ### When to use Staging Most changes go straight from Sandbox to Live. You can already test a Branch in Sandbox over an in-app call or chat, with your integrations working as configured. Use Staging when you need to check that a real channel actually works, for example that a phone number is wired up correctly, or when you need someone without Agent Studio access to try the agent. You do not need Staging just to hear your agent. That works over an in-app call in Sandbox. ### Moving a Branch to Staging Branch actions menu on the Deployments page, showing Move to staging Find your Branch in the list. Use the Branch's actions menu. Call the Staging number, or use whichever channel you connected. Your agent answers from that Branch, using the connections configured for Staging. Publishing works the same as it does from Sandbox. Your Branch's changes are added onto Live. Each project has one Staging environment, holding one Branch at a time. Moving another Branch to Staging replaces the one already there, so agree with your team who is using Staging before you move yours. Support for multiple Staging environments is coming soon. ### Editing a Branch in Staging You cannot edit a Branch directly while it is in Staging. How you change it depends on your mode. * **In [Branches mode](/environments-and-versions/branches-mode)**, move the Branch out of Staging, make your change, then move it back. * **In [Sub-branches mode](/environments-and-versions/sub-branches-mode)**, make your edit in a Sub-branch and merge that Sub-branch into the Branch. Either route makes the update to Staging deliberate. Your changes save as you go, so without this a Branch would change while someone was testing on it. If you have given the Staging number to a colleague, they keep a stable, tested version until you choose to update it. ## Side by side | | **Sandbox** | **Staging** | **Live** | | ----------------------- | ---------------------------------------------- | -------------------------------------------- | --------------------------- | | **What it is for** | Building and testing inside Agent Studio | Testing on a real channel before you publish | Serving customers | | **What runs there** | Every Branch and Sub-branch | One Branch at a time | The published version | | **Available in** | Every mode | Branches and Sub-branches modes | Every mode | | **Channel connections** | None | Its own | Your production ones | | **Integrations** | Shared by everything in Sandbox | Its own | Your production credentials | | **Who reaches it** | Agent Studio users with access to your project | Anyone you give the details to | Your customers | ## Setting up each environment Connections and credentials are configured per environment. Whatever you connect to an environment is what a test there, or a customer conversation on Live, will reach. Most teams point Sandbox and Staging at test accounts and services, and Live at production. If you are unsure what a test will reach, check how that environment is configured. ### Channels Channel connections exist in Staging and Live only. Each one points at a single version of your agent, and Sandbox holds many at once. * **Phone numbers.** Grouped by environment under **Voice > Numbers**. Assign a number to Staging or Live. This needs a telephony integration between your provider and PolyAI first. See [Phone numbers](/voice-channel/numbers/route-management). * **Widgets.** Chosen under **Integrations > Widgets**. Point a widget at Staging to test it against a Branch, or at Live for your website. You can move it between environments later without re-embedding. See [Configure a widget](/widgets/configure). ### Integrations Integrations work in every environment, including Sandbox, where every Branch shares one set of credentials. * **Apps.** Pre-built integrations under **Integrations > Apps**, each with a guided setup. Connect an account and pick the environment its credentials apply to. The steps differ for each app. See [Integrations](/integrations/introduction). * **APIs you set up yourself.** Added under **Integrations > APIs**. Each environment gets its own base URL and authorisation, so Sandbox and Staging can reach your test services while Live reaches production. See [APIs](/integrations/api/introduction). * **Knowledge sources.** Each source is enabled per environment. See [Sources](/knowledge/sources/introduction). API authentication is set per environment, not per Branch. Changing it on one Branch changes it for every Branch in that environment. ### Real-time configuration Values and schemas are set per environment, and changes take effect immediately rather than waiting for a publish. See [Real-time configuration](/real-time-config/introduction). ### Functions Functions can behave differently per environment by reading `conv.env`. A custom handoff function can use it to transfer to a different destination in Staging than on Live. See [Environment configuration](/tools/variables#environment-configuration). MCP servers are the exception. They are not configured per environment, so an agent connects to the same MCP server wherever it runs. ## Related pages How changes reach your customers, and the three deployment modes. Everyone works in their own Branch and publishes when ready. See what changed before you publish. Common questions about Sandbox, Staging and Live.