teta.so
Sign in

Sandboxes

Every Teta project runs inside its own cloud sandbox — an isolated container where your SvelteKit app, the AI agent, and all development tools live. Sandboxes are powered by E2B and provide a complete development environment without requiring anything installed on your local machine.

What sandboxes are

A sandbox is a lightweight cloud container that acts as your project's development server. Think of it as a remote machine dedicated to your project, running in the cloud. It has its own file system, its own running processes, and its own network — completely isolated from every other project on the platform.

When you open a project in Teta, a sandbox is created (or reconnected) automatically. You never need to manage infrastructure, install dependencies locally, or configure a development environment. Everything is ready in seconds.

What runs in a sandbox

Each sandbox runs several services simultaneously:

SvelteKit dev server

Your SvelteKit application runs in development mode with Vite's hot module replacement (HMR) enabled. When the AI agent edits a file or you make a change in the code editor, the preview updates instantly without a full page reload.

VS Code (code-server)

A full instance of code-server runs inside the sandbox, providing a browser-based VS Code experience. You can open files, edit code, use the terminal, and install extensions — all within the Teta editor interface.

AI agent

The Claude Code CLI runs inside the sandbox with direct access to the file system and terminal. This means the AI agent operates in the same environment as your running app. It can read source files, write code, install npm packages, and observe build output — all within the sandbox.

MCP tool servers

Model Context Protocol servers run as background processes in the sandbox. These provide specialized capabilities to the AI agent, such as image generation, browser interaction (screenshots, console logs), and web search. See the MCP Tools page for details.

Sandbox lifecycle

Sandboxes follow a predictable lifecycle:

Creation

When you open a project for the first time (or after a sandbox has expired), Teta creates a new sandbox. This involves:

  1. Provisioning a new E2B container from a pre-warmed template.
  2. Restoring your project files from the last saved state.
  3. Installing dependencies and starting the SvelteKit dev server.
  4. Starting code-server and MCP tool servers.
  5. Connecting the AI agent session.

This process typically completes in a few seconds thanks to pre-warmed containers.

Active use

While you are working, the sandbox stays running. Your SvelteKit dev server serves the live preview, the AI agent is ready to receive messages, and code-server is available for direct editing. All changes are persisted to the sandbox's file system in real time.

Idle caching

When you stop actively using a project, the sandbox enters a cached state. It remains available for approximately 10 minutes of inactivity. During this window, reopening the project reconnects to the existing sandbox instantly — no startup delay.

Expiration and reconnection

After the cache window expires, the sandbox is shut down to free resources. The next time you open the project, Teta creates a fresh sandbox and restores your files. This process is automatic and transparent — you pick up right where you left off.

Isolation

Sandbox isolation is a fundamental security property:

  • Process isolation — Each sandbox runs in its own container with its own process namespace. A runaway process in one sandbox cannot affect another.
  • File system isolation — Each sandbox has its own file system. There is no shared storage between projects, and one sandbox cannot access another's files.
  • Network isolation — Sandboxes cannot communicate with each other over the network. Each sandbox exposes only the ports needed for the preview, code-server, and internal communication with the Teta backend.
  • Resource isolation — CPU and memory are allocated per sandbox, preventing one project from starving another of resources.

Performance

Teta uses several strategies to keep sandbox interactions fast:

  • Pre-warmed containers — E2B maintains a pool of ready-to-use container images. Creating a new sandbox does not require building a container from scratch.
  • Template caching — Common SvelteKit project configurations are cached as templates, reducing setup time for new sandboxes.
  • Hot module replacement — Vite's HMR means code changes are reflected in the preview in milliseconds, not seconds.
  • 10-minute cache window — The idle cache keeps your sandbox alive during short breaks, so you do not experience startup delays when switching between tasks or taking a quick break.

File persistence

Files in your sandbox are the source of truth during development:

  • During active use — All file changes (from the AI agent, code-server, or the visual editor) are written directly to the sandbox's file system.
  • On deployment — When you deploy your app, the current state of the sandbox's file system is used as the build source.
  • On sandbox expiration — When a sandbox expires, the file state is preserved and will be restored when a new sandbox is created for the project.
  • Snapshots — Teta can take snapshots of your sandbox state, allowing restore points for your project.

You do not need to manually save or sync files. The system handles persistence automatically.

Resource limits

Each sandbox operates within defined resource constraints to ensure fair usage and platform stability:

  • CPU — Sandboxes have access to shared CPU resources with burst capability for build operations and dev server startup.
  • Memory — Each sandbox is allocated a fixed amount of RAM, sufficient for a SvelteKit dev server, code-server, and the AI agent running concurrently.
  • Disk — File system storage is allocated per sandbox. Typical SvelteKit projects (including node_modules) fit well within the limits.
  • Timeout — Sandboxes have a maximum active session duration. Very long-running sessions may be recycled, but your files are preserved.

What happens when a sandbox expires

When your sandbox shuts down after the cache window, here is what happens:

  1. The sandbox's file state is saved for future restoration.
  2. The running SvelteKit dev server, code-server, and MCP servers are stopped.
  3. Active AI agent sessions are terminated. In-flight messages may be lost, but your conversation history is preserved in the database.
  4. The container resources are released.

When you return to the project:

  1. A new sandbox is provisioned from a pre-warmed container.
  2. Your project files are restored to the exact state they were in when the sandbox expired.
  3. Dependencies are reinstalled and the dev server is restarted.
  4. A new AI agent session is created, ready to receive messages.

The entire reconnection process is automatic. From your perspective, you simply open the project and continue working.

FAQ

How fast is sandbox creation?

Sandbox creation typically takes a few seconds. E2B uses pre-warmed containers, so provisioning is fast. The majority of startup time is spent installing npm dependencies and starting the SvelteKit dev server. If your sandbox is still cached (within the 10-minute window), reconnection is nearly instant.

Can I SSH into my sandbox or use a local terminal?

Direct SSH access to sandboxes is not currently available. However, you have full terminal access through the VS Code code-server instance embedded in the Teta editor, and the AI agent can run any terminal command on your behalf.

What happens to my code if E2B has an outage?

Your project files are persisted independently of any single sandbox instance. If E2B experiences an outage, you would be unable to create new sandboxes temporarily, but your code is not lost. Once the service recovers, your project is restored to its last saved state.

Do sandboxes have internet access?

Yes. Sandboxes can access the internet for tasks like installing npm packages, fetching data from external APIs during development, and the AI agent's web search and fetch capabilities. Outbound access is available for standard HTTP/HTTPS traffic.

Can I increase the resources allocated to my sandbox?

Resource limits are currently set at the platform level and are the same for all projects. We are exploring options for configurable resource tiers in the future for projects that require more CPU, memory, or disk space.