Laufwerk

Deployment & security

Know where the work runs.
Know where the data goes.

Start with the boundaries of your environment. Then decide how Laufwerk, agent execution, and external systems fit within them.

Your infrastructureCurrent single-host model
Your application · Studio · CLI
Laufwerk runtimeYour TypeScript workflows coordinate the process.
Persisted stateSQLite, results, and run evidenceRead and write
Agent executionLocal / Docker / MicrosandboxWorkspace files and configured tools

Configured model requests and tool traffic

Model providersPrompts and relevant task context
Tools & business systemsConfigured integrations and permissions
Self-hosted execution does not imply offline inference. Tools and MCP servers have their own execution boundaries; an agent sandbox does not automatically contain them.

Review each boundary.
Not just the host.

Three different questions determine whether a deployment fits your data requirements.

What stays on the host?
Workflow state, working files, and retained evidence. Plan storage access, backup, restore, and retention for the data you keep.
What can leave it?
Prompts, relevant files, and tool requests can reach configured providers and systems. Review the permitted data classes and provider terms.
What grants access?
Runtime access, provider credentials, and integration permissions are separate decisions. Scope each one to the work it needs to perform.

Choose the execution boundary
for the work.

A working copy is useful separation of files. It is not, by itself, a security boundary.

Local execution

The host’s tools.
The host’s permissions.

Host
Agent process + native tools

Use the native environment deliberately. The agent’s access follows the permissions of the process running it.

Docker execution

An explicit container.
Explicit mounts and access.

Host
Container boundaryAgent process

Review workspace mounts, credentials, and network access. Read-only mounts can constrain file access for review work.

Read the isolation details

A deployment is only useful
when someone can operate it.

Establish owners for upgrades, incident response, recovery, and the business systems the workflow can affect.

Available today

A single-host runtime.

The published alpha supports local and Docker execution, with Microsandbox available for existing workflows. There is no supplied Kubernetes adapter or managed cloud.

Current setup requirements
Scope together

Your environment’s requirements.

For internal Kubernetes, review persistence, execution adapters, networking, identity, and operations before agreeing implementation work.

Map SSO, roles, audit retention, and availability requirements to verified capabilities and remaining gaps.

Back up & restoreInspect & reconcileUpgrade & recoverEscalate & support
Your next step

Bring your infrastructure team into the conversation.

We can review the deployment model against your requirements and define the work together.

Discuss your use casePlan the engagement