Project Development Service Plane

FractalOps workspaces must not become miniature production stacks. A developer workspace is for source editing, agents, tests, and short-lived client sessions. Project databases and other shared development services belong to the project runtime plane and are reconciled through Dokploy templates.

Rule

Workspace:
  - code checkout
  - agent tools
  - editor sessions
  - the bare dev server (live preview)
  - client connections to project services

Dokploy project stack:
  - Postgres, MySQL, Redis, queues, object stores
  - static/preview hosting
  - service templates
  - stable project-level connection endpoints

OpenBao:
  - workspace-scoped leases
  - credential rotation
  - revocation evidence

The workspace may connect to a database. It must not run the database unless a local-only scratch fixture is explicitly requested for a unit test.

There is no in-sandbox compose/build plane: docker is hard-walled in the workspace (the baked exit-127 stub). Live preview is the bare dev server (vite / next / uvicorn bound to 0.0.0.0), exposed through the daytona-proxy signed preview URL via the dev-preview MCP — see Dev Preview Plane. Per-project static and database hosting is provisioned on the project’s own Dokploy plane, not from inside the sandbox.

Semantics

A project service runs REMOTELY as its own Dokploy-deployed stack; the workspace receives a scoped, OpenBao-backed connection lease.
Ephemeral connection settings are exposed for tools such as app servers, migrations, Prisma, SQLAlchemy, or psql — never as long-lived credentials in workspace files.
Credential rotation refreshes the workspace lease without deleting the project service; service deletion is an explicit, evidence-producing mutation.

All mutation paths must produce connector evidence, be safe to replay with an idempotency key, and avoid storing long-lived credentials in workspace files.