Local vs Cloud
The same pairing tokens, worker registration, and client API work whether the control plane runs on your Mac mini or on Relay Cloud. Workers always stay on your infrastructure — Relay routes and authorizes; it does not run your agent workloads.
Deployment modes
| Mode | Control plane | Workers | Typical user |
|---|---|---|---|
| Local (home lab) | Your machine | Your machine(s) | Solo dev, hobbyist, privacy-first |
| Relay Cloud | Our API (api.relay.tinyfactories.space) | Your machines | SaaS builder, multi-site team |
| Enterprise self-hosted | Your VPC (licensed) | Your machines | Regulated / air-gapped org |
Home lab (free, native install)
Run the full stack on your hardware — Relay server, database, workers, and optional menu bar app. Nothing to pay by default. Validates pairing and routing in the real world before you connect to a hosted router.
Relay Cloud (future)
Connect workers to api.relay.tinyfactories.space instead of self-hosting the control plane. Same register/claim API, multi-tenant workspaces, usage metering, and ingress — without operating Postgres, auth, or the job queue yourself.
Relay Cloud is in development. Launch target: free local + Cloud Pro beta once Phase 1 onboarding is solid.
Data boundary
When using a hosted router, Relay sees worker presence, run queue metadata, and hashed tokens. It does not see artifact contents, repo code, or LLM prompts — by design.
| Data | Router sees? |
|---|---|
| Worker presence, backends, capability tags | Yes |
| Run queue metadata (status, required backend) | Yes |
| Worker / client tokens (hashed) | Yes |
| Artifact contents, repo code, LLM prompts | No |
Competitive frame
Relay is closest to self-hosted CI runners plus a job queue, made agent-aware — not LangGraph, n8n, or Cursor. Frameworks are partners; sandboxes use a different trust model; Cursor is a UX benchmark for device linking, not an infra competitor.