BYOR Pipeline

SCADABLE doesn't host your firmware source. You keep your own GitHub repo, you write your own firmware, you push commits. SCADABLE clones at the commit SHA, builds in the right ESP-IDF container, and publishes an artifact your fleet can pull via OTA.

We call this BYOR — bring your own repo.

The full loop

git push
    │
    ▼
GitHub webhook (push event)
    │
    ▼
SCADABLE clones at the commit SHA
    │
    ▼
Resolves .scadable/config.yaml → picks ESP-IDF container by device_type
    │
    ▼
Runs idf.py build inside that container
    │
    ▼
Uploads the firmware artifact to internal storage
    │
    ▼
Publishes a Release in the dashboard
    │
    ▼
You click "Deploy" — backend publishes scadable/<cn>/ota/command to selected devices
    │
    ▼
Library on each device downloads, installs, reboots, validates

Cold-cache build on a small firmware: 2–4 minutes. Incremental: under 90 seconds.

Pages in this section

• OTAs and rollouts: how releases reach devices, the A/B partition apply path, automatic rollback on validation failure.

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 webhooks. See Connect a Repository for the permission detail.

What SCADABLE controls

• Build environment. The ESP-IDF container is pinned per target (chosen by .scadable/config.yaml → device_type). v0.1.0 uses the latest stable IDF v5.x for your target.
• Artifact storage. Built firmware lives in SCADABLE's internal storage. Devices fetch via signed URL when an OTA is dispatched.
• Build droplet lifecycle. Each build spins up a one-shot Docker container (or a build droplet on DigitalOcean) and tears it down after. No long-running CI infrastructure.

What you don't have to think about

• Build infrastructure. No GitHub Actions to maintain, no self-hosted runner.
• Artifact storage and signed URLs.
• Cert provisioning at flash time (handled by the dashboard's web flasher).
• OTA download / install / rollback (handled by the library on the device).

What's not in BYOR yet

• Custom build steps. No Dockerfile or pre-build.sh honored. Stock idf.py build only.
• Per-PR builds. Only commits to the default branch trigger builds (v0.1.0).
• Multi-target single-commit. One commit = one target. Push to two repos with different device_type values for two chips.
• Signed artifacts. v0.1.0 ships unsigned binaries — broker auth is via cert. Artifact signing arrives in v0.2.0+.
• Staged rollouts (percent-based). v0.1.0 you pick which devices to deploy to, one at a time or all at once from the dashboard.

Where to look when something breaks

• Build failed. Releases view in the dashboard has the build log. Common cause: missing or malformed .scadable/config.yaml.
• Build succeeded but devices don't update. OTA is on-demand: you have to click "Deploy" in the dashboard to dispatch. There's no auto-deploy in v0.1.0.
• OTA fails on the device. Almost always partition layout. See Troubleshooting.