DEV Community: Masaaki Harada

Proxmox Multi-Tenant Guide: RBAC vs SDN vs MSL Setup (2026)

Masaaki Harada — Tue, 10 Mar 2026 12:50:01 +0000

How to Build a Multi-Tenant Environment on Proxmox for Personal / Small Office Use

Are you trying to build a carrier-grade cloud infrastructure at home with only one to three machines?

This guide organizes the practical options for creating multi-tenant or VPC-like environments on Proxmox in personal or small-office setups, from a hands-on operational perspective.

There are several ways to build a multi-tenant environment on Proxmox.

However, each approach differs significantly in learning curve, strength of network isolation, level of automation, and suitability for individual users.

This page focuses on home labs, freelancers, small development teams, and small offices.

Rather than discussing full-stack solutions designed for large data centers or commercial VPS providers, the goal here is to explore how far you can realistically achieve secure isolation using only 1–3 Proxmox hosts.

Note: This classification reflects practical operational experience and personal perspective. Use it as a reference when considering your own architecture.

1. The Short Answer

For personal or small-office Proxmox environments, multi-tenant designs generally fall into four categories:

RBAC + Resource Pools
RBAC + Resource Pools + SDN
SDN + OPNsense / pfSense + VLAN
MSL Setup (Basic / Personal)

Among these, if you want network isolation, a relatively low learning curve, and something practical for individuals, the most balanced option today is MSL Setup Personal.

On the other hand, if you simply want to start with the smallest possible setup and no additional tools, RBAC + Resource Pools is usually the entry point.

2. Comparison Table

Comparison: Alternatives for personal / small office Proxmox multi-tenant setups

Method	Learning Curve	Network Isolation	Automation	Individual-Friendly
RBAC + Resource Pools	Medium	None	GUI only	Limited
RBAC + Resource Pools + SDN	High	Partial to Strong	Manual setup	Partial
SDN + OPNsense / pfSense + VLAN	Very High	Strong	Manual setup	Partial
MSL Setup Basic	Low	Strong	Manual (Guided) setup	Excellent
MSL Setup Personal	Extremely Low	Strong	Fully automated	Excellent

3. What These Options Actually Look Like

3.1 RBAC + Resource Pools

The minimal configuration for people who want to stay within standard Proxmox features.

Suitable when

You want to share a system with relatively trusted users (family, friends, colleagues)
Network isolation is not required
You want to start with zero additional tools

What it provides

Restrict which VMs users can see
Delegate VM access through resource pools
Operate entirely through the native Proxmox GUI

Weak points

No network isolation
Tenants may still exist close to each other depending on bridge design
Limited quota and self-service capabilities
Although it looks simple, understanding path permissions, inheritance, and pool semantics can be unexpectedly difficult for beginners

In short

Good for controlled sharing, but weak for secure tenant environments.

3.2 RBAC + Resource Pools + SDN

For users who want stronger separation while staying within official Proxmox features.

Suitable when

You want to avoid additional products
You prefer to rely only on native Proxmox functionality
You are comfortable working with SDN

What it provides

Network segmentation using VNet / Zone
Tenant-level virtual network organization
Combined RBAC and network boundaries

Weak points

High learning curve
Requires understanding both Proxmox RBAC and SDN
You must design every aspect yourself:
- which VM goes into which VNet
- how traffic exits the network
- how far isolation should go
- how to mitigate potential security holes
Without automation, configuration reproducibility depends heavily on the administrator

In short

A pure-Proxmox solution, but neither the learning cost nor the operational burden is small.

3.3 SDN + OPNsense / pfSense + VLAN

The classic “serious networking” approach to isolation.

Suitable when

You understand VLANs, routing, and virtual routers
You want precise control over gateway and north-south traffic
You enjoy designing network architectures yourself

What it provides

Strong network isolation
Explicit control over multiple segments
Policy-based networking
Flexible outbound control via OPNsense or pfSense

Weak points

Very high learning curve
Requires knowledge of VLANs, routing, firewalling, NAT, policies, and VPNs
Often heavy relative to small-scale requirements
Documentation is fragmented, leading to many DIY designs

In short

A powerful solution for network enthusiasts, but not ideal for users who simply want isolation to “just work”.

Additionally, RBAC-based dashboard access must be designed separately.

Important Caveat: VLAN-Based Isolation Can Be Fragile Inside Guest VMs

One major pitfall of the OPNsense + VLAN approach is that security can become heavily dependent on how VLAN tagging is handled at the VM boundary.

If a guest VM can see a VLAN trunk, or if the virtual NIC configuration is overly permissive, a tenant inside the guest OS may attempt to manipulate VLAN settings from within the VM itself.

