Release audit trail

Your releases, provable.

When the auditor asks for change-management evidence on the software you ship to customer machines, a hand-rolled update feed has nothing to say. Relayer answers with a record: who shipped what, to which channel, at what rollout percentage, and when it was withdrawn.

Start shipping free Read the security posture

Evidence by archaeology

The question 'show me your release change controls' gets answered with Slack threads, CI logs and screenshots, assembled by hand, every audit cycle, and it never quite convinces anyone.

The S3 feed forgets everything

A latest.json overwritten in place has no memory. What version was live last Tuesday? Who changed it? An S3 feed cannot answer either question, and those are the only two questions auditors ask.

Rollbacks that leave no trace

The 2 a.m. hotfix overwrote the bad build and nobody wrote anything down. Untracked rollbacks are exactly the events an auditor most wants to see, and exactly the ones DIY pipelines lose.

How it works

Ship the way you already ship

Publish through the API, the CLI or the GitHub webhook. Every release is recorded immutably with its actor: a person by email, or a named API key for CI.

Control rollouts, get evidence free

Stage percentages, pause, promote or roll back from the console. Every control action is appended to the log the moment it happens, with actor, IP and timestamp.

Answer from one screen

When the question comes, open the audit page, filter, and read the answer. What a device was offered on any date is reconstructable because releases are never edited in place.

one audit log entry

{
  "action": "release.rolled_back",
  "actor": { "type": "user", "label": "priya@acme.dev" },
  "subject": { "type": "release", "version": "2.1.0" },
  "meta": { "channel": "stable", "reason": "status -> rolled_back" },
  "ip": "203.0.113.7",
  "createdAt": "2026-07-14T18:22:41Z"
}

The audit page in the console is filterable and paginated; entries look like this. No setup, it's on for every organization from the first action.

Append-only by construction

Every publish, ramp, pause, rollback and API-key use lands in an append-only log with actor, IP and timestamp. Rows are never updated or deleted by application code, and they survive the deletion of everything they describe.

Immutable releases

A published version is never edited in place. Fixing a bad release means an audited rollback plus a new version, so what any device was offered on any date is always reconstructable.

Attributable automation

CI publishes with an API key that is hashed at rest and shown once. Every action it takes is attributed to that key by name in the log, so 'the pipeline shipped it' is an answer with a paper trail.

Point one device at one URL.

Publish one release through Relayer and the trail starts itself. Free while in beta.

Start free