Skip to content

Settings

Where user apps run. One choice — a directory on this machine, or an isolated cloud sandbox — plus the key the cloud option needs.

/admin/settings:

Settings Where user apps run.

This page is sandbox configuration and nothing else. There is no email, branding, security or member section in this build.

The two drivers

Local runs each app as a directory and dev server on this machine — no external service, right for development and small installs. Daytona runs each app in an isolated cloud sandbox — right for production. The driver applies to newly created projects; existing ones keep theirs.

Local (this machine). Each project is a folder on the server, with its own Next.js development server on its own port, taken from a configured range — 4100 to 4199 by default. Nothing external is required.

The trade-offs: every project's app runs as an ordinary process on your server, so there is no isolation between one user's generated code and another's; every running project holds a port, so the range caps how many can be live at once; and the preview address is a localhost address that only resolves on the server itself.

Daytona (cloud sandboxes). Each project is an isolated container running a node:20 image, with the development server on port 3000 and a public preview link supplied by Daytona. This is the production choice: real isolation, and a preview address that works from any browser.

It needs an API key, and each sandbox costs whatever Daytona charges.

Choosing one

Driver for new projects is a two-option select. The label is precise: for new projects.

A project's driver is fixed when it is created and never changes. Switching to Daytona does not migrate anything — existing projects keep running locally, new ones get cloud sandboxes. The two coexist indefinitely.

There is no migration path. To move a project, download its source and start a new project from it.

The Daytona API key

Daytona API key with a status badge beside it: Set, plus a hint of the key, or Not set.

  • Type a key and press Save settings to store it, encrypted.
  • Leave the field blank to keep the stored key. Blank does not mean "remove".
  • Press Remove to delete it. Toast: Daytona key removed.

Under the field:

Encrypted at rest. The DAYTONA_API_KEY environment variable, when set, wins over this.

That precedence matters: if the environment variable is set, the key you type here is stored but never used, and the badge's hint reads from environment.

With the driver set to Daytona and no key available anywhere, every first build fails with:

The Daytona driver needs an API key: set DAYTONA_API_KEY or add one under Admin → Settings.

Encryption

Keys are encrypted at rest with AES-256-GCM. If the installation has no encryption key, the field refuses to store anything and an amber box explains why:

No encryption key is configured. Set BOOKBAG_ENCRYPTION_KEY to 64 hex characters (openssl rand -hex 32) and restart.

or

BOOKBAG_ENCRYPTION_KEY is set but is not 32 bytes — it must be 64 hex characters or a 32-byte base64 value.

There is deliberately no plaintext fallback. The same encryption key protects the platform's AI provider keys and every user's own key, so the server refuses to start without one.

What sandboxes cost you in resources

Worth planning for, because sandboxes do not shut themselves down. There is no idle timeout and no cleanup job anywhere in the product. A sandbox stops only when its project is archived or deleted, or when the server restarts and finds its development server gone.

On the local driver that means every project a user has ever built, and not archived, holds a Node process and a port for as long as the server is up. The 4100–4199 range gives you a hundred; past that, builds fail with:

No free preview port in the configured range — archive an old project or widen sandbox.previewPortStart/End.

Two ways to manage it: widen the port range in the server's configuration, or move to Daytona.

Detached development servers survive an API restart on purpose. At start-up Bookbag health-checks every project that thought it was running: healthy ones are left alone, dead ones are marked stopped and revived on that project's next build. The log line reads [sandbox] after restart: N still running, M marked stopped.

The limits that apply either way

Limit Value
Files listed per project 500
Characters read from one file 60,000
Shell command timeout 3 minutes
npm install timeout 8 minutes local, 10 minutes cloud
Development server readiness wait 60 seconds local, 90 seconds cloud
Production build during publish 10 minutes
Steps in one build run 60

None of these is configurable from this page.

Next