BYOR Pipeline

SCADABLE doesn't host your firmware source. You keep your own GitHub repo, you write your own firmware, you push tags. SCADABLE clones at the tag SHA, builds in the right ESP-IDF container, signs the artifact, and publishes a release your fleet can pull.

We call this BYOR — bring your own repo.

The full loop

git push --tags
    │
    ▼
GitHub webhook (push event with vX.Y.Z tag)
    │
    ▼
service-builder clones at the tag SHA
    │
    ▼
Resolves .scadable/config.toml → picks ESP-IDF container
    │
    ▼
Runs idf.py build for the declared target (esp32 / esp32-s3 / ...)
    │
    ▼
Signs the artifact with the namespace's release key
    │
    ▼
Uploads to the SCADABLE CDN
    │
    ▼
Publishes a Release in the dashboard
    │
    ▼
Fleet receives SCADABLE_EVT_OTA_AVAILABLE on next broker handshake

End-to-end on a cold cache: 2 to 4 minutes. Incremental (cached layer for your IDF version): under 90 seconds.

Pages in this section

• Starter templates: forkable repos pre-wired for libscadable. Fastest path to first release.
• Custom firmware: writing your own firmware that links libscadable from a non-template repo.
• OTAs and rollouts: how releases get applied to devices, rollback semantics, staged rollouts.

What you control

Everything inside your repo. SCADABLE doesn't read your code beyond what's needed to build it; doesn't open PRs; doesn't push commits. The GitHub App is read-only on Contents (clone source) and receives push / release webhooks. See Connect a Repository for the permission detail.

What SCADABLE controls

• Build environment. The ESP-IDF container is pinned per target. You can't override the IDF version (yet); the build uses the version declared in .scadable/config.toml if you set one, or the latest stable IDF for your target.
• Signing. Artifacts are signed at build time with a per-namespace key managed by SCADABLE. Devices reject unsigned or wrong-signature artifacts at OTA-apply time. The signing key never leaves SCADABLE.
• CDN. Artifacts are served from cdn.scadable.com over HTTPS. Devices fetch via the URL embedded in the OTA notification.

What you don't have to think about

• Build infrastructure. No GitHub Actions to maintain, no self-hosted runner.
• Artifact storage, signed URLs, CDN.
• Cert provisioning at flash time (handled by the web flasher).
• Release rollback (bootloader's A/B scheme handles it — see OTAs and rollouts).

What's not in BYOR yet

• Custom build steps. No Dockerfile or pre-build.sh honored today. File an issue if you need a non-IDF step.
• Per-PR builds. Only tags trigger builds.
• Multi-target single-tag. One tag = one target. Push two tags for two chips.
• In-place release editing. Cut a new tag instead.

Where to look when something breaks

• Build failed. Releases view in the dashboard has the build log. Most common: .scadable/config.toml schema error (SCAD_E0xxx).
• Build succeeded but devices don't see it. Devices receive the OTA notification on reconnect; offline ones catch up on next online.
• OTA fails on the device. Almost always signature or partition-size. See Troubleshooting.