Skip to main content
Yboard provides sandbox environments — isolated, stateful containers where your app runs during development. Each sandbox manages its own files, secrets, configurations, and deployment state.

Sandbox lifecycle

Pause and resume

Sandboxes can be paused to save resources and resumed when needed:
  • Pause — Schedules the sandbox to stop after a delay. Accepts a delaySeconds parameter.
  • Resume — Immediately restarts a paused sandbox.
Pausing is useful for apps with intermittent usage. The sandbox state (files, secrets, configuration) is preserved while paused.

State management

Each sandbox maintains a state object that tracks:
  • Environment configurations — Separate state for dev, preview, and production.
  • Dev deploy map — Tracks development deployments.
  • Navigations — UI navigation state.
State can be updated with merge mode (deep merges into existing state) or replace mode (overwrites entirely). Merge mode is the default and handles nested environment objects intelligently.

Secrets per environment

Secrets in sandboxes are scoped to environments, allowing different configurations for development, preview, and production:

List secrets for an environment

Set secrets

Update a single secret

Sandbox files

Sandboxes have their own file storage, separate from the main file management system:
  • List files — View all files in the sandbox.
  • Save files — Write files to the sandbox.
  • Bulk upload — Upload multiple files at once via the /upload-files-to-sandbox endpoint.

Dev server connections

Each sandbox can have active development server connections. You can:
  • List connections — See all active connections to the sandbox.
  • Disconnect — Force-disconnect dev server connections when needed.

Sandbox configuration

Sandboxes expose configuration through several endpoints:

Deployment from sandbox

Sandboxes support a deployment flow where changes move through environments:
  1. Dev — Active development in the sandbox.
  2. Preview — Deployed for testing with isolated database and secrets.
  3. Production — Live deployment accessible to users.
Each environment has its own worker script, secrets, and database branch. Use the POST /post-deploy-worker endpoint to trigger post-deployment processing.