Deno Sandbox

Use Deno Sandbox when permission-style runtime controls matter more than matching a specific hosting platform. It works well when network allowlists, secrets, ports, or filesystem-style isolation need to stay explicit.

Before you start

Install the Deno SDK alongside @vitehub/sandbox.

pnpm add https://pkg.pr.new/vite-hub/vitehub/@vitehub/sandbox@main @deno/sandbox

Create a fresh Deno organization token before you run a sandbox. @deno/sandbox reads this token from DENO_DEPLOY_TOKEN.

1. Open console.deno.com and sign in.
2. Select the Deno organization that should own the sandboxes.
3. Open the Sandboxes area and create an organization token. Some dashboard versions show this under the Sandboxes integration flow, while others expose it from organization token settings.
4. Copy the token when Deno shows it. Store it somewhere safe because the dashboard may not show the full value again.
5. Add it to .env or another env source that your app loads into process.env:

DENO_DEPLOY_TOKEN=your-token

The token must belong to the same Deno organization that should run the sandbox. If an existing token fails, create a fresh one instead of reusing an expired or revoked token.

ViteHub does not load .env files for you. Nuxt, Nitro, Vite, or your process manager must load the value before the server starts.

Configure Deno

export default defineNuxtConfig({
  modules: ['@vitehub/sandbox/nuxt'],
  sandbox: {
    provider: 'deno',
    allowNet: ['api.notion.com'],
  },
})

Top-level sandbox config is the right place for defaults that most sandboxes should inherit.

Define a sandbox

Sandbox definitions accept only portable options (timeout, env, runtime). Set Deno-specific options such as allowNet, memory, region, and secrets in the top-level sandbox config.

import { defineSandbox } from '@vitehub/sandbox'

export default defineSandbox(async (payload?: { notes?: string }) => {
  return { notes: payload?.notes || '' }
}, {
  timeout: 90_000,
})

What changes on Deno