Pilot Program

Test carefully before calling anything supported.

RelayHub pilots will help test local-first communication, onboarding, recovery, trust, documentation, hardware classes, support boundaries, and real community usefulness before wider deployment.

Register interest Community guides

Pilot types

Different pilots test different risks.

A good pilot is small, bounded, observable, recoverable, and honest about what is being tested. RelayHub should validate people, process, documentation, recovery, and hardware — not just connectivity.

Community pilot

A small group tests local-first communication, trust, documentation, recovery, and community coordination workflows.

Household pilot

A household tests appliance-style setup, pairing, local dashboard, recovery, status comprehension, and ordinary usability.

Developer pilot

Developers test RelayOS concepts, future APIs, validation tooling, documentation, and integration boundaries.

Hardware pilot

Builders test hardware classes, boot behaviour, storage, power, thermal behaviour, Reticulum operation, and recovery paths.

Education pilot

Trainers and organisers test workshop material, onboarding guides, recovery cards, and non-technical explanations.

Field pilot

A controlled real-world test of degraded operation, intermittent connectivity, local-only workflows, and support expectations.

Who should apply?

Early pilots need patient, practical testers.

The best early participants are people who understand that pilots are about learning, validation, feedback, and safe improvement — not polished product promises.

  • Community organisers
  • Local resilience groups
  • Households willing to test setup and recovery
  • Reticulum users
  • NixOS users
  • Hardware builders
  • Documentation contributors
  • Accessibility testers
  • Regional community groups
  • People comfortable giving detailed feedback

Pilot pathway

A pilot should have a beginning, boundary, and decision point.

RelayHub pilots should move through clear stages so participants know what is happening, what is being tested, what evidence matters, and what happens next.

1. Register interest

Tell RelayHub who you are, where you are, what you want to test, and what experience or hardware you already have.

2. Scope the pilot

Define the use case, participants, hardware class, support expectations, safety boundaries, and success criteria.

3. Prepare materials

Prepare guides, checklists, recovery instructions, status explanations, and feedback forms before testing begins.

4. Run the pilot

Test setup, local-only operation, trust, recovery, documentation, degraded states, and support workflows.

5. Capture evidence

Record what worked, what failed, what confused users, what needs validation, and what must not be claimed yet.

6. Decide next step

Continue, revise, pause, expand, or stop safely based on evidence rather than enthusiasm alone.

What pilots test

Human comprehension matters as much as technical function.

A RelayHub pilot should prove whether real people can understand setup, status, trust, recovery, support, and product boundaries.

  • Can people understand what RelayHub is?
  • Can non-technical users find the first step?
  • Can users complete setup without terminal instructions?
  • Can users explain Ready, Local-Only, No Peers, Degraded, and Recovery?
  • Can recovery be found without internet access?
  • Can trust and discovery be explained clearly?
  • Can support information be shared without exposing secrets?
  • Can participants distinguish current features from planned features?
Validation Accessibility

Pilot rules

Pilots must not create false confidence.

A pilot is a learning and validation activity. It should not be marketed as a supported release, certified deployment, or emergency service.

A pilot is not a product-supported release.

Experimental hardware must be labelled experimental.

Recovery must be tested before expansion.

Support boundaries must be clear before participants rely on the system.

No participant should be told RelayHub provides perfect anonymity.

Radio transmit must not be assumed lawful merely because hardware exists.

Pilot evidence should guide the roadmap.

A pilot may stop safely if the system is not ready.

Current limitations

The pilot programme is not open as a formal release yet.

RelayHub is currently collecting interest and preparing public foundations. Product builds, hardware certification, and formal pilots come later.

  • No public RelayOS images are available yet.
  • No certified hardware programme is active yet.
  • No partner directory is active yet.
  • No formal community federation programme is active yet.
  • No emergency service guarantee exists.
  • No supported product release exists yet.
Status Downloads

Apply for a future pilot

Tell us what you want to test.

RelayHub is looking for practical interest from households, communities, builders, developers, educators, and organisations that understand the difference between a pilot and a supported product.

Useful details

  • Who you are
  • Where you are located
  • Whether you are a household, community, developer, builder, or organisation
  • What you want to test
  • What hardware you already have
  • Your technical comfort level
  • How many people may participate
  • What outcome would make the pilot useful
Register interest Contact RelayHub