Images and signatures

Helix is delivered as container images, not as files to download. The image carries everything a node runs — the Helix services, the web application, the Spiral optimiser and its travel engine — and the launcher, helixctl, that installs and starts it. The road data for the travel engine is published as images too.

Note

The trial executables and the example files this page used to offer (spiral.l64, spiral.exe, spiralTravelOSRM.l64, an example map and domain, an OSRM tar) are retired. Spiral now runs inside the image — for a system that used to call spiral.l64 itself, the spiral and spiralOnly commands are the drop-in — and the demos (Breakdown, Blue Light, Rail) are the working examples of a domain and a map.

The images

All are in registry.gitlab.com/honeywick-consulting/helix/.

Image	What it is
helixcore:<version>	A release of the Helix core, e.g. helixcore:0.0.18 — what a client deploys and what a security review assesses.
helixcore:<version>-dev	The same image plus npm, for building a client’s own extension inside a container (helixctl start dev, helixctl release). Not for production.
helixcore:latest, helixcore:sdk-<minor>	Floats that follow the newest release (for one client SDK minor). A client pins an exact version instead.
osrm:<country>-latest, osrm:<country>-<osrm>-<date>	The preprocessed road network for the travel engine, one image per country.

You do not normally pull them by hand: helixctl pull (or install) fetches the pinned core and the road data the node’s travel calculator names — see Versions and upgrades and travelCalculatorObject.

Verifying a release

Every release image — the core and its -dev overlay — is signed with Honeywick’s key, by digest, using cosign. Its software bill of materials (CycloneDX) is attested with the same key, so the parts list is provably the one for that image. Pre-release test cores (a letter after the version, such as 0.0.18a) may be unsigned; a release never is.

The public key — helix-release.pub:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEkfZqZ555RQzfxTnmtNQfxmuiRoB
qvnIIWskAKlRUpskILnW/bU+KTSFKZNyO/uvpE5dZA7nD2gT9jdk2E3d7g==
-----END PUBLIC KEY-----

Check the signature, and the SBOM attestation, for the image you are about to run:

curl -fsSO https://honeywick.co.uk/helix-release.pub
cosign verify --key helix-release.pub registry.gitlab.com/honeywick-consulting/helix/helixcore:0.0.18
cosign verify-attestation --key helix-release.pub --type cyclonedx \
       registry.gitlab.com/honeywick-consulting/helix/helixcore:0.0.18

cosign verify prints the digest the tag resolves to. The digest is the identity: a tag can be moved, a digest cannot, so a review signs off the digest, and a node pinned by digest runs exactly what was reviewed. The signature is a separate artefact in the registry; the image’s own bytes and digest are unchanged by signing, so any container runtime Helix supports pulls them as before.

Related

• Versions and upgrades
• Development Plans