What Is a Sandbox Environment?
How sandboxes isolate code, where they fit in development, and what changes when the code is untrusted.
A sandbox environment runs code with defined access to the system around it. A development container that keeps dependencies off a laptop is a sandbox, but so is a microVM built to contain code supplied by a user or generated by an agent.
Code from a team repository and code submitted by a user can need exactly the same filesystem, package manager, and network access without deserving the same level of trust, which is why the isolation model has to account for provenance as well as the workload's technical requirements, including its credentials, egress, persistence, and cleanup.
When a sandbox is used as a coding-agent workspace, isolation is only the starting point. The final section looks at how Encore gives the agent a complete backend inside that workspace, so it can change a schema, run the application, call an endpoint, inspect what happened, and verify the result before returning a patch.
Step 1: Decide whether the code is trusted
Code from your own repository usually needs a reproducible place to run without interfering with another project or branch. Code supplied by a customer, package, plugin, or agent needs containment, since it has not been reviewed by the team operating the environment.
That distinction changes the useful defaults:
Local development and pull request previews normally run code from the team itself, so the sandbox is mainly there to make the environment reproducible and keep one project or branch from interfering with another. It may include databases, queues, buckets, and caches as well as the language runtime, with a preview environment extending the same model to a complete deployment that is removed when the pull request closes. Its data should remain separate from production, and any production records used to seed it should be sanitized first.
CI sits between the two trust models. The repository belongs to the team, but a build may execute dependency scripts or pull-request code while holding release credentials. A container or VM supplies the runtime boundary, and branch rules, job permissions, secret policy, and cleanup determine what a compromised build can reach.
Coding agents and user-submitted programs need a terminal, filesystem, package installation, and often network access without having been reviewed by the team. Dedicated platforms such as E2B and Daytona create, control, and destroy the isolated execution environment, and the surrounding application handles authentication, job state, rate limits, queues, storage, and observability.
Infrastructure changes need a wider boundary than an individual process or machine. A separate AWS account, GCP project, or Azure subscription isolates IAM, networks, billing, and managed resources from production, usually with budgets, organization policies, and automated cleanup applied at the account level.
Step 2: Choose the isolation boundary
Once the trust level is clear, the runtime boundary becomes easier to choose. Containers, virtual machines, and microVMs all isolate workloads, but they make different tradeoffs between startup time, resource use, and separation from the host.
Containers isolate processes using operating-system features such as namespaces and control groups. Their fast startup and clean dependency packaging suit development environments and CI jobs. Since containers share the host kernel, arbitrary code from unrelated users usually calls for a stronger boundary. Privileged mode, mounted host paths, broad Linux capabilities, and access to the host Docker socket weaken container isolation further.
Virtual machines run a complete guest operating system on virtualized hardware and are commonly used when workloads belong to different users or trust domains. They use more resources and usually start more slowly than containers, although snapshots and prebuilt images reduce startup time for cloud development environments that need a complete machine with terminals, compilers, and long-running processes.
MicroVMs use the hardware boundary of virtualization with less device and boot overhead than a traditional VM, which suits serverless functions and short-lived code execution. The platform around the microVM still has to inject files and credentials, control networking, collect output, enforce limits, and remove the environment when the run ends.
Step 3: Choose a sandbox provider
Teams that do not want to operate the runtime themselves can create and control isolated environments through a hosted sandbox API. The most relevant options for agent-generated or user-submitted code differ in their isolation model, persistence, runtime customization, and the cloud platform they expect the surrounding application to use.
The provider is only the execution layer. Before choosing one, compare its egress controls, secret handling, maximum lifetime, snapshot and persistence model, available regions, startup latency, observability, and pricing against the workload. The application still needs to authenticate users, track jobs, store durable inputs and outputs, enforce quotas, and handle cleanup when a sandbox call fails.
Step 4: Limit what the sandbox can reach
Isolation does not make every action inside the environment safe. Data can leave through an allowed network connection, a copied secret can be printed or sent elsewhere, and a workload without CPU, memory, or time limits can become a denial-of-service problem. Long-lived environments accumulate packages, files, and credentials. Preview environments retain any production access they are given. The runtime, identity, network, resources, orchestration API, and lifecycle have to be designed as one security boundary.
The runtime is therefore only one part of the sandbox. The surrounding policy needs to answer each of these questions:
Resource limits and timeouts should be enforced outside the workload, since untrusted code cannot be relied on to stop itself. Required output belongs in external storage so the runtime can be discarded after the run. Logs should connect each run to its creator, image, policy, scoped identity, stop reason, and cleanup result without recording secret values.
Before handling real workloads, exercise the failure paths as well as the happy path. Network failures, crashes, expired credentials, timeouts, and incomplete cleanup are the moments when an apparently isolated runtime is most likely to leave data or resources behind.
Step 5: Give the agent a complete backend inside the sandbox
A sandbox gives a coding agent a machine with a filesystem, terminal, and somewhere safe to run code. On its own, it does not give the application a database, queue, bucket, cache, or the runtime information the agent needs to understand whether its change actually works.
Encore lets the application declare those resources alongside its existing framework. When the agent runs encore run inside the sandbox, Encore starts the APIs and local implementations of the declared infrastructure there as well, without a separate Docker Compose setup or shared cloud environment.
The sandbox can then hold the whole verification loop rather than only the code-generation step. An agent can change the database schema, add a queue or bucket, restart the backend, seed data, call an endpoint, inspect the resulting trace, and run the integration tests before it hands the change back for review. Type errors and invalid infrastructure declarations surface through encore check while the agent is still working, rather than after the code reaches a shared environment.
The same declarations are used in preview environments and when Encore provisions the supported production resources in AWS or GCP, so the application does not need a second infrastructure model after it leaves the sandbox. The Encore and E2B example and Encore and Daytona example show this workflow with two different sandbox providers.
Related guides
Frequently asked questions
What is a sandbox environment?
A sandbox environment is an isolated place where code can run without being given unrestricted access to the host system, production data, or other workloads. Sandboxes are used for development, testing, security research, and running untrusted code.
Is a sandbox the same as a virtual machine?
No. A virtual machine is one way to build a sandbox, but sandboxes can also use containers, operating-system processes, browser isolation, or managed execution environments. The right boundary depends on how much you trust the code and what it needs to access.
What is the difference between a sandbox and a development environment?
A development environment is optimized for building and debugging software. A sandbox is defined by its isolation boundary. A development environment can be sandboxed, but the two terms describe different properties.
Are containers secure sandboxes?
Containers provide useful process and filesystem isolation, but they share the host kernel. They can be appropriate for trusted development workloads, while hostile or multi-tenant code usually needs a stronger boundary such as a microVM plus strict network, credential, and resource controls.
How does Encore use sandbox environments?
Encore gives coding agents a complete local backend inside a sandbox. Running encore run starts the application's APIs and local databases, queues, buckets, caches, and other declared infrastructure, so the agent can implement and verify an end-to-end change before returning its patch.
Deploy to your cloud on AWS and Google Cloud
without managing infrastructure
Encore lets developers and agents define application infrastructure directly in code, then automatically provisions it from local development to production in your AWS or GCP account.