In such cases, maintaining strict tenant isolation becomes more difficult than it initially appears.

In other words, VLAN-based designs are not just about configuring switches and routers correctly.

You must also ensure that guest VMs themselves cannot abuse VLAN visibility or tagging behavior.

This is a major hidden risk when building DIY VLAN-based multi-tenant environments in small Proxmox deployments:

Isolation may appear correct from the outside
But enforcing it against tenant-controlled guest OS behavior can be surprisingly difficult

For this reason, approaches that define isolated virtual networks at the Proxmox SDN layer in advance can be operationally safer for personal and small-office environments.

3.4 MSL Setup Basic

For users who want strong isolation without designing SDN entirely from scratch.

MSL Setup Basic combines Proxmox SDN, firewall rules, and Pritunl to create

a structured framework for dividing a single Proxmox host into multiple isolated tenant environments.

Suitable when

You want a free solution
Following a guide is acceptable
You want tenant isolation without VLAN switches
You need isolated environments for labs, education, or client projects

What it provides

L2 isolation per tenant
VPN access per project
Add isolated environments without breaking existing VMs
Uses only native Proxmox building blocks

Weak points

Not fully automated
Requires following documented steps
Still not “zero-knowledge one-click deployment”

In short

A practical free option for building serious isolation.

3.5 MSL Setup Personal

The most practical option for individuals or small offices who want isolation with minimal learning overhead.

MSL Setup Personal is an automated setup tool that includes:

Proxmox SDN pre-configuration
Network overlap detection
VPN deployment
Automatic creation of tenant environments

Suitable when

You want to deploy quickly
You prefer not to learn SDN or VLAN deeply
You are building home labs, freelance project environments, or small team infrastructure
You want VPN connectivity included in the setup

What it provides

Network design assistance
Automatic Proxmox SDN and firewall configuration
Pritunl-based VPN environment
Multi-tenant architecture on existing infrastructure
A setup approachable even for individual users

Weak points

Not intended for large commercial VPS providers
Advanced quota and self-service features belong to the Corporate edition

In short

A solution designed to transform 1–3 Proxmox hosts into a safe multi-tenant platform with minimal effort.

4. Common Misconceptions

4.1 “Doesn't RBAC already provide multi-tenancy?”

Partially yes, partially no.

RBAC is excellent at controlling visibility, but it does not automatically enforce network-level separation.

So while RBAC can support multi-user environments, it does not always guarantee true multi-tenant isolation.

4.2 “If Proxmox has SDN, isn't that enough?”

Technically possible, but in practice you still need to design:

which zones to use
how to allocate VNets
how north-south traffic should be handled
how VPN connectivity should work
how to ensure reproducibility

In other words, the components exist, but the architecture is not predefined.

4.3 “What about PDM?”

Proxmox Datacenter Manager (PDM) is very interesting, but it primarily acts as a management plane for multiple clusters.

Its role is closer to centralized infrastructure management rather than a simple tool for creating multi-tenant environments on 1–3 small hosts.

While powerful with EVPN / VXLAN and fabric management, it can be over-engineered for small environments.

5. Which Should You Choose?

Goal	Recommendation
Simple sharing without additional tools	RBAC + Resource Pools
Pure Proxmox solution with stronger separation	RBAC + Resource Pools + SDN
Full manual network control	SDN + OPNsense / pfSense + VLAN
Free solution with structured guidance	MSL Setup Basic
Free, simple, secure multi-tenant setup	MSL Setup Personal

6. The Gap in the Market

Today the Proxmox ecosystem often falls into two extremes:

Pure native setups requiring manual design
DIY network architectures built by networking experts
Heavy enterprise platforms designed for large providers

What has been missing is a solution that:

keeps Proxmox simple while allowing individuals and small offices to create secure multi-tenant environments with minimal effort.

MSL Setup attempts to fill that gap.

7. Conclusion

When building multi-tenant Proxmox environments for personal or small-office use, the key question is not:

“Is this theoretically possible?”

but rather:

“Who can operate this safely, and with how much knowledge?”

RBAC + Pools is lightweight but weak in isolation
RBAC + Pools + SDN stays native but requires significant expertise
SDN + OPNsense is powerful but networking-heavy
MSL Setup Basic / Personal aims for a practical balance between simplicity and isolation

If your goal is to safely divide a single Proxmox host into multiple project or team environments,

MSL Setup is a realistic and practical option.

Note: I am the author of MSL Setup referenced in this guide.

How Not to Burn Out on Impossible Client Schedules (with Shadow Labs on Proxmox)

