CyberRack project charter
The complete design document behind the build, at version 1.1.
Two reasons it's here in full. First, if you're building your own version you should be able to see the reasoning, disagree with parts of it, and fork it. Second, it's a worked example of the thing this course keeps insisting matters: infrastructure documentation with a stated mission, explicit design principles, scope boundaries, a technology baseline, success criteria, and a decision rule for future changes.
Most people have never seen one. If you're heading for a role where you'll be asked to write a design document, read this for its shape as much as its content.
This reads like a formal charter rather than a lesson, because that's what it is. Course modules talk to you; this specifies a system.
How to read it
Charters are written for people who already have the vocabulary, and this one is no exception: it uses about forty acronyms and expands none of them. If you've come to CyberRack without doing the course, that's a wall. The glossary below is the missing half. Open it in a second tab.
Three conventions of the genre, which trip people up more than the jargon:
"Should" is not "must". Requirements documents use these precisely. Must is a hard requirement that fails the project if unmet. Should is a strong default you're allowed to depart from with a reason. Most of this charter says should, which is why it reads as opinionated rather than rigid.
"Definition of done" is a real term, not a flourish. §30 exists so that "finished" is decided before the work starts rather than argued about afterwards. Every team that has ever shipped late has had this argument.
"North star" means the tiebreaker. §32 is what you consult when two reasonable options are in front of you and the rest of the document doesn't decide between them.
Glossary: the acronyms this charter assumes you know
Networking
- VLAN, Virtual Local Area Network. One physical switch carved into several separate networks that cannot talk to each other without going through a router.
- WAN, Wide Area Network. Here it means the interface facing your home internet connection.
- DHCP, Dynamic Host Configuration Protocol. What hands a device an address automatically when it joins a network.
- DNS, Domain Name System. Turns names into addresses.
- NTP, Network Time Protocol. Keeps clocks in agreement, which matters more than it sounds: certificates and Kerberos both break when clocks drift.
- VPN, Virtual Private Network. An encrypted tunnel into the network from outside it.
- SFP+, Small Form-factor Pluggable. The cage a fibre or high-speed copper module slots into, as opposed to a fixed RJ45 socket.
- SNMP, Simple Network Management Protocol. How network gear reports its health to monitoring systems.
Storage
- ZFS. A filesystem and volume manager in one, notable for checksums that detect silent corruption and for cheap snapshots.
- NAS, Network Attached Storage. A box whose job is serving files.
- SAN, Storage Area Network. The enterprise-scale version, listed in this charter only as something deliberately out of scope.
- NFS, Network File System. The usual way Linux and Unix machines share files.
- SMB, Server Message Block. The usual way Windows machines do.
- iSCSI. Presents remote storage as if it were a local disk.
Identity and certificates
- AD, Active Directory. Microsoft's directory service: the central list of users, computers and groups.
- AD CS, Active Directory Certificate Services. Microsoft's built-in certificate authority.
- PKI, Public Key Infrastructure. The whole system of certificates, the authorities that sign them, and the rules for trusting them.
- CA, Certificate Authority. The thing that signs certificates.
- LDAP, Lightweight Directory Access Protocol. The protocol applications use to ask a directory about users.
- SSO, Single Sign-On. Log in once, reach many applications.
- SAML and OIDC (OpenID Connect). The two protocols that make single sign-on work. SAML is older and speaks XML; OIDC is newer, built on OAuth 2.0, and speaks JSON.
- TLS, Transport Layer Security. The encryption behind the s in HTTPS.
- SSH, Secure Shell. Encrypted remote command line.
Security operations
- SIEM, Security Information and Event Management. Collects logs from everything and raises alerts on patterns.
- IDS and IPS, Intrusion Detection and Intrusion Prevention System. One watches traffic and warns; the other watches and blocks.
Platform and practice
- HA, High Availability. Designing so one machine failing doesn't take the service down.
- CI/CD, Continuous Integration and Continuous Delivery. Automatically building and testing changes, then automatically shipping them.
- IaC, Infrastructure as Code. Defining servers and networks in files you version-control, instead of clicking through a console.
- ADR, Architecture Decision Record. A short note recording a decision and, crucially, the reasoning and the alternatives rejected.
- API, Application Programming Interface. The way one program asks another to do something.
- k3s. A stripped-down Kubernetes, small enough to run on a mini PC.
- UPS, Uninterruptible Power Supply. A battery that keeps equipment running briefly when mains power fails. This build deliberately has none inside the rack; §24.1 explains what replaces it.
Hardware names, which are models rather than acronyms
- N100. A low-power Intel processor common in small firewall boxes.
- CRS310-8G+2S+IN. A MikroTik switch model. The suffix describes it: 8 gigabit copper ports, 2 SFP+ cages, indoor.
- TrueNAS SCALE. The Linux-based version of the TrueNAS storage operating system. SCALE is a product name, not an acronym.
- NVMe, Non-Volatile Memory Express. The fast solid-state drive standard that plugs directly into the motherboard.
This document is at version 1.1, and §33 records what changed from 1.0 and why. Version 1.0 required the platform to be portable and also placed an uninterruptible power supply inside a ten-inch rack. Both are reasonable requirements. Together they are impossible, because rack UPS units are manufactured for nineteen-inch rails and do not fit at any size.
That is worth studying rather than skipping. The conflict was invisible while the document described qualities in one section and components in another, which is where this class of error almost always hides. It surfaced at the point of purchase, which is the normal place for it to surface and a cheap place to catch it.
What a design document is for is being revised when reality pushes back. A charter nobody ever amends is not a stable charter; it is one nobody checked against anything. The build page carries the resulting decision.
CyberRack Project Charter
Enterprise Mini Infrastructure Platform
Version: 1.1 Status: Approved Project North Star Revised: power protection moved out of the rack (see §33) Target Budget: $2,500 USD Target Audience: College students, early-career IT professionals, cybersecurity students, and self-directed infrastructure learners
1. Mission Statement
Build a lab that demonstrates modern enterprise infrastructure using the fewest possible devices while maximizing learning, portability, and long-term upgradeability.
CyberRack is an intentionally designed miniature enterprise infrastructure platform.
It is not intended to be the largest homelab, the fastest server environment, or a collection of unrelated technology products. Its purpose is to provide a compact, affordable, reproducible, and professionally documented platform for learning modern infrastructure, networking, cybersecurity, storage, identity, automation, and platform engineering.
Every hardware purchase, software deployment, and architectural decision must support a clearly defined learning objective.
2. Project Vision
CyberRack should operate like a miniature enterprise datacenter while remaining small enough for a desk, dorm room, apartment, home office, or classroom.
Although physically compact, the platform should demonstrate the technologies and operational practices found in modern organizations, including:
- Clustered virtualization
- Enterprise networking
- Network segmentation
- Shared storage
- Centralized identity
- Public key infrastructure
- Security monitoring
- Network intrusion detection
- Centralized logging
- Backup and disaster recovery
- Infrastructure automation
- Containerized applications
- Observability
- Configuration management
- Infrastructure as Code
- Technical documentation
The platform should be useful both as a learning environment and as a professional portfolio project.
3. Project Objectives
CyberRack must accomplish the following objectives:
- Provide hands-on experience with modern enterprise infrastructure technologies.
- Fit within an initial project budget of approximately $2,500.
- Use a small number of standardized, power-efficient devices.
- Remain quiet enough for use in a bedroom, dorm, library workspace, or home office.
- Support incremental upgrades without requiring a complete rebuild.
- Demonstrate professional infrastructure design and operational practices.
- Be reproducible by another student using the project documentation.
- Produce artifacts that can be included in a professional portfolio.
- Encourage automation instead of permanent manual administration.
- Provide a safe environment for cybersecurity experimentation and defensive testing.
4. Budget Principle
The initial CyberRack build should target a total project cost of no more than:
$2,500 USD
The budget should include:
- Compute nodes
- Storage appliance
- Firewall appliance
- Managed network switch
- Rack
- Patch panel
- Cabling
- Power distribution
- Memory and storage upgrades
- Required adapters and mounting hardware
An uninterruptible power supply is deliberately excluded. See §24.
Optional future upgrades are not required to fit inside the initial $2,500 budget.
The version 1.1 bill of materials comes to approximately $2,959 against this $2,500 target. The overrun is recorded rather than hidden, because the useful question is which line to cut, not whether the original figure was wrong. The staged purchasing path exists so that most of this can be deferred.
Because used-equipment prices fluctuate, the final bill of materials should include a contingency reserve of approximately 5–10 percent.
A purchase should not be made solely because money remains in the budget. Unused budget should be preserved for failures, replacement parts, storage expansion, or future upgrades.
5. Core Design Principles
5.1 Learning First
Learning takes priority over maximum performance.
Every hardware or software component must teach one or more transferable enterprise skills.
Examples include:
- Virtualization
- Network segmentation
- Firewall administration
- Identity management
- Storage administration
- Backup and recovery
- Monitoring
- Automation
- Security operations
- Container orchestration
Hardware exists to support learning. Hardware acquisition is not the primary objective of the project.
5.2 Fewest Practical Devices
CyberRack should use the smallest number of physical devices that can still demonstrate the required enterprise concepts.
Device consolidation is encouraged when it:
- Reduces cost
- Reduces power usage
- Reduces cable complexity
- Simplifies maintenance
- Preserves educational value
Additional devices should only be introduced when they provide a meaningful architectural or educational benefit.
5.3 Simplicity Before Complexity
The simplest architecture that satisfies the learning objectives should be preferred.
Avoid unnecessary:
- Servers
- Appliances
- Network hops
- Management consoles
- Duplicate applications
- Storage layers
- Authentication systems
- Monitoring systems
Complexity should be introduced deliberately rather than accidentally.
5.4 Small Form Factor
The platform should remain:
- Desk-friendly
- Dorm-friendly
- Apartment-friendly
- Quiet
- Portable
- Energy efficient
- Easy to relocate
The preferred physical format is a compact 10-inch rack.
The initial rack should target approximately 10U of usable space.
This choice constrains what can be mounted. A 10-inch rack sets its rails approximately 236.5 mm apart, while rack-mounted equipment is overwhelmingly manufactured for the 19-inch standard. Any component selected for this platform must be available in a 10-inch form factor, shelf-mounted, or placed outside the rack. Weight is a requirement in its own right: a platform that cannot be lifted is not portable, whatever else it achieves.
5.5 Standardization
Identical hardware should be used whenever practical.
The compute cluster should use three matching systems with equivalent:
- Processors
- Memory
- Storage
- Network interfaces
- Firmware
- BIOS settings
- Hypervisor versions
Standardization reduces troubleshooting time and reflects normal enterprise infrastructure practices.
5.6 Enterprise Architecture
CyberRack should model enterprise design practices rather than relying on shortcuts.
Examples include:
- VLAN segmentation
- Centralized authentication
- Role-based access control
- Least privilege
- Certificate-based encryption
- Dedicated management networks
- Monitoring and alerting
- Automated backups
- Change documentation
- Recovery testing
- Configuration management
- Version control
5.7 Open Standards
Preference should be given to technologies that implement widely used and interoperable standards.
Examples include:
- Ethernet
- VLAN
- IPv4 and IPv6
- DNS
- DHCP
- NTP
- LDAP
- Kerberos
- SAML
- OAuth 2.0
- OpenID Connect
- TLS
- SSH
- NFS
- SMB
- iSCSI
- SNMP
- Syslog
- REST APIs
Open standards reduce vendor dependency and improve the transferability of learned skills.
5.8 Upgrade Without Rebuilding
The architecture must support incremental growth.
Future improvements should extend or replace individual components without requiring the entire platform to be redesigned.
Examples include:
- Increasing memory
- Replacing NVMe drives
- Adding storage capacity
- Adding 10GbE interfaces
- Adding a GPU-enabled node
- Introducing Kubernetes
- Adding redundant storage
- Adding high availability
- Replacing the firewall platform
- Adding cloud integration
5.9 Replaceability
No individual technology should become an irreplaceable dependency.
Each major component should communicate through documented standards and interfaces.
A firewall, switch, compute node, storage platform, monitoring system, or identity provider should be replaceable without invalidating the entire architecture.
5.10 Reproducibility
Another student should be able to recreate CyberRack using the project repository.
The documentation must include:
- Project charter
- Bill of materials
- Rack elevation
- Network topology
- VLAN plan
- IP addressing plan
- Storage design
- Power design
- Installation procedures
- Configuration procedures
- Automation scripts
- Backup procedures
- Recovery procedures
- Upgrade procedures
- Architecture Decision Records
Documentation is part of the infrastructure.
6. Scope
6.1 Included in Scope
CyberRack includes the design and implementation of:
- A three-node virtualization cluster
- A dedicated shared-storage appliance
- A dedicated firewall appliance
- A managed network switch
- A segmented network architecture
- Centralized identity services
- Certificate services
- Centralized monitoring
- Security monitoring
- Network intrusion detection
- Automated virtual-machine backups
- Containerized application hosting
- Configuration automation
- Version-controlled documentation
- Recovery testing
- A compact rack and power system
6.2 Out of Scope for Version 1.1
The following capabilities are not required for the initial build:
- Production-grade uptime guarantees
- Fully redundant power
- Fully redundant switching
- Dual storage controllers
- Enterprise support contracts
- Large-scale GPU computing
- Multi-site disaster recovery
- Public cloud dependency
- Full Ceph deployment
- Production Kubernetes
- Internet-facing production services
- Large-scale surveillance storage
- High-end enterprise SAN hardware
These capabilities may be explored in later phases when they provide clear educational value.
7. Physical Architecture
The preferred rack format is:
10-inch, approximately 10U mini rack
The rack should emphasize:
- Density
- Organization
- Portability
- Cable management
- Airflow
- Serviceability
- Maintainability
- Visual clarity
A reference rack layout is:
| Rack Unit | Component |
|---|---|
| U10 | Spare, reserved for future expansion |
| U9 | Intel N100 firewall appliance |
| U8 | MikroTik managed switch |
| U7 | Brush or cable-management panel |
| U6 | 12-port CAT6 keystone patch panel |
| U5 | Lenovo ThinkCentre M920q — Atlas |
| U4 | Lenovo ThinkCentre M920q — Hermes |
| U3 | Lenovo ThinkCentre M920q — Daedalus |
| U2 | AOOSTAR WTR Pro storage appliance |
| U1 | Power distribution unit (PDU) |
The exact mounting arrangement may change based on equipment dimensions, airflow, rack depth, and available mounting accessories.
8. Technology Selection Philosophy
Technology selections are evaluated using the following questions.
8.1 Does It Teach an Enterprise Skill?
Every technology must answer:
What enterprise skill does this teach?
If the answer is unclear, the technology should not become part of CyberRack.
8.2 Is It Widely Applicable?
Preference should be given to technologies with skills that transfer to:
- Enterprise IT
- Cybersecurity
- Cloud engineering
- DevOps
- Platform engineering
- Systems administration
- Network engineering
- Security operations
8.3 Does It Fit the Budget?
The technology must provide reasonable educational value for its total cost.
Total cost includes:
- Hardware
- Licensing
- Memory
- Storage
- Networking
- Power consumption
- Required accessories
- Maintenance
- Replacement availability
8.4 Can It Scale?
The selected technology should remain useful as the student advances.
The preferred solution should support both basic learning and more advanced future implementation.
8.5 Is It Supported by a Strong Community?
Preference should be given to technologies with:
- Active documentation
- Large user communities
- Available troubleshooting resources
- Regular security updates
- Accessible installation media
- Broad hardware compatibility
9. Technology Baseline — Version 1.1
CyberRack intentionally standardizes on a selected technology stack.
These selections are strategic commitments for Version 1.1 and should only change when there is a compelling architectural, financial, security, or educational reason.
The baseline is selected according to:
- Enterprise relevance
- Learning value
- Community support
- Hardware availability
- Affordability
- Long-term sustainability
- Interoperability
- Upgradeability
10. Compute Platform
10.1 Standard Compute Hardware
The standard CyberRack compute platform is:
Lenovo ThinkCentre M920q Tiny
Three identical Lenovo ThinkCentre M920q systems will form the Proxmox virtualization cluster.
Minimum Standard Configuration per Node
- Intel Core i5-8500T
- Six physical CPU cores
- 64 GB DDR4 memory
- 512 GB NVMe operating-system drive
- 1 TB NVMe virtual-machine storage drive
- Intel Gigabit Ethernet
- Intel virtualization extensions
- Intel VT-d support
- Intel vPro where available
Preferred Configuration
- Intel Core i7-8700T
- 64 GB DDR4 memory
- 512 GB NVMe operating-system drive
- 1–2 TB NVMe virtual-machine storage drive
- PCIe riser
- 2.5GbE or 10GbE network interface
Selection Rationale
The Lenovo ThinkCentre M920q was selected because it provides:
- Enterprise-class build quality
- Low power consumption
- Quiet operation
- Compact dimensions
- Strong Proxmox compatibility
- 64 GB memory support
- Intel virtualization support
- Optional PCIe expansion
- A large used-equipment market
- Accessible replacement parts
- Consistent hardware standardization
- A practical upgrade path to faster networking
10.2 Compute Node Names
The three compute nodes will use the following hostnames:
| Node | Hardware | Primary Learning Role |
|---|---|---|
| Atlas | Lenovo ThinkCentre M920q | Identity, directory services, PKI, DNS and foundational services |
| Hermes | Lenovo ThinkCentre M920q | Security monitoring, logging, IDS, SIEM and firewall laboratories |
| Daedalus | Lenovo ThinkCentre M920q | Containers, development, automation, CI/CD and Kubernetes |
These roles describe the preferred workload placement but do not create permanent physical dependencies.
Virtual machines and containers should remain migratable between cluster nodes.
11. Virtualization Platform
The primary virtualization platform is:
Proxmox Virtual Environment
Proxmox VE is the foundation of CyberRack.
The three M920q systems will operate as one Proxmox VE cluster with a shared management plane.
11.1 Required Capabilities
The cluster should demonstrate:
- Centralized management
- Cluster membership
- Quorum
- Virtual machines
- Linux containers
- Storage integration
- Snapshots
- Templates
- Cloning
- Live migration
- Backup integration
- Role-based access
- Virtual networking
- Resource monitoring
- High availability concepts
11.2 Future Capabilities
Later phases may introduce:
- Proxmox high availability
- Software-defined networking
- Automated node deployment
- API-based provisioning
- Terraform integration
- Ceph as an educational experiment
- Cluster-aware monitoring
- Automated workload balancing
The project intentionally standardizes on Proxmox rather than requiring a proprietary virtualization management appliance.
12. Storage Platform
12.1 Storage Hardware
The preferred dedicated storage appliance is:
AOOSTAR WTR Pro
Initial Configuration
- Intel N100 processor
- 32 GB memory
- Dual 2.5GbE networking
- TrueNAS SCALE
- Two matched 4 TB NAS drives
- ZFS mirror
- Approximately 4 TB of usable mirrored storage
Additional drives may be added when the hardware configuration and budget allow.
12.2 Storage Operating System
The primary storage operating system is:
TrueNAS SCALE
12.3 Storage Technologies
The storage platform should demonstrate:
- ZFS
- Storage pools
- Datasets
- NFS
- SMB
- iSCSI
- Snapshots
- Replication
- Data integrity
- Storage monitoring
- Capacity management
- File permissions
- Network storage security
12.4 Storage Architecture Principle
Storage must remain independent of the compute cluster.
The failure, replacement, or maintenance of one Proxmox node should not eliminate access to the primary shared-storage platform.
The initial design should favor simplicity and recoverability over maximum storage performance.
13. Firewall Platform
13.1 Firewall Hardware
The preferred firewall platform is:
Intel N100 multi-port firewall appliance
The appliance should include:
- At least four Ethernet interfaces
- Preferably 2.5GbE interfaces
- Intel network controllers where possible
- Replaceable storage
- Sufficient memory for firewall, VPN, and IDS laboratory workloads
13.2 Firewall Operating System
The primary firewall operating system is:
OPNsense
13.3 Learning Objectives
The firewall platform should teach:
- IPv4 and IPv6 routing
- VLAN interfaces
- Firewall rules
- Stateful inspection
- Network Address Translation
- DHCP
- DNS forwarding
- VPN
- WireGuard
- IPsec
- Traffic shaping
- Logging
- IDS/IPS
- Certificate management
- Reverse-proxy concepts
- Multi-WAN concepts
- Network isolation
The firewall should remain vendor-independent and should not require a proprietary cloud-management ecosystem.
14. Switching Platform
The preferred switching platform is:
MikroTik CRS310-8G+2S+IN
14.1 Required Capabilities
The switch provides:
- Eight 2.5 Gigabit Ethernet ports
- Two 10 Gigabit SFP+ interfaces
- VLAN support
- Layer 2 switching
- Link aggregation
- Spanning Tree
- Port isolation
- Traffic monitoring
- MikroTik RouterOS and SwitchOS learning
- A future 10GbE upgrade path
14.2 Selection Rationale
The MikroTik CRS310-8G+2S+IN was selected because it provides:
- Multi-gigabit connectivity
- 10GbE uplinks
- Strong learning value
- Enterprise-style switching concepts
- Compact dimensions
- Low power consumption
- Good price-to-capability ratio
- Freedom from a single-vendor ecosystem
The switching platform should expose enterprise networking concepts without requiring enterprise hardware pricing.
15. Network Segmentation Baseline
CyberRack should use VLANs to separate management, workloads, backups, monitoring, guests, and untrusted devices.
The initial VLAN structure is:
| VLAN | Name | Example Subnet | Purpose |
|---|---|---|---|
| 10 | Management | 192.168.10.0/24 | Proxmox, switch, firewall, storage and administrative interfaces |
| 20 | Servers | 192.168.20.0/24 | Virtual machines, containers and internal applications |
| 30 | Backup | 192.168.30.0/24 | Backup, replication and recovery traffic |
| 40 | Monitoring | 192.168.40.0/24 | Logging, metrics, SIEM and observability platforms |
| 50 | Guest | 192.168.50.0/24 | Internet-only guest access |
| 60 | IoT | 192.168.60.0/24 | Isolated or untrusted devices |
| 70 | Security Lab | 192.168.70.0/24 | Cybersecurity testing, attack simulation and vulnerable systems |
The exact addressing may change, but functional separation should remain.
Traffic between VLANs must be controlled through documented firewall policies.
16. Identity Platform
The primary identity technologies are:
- Microsoft Active Directory Domain Services
- Keycloak
- Microsoft Active Directory Certificate Services
16.1 Learning Objectives
The identity platform should demonstrate:
- LDAP
- Kerberos
- DNS integration
- Organizational Units
- Group Policy
- Role-based access
- Service accounts
- Group Managed Service Accounts
- Single Sign-On
- SAML
- OAuth 2.0
- OpenID Connect
- Multi-factor authentication
- Certificate enrollment
- Certificate templates
- Certificate revocation
- Trust relationships
- Identity federation
16.2 Identity Principle
Active Directory, Keycloak, and AD CS should each have a defined purpose.
Duplicate identity services should not be deployed without a specific learning objective.
17. Public Key Infrastructure
Microsoft Active Directory Certificate Services will provide the initial enterprise PKI environment.
The PKI should demonstrate:
- Offline root CA concepts
- Enterprise subordinate CA
- Certificate templates
- Server certificates
- User certificates
- Computer certificates
- TLS
- Smart-card concepts
- Certificate revocation lists
- Auto-enrollment
- Certificate lifecycle management
- Private-key protection
- Certificate renewal
- Certificate inventory
PKI should support other CyberRack services rather than existing as an isolated laboratory.
18. Monitoring and Observability Platform
The primary monitoring technologies are:
- Prometheus
- Grafana
- Uptime Kuma
- Alertmanager
18.1 Learning Objectives
The monitoring platform should demonstrate:
- Metrics collection
- Dashboards
- Service availability
- Node monitoring
- Capacity planning
- Alerting
- Threshold configuration
- Trend analysis
- Infrastructure health
- Storage utilization
- Network visibility
- Backup status
- Cluster health
Monitoring should be introduced early rather than added only after failures occur.
19. Security Monitoring Platform
The primary security monitoring technologies are:
- Wazuh
- Suricata
Future technologies may include:
- Zeek
- CrowdSec
- OpenSearch
- Vulnerability-management integrations
- Threat-intelligence feeds
19.1 Learning Objectives
The security platform should demonstrate:
- Security Information and Event Management
- Host-based intrusion detection
- File-integrity monitoring
- Log analysis
- Network intrusion detection
- Traffic analysis
- Alert triage
- Threat hunting
- Vulnerability detection
- Endpoint visibility
- Security dashboards
- Incident response workflows
Security monitoring should be integrated with the broader infrastructure rather than deployed as an isolated product demonstration.
20. Backup Platform
The primary virtualization backup platform is:
Proxmox Backup Server
20.1 Responsibilities
Proxmox Backup Server should provide:
- Virtual-machine backups
- Container backups
- Incremental backups
- Deduplication
- Compression
- Retention policies
- Backup verification
- Encryption
- Scheduled jobs
- Recovery testing
20.2 Backup Policy
The initial backup policy should include:
- Daily incremental backups
- Weekly full validation or verification
- Monthly offline or off-system copies where practical
- Regular virtual-machine restore tests
- Configuration backups for the firewall, switch, storage appliance, and Proxmox cluster
- Documentation of recovery procedures
A backup is not considered reliable until it has been successfully restored.
21. Automation Platform
The primary automation technologies are:
- Git
- Gitea
- Ansible
Future automation technologies may include:
- Terraform
- Packer
- OpenTofu
- GitOps tools
- CI/CD runners
- Proxmox API automation
21.1 Automation Objectives
Automation should eventually support:
- Virtual-machine provisioning
- Container deployment
- Operating-system configuration
- User creation
- Package installation
- Certificate deployment
- Monitoring-agent installation
- Backup configuration
- Network configuration
- Configuration validation
- Documentation generation
Manual configuration should gradually decrease as CyberRack matures.
Automation should be version controlled and documented.
22. Container Platform
The initial container platform is:
Docker
The future orchestration platform is:
Kubernetes using k3s
22.1 Container Objectives
The container platform should demonstrate:
- Container images
- Registries
- Volumes
- Container networking
- Secrets
- Compose files
- Service health
- Reverse proxies
- Persistent storage
- Application deployment
- CI/CD
- Kubernetes fundamentals
- High-availability concepts
- GitOps concepts
Containers should become the preferred deployment method for lightweight services when appropriate.
Virtual machines should remain available where operating-system isolation or specialized networking is required.
23. Documentation Platform
The preferred documentation technologies are:
- Markdown
- Mermaid
- Draw.io
- Git
- Gitea
- MkDocs in a future phase
23.1 Required Documentation
The project repository should contain:
- Project charter
- Requirements
- Bill of materials
- Architecture Decision Records
- Rack elevation
- Network topology
- VLAN plan
- IP addressing plan
- Firewall rule matrix
- Storage design
- Virtualization design
- Identity design
- PKI design
- Monitoring design
- Backup strategy
- Build procedures
- Recovery procedures
- Upgrade procedures
- Security procedures
- Lessons learned
Documentation must be maintained as the environment changes.
Outdated documentation should be treated as an infrastructure defect.
24. Power, Noise, and Thermal Requirements
CyberRack should target:
- Approximately 80–150 watts at idle
- Less than approximately 300 watts during normal peak activity
- Quiet operation suitable for a bedroom, dorm, or office
- No dependency on high-speed server fans
- No requirement for specialized cooling
- Adequate airflow between rack components
Power bricks and adapters should be organized safely.
24.1 Power Protection
No uninterruptible power supply is installed in the rack. Rack-mounted UPS units are manufactured for 19-inch rails and cannot be fitted to a 10-inch rack, and the sealed lead-acid units that would otherwise be candidates conflict directly with the portability requirement in §5.4.
Where mains power is unreliable, an external UPS should be placed outside the rack. It should be sized for orderly shutdown rather than continued operation: at the idle and peak figures above, five minutes of runtime requires roughly 12 to 25 watt-hours, which is well inside the capability of any consumer unit.
Any such unit must provide a data connection, over USB or the network, so that connected systems can be signalled to shut down. A unit that cannot signal delays an unclean shutdown rather than preventing one.
Where the platform is expected to be relocated frequently, power protection should be omitted entirely and the platform shut down before it is moved.
USB-C power conversion may be used only when voltage, amperage, connector polarity, and total power capacity have been verified.
Reliability takes priority over eliminating every individual power adapter.
25. Security Principles
CyberRack must follow the following security principles:
- Default-deny inter-VLAN routing
- Least-privilege access
- Dedicated management network
- Strong administrator credentials
- Multi-factor authentication where supported
- Certificate-based encryption
- No unencrypted administrative interfaces
- Centralized logging
- Regular patching
- Secure secrets storage
- Restricted backup access
- Documented firewall rules
- No direct exposure of management interfaces to the internet
- Separation of vulnerable laboratory systems from trusted networks
- Regular recovery testing
Cybersecurity experimentation must be contained within authorized laboratory networks.
26. Technology Governance
26.1 Standardize
Use one preferred solution whenever possible.
Avoid maintaining multiple technologies that solve the same problem unless the comparison itself is an explicit learning exercise.
26.2 Document Decisions
Major technology choices must be recorded through Architecture Decision Records.
An ADR should include:
- Decision
- Context
- Options considered
- Rationale
- Consequences
- Risks
- Reconsideration triggers
26.3 Avoid Unplanned Technology Sprawl
New applications should not be deployed simply because they are popular or available.
Before adding a technology, document:
- The problem it solves.
- The enterprise skill it teaches.
- Its resource requirements.
- Its security implications.
- Its backup requirements.
- Its dependencies.
- Whether an existing platform already provides the capability.
26.4 Preserve Replaceability
Each technology should use documented protocols and interfaces whenever possible.
Replacement of one component should not require a complete platform redesign.
26.5 Control Scope
The project should prioritize completing functional capabilities before introducing additional platforms.
A smaller, well-documented, recoverable environment is preferred over a larger environment with incomplete configuration.
27. CyberRack Version 1.1 Reference Architecture
| Domain | Approved Standard |
|---|---|
| Compute | 3× Lenovo ThinkCentre M920q Tiny |
| Minimum CPU | Intel Core i5-8500T |
| Memory | 64 GB DDR4 per compute node |
| Hypervisor | Proxmox VE cluster |
| Storage hardware | AOOSTAR WTR Pro |
| Storage operating system | TrueNAS SCALE |
| Storage protocols | ZFS, NFS, SMB and iSCSI |
| Firewall hardware | Intel N100 multi-port appliance |
| Firewall software | OPNsense |
| Switching | MikroTik CRS310-8G+2S+IN |
| Backup | Proxmox Backup Server |
| Identity | Active Directory and Keycloak |
| PKI | Microsoft Active Directory Certificate Services |
| Monitoring | Prometheus, Grafana, Uptime Kuma and Alertmanager |
| Security monitoring | Wazuh |
| Network security | Suricata |
| Automation | Git, Gitea and Ansible |
| Future automation | Terraform or OpenTofu |
| Containers | Docker |
| Future orchestration | Kubernetes using k3s |
| Documentation | Markdown, Mermaid, Draw.io, Git and MkDocs |
| Rack | Approximately 10U, 10-inch mini rack |
| In-rack power | Managed power distribution unit. No UPS, see §24 |
28. Success Criteria
CyberRack Version 1.1 will be considered successful when it can demonstrate the following capabilities.
28.1 Physical Infrastructure
- All equipment is securely mounted or positioned.
- Cabling is labeled and organized.
- Power consumption is documented.
- The system operates within acceptable temperature and noise limits.
- The rack can be moved without requiring a complete rebuild.
28.2 Virtualization
- Three Proxmox nodes operate as one cluster.
- Cluster quorum is healthy.
- Virtual machines and containers can be created from templates.
- Workloads can be migrated between nodes.
- Shared storage is available to the cluster.
- Proxmox Backup Server successfully backs up and restores workloads.
28.3 Networking
- VLANs are implemented.
- Inter-VLAN routing is controlled by OPNsense.
- Management interfaces are isolated.
- Guest and IoT networks are restricted.
- Firewall rules are documented.
- Remote access uses a secure VPN.
28.4 Storage
- TrueNAS SCALE provides shared storage.
- ZFS snapshots are scheduled.
- NFS or iSCSI is available to Proxmox.
- SMB is available for administrative file storage.
- Storage recovery procedures are documented and tested.
28.5 Identity
- Active Directory provides centralized Windows identity.
- Keycloak provides SAML or OpenID Connect services.
- AD CS issues certificates.
- At least one application uses centralized authentication.
- At least one service uses an internally issued TLS certificate.
28.6 Security
- Wazuh receives endpoint events.
- Suricata analyzes network traffic.
- Security alerts are visible in a central dashboard.
- Vulnerable laboratory systems are isolated.
- An incident-response exercise is documented.
28.7 Monitoring
- Proxmox nodes are monitored.
- Storage health is monitored.
- Firewall and switch availability are monitored.
- Dashboards display resource use and service status.
- At least one meaningful alert is configured and tested.
28.8 Automation
- Git stores configuration and documentation.
- Ansible performs at least one repeatable infrastructure deployment.
- A virtual machine or service can be rebuilt using documented automation.
- Secrets are not stored in plaintext repositories.
28.9 Documentation
- Another person can understand the architecture from the repository.
- The bill of materials matches the physical environment.
- IP addresses and VLANs are documented.
- Backup and recovery procedures are current.
- Major decisions are recorded through ADRs.
29. Project Roadmap
Phase 1 — Foundation
Objectives:
- Finalize bill of materials
- Acquire hardware
- Assemble rack
- Install power distribution
- Install OPNsense
- Configure MikroTik switch
- Create VLANs
- Install Proxmox on three M920q systems
- Form the Proxmox cluster
- Establish the Git repository
- Document the physical and network architecture
Phase 2 — Storage and Recovery
Objectives:
- Install TrueNAS SCALE
- Create ZFS storage pools
- Configure NFS, SMB and optional iSCSI
- Integrate shared storage with Proxmox
- Deploy Proxmox Backup Server
- Create backup schedules
- Test virtual-machine restoration
- Document disaster-recovery procedures
Phase 3 — Enterprise Identity
Objectives:
- Deploy Active Directory
- Configure DNS and NTP
- Deploy AD CS
- Create certificate templates
- Deploy Keycloak
- Integrate an application with SSO
- Implement role-based access
- Document identity and PKI architecture
Phase 4 — Monitoring and Security
Objectives:
- Deploy Prometheus
- Deploy Grafana
- Deploy Uptime Kuma
- Deploy Wazuh
- Deploy Suricata
- Configure centralized logging
- Create dashboards
- Test alerts
- Perform a documented security exercise
Phase 5 — Automation
Objectives:
- Deploy Gitea
- Create Ansible inventory
- Automate operating-system configuration
- Automate monitoring-agent deployment
- Automate certificate deployment
- Automate backup validation
- Introduce Terraform or OpenTofu where appropriate
- Establish configuration review practices
Phase 6 — Containers and Platform Engineering
Objectives:
- Deploy Docker services
- Implement container registries
- Deploy a k3s cluster
- Integrate persistent storage
- Implement CI/CD
- Explore GitOps
- Document container and Kubernetes operations
Phase 7 — Advanced Expansion
Possible future objectives:
- Upgrade selected links to 10GbE
- Add higher-capacity storage
- Add a GPU node
- Test Proxmox high availability
- Explore Ceph
- Add a second storage appliance
- Implement off-site replication
- Integrate public cloud services
- Explore zero-trust architecture
- Add automated compliance checks
Expansion is optional and must remain aligned with the project mission.
30. Definition of Done
CyberRack is not considered complete merely because all hardware has been installed.
A phase is complete only when:
- The capability works.
- The configuration is documented.
- Monitoring is enabled.
- Backup requirements are addressed.
- Recovery has been tested.
- Security implications are understood.
- The learning outcome is recorded.
- Another person could reproduce the result.
31. Final Definition of Success
CyberRack succeeds when it becomes more than a homelab.
It should function as:
- A learning platform
- A cybersecurity range
- A miniature enterprise datacenter
- A professional portfolio project
- An architecture reference
- An automation laboratory
- A documentation repository
- A disaster-recovery exercise platform
- A repeatable blueprint for other students
The project is successful not when there is nothing left to add, but when every remaining addition must justify itself through a clear educational or architectural purpose.
Every upgrade should increase knowledge, capability, resilience, or maintainability—not merely specifications.
32. North Star Decision Rule
When evaluating any future purchase, deployment, or architecture change, ask:
- What enterprise skill does this teach?
- Does it reduce or unnecessarily increase complexity?
- Does it preserve the small-form-factor objective?
- Does it fit the project budget or documented upgrade plan?
- Can it be replaced later?
- Can it be automated?
- Can it be monitored?
- Can it be backed up and recovered?
- Can another student reproduce it?
- Does it move CyberRack closer to its mission?
If the answer to these questions is unclear, the proposed change should not be adopted until its purpose is better defined.
33. Revision History
Version 1.1
Change. Power protection removed from the rack. §4 no longer budgets for an uninterruptible power supply, §7 places a power distribution unit in U1, and §24.1 specifies external power protection as an option rather than a component.
Reason. Version 1.0 required the platform to be portable and easy to relocate (§5.4) while placing a UPS inside a 10-inch rack (§7). Those requirements are incompatible. Rack UPS units are manufactured for 19-inch rails and do not mount in a 10-inch rack at any size, and the battery chemistry in that equipment class is the heaviest single component a build of this scale would carry.
The conflict was not visible while the document described qualities and components in separate sections. It became visible at the point of purchase, which is the normal place for this class of error to surface.
Effect on the build. The rack carries a power distribution unit only. U10 is now recorded as spare rather than as a monitoring display, matching the reference elevation. The reasoning behind sizing external power protection for shutdown rather than uptime is documented in §24.1.
Also recorded. §4 now states the version 1.1 bill of materials comes to approximately $2,959 against a $2,500 target, and §5.4 states the 10-inch rail constraint explicitly so that future component selection accounts for it.