Deployment
One node per site, running on site, close to the sensors.
DomeCommand is one server process plus a database. It runs where the fight is, so the loop keeps turning when the link to anywhere else is poor or contested. The time-critical work, fusing the picture and re-solving the engagement, happens locally.
A single site
The reference edge node is an Orange Pi 5 Pro. It runs the server, the console, the simulator and the database together.
| SoC | Rockchip RK3588S |
| CPU | 8 cores: 4 × Cortex-A76 and 4 × Cortex-A55 |
| GPU | Mali-G610, 4 cores |
| NPU | RKNPU, for on-device inference |
| Memory | 16 GB |
| Storage | 32 GB eMMC, expandable over NVMe |
| Operating system | Ubuntu 22.04, Rockchip kernel |
| Network | Gigabit Ethernet and Wi-Fi |
That is the whole deployment for one defended site. It draws little, fits in a cabinet, and has no moving parts.
Why this size is enough
The server's work is fusion, planning and the decision loop. All three are CPU-bound and none of them want a discrete GPU. What wants an accelerator is vision, and vision runs on the NPU on the same board or on a second one beside it.
If you are running cameras with on-device detection, plan for a second node rather than a bigger one. See Recommended infrastructure for where each workload should sit.
More than one node: Dome Central
One node defends one site. Dome Central aggregates several, so tracks, alerts and decisions from each node come together into one picture across sites and domains, while each node keeps running on its own when the link between them drops.
That is a deployment we size and set up with you rather than something you install from these pages. Talk to us about what you are covering.
Several agencies on one node
Worth separating from the above, because they are different problems.
An incident rarely belongs to one organisation. Air defence, police, airport operations and emergency services each run their own systems and coordinate by phone. On a single DomeCommand deployment they can share one fused picture instead: each gets its own channel, sees what it is cleared to see, and can command only what its gates allow. The audit trail spans all of them.
That is a property of one node, not a reason to need several.
Running it somewhere else
Nothing in DomeCommand is tied to this board. It is a Linux server process and a Postgres database, so a rack server, a mini PC or a VM all work. The Orange Pi is the reference because it is the smallest thing that comfortably runs a site, and sizing up from a known floor is easier than guessing down from a datacentre.
| Minimum | Comfortable | |
|---|---|---|
| CPU | 4 cores | 8 cores |
| Memory | 8 GB | 16 GB |
| Storage | 50 GB | 250 GB SSD, more for long run history |
| GPU | none | none |
Who can see what
A deployment is organised around workspaces. Every scenario, run, asset and sensor signal belongs to one, and is only ever visible inside it. A team gets its own space with role-based membership, so the right people have the right level of control.
People sign in, with short-lived sessions.
Machines use API keys, scoped to a workspace and issued and revoked independently of any person's login. That is what a sensor bridge or a middleware integration authenticates with. See Signals API.
What is recorded
Every run, the fused picture over time, the decisions taken and the raw signals ingested are kept as time-series data. That is what lets you look back at exactly what was seen and decided, second by second, for after-action review and for answering how a decision was reached.
See Runs and training.
Where to go next
- Recommended infrastructure for where sensor detection should run.
- Getting started to connect the first sensor.