Sandbox Providers

Coding agents execute code inside isolated sandboxes. By default, MeetLoyd runs the sandbox for you — there's nothing to set up. Enterprises that need code to stay inside their own infrastructure can bring their own compute, so nothing leaves their environment.

This guide covers the two models, how to configure a bring-your-own provider, persistence across pauses, and the built-in isolation and cleanup safeguards.

Two models

Model	What it is	Best for
MeetLoyd-managed (default)	MeetLoyd provisions and runs the sandbox for you, on managed cloud infrastructure. Zero configuration.	Most teams — get coding agents working immediately, nothing to operate.
Bring your own	The sandbox runs in your infrastructure (your E2B account or your Kubernetes cluster). Code and data never leave your environment.	Regulated industries and data-residency / sovereignty requirements.

The managed option is the default for every tenant and is the fallback that keeps teams unblocked. Bring-your-own is available to Enterprise.

Configuring a bring-your-own provider

Open Coding → Sandbox Providers in the dashboard. Each provider has a Configure action where you enter your credentials and run a Test connection before saving. Credentials are stored encrypted in MeetLoyd's secret vault — never in plain text — and are only ever used to launch your own sandboxes.

E2B (your account)

Run sandboxes on your own E2B account.

• You provide: an E2B API key.
• Isolation: managed microVM.
• Templates: base, node20, python3.12, rust, and custom.

Kubernetes (your cluster)

Run sandboxes as isolated pods inside your existing cluster (EKS, GKE, AKS, or self-managed).

• You provide: a kubeconfig with permission to create pods in a namespace.
• Isolation: runtime class (gVisor recommended, or Kata), per-pod resource limits, no mounted service-account token.
• Options: namespace, runtime class, and an optional storage class (see Persistence below).

Self-hosted micro-VMs

For fully on-prem deployments, MeetLoyd can also run sandboxes as self-hosted micro-VMs on your own Linux hosts. Contact your account team — this is part of an on-prem deployment, not a self-serve toggle.

Local development

A local Docker option exists for development only and is disabled in production deployments. It is not an isolation tier for running untrusted code.

Persistence across pauses

A coding session can pause — for example, to wait for a human approval. On providers that support persistence, the session resumes with your workspace intact: your cloned repository and in-progress work are preserved on a persistent volume, so the agent picks up where it left off instead of starting over.

• Kubernetes: enable by setting a storage class when you configure the provider (a persistent volume is provisioned for the workspace).
• MeetLoyd-managed: persistence is handled for you.

If a provider doesn't preserve the workspace, MeetLoyd safely restarts the session from your latest committed work — no progress is lost, it's just re-prepared.

Resource limits

Resource	Default	Description
CPU	2 cores	Maximum CPU allocation
Memory	2048 MB	Maximum memory allocation
Disk	10240 MB	Maximum disk space
Lifetime	up to 6 hours	Maximum sandbox lifetime

These defaults can be tuned per session.

Network policy

By default, sandboxes allow outbound internet only to a whitelist:

Allowed hosts	Purpose
github.com, gitlab.com, bitbucket.org	Git operations
registry.npmjs.org, pypi.org	Package managers

Inbound connections are always blocked. The whitelist is customizable.

Built-in safeguards

• Git credentials are injected at sandbox creation, written inside the sandbox, and destroyed with it. For bring-your-own deployments they never leave your network.
• Orphan cleanup: a background reaper removes any sandbox (and its persistent volume) that exceeds its maximum lifetime, even if a session is interrupted — so nothing is left running or billing.
• Encrypted credentials: provider keys and kubeconfigs are stored in MeetLoyd's encrypted vault.