Masaaki Harada — Mon, 26 Jan 2026 05:57:49 +0000

Last updated: 2026-01-26

This post is about how freelancers and small shops can survive brutal project schedules without burning themselves and their team to the ground – by quietly preparing a separated, secure dev environment and an internal project plan of their own.

2026-01-25 Update

The “shadow lab per project” idea in this article eventually pushed me to build a small automation toolkit on top of Proxmox.

It creates multiple, securely separated project labs on a single Proxmox host, so VPN users can’t hop into your main LAN or see other projects’ VMs.

I released it as Zelogx™ Multiverse Secure Lab Setup (MSL Setup).

For anyone curious, the Personal / Community Edition is available here:

GitHub: https://github.com/zelogx/msl-setup
Overview (EN/JP): https://www.zelogx.com/

Intro: The reality for freelancers and small shops

If you join projects as a freelancer or as a head-count style subcontractor, the story often looks like this:

The prime contractor (big SI / vendor) presents a beautiful project plan and Gantt chart – with lots of hidden holes.
Most people on the receiving side don’t have enough real-world review experience to see those holes.
- Or even if they do, they’re not in a position to openly challenge the prime.
The downstream vendor follows that (usually waterfall-style) plan and:
- Does only “high-level design” during the high-level design phase
- Does only “detailed design” during the detailed design phase
Work starts while the overall system is still fuzzy, critical items are missing from the big picture, and only when the environment is finally put together does reality show up.

The result is familiar:

Requirements gaps
Unplanned work and painful change-request negotiations
“Just-barely” deadlines
Unhappy users

In an ideal world, the prime’s project plan would be shared with partners, reviewed together, and adjusted with mutual understanding.

In reality, many small-shop owners and freelancers treat that project plan as nothing more than a kickoff ritual.

At that time you should be hearing:

What risks the PM is assuming
How those risks are going to be mitigated …but for many reasons, that kind of discussion rarely happens.

So this article assumes that reality and talks about:

“If you rely only on the prime’s project plan, you will probably burn.

So as a freelancer / small shop, what kind of internal plan and shadow environment can you quietly prepare for yourself?”

1. Assume the prime’s project plan is the PM’s “wish list”

First, an important mindset:

The prime’s project plan is essentially

“what the PM wishes would happen.”

Usually you won’t see much about:

When the production architecture will actually be finalized
How much of that will be reproduced in test
What exactly will be tested at each stage

In other words, safety margins and risk-mitigation on the ground are mostly absent.

In more extreme cases you’ll see plans where:

There is no proper requirements-definition phase
Deliverables per phase are not defined
There is no real high-level / functional / detailed / operations design – you jump straight to “parameter sheet”
Someone says “we already did a PoC, so let’s just build it, we don’t really need formal design, right?”
It’s not even a production cut-over, but staging is treated as production with almost no time or resources set aside
Implementation window is strangely short (3 weeks), yet you’re supposed to:
- Build the environment
- Implement features
- Test
- Write test specs
- Do code review
- Write test reports
There is no security design or secure-coding guideline, and only at the very end a vulnerability scan blows everything up

You may have seen project plans like this. (This is just a partial list.)
And the boss says something like:

“I got us this job; just shut up and do it.”

Realistically, the prime should be the one to sort this out.

But they also have to chase revenue to survive.

The problem is: if you just ride along, you’ll probably burn in the second half.
So for freelancers and small shops, it becomes very important to:

Respect the “external project plan” as a public contract,

but quietly maintain your own internal plan behind the scenes.

I’m not saying you must suddenly start writing a 50-page project plan of your own.

I’m also not saying you must instantly master reading huge Gantt charts like a senior PM.

There is a much simpler, more practical way.

2. Technique #1 – Build a “shadow prototype environment” early in high-level design

The first technique:

During the early high-level design phase,

quietly build a shadow prototype environment on your side that mimics the production setup.

What I mean by “prototype environment” is a set of boxes that:

Use the OS you expect to use in production
Include the key middleware (app server, reporting platform, etc.)

…built in a way that’s as close to the real production architecture as you can reasonably guess at that point.

In almost any moderately sized system, you’ll eventually need things like:

GitLab or some kind of source-control / CI/CD platform It helps to prepare at least that much from the beginning.

Why this matters

If you do this, you can:

Notice big design holes early, like:
- “We are missing a reverse proxy here, aren’t we?”
- “With this structure we actually need another DB.”
Even if the prime’s high-level design is fuzzy, you can see a working big picture with your own eyes. And please, keep the build notes and setup steps for this prototype. Rough notes are fine; you just need something you can explain later.

With those notes and the original requirements, you can often write the actual high-level design document in 2–3 days later.

