A Business Central tenant gives you one production environment and three sandboxes. How to use them, when to add a Docker container, how to refresh a sandbox from production without breaking integrations, and the environment plan that keeps development, UAT and release waves from tripping over each other.
The default Business Central online subscription comes with one production environment and three sandboxes, and most businesses use one sandbox for everything: development, testing, training and "let me just try something". Then the developer's half-finished extension breaks UAT, the trainer's test data confuses the tester, and someone discovers the sandbox has been sending real emails. An environment plan is a page long and prevents all of it.
| Environment | Purpose | Who | Refreshed |
|---|---|---|---|
| Production | The business | Users; pipeline deploys releases | Never (it is the source) |
| Sandbox: UAT | Testing release candidates with production-like data; regression testing before each release wave; super user training | Super users, consultants; pipeline deploys release candidates | From production before each UAT cycle and before each release wave preview |
| Sandbox: Dev | Developers publishing from VS Code (Dev scope), integration testing against a stable copy | Developers | From production occasionally, when realistic data is needed |
| Sandbox: Next major / spare | Created on the preview of the next release wave for compatibility testing; or training; or a scratch copy for a data fix rehearsal | Consultants, developers | Created and deleted as needed |
| Docker container (local) | Fast developer iteration, unit tests in the pipeline, specific versions, destructive experiments | Developers, pipeline | Thrown away and recreated |
The pipeline (AL-Go) is the only thing that deploys to UAT and production, as PTEs; developers publish Dev scope to the Dev sandbox or a container only (see Global, PTE or Dev).
Business Central runs in Docker (Windows containers) on a developer's machine or a build agent, created with the BcContainerHelper PowerShell module from Microsoft's artifact feed, at any version including the next major's preview. A container compiles and publishes in seconds, can be reset with one command, and is what the pipeline uses to run tests. The trade-off is that it is on-premise under the hood (so some cloud-only behaviours differ: no Entra sign-in, no admin centre, no AppSource install) and the developer's laptop has to be Windows with enough memory. Use it for the inner loop and unit tests; use the Dev sandbox for anything that touches integrations, Entra, agents or cloud-only features.
The admin centre copies production to a sandbox (new or replacing an existing one) in an hour or two for most databases. Before you rely on the copy:
EnvironmentInformation.IsSandbox and holds every entry, so it is automatic.Microsoft updates sandboxes earlier than production by default, and lets you create a sandbox on the next major's preview weeks before general availability. Use that: a fresh UAT copy on the preview, the regression scripts run there, extensions compiled against it in the NextMajor pipeline build, and only then the production update date set. The release wave checklist has the sequence.
Additional sandboxes are a paid add-on, and most businesses do not need them. Where it is worth it: multi-country tenants with per-country UAT; businesses with several partners or ISVs needing isolated test environments; or a large programme with parallel workstreams. Otherwise the spare sandbox and containers cover the peaks.
Names of the environments and their purpose; who may log in to each; what deploys to each and how; the refresh schedule and the refresh checklist above; the release wave dates for the year; and who owns the plan. Put it next to the IT roadmap. If the current answer to "which sandbox is UAT?" is "the one Dave uses", the plan is overdue.