16 questions you should ask before choosing a sandbox provider

Comparing sandbox providers is difficult because the important differences are not always obvious. These are the questions you should have answers to before making a decision.

Core capabilities

1. What are the minimum and maximum sandbox sizes?

These limits define how much of your use case a provider can cover. For simple code execution, you probably want the smallest possible size. For complex coding agents, you want a large ceiling. Databases may benefit from high disk with relatively low CPU. Be sure your ideal shape is available rather than paying for resources you do not need.

2. How flexible are sandbox sizes after creation?

Resizing matters in two ways. First, many providers offer only strict CPU x RAM x disk configurations, so custom sizing helps you get the ideal shape. Second, some providers let a sandbox grow after creation, such as adding memory when it runs out. This matters most for long-running workloads and much less for simple run-AI-code workflows. Very few providers allow for dynamic resize down after creation, if a provider does offer this it's important to ask about data stability during this transition.

3. What kind of virtualization do you use?

Virtualization type determines what the VM can do. Many providers use gVisor, which prevents them from supporting some syscalls and kernel features. Others use full hardware virtualization with a real kernel per VM. Understand what the model unlocks, what it makes impossible and whether compatibility claims rely on partial shims.

4. Which operating system and kernel capabilities are supported?

Be aware of support for Docker, FUSE, eBPF, Landlock, nested virtualization, modern syscalls such as clone3 and filesystems such as Btrfs, XFS or ZFS. Some platforms provide proper support, while others shim only part of a feature or use a very slim kernel. The important question is whether the capabilities your workload relies on are actually available.

5. How does the isolation model balance security and performance?

The isolation model determines both the security boundary and the overhead your workloads experience. Hardware virtualization with a hard kernel-per-VM boundary is the gold standard because untrusted code does not share a kernel with other customers. Be aware of what remains shared, how the boundary is enforced and what guarantees the provider makes against sandbox escapes. Also consider CPU, memory, disk and network overhead, tail latency, noisy-neighbor behavior and performance under sustained workloads.

6. What kinds of snapshots are available?

Some platforms support memory snapshots while others support only disk snapshots. Memory snapshots preserve process state as well as disk state, so they can resume browsers, CLIs, dev servers and other running tools instead of rebuilding them. Memory snapshots are a superset of disk snapshots, so a platform with full memory snapshots can also cover disk-only use cases.

State and lifecycle

7. How fast are startup and resume in practice?

Startup numbers often refer to different endpoints. One provider may stop the clock when an ID is returned, while another waits until the first command can run or an application can receive traffic. Be aware of cold starts, image starts, resumes and snapshot restores in the environment you plan to use, including tail latency during bursts.

8. Can sandboxes be copied or branched?

Copying a configured sandbox can be more useful than rebuilding the same environment repeatedly. Check whether a copy includes only the filesystem or also memory and running processes, whether the source must pause and whether the resulting branches are fully independent.

9. What happens when a sandbox becomes idle?

Most interactive sandboxes spend more time waiting than computing. A provider may keep billing the full machine, stop it and discard its processes, delete it or pause it with memory intact. Understand what counts as activity, how the sandbox wakes and what the first request after waking experiences.

Environment and access

10. What networking options are available?

Start with ingress. For a Lovable-style AI app builder, HTTPS ingress may be enough. More advanced products may need multiple ports, dedicated IPs, non-HTTP traffic or custom protocols. Then consider egress and private networking. Relevant capabilities include private sandbox networks, secure VPC connections to AWS or GCP, outbound traffic controls and network-level secret injection. These become especially important for enterprise customers that want to expose private infrastructure to your product without exposing it to the internet.

11. How customizable is the environment?

Some providers give you a narrow runtime or container image, while others provide something closer to a normal computer. Understand your control over the base image, packages, users, services, startup process and machine configuration. Missing flexibility becomes expensive when your workload falls outside the common path.

12. How do you interact with a running sandbox?

Running a command is the baseline, but long-lived environments need more. Examine output streaming, cancellation, reconnection, detached processes, file transfer, interactive terminals and SSH. These capabilities determine whether a sandbox remains usable and debuggable after something goes wrong.

13. How can end users safely access a sandbox?

Interactive products often need to give an end user access to a terminal, file, preview or service. Understand whether access can be narrowly scoped to one sandbox or capability, whether it expires and whether every interaction must be proxied through your own backend.

14. How are secrets handled?

Environment variables are simple, but untrusted processes can usually read them. More advanced systems can scope secrets to a process, mount them temporarily or inject credentials into outbound requests. Check how secrets interact with snapshots, branches and logs, and whether the workload must ever see the underlying credential.

Scale

15. How does the platform scale with your workload?

Scale includes more than the maximum sandbox count. It also covers creation rate, burst capacity, quota increases, control-plane responsiveness and fan-out from a snapshot or configured sandbox. Be aware of how quickly one starting point can become tens, hundreds or thousands of independent sandboxes, and whether that fan-out remains fast during bursts. A platform that can eventually run a large fleet is different from one that can create it quickly enough for an interactive product.

16. How do snapshots behave in practice?

Be aware of how long snapshots take to create and restore, whether the source must pause, how available they are and what they cost. A platform that takes 45 seconds to snapshot a VM is very different from one that takes 10 milliseconds. Also do not assume memory snapshots are automatically more expensive. Storage can be much cheaper than repeated memory and CPU time, so the snapshot cost may barely show up.

How Freestyle answers the checklist

Freestyle VMs are full Linux virtual machines designed for long-running, complex tasks. They are strongest when an agent needs a real computer, long-lived state, private networking, or snapshot-based branching.