OTA firmware platform

Samfrevolt OTA

Fleet-ready firmware updates for embedded devices. Stop creating temporary file links, manual scripts, and fragile OTA backends from zero. Upload releases, manage channels, and let deployed devices check for updates through a structured server.

3release channels
Ed25519firmware signing
<50msmanifest response
fleet-control / solar-cooker
Fleet overview
Stable rollout is active and signed
online
Devices
128
Updating
12
Offline
4
Firmware v2.4.1 / stable
mandatory: false
Rolling out to 96 devices 78% complete
# DEVICE-4421 polling firmware update
GET /ota/check?channel=stable
200 update_available=true
SHA256 verified before flash
OK rebooting into v2.4.1

From release to device

Upload
firmware
> Publish
channel
> Devices
update

See the OTA platform in motion.

Watch how the service is presented from the embedded developer point of view: the problem with manual updates, why simple links are not enough, and how Samfrevolt OTA gives projects a fleet-ready firmware update flow.

Start for free See workflow
samfrevolt-ota-demo.mp4
96 sec overview Embedded OTA Fleet ready

Manual OTA works once. Fleet updates need discipline.

Hobbyists, freelancers, and small teams often start with quick OTA shortcuts. The pain starts when devices are installed, customers are waiting, and firmware versions begin to drift.

USB

Manual flashing does not scale

USB updates are fine on a desk. They become expensive when devices are remote, sealed, or already with a customer.

URL

Temporary links are fragile

Basic file hosting does not give you release history, device targeting, channels, rollout state, or firmware integrity.

API

Custom backends take time

You can build OTA infrastructure yourself, but your time is better spent improving the product firmware and hardware.

A ready OTA backend for real embedded projects.

Samfrevolt OTA gives you the server-side structure around firmware releases, while your device keeps control of the actual flashing logic.

Fleet Cloud OTA
01

Project isolation

Each product has its own dashboard, admin access, device API key, releases, channels, and logs.

Release channels
02

Release channels

Publish firmware to stable, beta, or dev so test devices and production devices do not receive the same update.

Hardware targeting
03

Hardware targeting

Serve different firmware to different PCB or hardware revisions while keeping one organized project.

Firmware integrity
04

Firmware integrity

Use SHA-256 verification and Ed25519 signing on paid plans to protect firmware identity.

Staged rollouts
05

Staged rollouts

Start with a percentage of the fleet, monitor behavior, then increase rollout when you are confident.

Device API keys
06

Device API keys

Devices authenticate with a project key, and credentials can be rotated from the dashboard.

Edge OTA
07

Wi-Fi, Ethernet, GSM, cellular

Use the same OTA server with Wi-Fi devices, wired Ethernet (W5500 PoE), SIM7600-style cellular designs, loggers, controllers, and sensors.

Fleet visibility
08

Fleet visibility

See update checks, downloads, device versions, and release adoption instead of guessing what is deployed.

Device identity
09

Device identity protection

Hardware fingerprint binding, version regression detection, and concurrent clone detection prevent spoofed or duplicated device identities.

Provisioning
10

Security notification inbox

Every security event — new device, suspected clone, identity lock — lands in a per-project inbox.

11

Device provisioning

Pre-register a device's identity before it ships. The server recognises it on first contact. Combine with strict mode to block any unregistered device entirely. Available on paid plans.

12

Configurable security rules

Each security check — hardware ID binding, version regression lock, clone detection, strict mode — can be toggled per project. Turn off what does not fit your hardware; leave the rest on by default.

The device only asks one question: do I need an update?

The server answers with a clear manifest. Your firmware decides when to download, verify, flash, and reboot.

1

Upload a firmware release

Add version, hardware revision, release notes, and channel.

2

Publish when ready

Keep drafts hidden until the release is signed, checked, and approved.

3

Devices poll the manifest

Each device sends project, channel, hardware revision, current version, and API key.

4

Download and verify

