The browser and API manage organisations, uploads, analysis requests and reports. Background workers process queued jobs, reading firmware from the selected storage service and writing results to the application database. A separate controlled execution path runs supported dynamic work. Hosted and on-premises installations use the same logical responsibilities, with different operators and external connections.
01 · Browser → frontend / API
Authorised uploads, sign-in, review and exports over TLS.
02 · API → records and storage
Organisation records in PostgreSQL; firmware and artifacts in approved storage.
03 · Queue → analysis workers
Background extraction, identification, checks and report generation.
04 · Workers → runtime sandbox
Supported emulation and fuzzing under resource and network restrictions.
05 · Results → reviewer
Findings, coverage and evidence returned for human decisions.
06 · Optional connections
Identity, feed updates, monitoring and notifications: permit explicitly or provide local alternatives.
Hosted: Magdox operates the agreed platform. On-premises: these components run in the customer environment. Identity and outbound paths require deployment-specific configuration.
| Component | Responsibility | Data boundary |
|---|---|---|
| Browser and frontend | Sign-in, uploads, review and export | Customer-to-application TLS; protect downloaded reports |
| API and identity provider | Authentication, organisation permissions and request handling | Only authorised users and integrations should reach organisation data |
| PostgreSQL | Accounts, findings, assessment and audit records | Private network access; restricted roles and backups |
| Valkey and workers | Queue, cache and background processing | Private services; bounded concurrency and durable queue state |
| Object or local storage | Firmware, extracted artifacts and exports | Customer-scoped access, retention and capacity controls |
| Sandbox execution | Per-binary emulation and fuzzing; system boot only where a compatible kernel is provided | Restricted runtime permissions, resource limits and blocked job egress |
| Intelligence and notifications | Feed refresh, optional email and integrations | Explicitly approved outbound paths; offline installations need a transfer process |
One website does not imply one data store
Magdox publishes both products here. FDIE's firmware and analysis data remain in FDIE. Code Security's local scans and uploaded repository findings follow its own documented path. Sharing the company identity or an identity provider does not itself join organisations, permissions or subscriptions.
Trace one image through the system
- An authorised user submits the image through application ingress; the service records the organisation, image identity and processing request.
- The configured queue dispatches work to analysis workers. Those workers read the image, use temporary extraction space and retain the relevant results.
- Supported runtime work uses the controlled execution path. Its success or failure becomes part of the assessment context.
- The review interface retrieves authorised findings and artifacts. Exports become customer-controlled copies when downloaded.
The logical data flow is stable across deployment choices; the actual queue, worker and storage implementation follows the supplied release. Planned AWS changes are described in the security addendum with their activation conditions, not as completed migration evidence.