Sovereign Sandboxes

Sovereign Sandboxes are isolated, cloud-hosted development environments powered by Coder. In our default hosted profile, the Coder control plane runs on Railway. The same operating model also works for customer-managed Coder deployments when a customer wants a governed place to evaluate, extend, and validate Deciding.org without moving work onto personal laptops.

Who This Is For

• internal Deciding.org engineers joining an existing Coder deployment
• customer-site engineers customizing a customer-managed Deciding.org instance
• platform owners who need a governed workspace pattern for enablement, debugging, and rollout support

Key Capabilities

• Instant Onboarding: Provision a pre-configured workspace in seconds with all necessary tools (Node, PNPM) pre-installed.
• Governed Customization: Safely modify framing engines and private instance logic within a controlled sandbox.
• Boundary-oriented security (not a formal “zero trust” product attestation): Source code and sensitive environment variables are intended to stay inside the governed workspace and approved control planes. Day-to-day access is through Coder-managed remote sessions (for example Coder Remote in VS Code or Cursor, which may use OpenSSH plumbing under the hood) rather than ad hoc ssh to arbitrary servers. Operator hygiene still matters: any step where someone copies production-class secrets onto a personal laptop (for example pasting URLs into a local terminal) moves that data outside the workspace boundary until the team replaces that habit with UI-only or in-workspace flows.
• Collaborative debugging (contractual): Joint troubleshooting with Deciding.org support is available when your agreement and access controls explicitly allow it (screen share, time-boxed access, audit trail per your org). The stock infra/coder template exposes workspace apps as owner-only by default and does not enable multi-user browser code-server; treat “co-development” as an operating model you enable with the platform owner, not something the template turns on automatically. Where logs live, retention, and customer export rights for support sessions are defined in your contract and support runbooks, not in this product page.

Access Modes

• Browser dashboard: sign in, manage workspaces, and launch exposed apps
• Browser terminal: run commands without installing a local IDE
• VS Code or Cursor: connect with the Coder Remote extension
• Current template note: the repo's current Coder template exposes app links and terminal access, but does not currently provision browser code-server

Why This Beats A Browser-Only Editor

For a large, running monorepo, Coder is not just an editor in a tab. It is a full remote development environment.

• indexing and search happen against remote workspace resources rather than the user's laptop browser tab
• package installs, terminal work, app boot, and health checks run in the governed workspace itself
• the workspace can expose multiple apps and services side by side
• persistent volumes keep the environment warm across sessions

That is the practical difference between a remote workspace and a lightweight browser editor such as vscode.dev.

Porting Local Tooling Into The Sandbox

Sovereign Sandboxes are also a good home for developer tooling that has outgrown a laptop-first setup.

• MCP servers, repo-aware search helpers, and other context-heavy tools can run in the workspace's Linux environment
• this keeps indexing, search, and AI context retrieval close to the checked-out code
• it reduces the amount of heavy processing pushed onto a local browser tab or older laptop

The current Deciding.org template already installs the basics needed for many such tools:

• Node 24
• Python 3
• workspace terminal access

Important:

• MCP servers are not preconfigured by default
• background tool processes should be added deliberately to the template or bootstrap flow once they are proven useful
• do not assume automatic access to Railway private services, Buildkite, or internal databases unless the deployment has been explicitly wired for that access

MCP Migration Checklist

When moving a local MCP server or similar helper into the sandbox:

1. Prove it manually in the workspace first.
2. Confirm the runtime and network requirements are available.
3. Keep secrets and private access explicit rather than implicit.
4. Decide whether it is personal tooling or a shared workspace capability.
5. Only then move it into the template or bootstrap flow.

Local UI vs Remote Tooling

When engineers connect from VS Code or Cursor, there is a useful split:

• local editor preferences can stay on the developer machine
• remote language tooling, debuggers, and workspace-aware extensions can run against the sandbox itself

That lets the laptop behave more like a thin client while the workspace does the heavier development work.

Standard Workspace Flow

1. Sign in to the shared Coder URL in your browser.
2. In VS Code or Cursor, install Coder Remote by coder.coder-remote.
3. Run Coder: Login from the command palette and authenticate against your Coder URL.
4. Run Coder: Open Workspace and select your workspace.
5. If you need to create a workspace, use the deciding-org template and keep database_backend=neon unless your platform owner explicitly wants local_postgres.
6. Once the workspace terminal is ready, run:

deciding-bootstrap
deciding-dev

Optional:

deciding-seed

Supported Customization Surfaces

Deciding.org enforces a strict separation between the core governance engine and pro-code integrations, creating a clear two-tiered customization model:

1. Studio (No-Code Governance): Used by Admins and Executives. This UI-driven control plane modifies the behavior of the engine via configuration. Use this to add Claude Skills, tweak prompt strategies, define company-wide guardrails, and build decision templates.
2. Coder Sandbox (Pro-Code Integration): Used by Enterprise Engineers. This code-driven integration plane modifies the connectivity of the engine.

When using Coder for customer-specific work, you operate within an Adapter Shell (a product and architecture boundary for pro-code integrations—see docs/adr/ADR-0043-customer-sandbox-adapter-boundary.md in the repo) rather than modifying the core engine directly. It is not the name of a Coder resource or Terraform object in infra/coder/main.tf; the stock template is still the full monorepo clone described in infra/coder/README.md. Keep changes in the right layer:

• Adapter Implementation: Write custom TypeScript adapters to implement explicitly exposed interfaces (e.g., custom Active Directory RBAC, internal API downstream fetches, bespoke SSL termination). The core engine (packages/decision-core) is injected as locked dependencies to guarantee stability.
• Workspace shape: use the dedicated Customer Sandbox Coder template parameters.
• Runtime domains and URLs: manage AUTH_BASE_URL, AUTH_TRUSTED_ORIGINS, NEXT_PUBLIC_SITE_URL, and DECIDING_API_BASE_URL in the canonical runtime control plane
• Secrets: keep DATABASE_URL, DIRECT_URL, BETTER_AUTH_SECRET, and any AI or provider keys in the canonical runtime and CI control planes, then securely inject them into Coder via Vaults or secure inputs (avoiding local shell exposure).
• Generated .env.local: treat it as a local convenience file, not the shared source of truth for a customer deployment

Secret Custody Model

The custody rule stays consistent even when the hosting shape changes:

• Default hosted profile: Railway is the runtime source of truth, Buildkite is the CI source of truth, and Coder consumes copied values only when the workspace needs them
• Customer-managed profile: the customer's approved runtime env manager and CI system become the source of truth, and Coder still remains a secondary workspace consumer

That separation keeps workspace onboarding fast without turning the sandbox itself into the canonical secret store.

Longer-term enterprise narratives for rotation, tenant-scoped secrets, and audit evidence may tighten further as the platform’s deferred zero-trust secrets execution work completes; your platform owner should point you at the then-current contract and ops artifacts.

Recommended Operating Pattern

For the best balance of speed and stability:

1. Start or resume the workspace from the Coder dashboard.
2. Use VS Code or Cursor against the remote workspace for primary editing.
3. Use the browser dashboard and terminal as the fallback path when you are away from your main development machine.
4. Move heavy repo-aware tooling into the workspace before adding more load to local machines.

If a future template enables browser code-server, document that as an additional access path rather than the default assumption.

Technical Alignment

Sovereign Sandboxes are configured to mirror the relevant production delivery path as closely as possible, so logic developed in the sandbox behaves predictably when promoted into the target deployment profile.