Skip to main content
When an Expert needs to “get things done” — write code, run programs, operate on files — it doesn’t execute on some shared server. Instead, it operates within a dedicated, isolated cloud container. This is Profy’s declarative sandbox architecture: every conversation has its own complete development environment, fully isolated from others, disposable after use.

​
Why a Sandbox?

Security Isolation

Code executed by AI may contain errors or even risks. The sandbox ensures all operations are confined within the container, unable to affect the host system or other users.

Consistent Environment

Pre-installed with a complete development toolchain (Node.js, Python, system tools), so the Expert doesn’t spend time setting up — it can start working immediately.

Persistent State

The file system persists throughout the conversation. Code written, dependencies installed, and files generated by the Expert are still there when the next message arrives.

On-Demand Start

Sandboxes are only created when the Expert actually needs to execute tools — pure conversations incur zero resource cost.

​
Sandbox Lifecycle

1

Lazy Provision

Sandboxes are not created when the conversation starts, but only when the Expert first needs to execute a tool operation. Pure text conversations consume zero resources.
2

Sub-Second Warm Start

Based on pre-warmed container images, sandboxes typically go from creation to ready in under 1 second. Users barely notice any wait.
3

Cross-Message Persistence

Multiple messages within the same session share a single sandbox instance. Dependencies installed in the first message are still available in the fifth.
4

Idle Hibernation

When the conversation pauses, the sandbox automatically hibernates, releasing compute resources. The file system persists through cloud file storage (CFS), nothing is lost.
5

Seamless Resume

When the user sends another message, the sandbox is woken up to its previous file system state. The Expert can seamlessly continue its previous work.

​
Image Pre-Baking

The sandbox is not an empty container — it comes pre-installed with a rich development toolchain, ready for the Expert to use out of the box:
  • Node.js + bun (JavaScript/TypeScript full-stack)
  • Python 3 + uv package manager (data science + AI development)
  • TypeScript compiler + language server
  • Biome code formatting and static analysis
  • pandas, numpy, matplotlib, seaborn
  • scipy, scikit-learn
  • Pillow image processing
  • openpyxl Excel handling
  • Pandoc document format conversion
  • WeasyPrint PDF rendering
  • Tesseract OCR text recognition
  • ImageMagick image processing
  • Poppler PDF tools
  • TanStack Start (pre-baked + node_modules)
  • FastAPI / Flask (Python Web)
  • Complete HTTP client toolchain
The core idea behind pre-baking is “shifting wait time from runtime to build time.” Users don’t need to wait for npm install or pip install — hundreds of megabytes of dependencies are already installed during image build.

​
Working Directory Architecture

This design lets the Expert quickly start from a template (zero installation delay) while ensuring the user’s actual work is not affected by subsequent image updates.

​
Dev Server Lazy Start

Web preview is a commonly used Expert capability — letting users see the visual effects of code in real time. But a Dev Server is a resource-intensive process: Invariant: The only entry point for starting a Dev Server is the Expert proactively calling the initialization tool. Conversations that don’t need preview (data analysis, script execution, document processing) never pay the memory and CPU cost of a Dev Server.

​
Network and Security Policies

Sandboxes have controlled network access capabilities:

Outbound Access

Experts can access external APIs, download resources, and make network requests. This is essential for web development and data collection.

Process Isolation

Each sandbox is an independent Linux container with complete process namespace isolation. One user’s operations can never affect another user.

Resource Limits

CPU, memory, and disk usage all have container-level hard limits, preventing malicious or runaway programs from exhausting shared infrastructure.

File System Isolation

Cloud file storage is mounted with per-session isolation, inaccessible across sessions. Even different sessions from the same user cannot see each other’s files.

​
Provider Abstraction

The sandbox system uses a Provider abstraction design, allowing the underlying implementation to be transparently swapped: The Runtime doesn’t care about the specific container implementation details — it interacts with sandboxes through a unified Provider interface. This means new container providers can be seamlessly integrated in the future without any changes to the upper-layer Agent logic.

​
File Sync and Preview

Files created by the Expert in the sandbox can be previewed and downloaded by users in real time:
  • Code files: Displayed with syntax highlighting, supporting diff comparison
  • Web projects: Real-time preview via Dev Server, supporting HMR hot reload
  • Data files: Tables and charts rendered inline
  • Documents: PDF and Markdown instant preview
Users can also sync files from the sandbox to cloud storage for access after the conversation ends.
The sandbox is the technical foundation of Profy’s “AI doesn’t just talk, it does” philosophy. Without it, Experts can only generate text; with it, Experts can write code, run programs, create projects, generate documents — working like a true digital colleague.

​
Design Trade-offs