hawkBit Compatibility
raptor implements a subset of hawkBit, chosen to cover the device update workflow first. This page is the source of truth for what exists today.
Baseline: this matrix is measured against hawkBit 1.x. hawkBit reached 1.0 in April 2026 and 1.1.0 in July, removing some features along the way — rows below reflect that, not the older 0.x contract.
Device API (DDI v1)
The DDI v1 contract is implemented field-for-field and verified with golden fixtures and an end-to-end test against a real hawkBit DDI client.
| Feature | Status |
|---|---|
Poll root, config.polling.sleep, _links | ✅ |
deploymentBase (download/update modes, chunks, artifacts) | ✅ |
Chunk part from module type (application → bApp, os/firmware → os, runtime → jvm, custom keys as-is) | ✅ |
| Deployment feedback state machine | ✅ |
cancelAction + cancel feedback | ✅ |
configData (attributes: merge / replace / remove) | ✅ |
installedBase | ✅ |
Artifact download with HTTP Range (resume, multi-range multipart/byteranges) | ✅ |
.MD5SUM companion endpoint | ✅ |
| Auto-registration (gateway token / anonymous¹) | ✅ |
confirmationBase confirmation flow | ✅ |
Maintenance windows (deployment.maintenanceWindow) | ✅ |
| DMF (AMQP) device path | ❌ (#11) |
pollingTime RSQL-matched overrides (hawkBit 0.10) | ✅ |
¹ hawkBit 0.8 removed anonymous controller support and anonymous download. raptor keeps anonymous mode as a raptor extension (useful for dev/lab setups), not a hawkBit 1.x compatibility item — see the Auth table.
Management API
| Area | Status |
|---|---|
Targets CRUD, assignedDS, installedDS, actions, attributes | ✅ |
| Software modules CRUD + multipart artifact upload/list/download/delete | ✅ |
| Distribution sets CRUD + module composition | ✅ |
| Actions (per-target and fleet-wide list/filter) | ✅ |
| Rollouts (create/start/pause/resume/stop/delete, deploy groups) | ✅ |
| Target filters + auto-assignment | ✅ |
| Per-target auto-confirm | ✅ |
FIQL filter targets by auto-confirm status (autoConfirm==, hawkBit 1.1) | ✅ |
Target groups (group attribute, q=group==) | ✅ |
Paging (offset/limit), sort=, q= FIQL on lists | ✅ |
Software-module / distribution-set / target types CRUD (composition drives complete; target-type/DS-type compatibility enforced) | ✅ |
Target / distribution-set tags CRUD, assign/unassign, q=tag==x | ✅ |
Metadata endpoints (targets / modules / DS, targetVisible on module entries) | ✅ |
All four action types + force escalation (PUT .../actions/{id}) and force-quit (DELETE ...?force=true) | ✅ |
Rollout approval workflow (rollout_approval_enabled, approve/deny with remark; raptorctl rollout approve|deny) | ✅ |
Dynamic rollouts (dynamic, dynamicGroupTemplate; trailing group absorbs newly-matching targets, rolls over at capacity, never self-completes) | ✅ (amountGroups: 0 “pure dynamic” rollouts, with no static groups at all, are not accepted — #147) |
| Maintenance windows on direct assignments | ✅ (hawkBit’s own Management API has no maintenanceWindow field on rollout creation or target-filter auto-assignment to be at parity with — see #116) |
Per-entity quotas ([quota], hawkBit’s defaults, 429 on breach) | ✅ |
Automatic action cleanup ([cleanup], action.cleanup.auto.*) | ✅ (raptor additionally keeps rollout progress stable across a sweep, which upstream does not) |
Release retention ([retention] keep_releases: keep the newest N sets per name, hard-delete older ones and their artifacts) | raptor extension; hawkBit has no equivalent |
| Multi-assignment / action weights | removed upstream in hawkBit 0.10; not planned (#10) |
Wire-format alignment with hawkBit 0.10: successful deletes return 204 No Content — raptor’s mgmt delete handlers already do. Quota violations return
429 with hawkbit.server.error.quota.tooManyEntries, which raptor matches —
see the [quota] section.
Action types
hawkBit has forced, soft, downloadonly, and timeforced. raptor models all
four. timeforced starts out soft and escalates once its deadline passes;
downloadonly forces the download and never asks the device to install. An
operator can escalate a running action to forced with
PUT /rest/v1/targets/{controllerId}/actions/{actionId}, and force-quit one that
the device is not acknowledging with DELETE …/actions/{actionId}?force=true.
Auth
| Mechanism | Status |
|---|---|
| DDI target security token | ✅ |
| DDI shared gateway token | ✅ |
| DDI anonymous mode (raptor extension¹) | ✅ |
| Management API HTTP Basic (single admin) | ✅ |
| Session cookie for the web console | ✅ |
| mTLS / certificate DDI auth | ❌ (#13) |
| Multiple users / roles, OIDC | ❌ (#13) |
Tenancy
raptor is single-tenant (#12).
It answers to exactly one tenant on the DDI URL’s /{tenant}/controller/v1/...
segment — the tenant config key, default DEFAULT — and rejects any other
segment with 404, matching hawkBit’s own behavior. There is no per-tenant
data isolation — run one raptor instance per fleet. The schema does carry a
tenant column on every query-root table so isolation can land later without
a migration; see the
design doc.
Note: Items marked ❌ link to their tracking issue on the GitHub repository. The schema is designed so these can be added without breaking existing deployments.