Formatting and polishing are painful, but LLMs can help with that part.

The key mindset is:

Not: “In the high-level design phase I only write documents, because that’s what the plan says.”
But: “In the early part of high-level design, I secretly build and run a prototype environment.” You quietly re-order the internal steps.

You don’t have to tell anyone.

(That step doesn’t exist on the official plan, so there’s nothing to report.)
This is purely insurance so you don’t burn later.
Also, you don’t necessarily need a big new budget for this.
At the beginning of projects there is often a lot of “waiting time”:

Requirements not finalized yet
Basic policies still under discussion
Kickoff is next week

You can use those gaps – or long meetings where you’re mostly a listener – to make partial progress on your shadow env.

In other words:

Use idle time to build at least a partial, working prototype.

It’s like secretly running a mini-agile loop under the waterfall plan.

3. Technique #2 – Push for an early “version-pinning meeting”

There is one big trap when building prototypes early:

Versions change later and you have to rebuild everything.
If you have good build notes, this isn’t fatal—but we’d still prefer to minimize rework.
To avoid that, it helps to quietly insert an early:
“Version pinning meeting”
…during the start of the high-level design phase.

At minimum, try to get provisional agreement on:

OS version (major + minor, if possible)
Key middleware (app server, reporting, batch platform, etc.) and their versions
Support situation for each (EoL, vendor support or not, OSS community activity, etc.)

It doesn’t have to be perfect

The important point is:

This is not a promise that versions will never change.
It’s a “let’s at least assume this for design and estimation” kind of agreement.

Later you will still get:

“Security says this version isn’t allowed…”
“The antivirus vendor doesn’t officially support this OS…”

That’s life. You adjust when necessary.
But having that early baseline makes your shadow prototype much less likely to be total rework.

4. Technique #3 – Don’t talk about the prototype; frame it as “experience from other projects”

This one is surprisingly important.
Once you have a shadow environment and some performance numbers, you will be asked questions like:

“How many CPU cores do we need for this?”
“Roughly how many users can this handle?”
“What kind of machine size should we provision?”

In reality, you’ve already measured quite a bit in your prototype.

But you don’t have to say:

“We secretly built a production-like environment on our own and ran load tests!”

In fact, it’s usually better not to say that.
This is about expectation management.

How to talk about it externally

You can phrase it like:

“Based on experience from similar-sized systems we’ve built, CPU usage stayed around X% at this level of load.”
“Looking at previous projects with a comparable architecture, starting with this instance size seems reasonable.”
“From projects with similar business load, this spec should give us enough headroom for the initial phase.”

In practice, one of those “previous projects” is… your very current shadow lab.
From outside, though, that’s perfectly fine to present as “experience.”
The balance is:

Internally, you measure properly.
Externally, you don’t oversell “We did EVERYTHING for you.”
You present it as: “We’re using past experience to suggest a realistic range.”

5. Technique #4 – Write down steps as if you’ll feed them to an LLM later

This is a trick that only became powerful in the last few years.
When you build the shadow environment, focus on how you leave behind your notes, more than on writing the “perfect” design doc.

Why? Because:

If you feed those notes to an LLM,

you can get a surprisingly solid draft high-level design in very little time.

The pattern looks like:

Build the shadow environment.
While doing that, jot down:
- Install steps
- Middleware settings
- Where you got stuck and how you solved it
Later, give those notes to an LLM and say:
- “Propose a structure for the high-level design document.”
- “Rephrase this for client-facing language.”
- “List likely test items.”
- “Generate a first draft of the parameter sheet.”
Suddenly, what used to take 2–3 days now takes hours.

So:

“First build the prototype”

plus

“Leave decent notes assuming you’ll feed them to an LLM”
…becomes a strategy that:

Reduces implementation risk, and

Shrinks documentation effort at the same time. ---

6. Run a secret agile loop under a waterfall surface

If we sum up the story so far:

On the surface you follow waterfall,

but underneath you quietly run small agile cycles to stay ahead.
On the surface:

You appear to follow the big waterfall plan the prime gave you.

Milestone names and deliverables match: high-level design, detailed design, integration test, etc.

Under the hood:

During high-level design you already:
- Build and run the prototype
- Pin down versions
- Lock in a working architecture early
Using that, you can quickly provide:
- Performance estimates
- Resource estimates
- Clear lists of risks

So even though the official methodology looks like pure waterfall,

internally you’re continuously reducing uncertainty in advance.

This doesn’t mean:

“You may delay the prime’s master schedule.”
Quite the opposite:

Because you already have a working prototype,

