Zelogx™ Multi-Project Secure Lab Setup is an open-source provisioning toolkit for building secure, L2 isolated development environments on proxmox utilizing Proxmox SDN, Firewall(Security group) and Pritunl.
© 2025 Zelogx. Zelogx™ and the Zelogx logo are trademarks of the Zelogx Project. All other marks are property of their respective owners.
This project builds completely isolated development environments per project by Layer 2 level, accessible securely via VPN.
It's a blueprint for low-cost distributed development, offshore projects, or private team labs.
On a single Proxmox VE node:
- Per-project, fully isolated network segments with VPN-secured access for remote teammates.
- Expose each project's environment to your team without risking the main LAN.
- Secure design --- no packets other than VPN tunnels traverse and DNS inquiry into your corporate or home LAN.
- Automated client provisioning: user registration, certificate generation, and VPN management via Prutunl GUI.
- GUI-based server control (start/stop per project VPN).
- No VLAN-capable switches required.
For those who just want to build it now --- jump to Quickstart.
- Grant access only to what each partner/freelancer needs, preventing cross-project leaks by design.
- Build a private development cloud for small/mid-size software firms or startups.
- Safer, faster, and cheaper than giving developers full cloud freedom.
- Entirely open-source --- all you need is one small server (even a NUC) and ~¥1,000/month for electricity.
- No vendor lock-in, no subscription required.
Equivalent commercial setups cost millions of yen with maintenance contracts.
This achieves the same goal for (almost) zero cost.
| Vendors / Product | Strength | Weakness / Gaps You Can Fill |
|---|---|---|
| Palo Alto Networks “Prisma Access” | Enterprise-grade SASE / ZTNA coverage | Overkill for small on-prem or hybrid labs |
| Zscaler “Zero Trust Exchange” | Global edge presence, strong remote-user security | Needs customization for on-prem virtualized networks |
| Check Point + Perimeter81 | Integrated Zero-Trust WAN | Complex setup, high cost for small deployments |
| StrongDM | Access management (SSH / RDP / DB) | Does not handle virtual-network segmentation or VPN-based multi-tenancy |
| JumpCloud | Wide SaaS IAM coverage | Limited to identity layer, not virtual network control |
-
Pritunl
Free to use, with optional paid features for enterprise management.
A single enterprise license covers all servers in the cluster.
→ Pritunl -
Proxmox VE
The core Proxmox VE (PVE) software is open source and licensed under the GNU Affero General Public License v3 (AGPL v3). According to the official Proxmox stance, no “license fee” is charged — meaning there is no cost required to use the software itself. Proxmox, Proxmox Forum
However, paid subscriptions (support contracts) are offered separately.
- “We already let our developers freely spin up AWS instances to build a fast, distributed development environment. Security? Well… when someone asks that, management and executives of small software houses just glance at the person in charge for help.”
- “I have my own development/lab environment at home, so I aggressively spin up VMs and develop there. Other team members? I assume they’re each figuring things out on their own?”
- “These days I use WSL and run Linux VMs on my Windows PC. Security if I lose my PC? BitLocker keeps it safe… or so they say. Everyone develops in totally different environments. Integration testing takes forever (lol).”
- “Even in large enterprises, right. Servers are in the server room with strict access control. Basically, no personal data exists in the development environment. NDAs with each employee? Yes, we enforce those. And of course you can only log in through VDI. But the root password for all VMs is the same. And because they’re all on the same segment… theoretically, if someone wanted to log in to other VMs? They could, haha.”
- “Also in large enterprises: projects that need it each have their own VPN. If you can log into one VM, could you get into others too? I haven’t checked, but I don’t think so… We’ve never had such an incident. Plus, we conduct security training twice a year.”
This project requires no public cloud services and operates entirely on local infrastructure.
Typical “Pain Points” When Development Environments Live in the Public Cloud
-
Still assigning a public IP directly to the VM and SSHing straight into it
-
Because it has a public IP, your untested web application server is actually exposed to the entire Internet
-
Development environments across projects are visible to each other
-
Spinning up a flood of instances without considering the blast radius
-
Network bandwidth dying because of large data transfers (yes, that old meme)
-
Approval → Estimation → Approval → Provisioning… What is “development speed” again?
-
“Just for testing” instances … left running for six months
-
Falling asleep waiting for builds on a weak CPU instance
Are we really safe letting application developers with low security literacy — or people who “think they understand infrastructure” — operate the cloud freely? They’re not malicious. They simply lack the mechanisms required to fulfill the responsibilities expected of them. The result: exploding costs, expanded attack surfaces, permission spaghetti, and the phenomenon of “Turns out on-prem was safer after all.”
Result: High cost, low visibility, accidental exposure.
Even with best intentions, teams lack the "systemic guardrails" that prevent human error.
Let’s compare AWS EC2 c5d.large (2 vCPUs) with a 2-vCPU VM running on an Intel NUC.
The machine used in this project: Intel NUC Pro, Core i7-1360P (12 cores / 16 threads, up to 5.0 GHz).
| Item | AWS EC2 (c5d.large) | 2-vCPU VM on NUC |
|---|---|---|
| Assigned vCPUs | 2 vCPUs | 2 vCPUs |
| Physical CPU | Xeon Platinum 8124M | Core i7-1360P |
| Physical CPU specs | 18C/36T / max 3.5 GHz | 12C/16T / max 5.0 GHz |
| RAM | 4 GB | Custom / as needed |
| Cost | $89/month (~¥13,000) | ~¥200/month electricity (for 2 vCPUs) |
| Storage | EBS (billed separately) | Local NVMe (high-speed, low-latency) |
| Network charges | Charged after 100 GB | None (local LAN) |
| Performance (2-vCPU eq.) | Baseline | ~3.3–3.5× faster in benchmarks |
> Reference benchmark score (baremetal) > | Bench | Score(8124M) | Score@1360P | > | ---------------------- | ----: | ----: | > |PassMark single thread | 2.040| 3.573| > |PassMark CPU Mark | 22.287| 20.824| > |Geekbench 4 single core | 3.954| 6.517| > |Geekbench 4 multi core | 35.420| 35.803| > > Benchmarks show \~3.3x higher performance per vCPU compared to EC2.\ Refer to : [gadgetversus](https://gadgetversus.com/processor/intel-xeon-platinum-8124m-vs-intel-core-i7-1360p/)
| Risk | Mitigation |
|---|---|
| Hardware failure | Use a secondary node with Proxmox Backup Server |
| Power outage | UPS or planned manual shutdown |
| Overheating | NUCs are rated for 35 °C continuous operation |
| Data loss | Backup to S3-compatible storage |
| Physical access | Keep servers in restricted rooms or home labs |
All open-source components --- reproducible setup from scratch.
- One Proxmox VE 9.0+ host
- Internet router (for port forwarding VPN traffic)
- Static IP (for Pritunl)
You will need to provide the following network addresses, which must be configured appropriately. If your environment has no additional subnets other than the one connected to Proxmox VE, you can generally keep the example values below as-is — except for (a) and (b), which should be set according to your actual network to avoid conflicts.
- The network address of your company or home lab’s main LAN.
- This LAN is likely connected to smart speakers, TVs, game consoles, employees’ or family members’ PCs and smartphones, as well as lab-related VMs (such as web servers, Cloudflared, Nextcloud, Samba, personal OpenVPN/WireGuard servers, Unbound DNS, etc.).
However, all VMs belonging to individual projects (VMnPJxx) are completely isolated by the PVE Firewall and vnet, ensuring secure separation. - The “Pritunl mainlan-side IP” configured later must fall within this IP range.
- Since most internet routers can only perform port forwarding to LAN-side IP addresses, it is recommended that the Proxmox VE host be connected directly under the router’s LAN segment.
- This becomes the destination IP when adding a static route to the Internet router.
- Route used by VPN clients to access development project subnets.
- Requires at least a /30 network.
- Separated for wg and ovpn. Example: 192.168.81.2–126/25, 192.168.81.129–254/25
- Further divided into /28 based on the “number of isolated development segments to be created.”
- Maximum VPN-capable clients per project is 13. For offshore distributed development, securing more would be better.
- Minimum is 2, and must be a power of two: 2, 4, 8, 16, etc.
- If the number of projects is 8: project IDs will be 01–08, and segments will be vnetpj01 to vnetpj08.
- Network segment for each project. This IP range is divided according to the “number of isolated development segments to be created.”
- Example: If the network address assigned to vnetpjxx is 172.16.16.0/20 and you are creating 8 segments, it will be divided accordingly as shown below.
- VM groups inside vnetpjxx (172.16.16.0/24) can communicate freely within that segment.
- Firewall settings for these VMs are controlled by Security Groups (SG).
- These segments are mapped to a Pritunl server instances and organization.
- This becomes the forwarding destination IP when adding port-forwarding rules on the Internet router.
- Subnet used by Pritunl clients when they exit toward each project’s subnet. Minimum /30 is sufficient but we allocate a larger /24 here.
- Number of isolated development segments (projects) × 2 = (16)
Note:
- Some routers limit the number of port-forwarding entries. For example, Buffalo routers allow a maximum of 32. Therefore, when deciding value 5, you should also consider your router’s maximum port-forwarding capacity.
- Also, if you are using IPoE with ND Proxy / MAP-E / DS-Lite, there are restrictions on available ports, so you must check in advance.
Please follow build-instructions.md
This repository includes documentation, diagrams, and configuration knowledge that are governed by the Zelogx Basic Edition EULA.
By cloning, using, or referencing this repository, you agree to the terms of the Zelogx Basic Edition EULA.
The EULA explicitly prohibits redistribution, derivative works, automation script generation based on this documentation, and competitive use.
Software snippets contained in this repository remain under the MIT License.
Documentation and architectural content are protected under the EULA.
Please make sure to review the EULA before using this project. See: EULA_Zelogx_Basic.md
Public clouds deliver global scale and strong SLAs — no argument there. But when the goal is controlled, secure, and cost-efficient team development, a well-designed on-prem environment still has a place.
This architecture proves that small software teams, SaaS startups, and serious home-lab engineers can build isolated, compliant, production-grade development labs without burning money or giving up autonomy.
Security, performance, and independence don’t have to be trade-offs. They can coexist — by design.
- Network diagram theme behavior
The color scheme of SVG-based network diagrams does not follow the Proxmox GUI theme (Light/Dark).
Instead, it respects the OS / browserprefers-color-schemesetting.
As a result, when your OS or browser is set to light mode, the diagram may appear with light-theme colors even if the Proxmox GUI is using the dark theme (and vice versa).