BryanNetDeployment sizing by workload
Prerequisites and authority
Confirm the installed edition and release. Use the glossary and deployment record before selecting an installation path.
Choose capacity from workload
Size the BryanNet host for the work it performs: customer transactions, database activity, router management, accounting, background jobs and reporting. Customer internet traffic normally travels through the network routers, so a server's Ethernet speed does not by itself define hotspot throughput.
Start with the expected number of active subscribers, simultaneous connections, routers, locations and daily payment events. Add the frequency of usage sampling, report generation and imports. A deployment with several remote routers can create more management work than a larger single-router deployment.
| Deployment pattern | Capacity planning emphasis |
|---|---|
| Small single site | Reliable storage, Docker support, backups and uninterrupted power |
| Several routers at one site | Router polling, global session reconciliation, database growth |
| Several locations | VPN reachability, WAN latency, accounting delay and recovery |
| Frequent imports or reporting | Peak CPU and memory, queue completion, disk headroom |
Use SSD storage and leave capacity for the database, logs, image archives and retained backups. Monitor disk growth rather than estimating storage only from the installer size. A backup on the same disk does not protect against disk failure.
Validate the proposed host
- Install the target build in a representative test environment.
- Exercise onboarding, purchases, router synchronization and reports together.
- Record CPU, memory, disk growth, response times and worker completion.
- Repeat at the expected busiest period and during a backup.
- Increase resources when jobs fall behind or normal transactions become slow.
No tested minimum RAM, CPU or subscriber-per-host benchmark is established. License limits and add-ons are entitlement limits, not hardware sizing measurements; do not derive capacity guarantees from the edition name.
Disk space for installation and updates
The test.28 Linux update download is approximately 400 MB and expands to roughly 1.2 GB of payload. These are approximate package sizes, not the required free space or installed footprint. Other releases and operating-system packages can differ.
Allow space for the downloaded archive, extracted payload and temporary staging, imported Docker images/layers, the existing installation and its database, and the final pre-update database backup. Retaining earlier images, packages or backups increases the requirement. Database dumps and migration working space depend on actual data and are not bounded by the download size. Docker storage, temporary files and the installation may be on different filesystems; check each, including the backing disk for Windows WSL/Docker storage.
A validated minimum for installing/updating requires measuring peak disk use during those operations with a stated database size. The installer source's 2 GiB update free-space check is a rejection threshold, not proof that every update fits in 2 GiB. Do not present the 1.2 GB extracted payload as sufficient free space. Retain the known-good recovery point and never delete database volumes merely to make room for an update.
Related guides
Related guides: Deployment verification and first login, Add and bootstrap a router in BryanNet, Customer journey: register to first connection, Daily operational checks.