Cyber resilience by design, not by retrofit.

Resilience. A microkernel that stays small and stable. Plugins that can fail without bringing the rest down. An event bus the system uses to observe itself and recover without ceremony. Compile-time safety properties so the kinds of bugs that normally let attackers in (a forgotten permission check, an unredacted prompt going out to an LLM, an AI verdict promoted without a human signature) are caught by the Rust type system before the code ships. They become build failures, not production breaches.

Usability under pressure. Day-to-day usability matters. Under-pressure usability matters more. Fleet is the system an operator reaches for when they are pushing emergency updates during an active attack, when the dashboard is the difference between containment and escalation, when wrong clicks have real consequences. The interfaces, the flows, the amount of thinking required at each step are all designed for that moment, not the calm one.

And the operator should not be thinking about documentation while the fire is still burning. When Fleet detects an incident, a black box opens. Every action, every decision, every system response, every artefact gets captured automatically. The operator's job is to put the fire out. Fleet's job is to keep the record that protects them afterwards. Liability cover. Insurance cover. The evidence a notified body wants to see when they ask what happened. None of it asks the operator to remember to write anything down.

Compliance as consequence. The CRA and every other regulatory framework Fleet reaches codifies what auditors and regulators have learned about how things actually break. A system genuinely built to keep working through breakage, and to let its operators stay effective under pressure, will look conformant to those frameworks without trying. It will also adapt as the frameworks evolve, because nothing in the design is bolted to a fixed version of any of them.

The kernel and the plugins

Kernel. Two small, stable crates. fleet-bus is the broadcast relay: at-most-once delivery, subscribers persist their own jobs. fleet-core holds the shared primitives every plugin needs. Types, auth middleware, db connection pools, principal threading, config, error types. No domain logic. The interface freezes early and changes slowly.

Update-server. fleet-update is the original product. Release management, applications, downloads, assets, users, billing, S3, notifications, GitHub webhooks, SBOM, scans, findings, evidence. It publishes events to the bus; everything else subscribes. It owns the fleet_core database. This crate ships alone as the lean update-server-only product.

The plugins

The event bus

The API contract between the update-server and the plugins. fleet-update publishes release.published, scan.completed, release.deleted, and so on. Plugins subscribe to the events they care about. The bus is the only way plugins learn about update-server state changes. No plugin queries fleet_core.

What β gives you that γ doesn't

• Failure isolation. If fleet-core-pg goes down for maintenance, the plugin tier doesn't crash. If fleet-plugins-pg goes down, the update server keeps shipping releases; CRA workflows pause but core distribution continues.
• Independent backup regimes. fleet-plugins-pg carries the 10-year CRA retention burden; it can be on cheaper, slower disk with daily snapshots to cold storage. fleet-core-pg can be on fast disk with continuous WAL streaming for low RPO.
• Independent scaling. The plugin tier handles audit-chain writes for every advisor consult; it can be scaled independently of the update server.
• Provable isolation for regulators. A notified body asking "where does the audit chain live, who can write to it?" gets a one-sentence answer: a separate database on a separate host that the update-server cannot reach.

Migration γ → β is config-only

The application is already written assuming the two pools are independent. Migrating γ → β is operational, not architectural:

• Stand up fleet-plugins-pg host
• pg_dump fleet_plugins | pg_restore to the new host
• Switch FLEET_PLUGINS_DB_URL to point at the new host
• Restart Fleet
• Drop the old fleet_plugins database from the original host

Total downtime: minutes. Zero application code changes.

Cybersec. Three deployment modes from one crate.

Vulnerability data exists in two real-world forms, and the architecture supports both as deployment modes of the same fleet-cybersec plugin:

One crate. Mode selected via FLEET_CYBERSEC_MODE=local|managed|hybrid. The interface exposed to fleet-cra is the same regardless of mode. fleet-cra does not know or care where the CVE data came from.

Regulatory frameworks. CRA is the first, not the only.

The architectural shape of fleet-cra is the shape of every regulatory framework. Same components (requirement catalogue, workflow state machine, evidence collection, retention policy, reporting deadlines) bound to different jurisdictional specifics.

Architectural posture. Credentials for critical infrastructure.

Fleet's architectural choices were made before the Hajj framework crystallised. They have continued to line up with it as it has developed, not because they were retrofitted to match. The credentials a critical-infrastructure pitch should cite:

• Zero cryptographic signing keys on the server. A server breach does not enable forgery, only replay of what the developer has already signed. Signing key material lives in the developer's CI environment, never on the Fleet server.
• Rigorous dependency-reduction workflow. 542 audited crates, 4 banned in deny.toml, 2 vendored. Hand-written S3 client replacing approximately 10,000 lines of third-party code. cargo audit and cargo deny green.
• TLS termination outsourced to a purpose-built reverse proxy rather than handled in-process. rustls in-tree; OpenSSL banned at the dependency policy level.
• CRA Article 23 ten-year retention already encoded in the evidence schema (migration 004, enforced by 006).
• On-premises only. No freemium hosting. The customer owns the distribution data. Fleet deploys natively inside air-gapped networks, with no outbound calls in the core delivery path.

Hajj scenarios A–E. Fleet's support.

Hajj common requirements: R-SU-2, R-SU-3, R-SU-4

A moving target, and Fleet's posture toward it.

The Hajj framework v02 (April 2026) is not the final word. The prEN 40000 series is in active drafting. The CRA's vertical standards are being shaped in working groups across the EU. ENISA guidance shifts. Notified bodies are still calibrating their assessment criteria. This is normal for regulation reaching a market this large.

Fleet's posture toward the moving target:

• Continuous measurement against the latest published version. Currently Hajj v02. Every new draft and guidance release is reviewed within the development cycle that follows it. The internal source-verified inventory gets re-run against the new criteria.
• Architecture engineered to absorb framework evolution. The kernel and plugin shape means regulatory plugins (fleet-cra, fleet-soc, and the rest) can be revised independently of the update server. The compliance kernel (advisor, audit chain, Ed25519 signing) is framework-agnostic. It serves whatever workflow each plugin requires.
• Conformance evidence structured for re-assessment. Audit records are immutable and retention-policy-tagged. When the standards shift, prior assessments don't have to be regenerated. They get re-validated against the new criteria.

Fleet's bet is on infrastructure that moves with the standards rather than freezing against any single snapshot of them. The moving target is treated as a feature of the operating environment, not a bug to wait out.

What this means for customers.

The update server is not a turn-key path to CRA compliance. CRA conformance is the manufacturer's responsibility under Module A, and the standards governing it are still being written. What Fleet provides is the distribution infrastructure CRA-aligned operations require. An architecture built toward Hajj's framework as it gets written. Re-measured against the latest published draft. Deployed on-premises, within the customer's own control.

Plug Fleet into a CRA-aligned product process and the digital-distribution leg is well-served by the architecture. The evidence trail Fleet produces (release artefacts, signature provenance, SBOMs, audit chain) is what a notified body wants to see today, and what re-validates cleanly as the assessment criteria mature.