Releases: rosterloh/raptor
Release list
v1.0.0
raptor 1.0.0 — a hawkBit-compatible OTA update server in Rust. One binary, one config file.
What 1.0.0 means
The hawkBit compatibility surface is now a contract rather than a moving target. Stock DDI clients — SWUpdate, RAUC hawkbit-updater, Zephyr's hawkBit module, hawkbit-rs — work against raptor unchanged, and the wire format they depend on is frozen for the 1.x series: JSON field names, the paging envelope, error bodies, and the DDI link structure. Everything still on the roadmap is additive.
If you are already running 0.9.0, this release is a version bump plus the changes below. There are no breaking changes and no manual migration steps — schema migrations run at startup as usual.
Since 0.9.0
DDI compatibility pass (#39–#44). Six fixes found by running Zephyr's hawkBit client against raptor:
- the confirmation flow no longer strands clients that don't implement
confirmationBase— they would otherwise poll forever without installing. The flow stays off by default, andauto_confirm_defaultauto-confirms newly registered targets when you do turn it on configDatais advertised only until the device has reported its attributes, instead of on every poll (Zephyr was re-uploading every cycle)- artifact
download-httplinks carry plain HTTP rather than inheriting the request's scheme - the device address (
ipUri) is recorded from controller polls, so the target list shows where a device last called from - the
DEFAULT-tenant constraint in emitted links is documented and guarded - a Zephyr integration guide with a per-feature compatibility matrix
All four hawkBit action types (#4). forced, soft, downloadonly, and timeforced. A timeforced action starts soft and escalates when its deadline passes; downloadonly forces the download and never asks the device to install. Operators can escalate a running action with PUT /rest/v1/targets/{controllerId}/actions/{actionId} and force-quit an unresponsive one with DELETE …/actions/{actionId}?force=true. Rollouts carry an action type too.
Server-side dashboard statistics (#38). The web console's counter tiles read GET /rest/v1/system/statistics instead of tallying a page of targets and actions in the browser, so they stay correct on fleets larger than the old 500-target fetch. The dashboard also gained a read-only System configuration card showing the tenant config devices see — polling interval, confirmation flow, and the enabled authentication modes.
Dependencies. SeaORM 2.0, base64 0.23, and the usual minor/patch sweep.
Installing
Download raptor_1.0.0-1_amd64.deb below:
$ sudo dpkg -i raptor_1.0.0-1_amd64.deb
$ printf 'yourpassword\n' | raptor hash-password # put the hash in /etc/raptor/config.toml
$ sudo systemctl start raptorThe package does not auto-start on install: the shipped config carries a placeholder password hash, so edit /etc/raptor/config.toml first. The packaged binary includes the embedded web console at /ui.
From source:
$ cargo build --release # server only
$ cargo build --release --features embed-ui # with the web console (needs `dx build --release --package raptor-ui` first)What's in the box
DDI v1 in full — polling, deploymentBase, the feedback state machine, cancelAction, configData, installedBase, resumable Range downloads, .MD5SUM, auto-registration, and the confirmation flow. On the Management API: targets, software modules with multipart artifact upload, distribution sets, actions, rollouts with deploy groups, target filters with auto-assignment, types, tags, metadata, and FIQL q= filtering across the list endpoints. SQLite or Postgres, a content-addressed artifact store, optional OpenTelemetry export, and an optional embedded web console.
Not in 1.0
Tracked as issues and additive when they land: maintenance windows (#7), multi-assignment with action weights (#10), rollout approval (#17) and dynamic rollouts (#18), S3 artifact storage (#20), multi-tenancy (#12), mTLS/OIDC and multiple operator accounts (#13), quotas and action cleanup (#14), and the DMF/AMQP device path (#11). The web console also still trails the API in a few areas (#25, #34–#37).
Full documentation is in docs/ as an mdbook — start with hawkBit compatibility for the authoritative feature matrix.
Full changelog: v0.9.0...v1.0.0