From GitHub release to running fleet
Your CI builds the artifact; getting it onto two hundred machines safely is the part that pages someone. LynxTrac pulls release artifacts straight from GitHub and runs the delivery side: staged rollouts, approval gates, and rollback plans.
The division of labor is deliberate. GitHub stays the source of truth for code and builds, while LynxTrac owns what happens between the release and the fleet.
Release artifact ingestion
Point a deployment at a GitHub repository and LynxTrac fetches the release artifacts, no intermediate storage to maintain.
Approval-gated rollouts
Multi-stage release workflows with named approvers. The artifact that passed staging is byte-identical to what reaches production.
Per-device state and rollback
Every endpoint tracks its own pending, in-progress, success, or failed state, and validation failures trigger the rollback plan instead of a half-deployed fleet.
Setting it up
Add GitHub as an artifact source on a deployment, authorize access to the repository, and select the release pattern to track.
Private repositories work through scoped credentials, stored encrypted like all platform secrets.
This is artifact-level integration: LynxTrac pulls what GitHub has built. Native pipeline triggers from GitHub Actions are on the roadmap but not shipped, so today your pipeline finishes by publishing a release, and LynxTrac takes it from there.
Asked about this integration
Does LynxTrac replace GitHub Actions?
Can it trigger automatically when a release publishes?
See it connected to your own account
The free tier covers 2 servers forever, which is enough to wire this up and judge it on your infrastructure rather than ours.