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:f17a7e0df7f750d677a8e28f12d5b88e5b2f1bc9f7b933e228f02cbe08f060b1

list-keySigns only the withdrawal list: versions DayStorm has taken back.

sha256:636362f44bda0e86e8cadd0a9ebc5d7df6e0ff4a375eaea174d3584f4626f4ae

Two 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:

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.

How far git access reaches.

What leaves your factory.

Every way data leaves the machine.

DestinationWhatSent by
Your model providerPrompts and code excerpts of a build, through the access you set (Anthropic or AWS Bedrock).Factory
Your git hostClones, branches, pull requests, with your git token.Factory
DayStorm registryImage downloads by digest. Requests only, no data of yours.Pull command
DayStorm install doorA daily request for the signed withdrawal list, an update check (install key and product name, never the version you run) and the renewal of the fleet credential.Daily timer
DayStorm fleet, FrankfurtPseudonymous build reports and operating data, listed below.Company collector
Package registries and web pagesTraffic of the build agent that your build needs, for example package downloads.Build agent

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.