Embroid
Solution

Run real-device checks in CI.

Run real-device validation on pull requests, nightly builds, and releases.

The problem

Unit tests and builds don't prove that firmware works on the device. You only find out after merge — or worse, after release.

Firmware regressions escape to release because there's no cheap way to exercise real hardware in CI. Teams build ad-hoc test rigs that break under maintenance, or skip hardware validation entirely and hope nightly builds catch the problem.

How Embroid helps

Embroid lets CI jobs reserve hardware, flash firmware, run validation sequences, capture logs, and block or approve releases based on physical behavior.

CI reserves an Embroid-managed device, flashes the build, runs the same sequence developers run on their benches, and attaches an evidence record to the run. Gating a PR on hardware behavior becomes as normal as gating it on lint.

Workflow

How CI Hardware Testing works with Embroid

  1. 01A pull request opens.
  2. 02CI builds the firmware artifact.
  3. 03CI requests an Embroid device lease tagged for this workflow.
  4. 04Embroid flashes the target with the new build.
  5. 05Embroid runs a validation sequence (serial assertions, power checks, GPIO triggers).
  6. 06Serial logs and assertions are captured as the run proceeds.
  7. 07An evidence record is attached to the CI run.
  8. 08CI passes, fails, or flags for human review — the device returns to the queue.
Outcomes

What teams get from CI Hardware Testing

  • Gate PRs on real-device behavior, not just build success
  • Add on-target tests to nightly and release pipelines
  • Fail loudly and early — with reproducible evidence
  • Feed structured failure data back to the author (human or agent)
Products used

Which Embroid product fits this workflow

Embroid Client

Fine for local CI experiments on a developer's workstation.

Explore Client
Embroid Basic

The sweet spot for one always-on CI bench — local queue, one active lease.

Explore Basic
Embroid Pro

For shared validation labs with parallel jobs, scheduling, and resource locks.

Explore Pro
Platform capabilities

Built on these parts of the platform

Example evidence

What the record looks like

Every CI run produces a signed session record: firmware hash, target tag, operator (the CI actor), all commands, all log lines, and pass/fail per assertion. Pin it to a release tag and you have reproducible proof of what shipped.

Implementation path

A realistic rollout

Week 1

Install Basic on one validation bench and verify local runs.

Week 2

Wire GitHub Actions or GitLab CI to request Embroid leases; port one smoke test.

Week 3+

Add parallel validation, nightly sequences, and release gates. Consider Pro for shared labs.

CI Hardware Testing

Make this workflow real on your hardware.

Share your setup. We'll help you pick the right Embroid product and get you to a first working run.