heliograph

Run it on the machine you cannot reach

Heliograph Cloud sends your steps across an access boundary, runs them on the far side, and brings back the whole log. If a log cannot be shipped the run says so and names it, rather than going quiet. No inbound port, no VPN, no credential of yours on their machine. The station that runs on their machine is published, so the thing they are being asked to install is a thing they can read.

The round trip you are paying for

Somebody else operates the estate. You know what to run; they can reach it. So the work goes back and forth as instructions in a chat window and screenshots of output, and the record of what ran is whatever somebody remembered to paste.

What you get back

Each run is captured as it was produced and kept that way. Afterwards there is a record of what ran, where, and what came back, searchable and exportable, which is the thing you are buying.

edge-04 collect-diagnostics pushed back over git
09:14:02step accepted collect-diagnostics station edge-04
09:14:02+ systemctl status app.service
09:14:03 Active: inactive (exit-code) since 09:11:58 UTC
09:14:03+ terraform plan -no-color
09:17:15nothing was produced here. this is the answer.
09:17:15 Error: timeout while waiting for the state lock
09:17:16ended state: stopped 1842 lines captured
A synthetic run, written for this page. The three minutes between 09:14:03 and 09:17:15 are the point: a command that produced nothing is a finding, and it only exists if the whole run came back.
Two heliographs across a dark valley at night, with an unbroken train of light travelling between them. In the foreground a panel headed LOG shows timestamped rows of output, then a conspicuously empty band, then more rows. A measuring rule runs down the panel unbroken through the empty band.
The link is unbroken and the record is not. Time keeps being measured through the empty band while nothing is captured in it, and that disagreement is the whole of what a gap tells you. Nothing here is coloured as a warning, because the record establishes that nothing was produced and not why.

Why they will let you

The protocol, the CLI and the station are public, and a station on a customer's machine runs code that customer can read. Payload content is end-to-end encrypted and moves only through published components. The proprietary broker handles account, topology and authorisation metadata and can permit, deny or route a connection; it takes no part in the fingerprint comparison that pairs two ends, which happens out of band between two people.

Two heliographs on opposite ridges of a dark valley. Light travels left to right labelled you publish, then station fetches, and a second beam travels right to left labelled timestamped log. Panels read STEP disk-audit declared read-only, and LOG with timestamps. A strip by the far instrument reads action permission set at station start.
Two ends, and no wire between them. The operator starts their own station with their own flags, which is why the permission to take actions is drawn as a property of their machine rather than as something a request carries.

The licensing boundary, in full

What is true today, with its condition

  • A station verifies against a signed trusted set and publishes that set, so a key nobody authorised is detectable. Detectable rather than prevented, and on a beacon revocation is eventual.
  • The longest a revoked authorisation can still work is 15 minutes, proved by a test that revokes and then steps a clock.
  • Both relay implementations build reproducibly, and a stranger can rebuild the published hash themselves. Nothing is signed yet, and no deployed hash has been compared against a build.

The source a station and a control node run

Try it

If there is an estate you cannot reach, read the source, then try it against one machine.

Early access. The console works and an account can be created; the instruments have not been reviewed by a solicitor yet, so read the terms before you rely on it.