You are less likely to cause schedule slips later. You’re lining up the dominoes so they fall in your favor.

7. “We don’t have time to build a custom environment for every project”

At this point you might be thinking:

“I get the idea, but building a fresh prototype environment for every project is too heavy.”
And you’d be right.

For freelancers and small shops, it’s pretty tough to:

Rebuild OS, middleware, auth flows, and test clients
From scratch
For every new project So once you start getting a steady stream of work, it’s worth considering: > Building a template or tooling that lets you quickly spin up > “per-project sandbox environments.”

For example:

Keep one physical machine somewhere that has:
- A virtualization platform
- Scripts or tools to auto-create “project sandboxes”
When a new project starts, first spin up a shadow environment in ~30 minutes, then start design.

The actual tools / stack don’t really matter.

What matters is the mindset shift:

From “hand-craft a new environment every time”
To “instantiate a per-project sandbox from templates”

…and making sure that:

Partners can easily join via VPN, and
VMs from one project never leak into another project’s view.

One concrete implementation: MSL Setup on Proxmox

The ideas in this article are technology-agnostic, but in my own work I wanted something concrete, so I built:

Zelogx™ Multiverse Secure Lab Setup (MSL Setup)

It runs on a single Proxmox host and:

Builds per-project, L2-isolated dev labs (PJ01, PJ02… style)
Uses:
- Proxmox SDN simple zones + VNets
- Proxmox firewall security groups
- Pritunl as per-project VPN entry points

So when a new project comes in, I can:

Spin up an isolated lab quickly
Let external members in via VPN
Know they can’t see other projects’ VMs

If you’re curious how that looks in practice:

GitHub (Personal / Community Edition – free for individuals): https://github.com/zelogx/msl-setup
Overview & docs: https://www.zelogx.com/

Conclusion

For freelancers and small software shops, trusting only the prime’s project plan is a good way to get burned.

Instead, it helps to:

Maintain your own internal project plan, separate from the client-facing one
Quietly build a prototype environment early in high-level design
Lock down OS and middleware versions as early as reasonably possible
Treat numbers from your prototype as “experience from similar projects” rather than “we secretly built a lab just for you”
Leave good notes and let LLMs handle a lot of the document boilerplate
Outwardly follow waterfall, while inwardly running small agile loops to stay ahead

These aren’t “perfect textbook best practices.”

They’re more like street-level survival tactics picked up from real projects.
But if you stack enough of these small tricks, you’ll start to notice a difference in:

How often projects catch fire
How satisfied your users end up
How exhausted you and your team feel at the end If you’re in the “the prime’s plan is a mess but I still have to ship” club, I hope this gives you a few ideas for building your own safety net.

DEV Community: Masaaki Harada

Proxmox Multi-Tenant Guide: RBAC vs SDN vs MSL Setup (2026)

How to Build a Multi-Tenant Environment on Proxmox for Personal / Small Office Use

1. The Short Answer

2. Comparison Table

Comparison: Alternatives for personal / small office Proxmox multi-tenant setups

3. What These Options Actually Look Like

3.1 RBAC + Resource Pools

Suitable when

What it provides

Weak points

In short

3.2 RBAC + Resource Pools + SDN

Suitable when

What it provides

Weak points

In short

3.3 SDN + OPNsense / pfSense + VLAN

Suitable when

What it provides

Weak points

In short

Important Caveat: VLAN-Based Isolation Can Be Fragile Inside Guest VMs

3.4 MSL Setup Basic

Suitable when

What it provides

Weak points

In short

3.5 MSL Setup Personal

Suitable when

What it provides

Weak points

In short

4. Common Misconceptions

4.1 “Doesn't RBAC already provide multi-tenancy?”

4.2 “If Proxmox has SDN, isn't that enough?”

4.3 “What about PDM?”

5. Which Should You Choose?

6. The Gap in the Market

7. Conclusion

Related

How Not to Burn Out on Impossible Client Schedules (with Shadow Labs on Proxmox)

2026-01-25 Update

Intro: The reality for freelancers and small shops

1. Assume the prime’s project plan is the PM’s “wish list”

There is a much simpler, more practical way.

2. Technique #1 – Build a “shadow prototype environment” early in high-level design

Why this matters

3. Technique #2 – Push for an early “version-pinning meeting”

It doesn’t have to be perfect

4. Technique #3 – Don’t talk about the prototype; frame it as “experience from other projects”

How to talk about it externally

5. Technique #4 – Write down steps as if you’ll feed them to an LLM later

6. Run a secret agile loop under a waterfall surface

7. “We don’t have time to build a custom environment for every project”

One concrete implementation: MSL Setup on Proxmox

Conclusion