Deployment
The same software on a small board at the gate, a Jetson at a larger site, your own cloud, or a drone.
DomeCommand is one server process plus a database, built in Rust to a small footprint. 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.
Where it runs
The software is the same on each of these. Pick the hardware for the size of the site and for whether it needs AI running locally.
| Deployment | Fits | What runs there |
|---|---|---|
| Orange Pi 5, about $200 | Smaller sites: a single gate or a compact sensor installation | The whole stack on one board: server, console, simulator and database. 10 v 10 and 50 v 50 engagements run on it in real time. |
| NVIDIA Jetson | Mid-size sites that need local AI alongside command and control | The same stack, with room for on-device models and larger raids. Orin Nano class. |
| Private cloud or site servers | Larger deployments | The customer's own Azure or AWS tenancy, in region, or servers on site. Sizing is below. |
| On a drone | Autonomy on the aircraft | The same software as companion computing, beside a stock autopilot. See Interceptor onboard compute. |
Your data stays in your environment. Recordings, alerts and reports are kept inside the customer's deployment, whichever shape it takes. We hold none of it.
The reference edge node
For a single site the reference board 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. Connect the site's sensors and local defence is online. 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.
A small open-weight model runs on that NPU as well. Gemma 3 4B manages about 10 tokens a second, which is enough to draft and explain on site with no uplink and slow for long conversations. A site that leans on local AI is a Jetson site.
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
One node defends one site. Dome Central aggregates several, so tracks, alerts and decisions come together into one picture across sites and domains, while each node keeps running on its own when the link between them drops. C2 Connect sends that picture on to TAK, CoT and SAPIENT consumers.
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 line allows. The audit trail spans all of them.
That is a property of one node, not a reason to need several.
Sizing a server
Nothing in DomeCommand is tied to one board. It is a Linux server process and a Postgres database, so a rack server, a mini PC, a VM or a cloud instance 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 Simulation.
Where to go next
- Recommended infrastructure for where sensor detection should run.
- Getting started to connect the first sensor.
- How it works for the loop this page describes the inside of.