Skip to main content
Local flash lets any client — a native app, a CLI, or a web app with a local agent — deliver firmware to devices over USB or serial. This section covers third-party apps and tools that flash devices locally. The client requests a signed image from Firmngin, verifies it, and flashes the connected device. It does not need a Firmngin login: you create a scoped API key in the dashboard once, and the client uses it to request short-lived download tickets. This guide uses a desktop app as the running example. The desktop app is only an example, not a requirement: the same API works for a CLI, a factory tool, or a web app that hands the flash to a local agent. Web apps can use the same API through a backend or a local agent. A browser cannot flash a device by itself. See Client patterns for native, backend, and local-agent flows.
Local flash is different from cloud OTA. Cloud OTA pushes an update through Firmngin and the device pulls it over MQTT. Local flash is for devices that are physically connected to the app.

​
How it works

The report is advisory. It records what the app observed, but it does not update the device’s authoritative firmware status. Device-origin events remain the source of truth.

​
Artifact code binding

An API key can optionally be limited to specific artifact codes. Leave Artifact codes empty in the dashboard to allow every artifact code in the workspace. This keeps existing integrations working without a binding.

​
What you need

​
Supported endpoints

Building a web app? Read Client patterns before putting an API key anywhere near the browser.

​
Next steps

API reference

Endpoints, request bodies, responses, and error codes.

Security model

Tickets, signature verification, temp files, and advisory reports.