The firmware downloads the binary and verifies hash/signature before applying the update.

Manifest response application/json
{
  "update_available": true,
  "version": "2.4.1",
  "channel": "stable",
  "hardware_rev": "rev-a",
  "mandatory": false,
  "sha256": "9f3c...b71a",
  "size": 1048576,
  "download_url": "https://samfrevoltota.com/..."
}

From hobby prototype to deployed device fleet.

The platform is simple enough for makers, but structured enough for freelancers and small companies that need version control, client confidence, and repeatable firmware operations.

Samfrevolt OTA fleet dashboard
HobbyistsAvoid rebuilding a full OTA backend alone. Test your update flow with a free project.
FreelancersDeliver a professional update process to clients instead of asking for physical access to every device.
DevelopersManage releases, channels, device versions, and rollouts from a single web dashboard.
Small teamsStart with one project, then grow into fleets without changing the update server.

Simple plans for prototypes and fleets.

Start free. Pay when you need fleet features. No per-device charge on paid plans.

Free OTA plan
Free
€0forever

For testing an OTA flow and validating your first device integration.

  • 1 project
  • 3 OTA update slots lifetime
  • Unlimited devices
  • Stable channel only
  • Project goes inactive after 3 versions served
Start free
Lifetime OTA plan
Lifetime
€75per project · one-time

For long-running embedded projects where you want the same features without renewal ever.

  • Everything in Annual
  • No annual renewal fee
  • Project lives forever
  • All future paid features
Buy lifetime

Embedded firmware, hardware design, and OTA systems.

Samfrevolt is built around real embedded work: firmware, PCB and hardware support, IoT integration, test tools, device logging, and remote update workflows. OTA is one part of the larger mission: help makers, freelancers, and teams move from prototype to reliable connected product.

Need help integrating?

If you need ESP32 OTA code, GSM update logic, firmware architecture, or hardware debugging, you can contact Samfrevolt for engineering support.

Create account Contact

Questions developers ask before trusting OTA.

It hosts your firmware files and tells your devices when a new version is available. Your device asks the server if it needs an update, then receives a manifest with version, hash, channel, and download URL.
Yes. Your device still controls download, flash, verification, rollback, and reboot behavior. Samfrevolt OTA provides the backend, release management, manifests, hosting, and fleet organization.
Yes. Any device able to perform HTTP or HTTPS requests can check for updates. ESP32 Wi-Fi, wired Ethernet (W5500 PoE), and cellular devices all work with the same server — the OTA library is fully transport-agnostic.
One project, up to two devices, and the stable channel. It is enough to validate the OTA flow before scaling.
Instead of releasing to every device at once, publish to a percentage of the fleet first. Increase the rollout when the update looks healthy.
The device stays on its current firmware and retries later. A failed update check should not interrupt a running device.
The server tracks every device that checks in. It binds the hardware fingerprint (hw_id) on first contact and locks the device if the fingerprint changes — catching the most common cloning attempt. It also detects version rollbacks and simultaneous check-ins from two different IP addresses within 30 seconds. Locked devices stop receiving updates until an admin resets them.
The server locks the device identity and returns update_available: false with a device_locked flag. A notification appears in the project inbox so the admin knows. The real device can be unlocked by resetting its identity record — this rebinds its hardware fingerprint from scratch.
Yes, on paid plans. Device provisioning lets you register a device's expected ID and hardware fingerprint before it reaches the field. The server recognises it on first contact and you get a notification. Combined with strict mode, any device not on the list is blocked immediately — useful when shipping to clients and wanting to control exactly which units can receive updates.
Yes. Each rule — hardware ID binding, version regression lock, clone detection, strict mode — has its own toggle in the project security settings. All checks are on by default. If your hardware does not expose a stable chip UID, disabling hardware ID binding still leaves the other protections active.

Have a project or integration question?

Reach out for OTA access, firmware help, hardware support, or embedded product advice.

OTA platform demo
Click video to toggle sound 🔇