Trust & Install
The DayStorm Factory runs on your machines. This page lists what we sign, what stays with you, every way data leaves your installation, and how you go back.
Install keys
Fingerprints for verifying a DayStorm Factory installation.
Before you install, compare these two values with what the installer and get.daystormlabs.ai show you. They must match character for character. If they do not, stop and write to [email protected].
release-keySigns every release image and its release record.
sha256:f17a7e0df7f750d677a8e28f12d5b88e5b2f1bc9f7b933e228f02cbe08f060b1list-keySigns only the withdrawal list: versions DayStorm has taken back.
sha256:636362f44bda0e86e8cadd0a9ebc5d7df6e0ff4a375eaea174d3584f4626f4aeTwo keys, two sets of rights. Whoever may sign releases cannot sign the withdrawal list, and the other way round. The private halves sit in a hardware security module and cannot be exported. Every signed release record names the list-key fingerprint, so the release-key also vouches for the list-key.
What is signed.
Release images
Every image is signed with the release-key. A software bill of materials (SBOM) is attached to it as a signed attestation.
The release bundle
It comes with a signed record and step-by-step verification. You unpack it only when every check matches.
The withdrawal list
Signed with the list-key and refreshed weekly. Your installation checks it daily, so a withdrawn version is not installed by accident.
What stays with you.
These never leave your installation for DayStorm:
- Source code
- Spec text
- Log lines
- Branches
- Pull request content
- Repository names in the clear (outside your own company)
The DayStorm Factory, its Control Room and the company collector all run on your machine. Nothing connects into your network from outside. DayStorm has no access to it.
Where build code runs.
On your machine, in Docker on your Linux VM. Code from your repositories, meaning the check and test commands and the build agent itself, runs in its own guest container next to the DayStorm Factory, not inside it.
- The guest container sees the working copy of your repo, a fresh home folder for every request and the package caches. It gets no configuration, no credentials file, no state of the Factory and no Docker socket.
- Guest code runs as an unprivileged user without capabilities. At the start of every build, its processes are ended and its home and temporary folders are emptied.
- The Factory container itself runs with a read-only file system and without added privileges.
How far git access reaches.
- The Factory clones, pushes its own branches and opens pull requests with one GitHub token that you put into the configuration on your machine.
- We ask for a fine-grained token, limited to the repositories you connect, with the permissions Contents and Pull requests set to read and write. Nothing more.
- With automatic merging off, which is the default, the Factory never writes to your target branch.
- The token stays with the Factory. The guest container, where the code of your repositories runs, does not get it.
- Supported git host: GitHub.
What leaves your factory.
Every way data leaves the machine.
Telemetry of the Claude CLI inside the DayStorm Factory is off by default. A built-in check lists every outbound path of your installation.
The build report, field by field.
No code, no personal data and no names are in it. It measures builds, never people. Sent when a build ends, and again when its merge is reported. It is an allow-list: a field not named here does not leave. Your company collector replaces the repository fingerprint with its own before anything goes out.
build_id- the identifier of the build
company_id- the company identifier of your installation
instance_id- the identifier of the factory
status- running, success, failure or aborted
started_at, finished_at- start and end of the build
merged_at- when the pull request was merged, if reported
station_durations- the duration of each station
cost_usd, credits_consumed- the model cost of the build
score- the score of the build
failure_class- a short word for the kind of failure
estimated_dev_minutes, human_hours_estimate- the estimated developer time
engine_commit- the engine version that built it
predecessor_build_id- the build this one follows on from
repo_pseudonym- a keyed fingerprint (HMAC-SHA-256) of the repository name; the key never leaves your company
tokens_by_model- reserved, sent empty
Per factory, two more small signals leave: whether it is building right now and at which station, and how many specs wait for an answer to a question. Neither carries a repository name, spec name, branch or pull request number.
Fleet participation is part of the contract.
Outside your network, reports travel only over https, with a credential issued to your company that expires and can be revoked.
It measures builds, not people.
The DayStorm Factory works under its own technical identity. Nothing in the reports names or scores a developer. You get the field list and the data flows up front, for your risk assessment and your works council.
Updates and rollback.
- Updates come as signed bundles. The Factory tells you one is available, you decide when it goes in.
- One command goes back to the previous version that is kept on your machine.
- DayStorm can withdraw a version through the signed withdrawal list. Your installation will not switch to it.