System Requirements & Sizing Guide
This document outlines the hardware and software prerequisites for deploying the Dronetag Cloud Platform on-premise.
Key Highlights:
- Resource Efficiency: The platform does not require specialized proprietary hardware. It runs efficiently on standard virtual machines (vCPUs) and commodity SSD storage.
- Flexible Deployment: We support several different configurations, to adjust to individual customer needs.
- Simplified Operations: The architecture prioritizes ease of maintenance. Data integrity is secured through standard database backup procedures, eliminating the need for complex High-Availability (HA) hardware configurations.
1. Overview
The platform utilizes a Service-Oriented Architecture (SOA) based on Docker containers. The installation typically involves deploying up to 10 services/containers, managed via Docker Compose.
Incoming traffic is routed through an Nginx gateway, which is deployed as one of the containers.
While containers can theoretically be distributed across multiple nodes in various ways, we recommend two basic setups:
- Single-Node: Consolidates all services onto a single machine. Suitable for lower traffic environments or pilot testing. Significantly easier to configure and maintain.
- Dual-Node: Separates the Frontend (Web/UI/Maps) from the Backend (API/Database/Processing) for better performance isolation and scalability.
2. Software Requirements
Before provisioning hardware, ensure the host environment meets the following software criteria:
- Operating System: Linux is highly recommended for native Docker performance. Other operating systems may be considered, as far as Docker is supported.
- Preferred: Debian 13 (Trixie) or Ubuntu 22.04/24.04 LTS.
- Supported: Any modern Linux distribution capable of running a supported Docker Engine.
- Container Runtime: Docker Engine (Server Version 23.0+), Docker Compose (Version 2.37+).
- Architecture: x86-64 (AMD64).
3. Hardware Specifications
Please note that there are no strict minimal requirements. The following specifications are estimated based on typical usage patterns.
In the tables below, "vCPU" refers to one virtual core in a hypervisor environment (e.g., VMWare, KVM, AWS). We recommend a base clock speed of 2.0 GHz or higher.
Option A: Single-Node Deployment
This setup is recommended for most on-premise instances, unless you expect an enormous amount of simultaneous flights and/or users.
| Resource | Recommended Minimum | Optimal |
|---|---|---|
| CPU | 2 vCPU | 4 vCPU |
| RAM | 8 GB | 16-32 GB |
| Storage | 60 GB SSD * | 100 GB SSD * |
For the disk storage, see Capacity Planning notes below.
Option B: Dual-Node Deployment
This deployment splits the services between a Frontend Server (serving the Web UI and map data) and a Backend Server (handling API logic, flight processing, and database storage).
| Role | Resource | Recommended Minimum | Optimal |
|---|---|---|---|
| Backend Node | CPU | 2 vCPU | 4 vCPU |
| (Database & API) | RAM | 8 GB | 16-32 GB |
| Storage | 40 GB SSD | 60-80 GB SSD | |
| Frontend Node | CPU | 2 vCPU | 4 vCPU |
| (Web UI & Maps) | RAM | 4 GB | 8-16 GB |
| Storage | 30 GB | 50 GB |
For the disk storage, see Capacity Planning notes below.
4. Storage Capacity Planning
While CPU and RAM requirements depend on the expected amount of concurrent traffic, storage requirements can vary based on the amount of data stored, especially in the long-term view. The guidelines below can be used to estimate the necessary disk space.
Backend Storage (Flight Data)
The flight database grows approximately linearly based on the number of flights, their duration, and the number of sensors (receivers) tracking them. On the other hand, the amount of data is also inversely proportional to the quality of detection, which may vary and it is very difficult to predict. As a rough estimate of the storage required for flight telemetry data, count with approximately 2-3 MBs per 1 Detection Hour.
A Detection Hour corresponds to one drone being detected for the duration of one hour by one receiver. To avoid any ambiguities, the last part means that if a drone is simultaneously detected by multiple receivers, the storage requirements need to be multiplied by the number of those receivers.
Frontend Storage (Map Data)
The frontend application provides map coverage of a selected area. Storage requirements are static but depend heavily on the geographic size of the region, number of map layers, and their level of detail.
As a rule of thumb, you may count with ~5-10 GB for base map layers. If you require high-resolution satellite imagery, or detailed tactical maps with high details for large regions, storage requirements can easily exceed tens of Gigabytes.
Backup Storage
If you plan to do database backups (which is of course highly recommended, see below), count with some space needed to store these backups. This may (and most typically will) be a storage space in some different environment and configuration - for instance, it may employ some slower technology than SSD.
Summary of Scaling Factors
| Factor | Impact Area | Sizing Guidance |
|---|---|---|
| Simultaneous Flights | Backend CPU and RAM | High volumes of concurrent operations increase CPU load. Increase backend vCPU count if processing many active flights simultaneously. |
| Flight History | Backend Disk | See the Backend Storage formula above. Long-term retention of raw flight data requires planned disk expansion. |
| Concurrent Users | Frontend & Backend RAM | A high number of operators browsing the UI simultaneously increases both CPU and memory usage not only on the frontend server, but also on the backend. |
5. Reliability & Disaster Recovery
System Availability
The platform is designed for resilience through simplicity. The platform services are containerized and stateless (except for the database), allowing for rapid restart and recovery in the event of a service interruption.
It is assumed that short service interruptions (for instance, when there is a maintenance window) are tolerable for on-premise instances, and high-availability (HA) clustering is therefore generally not required for standard operational parameters.
If your availability level requirements are strict, i.e. you need HA clustering, please contact us to discuss available options.
Backup Strategy
All persistent system state and flight telemetry are centralized within the PostgreSQL database. Therefore, a robust disaster recovery plan relies primarily on the integrity of the database backups.
The following are recommendations to be considered. Your final setup may vary depending on your requirements and tolerance of potential data loss.
- Periodic Dumps: We recommend configuring a scheduled task (cron job) to perform a full database dump at regular intervals.
- Off-Site Storage: Backup files should be eventually transferred to a separate physical location or cloud storage to ensure survivability in case of physical failure or file-system loss.
- Storage Requirements: Reserve storage capacity equivalent to 3-5x the size of your active database to retain a rotation of recent backups (e.g., last 7 days, compressed).
6. Staging Environment (Optional)
While not strictly required for the platform's operation, we recommend provisioning a Staging Environment to ensure operational stability during lifecycle events. Such an environment typically has the following purpose:
- Upgrade Validation: A safe environment to test version upgrades and database migrations before applying them to the production environment and data.
- Integration Testing: A dedicated space for testing API integrations with third-party tools without risking production data integrity.
- User Playground: A safe "sandbox" for some users to play with and try extended platform functionalities, which is typically inappropriate in the production environment.
As for the sizing, the staging environment does not need to match production performance. It can usually be a scaled-down Single-Node deployment. However, we highly recommend to provide sufficient storage space to store a full copy of production data.