Self-hosted infrastructure planning
Plan infrastructure as one connected model.
TopoLogic brings hardware, networks, virtual machines, storage and labs into a single workspace. Document what exists, design what comes next, and check capacity before anything is bought or built.
Example topology: a firewall and core switch connecting two Proxmox hosts and a NAS in racks B2 and B3, and a proposed host for a cyber range lab.
Physical server
- Location
- Campus A › DC-1 › Rack B2 · U12
- Platform
- Proxmox VE 8.2
- Workloads
- 14 VMs · 3 containers
- Labs
- Teaching Lab 1, SOC Lab
- Uplink
- eno1 → core-sw01 Te1/0/3
Illustrative workspace with example data.
One model
Five perspectives on the same records
A host on the network diagram is the same host in its rack, under its VMs, behind its storage and inside its lab. Switching views rearranges records; it never copies them.
Physical links and virtual bridges between the same hosts and VMs.
Capacity planning
Capacity maths you can audit
Allocations, reservations and overcommit policies are explicit inputs, not hidden constants. Every result shows how it was reached, so a red number comes with a reason.
Worked example: 30 student VMs proposed for one host.
- Physical cores32
- −Reserved for host2
- ×Overcommit policy4 : 1
- =Allocatable120 vCPU
- −Existing allocations64 vCPU
- −Proposed · 30 VMs × 2 vCPU60 vCPU
- =Available−4 vCPU
- Physical memory512 GiB
- −Reserved for host16 GiB
- −Required free reserve · 10%49.6 GiB
- =Maximum planned allocation446.4 GiB
- −Existing allocations312 GiB
- −Proposed · 30 VMs × 4 GiB120 GiB
- =Available14.4 GiB
Does not fit as proposed. CPU is short by 4 vCPU under the 4 : 1 policy. Memory fits with 14.4 GiB to spare. Place 28 VMs here and 2 on pve-a02, or change the overcommit policy deliberately.
Storage planning
From a student's home folder to the disks underneath
Describe data the way you think about it: per user, as a dataset, or as daily log ingestion with retention. TopoLogic carries the requirement down through every layer without counting capacity twice.
Worked example: a teaching file server, forecast over three years.
- 01Data categories3,793 GiB
1,200 students × 2 GiB + 300 GiB course data, grown 12 %/yr for 3 years
- 02File share4,362 GiB
+ 15 % snapshot reserve
- 03Virtual disk4,847 GiB
+ 10 % filesystem headroom
- 04Storage pool6,059 GiB
usable capacity needed while keeping 20 % free
- 05Physical disks8,078 GiB
raw capacity under RAIDZ2 (6 data of 8 drives)
overhead added at each layer · bars drawn to scale
Backup is counted separately: 7,093 GiB on the backup target for one full copy plus 29 daily increments at 3 % change. It is never mixed into primary capacity.
Scenarios
Try a change before you make it
Scenarios are layered over the documented baseline. Add a lab, retire a server or move workloads, then compare resources, dependencies and open issues side by side.
Worked example: adding a 30-seat cyber range.
Built for
Environments that outgrew a spreadsheet and a diagram
Homelabs
Keep track of what runs where, which disks back which pool, and whether the next VM will fit.
Schools and universities
Model campuses, teaching labs and shared services like the LMS, with per-lab budgets and seat counts.
Cybersecurity academies
Design isolated ranges and SOC labs from templates and check isolation and capacity before term starts.
Enterprise IT
Separate development, staging and production while seeing the shared infrastructure they depend on.
Data centre teams
Plan hardware deployments and migrations against real rack, power and capacity constraints.
Research groups
Size compute and dataset storage for projects, including growth, retention and backup.
Self-hosted
Runs on your network, with your data
TopoLogic is a single web application and a PostgreSQL database. Planning works entirely from records you enter or import; it needs no access to production systems, no external services, and sends no telemetry.
$ git clone https://github.com/yanliangchan/topologic.git$ cd topologic && cp .env.example .env$ docker compose up -d# then open http://localhost:3000 and create the owner account
Multiple organisations
One instance can host several organisations, each with its own members and roles.
Invite-only access
The first account becomes the owner. Everyone else joins through an invite link.
Import and export
Bring existing inventory in from CSV or JSON, and take your data out the same way.