Security

Where everything runs

Two shapes. On our cloud, or on your own servers: one binary, your Postgres, your object storage, your model keys, your domain.

Row by row, what sits where.

The two deployments
WhatOn Daslab CloudOn your own servers
The scene recordWhat your team and its agents did, and the records they made. It carries a commit chain, so a scene's history is a version history rather than a log. Our database, in Frankfurt. Members see it by layer: Private is private from admins too. Your Postgres. Nothing about it reaches us.
Credentials you connectThe keys and tokens for the systems you link. Encrypted with a key that is not in the database, and decrypted in the process that runs your job, for that job. A copy of the database is not a copy of your credentials. Your database, your key, and nobody to ask.
Which credentials a job getsThe same rule in both. A scene's computer is handed only the credentials whose tile is linked in that scene. Not the workspace's others, and never your own sign-in token.
Code executionEvery scene gets a computer, made on first use. Files persist between runs; running processes do not. A rented computer, Daslab Bench, unless the scene is pinned to a machine you paired. Code execution can be switched off for a scene or a whole workspace. Your machines, or a sandbox account in your name.
Machines you pairA Raspberry Pi, a Mac, a GPU box. One token per workspace. The machine dials out; nothing connects in. When it is away the scenes pinned to it wait, and nothing moves elsewhere. Your hardware in both. A machine, or a layer, can be locked to named people: everyone sees it exists, only they may pin a scene to it. Each machine carries a policy for outbound traffic, open, an allowlist you write, or closed, enforced by the machine itself so you can check it where it runs.
Files a scene publishesImages, exports, anything a job writes out. Object storage behind an unguessable URL. Any S3-compatible store you name.
The traceEvery tool call as an OpenTelemetry span: who, which scene, which job, which tool, how long, what it cost. Ours, and it can be pointed at your own OTLP endpoint instead. Yours, wherever you send it.
The modelsWhose account answers the prompt. Your keys serve before ours. Switch ours off and every call runs on your accounts. Your keys only. A model you serve on your own machine never leaves the building.
Sign-inWho gets in. Apple, Google, GitHub, email, API keys, OAuth for MCP clients, and SAML with SCIM provisioning: your directory decides who is in, and removing someone there removes them here, sessions and API keys included. Members are owner, admin, member or viewer, and the last owner cannot be demoted away.
Share linksThe public read surface. An HMAC over the thing being shared plus a counter. No per-link row exists anywhere, so the URL is the credential; resetting the counter kills every link ever issued for that thing.
BackupsHow far back a copy goes. Managed Postgres in Frankfurt, with daily backups and point-in-time recovery. Your backup policy, on your schedule.
DeletingWhat actually goes. Deleting an asset removes it. Deleting a scene removes its contents, and the commit chain that referenced them is pruned. Erasing a workspace removes its scenes, its credentials and its machines' tokens, which drops those machines' connections. Backups age out on the window above.
Who else touches itEvery party your data can pass through. The application host and database in Frankfurt, object storage, a cache, Daslab Bench for the rented computer, the model providers you use, live video only in a scene that uses it, transactional email, and push notifications to the app. Named, with regions, on request. The ones you choose: your host, your storage, your model providers. We are not one of them.
Running it yourself

One binary, your Postgres, your domain

One process serves the API, the website, sign-in, webhooks and background jobs. It needs PostgreSQL, Redis and at least one model key; putting it on a domain adds object storage and an address for transactional mail. The schema creates and migrates itself. There is no cluster to operate.

The accounts take longer than the software. Integrations that sign your users in with Google, Slack or Microsoft need an app registered in your name, and the guide walks through each one. Self-hosted deployments are part of the Enterprise plan, and the build comes from us rather than a download page.

Asking us something specific

A review usually turns on one row. Tell us which and you get the answer in writing.