You all had other plans.

You Made Me Do This

A few days ago I published a post (and video) about a project I vibe-coded over a handful of nights using Claude Opus inside VS Code — a unified MikroTik management platform. Something like UniFi or Meraki, but for MikroTik hardware. I fully expected the response to be split between people who were excited about the concept and people who were ready to tar and feather me for writing production code with AI. And honestly, it was. But what I did not expect was over 70 comments asking me to open source and release the project.

Seventy. I’ve been doing this long enough to know that the community doesn’t usually agree on anything in that kind of volume or with that kind of consistency. So I listened.

MikroTik Manager is now live on GitHub.

Before we get into the how-to, I want to set some expectations up front, because I’d rather be honest with you than have you feeling burned later.

Setting Expectations: This Is a Beta Release

This is version 0.10.0 Beta. It works. I’ve been running it in my own homelab and I use it regularly. But it is beta software, and it was built by one person with an AI assistant over a few evenings — not by a team of engineers who went through a formal development and QA process.

Updates will happen on my schedule. I’m a dad, I work in IT full-time, and I make videos on the side. When I feel like adding features or fixing bugs, I will. I’m not committing to a roadmap, a release cadence, or SLA of any kind. If that’s a dealbreaker for you, I totally get it — but I wanted to be upfront rather than ghost a community that’s shown this much interest.

What I will say is this: contributions are welcome. If you’re a developer and you want to add something, fix something, or improve something, the door is open. More on that later.

With that said — let’s talk about what this thing actually does, because I think you’re going to like it.

What Is MikroTik Manager?

MikroTik Manager is a self-hosted, full-stack network management platform for MikroTik devices. It gives you a single web interface — a real one, with a modern UI — to monitor, configure, and manage your entire MikroTik infrastructure: routers, switches, and wireless access points.

If you’ve been relying on Winbox, the built-in web admin (which is basically Winbox in a browser), or raw SSH to manage your MikroTik gear, this is meant to be a significant quality-of-life upgrade. It communicates with your devices via the RouterOS API and SSH, so no agents, no special firmware, and no changes to your existing network are required beyond enabling the API service on each device you want to manage.

Features: The Full Breakdown

Let me walk you through everything the platform does right now, section by section.

Dashboard

The dashboard is your command center. At a glance you get:

• Live KPI cards — total devices in the system, online vs. offline count, total connected wireless clients, and active alert count
• Device type distribution chart — a quick visual breakdown of routers vs. switches vs. APs in your environment
• Historical client count graph — track connected client counts over time with adjustable ranges from 1 hour out to 30 days
• Firmware update notifications — if any of your devices have a newer firmware version available, it shows up here with per-device detail

This is the view I have open most of the time. It gives you a fast health check of the whole environment without having to dig into individual devices.

Device Management

Adding a device is straightforward: give it a name, IP address, credentials, and API port, and the platform takes it from there. From that point on, it polls each device automatically for status, model, firmware version, and RouterOS version.

Beyond the basics, each device supports:

• Per-device notes — document whatever you want about that piece of gear
• Rack location — record the rack name, slot, and physical address
• Map integration — enter a physical address and the platform generates a map pin for that device, which also populates a global map on the dashboard showing where all your gear lives
• Credential encryption at rest — device passwords are encrypted in the database, not stored in plain text

The device list gives you a quick view of all your hardware: names, IPs, model, firmware, status, last-seen timestamps, and controls to refresh or remove a device.

Per-Device Views

Each device has its own detail page with multiple tabs. Here’s what each one covers.

Overview

The overview tab is the first thing you land on for any device. You get:

• Cards for current CPU load, memory usage, uptime, and OS version
• A full system info card covering everything from the model and firmware version down to the device type, API port, and when it was last contacted
• The physical details card for rack and location info
• An in-line map from the physical address you entered
• Buttons to open the device’s native web admin, launch a draggable in-browser SSH terminal directly to the device, and force an immediate configuration sync

That SSH terminal is one of my favorite features. You’re already in the management platform — being able to drop to a terminal on the device without opening a separate SSH client is a genuine quality-of-life improvement.

Ports (Switches)

This tab is where I spent the most time during the build, and it shows. The platform has no hard-coded knowledge of MikroTik hardware models. When you add a switch, it pulls port data from the device and dynamically builds a visual port diagram that represents the actual physical hardware layout. Port states are color-coded: red for offline, green for online, blue for selected.

Below the diagram is a full port list showing name, status, speed, MTU, default VLAN, MAC address, comments, and a per-port reload control.

Selecting a port drops you into:

• Throughput and packet graphs with 1, 3, 6, 12, and 24-hour time range selectors
• Detailed port info: state, rate, duplex, auto-negotiation, RX/TX flow control
• Transceiver details — for SFP+ ports, it identifies the connected cable type and reports all available optic information from the transceiver

Port configuration is done directly in the interface — enable/disable, comment, MTU, PoE settings (where supported), link settings, and VLAN assignment. Select multiple ports at once to configure LAGs and LACP trunks in a single operation.

VLANs (Switches)

A clean list of all configured VLANs, their IDs, names, associated bridges, and a tagged/untagged port breakdown per VLAN. Each row has edit and delete actions inline. The Add VLAN button opens a creation dialog to define a VLAN ID, associate it to a bridge, and assign tagged or untagged ports — no CLI required.

Routing (Routers)

For devices in router mode, this tab surfaces full routing management:

• Route table — view and manage static routes
• OSPF — configuration and management
• BGP — configuration and management
• Route Filters and Route Tables

Firewall

MikroTik’s firewall capability is powerful, but navigating it in Winbox is not fun. This tab surfaces all configured firewall rules in a readable format and lets you create and manage rules through the UI.

Config

Your one-stop shop for device-level settings:

• Device name
• Date, time, timezone, and NTP server
• DNS servers
• Management IP configuration
• Built-in firmware update checker — click the button, find out if there’s a new version, and if there is, you can install it and reboot the device directly from the platform

Hardware

Rich telemetry for the physical device:

• CPU and memory usage graphs with 6h, 12h, 24h, and 7-day ranges
• Internal storage details and utilization
• Temperature readings from all available sensors, with Fahrenheit/Celsius toggle for my friends outside the US
• Fan status and RPM for all internal fans
• Power supply status
• Voltage monitoring for barrel-powered and 2-wire devices

Tools

I wanted the platform to actually be useful for troubleshooting, so these diagnostics are built in:

• Reboot the device
• Ping any address from any interface on the device
• Traceroute from the device
• IP Range Scan with optional reverse DNS lookups
• Wake-on-LAN — transmit a WOL packet from the switch to any MAC address on your network

Wireless Management

The wireless section is one of the more fully-featured parts of the platform, especially if you’re running MikroTik APs alongside your switches.

Per-AP SSID management — Create, edit, enable/disable, and delete wireless interfaces on individual APs directly from the UI. No Winbox, no SSH.

Bulk SSID deployment — This is the one that will save you real time if you have more than a couple of APs. Push an SSID configuration to all managed APs simultaneously with a single action. Want every AP to have a guest SSID with consistent settings? Do it once instead of once per device.

Security profile management — WPA2/WPA3, PSK, and EAP configurations managed from the platform.

Hardware radio information — Band filtering and hardware radio details for both the RouterOS 7 wifi package and the legacy wlan package, so it works with older deployments too.

Spectral scans — Schedule or trigger on-demand spectral scans per radio to see what’s going on in the RF environment around your APs.

AP scans — Schedule or run on-demand scans for nearby access points. Useful for surveying the wireless landscape and identifying interference sources.

Real-time radio monitoring — Live radio status as you’d expect.

Wireless client tracking — All wireless clients with vendor lookup via OUI database. Know what’s connected and who made it.

Network Services

This is where the platform goes from “nice device manager” to “real infrastructure tool.” Four core network services are managed from a unified interface, and each one supports multi-device management with conflict detection — meaning you can manage the same service across multiple MikroTik devices without stepping on yourself.

The WireGuard management in particular is something I’ve wanted in a homelab tool for a long time. Having it alongside DHCP, DNS, and NTP in one place is genuinely useful.

Network Topology

The topology view builds an auto-discovered network map of your infrastructure using LLDP, CDP, and MNDP neighbor data pulled from all connected devices. The result is an interactive node graph with device type icons and protocol-priority link deduplication — meaning if two devices report the same link via multiple protocols, you see one clean connection, not three overlapping ones.

It’s one of those features that’s genuinely impressive to look at the first time your topology renders correctly.

Client Tracking

The clients section aggregates all known network clients seen across every device in the system into a single view. You can filter by device, client type, or active status, and search by MAC address, IP, or hostname. Each client has a detail page with connection history and vendor identification from the OUI database.

A historical client count metric gives you trend data over time — useful for spotting unusual spikes in connected devices.

Backups

Trigger RouterOS configuration backups on demand via SSH for any connected device. Backup files are stored within the platform and can be downloaded or deleted from the UI. Simple, but the kind of thing that matters when something goes wrong at 2am.

Alerts

Configurable alert rules with cooldown periods so you’re not getting hammered with repeat notifications:

• Device online / offline events
• High CPU or memory usage (with configurable thresholds)
• SSL certificate expiry warnings
• Firmware update available
• RouterOS log errors and warnings
• New device discovered on the network

Global Search

A universal search bar in the top navigation lets you search across devices, clients, and events from anywhere in the platform. Type an IP, a MAC address, a hostname, or a device name and it returns relevant results instantly.

User Management and Access Control

Multi-user with role-based access control:

• Admin — full access to everything, including user management
• Operator — read/write access to devices and network features, no user admin
• Viewer — read-only access

JWT authentication with secure session handling. Admin-only user creation and role assignment. Default credentials on first run are admin / admin — change these immediately.

TLS / HTTPS

The platform generates a self-signed certificate automatically on first run, so you’re on HTTPS out of the box. If you have a real certificate (from Let’s Encrypt or your internal CA), you can upload it through the Settings UI. nginx handles TLS termination and automatic HTTP→HTTPS redirect.

The Tech Stack

Here’s what’s running under the hood, for those who want to know what they’re deploying:

Everything ships as a Docker Compose stack. PostgreSQL for relational data, InfluxDB for the time-series metrics that power all the graphs, Redis for caching and the job queue, and nginx in front of everything. It’s a real stack — not a SQLite file and a Python script.

Requirements

Before you deploy:

• Docker and Docker Compose v2+ on the host you’re deploying to
• MikroTik devices running RouterOS 6.x or 7.x with the API service enabled
• Network access from the host running MikroTik Manager to your devices on port 8728 (or your configured API port)

That’s it. No special networking, no agents on the MikroTik side, just the RouterOS API service turned on.

Quick Start

1. Clone the Repository

git clone https://github.com/2GT-Media-Group-LLC/mikrotik-manager.git
cd mikrotik-manager

2. Configure Your Environment

cp .env.example .env

Open .env and at minimum change these two values — and I mean it, actually change them:

JWT_SECRET=your_long_random_jwt_secret_here
ENCRYPTION_KEY=your_32_character_encryption_key_

The JWT_SECRET signs your authentication tokens. The ENCRYPTION_KEY is the key used to encrypt device credentials at rest in the database. If you leave these as the defaults and your box is ever compromised, you’ve given away the keys to your network. Use a password manager to generate proper random strings.

The other defaults are fine for a local homelab deployment:

Never commit your .env file to version control. The .gitignore already excludes it, but worth saying explicitly.

3. Start the Stack

docker compose up -d

On the first run, Docker will:

• Build the React frontend into static files
• Build the TypeScript backend into a Node.js application
• Initialize PostgreSQL with the database schema
• Initialize InfluxDB
• Generate a self-signed TLS certificate

This takes a few minutes the first time. Once it’s done:

4. Open the App

Navigate to https://localhost (or your server’s IP or hostname). Accept the self-signed certificate warning in your browser — or upload a real certificate in Settings → TLS Certificate if you want to skip that permanently.

5. Log In

Go to Settings → Users and change the admin password before you do anything else.

Updating

When a new version drops:

git pull
docker compose up -d --build backend nginx

Database migrations run automatically on backend startup, so there’s nothing else to do.

A Word on Security

I know some of you are already typing the comment. “This was vibecoded, how do you know it’s secure?”

Fair question. Here’s my honest answer: I don’t have a penetration test report for this. What I can tell you is that it was built with secure practices in mind — credentials encrypted at rest, JWT-based auth, HTTPS enforced, role-based access control. But this is beta software. Don’t expose it directly to the internet. Run it inside your homelab, behind a VPN, or behind an authenticated reverse proxy if you need remote access. The same rules you’d apply to any self-hosted management tool apply here.

If you find a security issue, open an issue on GitHub. I’d rather know about it.

Contributing

The project is open source under the AGPLv3 license. If you want to contribute:

1. Fork the repository
2. Create a feature branch: git checkout -b feature/your-feature
3. Commit your changes
4. Open a pull request

The one ask: open an issue before submitting a PR so we can discuss the approach first. Nothing worse than putting real time into a feature only to have it not fit the direction of the project.

If you’re not a developer but you find a bug, open an issue. That’s contributing too.

The AGPLv3 license means the code is free to use, modify, and distribute. If you run a modified version as a hosted service, you’re required to make your modified source available to users of that service under the same license. I chose AGPLv3 specifically to make sure improvements stay in the open.

What’s Next

I’ll be honest with you: I don’t have a formal roadmap. The topology view needs more polish. There are probably bugs I haven’t hit yet. And I’ve got a list of features I’d still like to add when I find the time — but I’m not making promises about when that happens.

What I do know is that the foundation is solid. The stack is real, the features are genuinely useful, and it’s the tool I actually run in my own homelab. That’s the best endorsement I can give it.

If enough of you use it, find issues, and contribute fixes, it’ll get better faster. That’s the whole point of open source.

Head over to GitHub, give it a star if you find it useful, and let me know in the comments how it goes in your environment. And if you missed the original post about how this whole thing came to be — including the part where I have a mild existential crisis about AI — check that one out first.

Thanks as always to everyone who’s supporting us through Patreon and the YouTube Membership program — none of this happens without you. Come hang out in the community Discord if you want to talk through your setup or just want to nerd out with like-minded homelabbers and engineers. We’ll see you on the next one!

In all the years I’ve been working on my homelab, working in IT, and making videos, I don’t think I’ve ever been as personally conflicted as I am right now. I’m equally 50% excited and stunned, and 50% uneasy and uncomfortable with what I’m about to show you. Stick around, friends — this one’s gonna be an interesting one.

Introduction

Hey there homelabbers, self-hosters, IT-pros, and engineers. Rich here! A few days ago, I created something that didn’t exist. I did it on a whim just to see if I could, and what resulted inadvertently completely changed how I feel about homelabbing, what I think about the future, and how I feel about AI and the future of creating.

For those of you who are regular viewers, you’ve probably heard me talk a lot more about AI in the live show. Recently I put together a local AI stack running Ollama and Open WebUI, and while that’s been a fun side project, it really hadn’t moved the bar for me in terms of how I felt about using or creating with AI.

Then a few weeks back, PegaProx hit the scene, and I made a video about it because I was truly impressed by what that small team of three people built. The comments were split — plenty of people pushed back hard on vibecoding, argued about security concerns, and insisted the original Proxmox UI was good enough. But there was no shortage of positive reactions either. No matter how you feel about AI in software engineering, it’s hard to argue with what PegaProx produced, because what they made is objectively incredible.

That experience sent me down my own path.

The Problem: Mikrotik is Powerful and Painful

I started looking around my homelab and seeing problems I could potentially solve. I landed on one that’s been bothering me for a while: Mikrotik.

I love my UniFi stack — the gear is good, it’s self-hosted, and the single pane of glass is great. But Ubiquiti’s higher-end switching is expensive, and their stock availability has been a recurring headache. My alternative is a Mikrotik switch with dual 100Gig ports and 8 25Gig ports — and that little switch costs less than $1,000. It runs my entire backbone between my Proxmox server and my TrueNAS storage server.

The fact that a mere mortal can have native 100Gig throughput between two servers, with 8 25Gig ports left over, for under a grand is absolutely mind-blowing. But there’s a massive catch.

Mikrotik is kind of a household name in Europe, and the hardware and features you get for the price can’t be matched anywhere I know of. But if I’m being blunt: configuring and managing these devices is a huge pain in the ass. Your options are their Winbox software, the built-in web admin (which is effectively the same as Winbox), or straight SSH. None of these options are anywhere near user-friendly, and unless you’re patient and have strong Google-fu, you’re going to struggle.

The Idea: A UniFi-Style Manager for Mikrotik

Punch drunk off the possibilities I’d seen with PegaProx, I decided to see if I could vibe-code a singular management platform — something like UniFi or Meraki — for Mikrotik hardware. A single pane of glass that lets me configure, manage, and monitor at least 85% of the general functionality you’d expect from those other platforms.

After talking through AI project ideas with friends, doing some light research, and a fair bit of just winging it, I decided to build using Claude Opus 4.6 inside Visual Studio Code. I signed up for a $20/month Claude Pro subscription, integrated it into VS Code, and sat down to give it a shot.

The Prompt

The hardest part was articulating exactly what I wanted. Here’s the prompt I ultimately landed on:

“I have network devices made by a company called Mikrotik. I want to build a unified, singular management system that allows me to configure, manage, and monitor all aspects of Mikrotik devices. I need to be able to add the devices to the system, configure their addressing, ports, VLANs, and monitor port traffic and device health. I want the system to display a port diagram for the device with selectable ports for individual configuration, as well as be able to select multiple ports for mass editing of port configs.

I want a dashboard landing page that shows overall device status and health, active clients, and aggregated alerts from the devices.

I want the system to be multi-user, with the ability to assign users to roles like admin and read-only.

Lastly, I want this deployed using Docker containers. The system you’re running on has Docker installed for you to test in, and I want the platform written using modern frameworks with a modern look and feel.

Ask any questions you have.”

Then I pressed enter.

The Build: 3–4 Nights of Iteration

Over the course of a few days, working on and off, I collaborated with Claude as it built and deployed the platform. I’d test, find bugs or design elements I didn’t like, Claude would fix them, and we’d keep going. The process was deeply iterative — I’d have a deployed feature I liked, realize I wanted something additional, tell Claude, it would implement it, and around and around we went.

I even went out and bought another cheap Mikrotik device, put it in router mode, and added it to the platform specifically so I could work with Claude to add router management features. All of this while writing video scripts, playing D&D with friends, and watching Plex.

In the end, I had something that blew me away. Never in my wildest dreams could I have imagined the finished product I created.

Mikrotik Manager: A Full Walkthrough

Login and Dashboard

The login screen features a living, animated network-like pattern that dynamically changes on every page load — inspired by Nutanix Prism. Dark mode is, of course, included, and it looks particularly sharp against the animation.

Once logged in, you land on the Dashboard with a familiar layout: collapsible left navigation and content on the right. At the top sits a universal search bar — type in IP addresses, device names, events, and the system returns matching results instantly.

The main dashboard area includes:

• Macro cards for total devices, active clients, alerts in the last 24 hours, and online vs. offline device counts
• A running graph of total connected clients detected across the network
• A device type breakdown pie chart
• A map showing the physical locations of all added devices
• A recent events card showing aggregated logs from all devices, filterable by error, warning, and info level

Device Management

The Devices section lists all added Mikrotik hardware with names, IP addresses, model, firmware version, status, last-seen timestamps, and refresh/delete controls. Adding a device is as simple as clicking Add Device, filling in the connection details, and saving.

Each device has its own detail view:

Overview Tab

• Cards for current CPU load, memory usage, device uptime, and OS version
• A detailed system info card: name, IP, model, OS version, firmware version, device type, API port, date added, and last contact
• An editable physical details card for location, rack name, rack slot, and notes
• A map generated from the entered physical address — the same data that populates the main dashboard map
• Buttons to open the device’s web admin, launch a draggable in-browser SSH terminal directly to the device, and force an immediate configuration sync

Ports Tab

This is the part I’m most proud of. The manager has no built-in knowledge of Mikrotik hardware models. When you first add a device, the system pulls port details from the switch and dynamically builds a visual port diagram representing the actual hardware. Port states are color-coded: red for offline, green for online, and blue when selected.

Below the diagram is a full port list showing name, status, speed, MTU, default VLAN, MAC address, comments, and a per-port reload button.

Selecting a port gives you:

• Throughput and packet graphs with 1, 3, 6, 12, and 24-hour time selectors
• Detailed port info: state, rate, duplex, auto-negotiation, RX/TX flow control
• Transceiver details — for SFP ports it will identify the connected cable type and report all available optic information

Configuring a port is done directly in the interface — enable/disable, comment, MTU, PoE (if supported), link settings, and VLAN configuration. Select multiple ports together and you can configure LAGs and LACP trunks from the same view.

VLANs Tab

A full list of configured VLANs, their IDs, names, associated bridges, and a tagged/untagged port breakdown per VLAN. Each row has edit and delete actions. The Add VLAN button opens a creation card to define a VLAN ID, associate it to a bridge, and assign tagged or untagged ports — all without touching the CLI.

Routing Tab

For Mikrotik devices running in router mode, this tab surfaces full routing functionality:

• Route table for managing static routes
• OSPF configuration and management
• BGP configuration and management
• Route Filters and Route Tables

Firewall Tab

All Mikrotik devices have built-in firewall capability. This tab lets you view, manage, and create firewall rules through the UI — no Winbox required.

Config Tab

Your one-stop shop for device-level settings:

• Device name editing
• Date, time, timezone, and NTP server configuration
• DNS server configuration
• Management IP address configuration
• Built-in update checker — click Check for Update, and if a new firmware is available, you can install and reboot the device right from the platform

Hardware Tab

Rich hardware telemetry for the device:

• CPU and memory usage graphs with 6, 12, 24-hour, and 7-day time scales
• Internal storage details and utilization
• Temperature readings from all available sensors, with Fahrenheit/Celsius toggle for my metric friends outside the US
• Fan status and RPM for all internal fans
• Power supply status
• Voltage monitoring for devices powered via barrel connectors or 2-wire interfaces

Tools Tab

I wanted the platform to be a real troubleshooting tool, so I surfaced the diagnostics already built into Mikrotik hardware:

• Reboot the device
• Ping any address from any interface on the device
• Traceroute from the device
• IP Range Scan with optional reverse DNS lookups
• Wake-on-LAN packet transmission from the switch

Beyond Devices: The Rest of the Platform

Clients — All known network clients seen by any Mikrotik device in the system. Each entry is configurable with custom names, and reverse DNS names auto-populate if you have DNS configured on your network.

Events — Aggregated logs from all connected hardware, searchable and filterable by topic, log level, and individual device. A clear button lets you wipe all stored events.

Topology — Still a work in progress. I’m building a dynamic network topology map from LLDP data pulled from all connected devices. The foundations are there and it’s kinda-sorta working — I just need to spend more time with Claude ironing out interface mapping and data interpretation.

Backups — Create configuration backups for any connected device, stored within the platform. Download, restore to the source device, or delete — all from the UI. This was actually the very first feature I built.

Switches / Routers — Dedicated sections that aggregate all switch-type or router-type devices respectively, with macro cards linking back to individual device pages. Each section has its own Settings tab for platform-wide configurations like LLDP and SNMP that are applied globally to all devices of that type.

Platform Settings — Control system-wide defaults:

• Default theme
• Backend polling intervals
• MAC scan settings (with enable/disable toggle)
• Automatic reverse DNS lookup (with enable/disable toggle)
• Maximum event data retention in days
• Users and Roles — manage user accounts, assign roles (Admin, Operator, Read-Only), create passwords
• My Password — self-service password change for the current user

The Dilemma: The Excitement Wore Off

You’d think building something like this and seeing how well it turned out would fill me with only pure joy. It didn’t — not entirely.

After the excitement wore off, it left me genuinely conflicted. For more than a few nights, I’d be lying in bed thinking of the next cool feature to add, only for a wave of existential dread to follow. I spent real time trying to figure out what those feelings were, and the best I can describe them is fear.

Anthropic — the company behind Claude, the AI I used to build this — published a report on the current and projected effects of AI on the labor market. It doesn’t paint a rosy picture for skilled technology workers in the long run. And we’re all seeing the headlines: large tech companies announcing layoffs while simultaneously pouring that headcount savings directly into AI programs. It’s hard not to feel like AI is a slow-moving threat, growing quietly until it’s turned loose on all of us as a weapon of corporate cost-cutting.

I don’t have the answers. There’s nothing I can personally do to control the future — only the decisions I make. Here’s what I’ve come to accept: it doesn’t matter if you don’t like AI, or think vibecoding is trash. These tools are coming, faster than anything I’ve seen move in my adult life. For me, the only real option is to embrace them as quickly as possible.

The Realization: I’m No Longer Just a Consumer

Building the Mikrotik Manager hit me with something that hadn’t occurred to me before. All these years of homelabbing, I’ve been a consumer. If something didn’t exist, I couldn’t create it — I’m not a software engineer, so everything I’ve run has been the fruit of someone else’s labor. That was just the way it was.

But not anymore. Now I can build the things I actually want.

The analogy that keeps coming back to me is 3D printing. Before I got into 3D printing, if I needed something, I’d go to Amazon and hope someone else had already made it. With a printer, if I need a specific part or have a crazy idea, I design it, print it, realize my measurements were off, redesign it, print it again, and eventually I have exactly what I needed. No compromises, no waiting.

Creating with AI is exactly that. The accessibility barrier is lower, the iteration cycle is faster, and now my homelab can run things I built myself, customized exactly to my needs. I no longer have to wait for the next cool open source project to drop. I can create that project.

“But Is It Secure?”

I can already hear a significant portion of you screaming at the screen: “Your vibecoded apps aren’t secure!”

You might be right. But here’s the point I think everyone is missing:

I wouldn’t 3D print a structural load-bearing component, bolt it onto an aircraft, and fly in it without extensive testing. Likewise, I wouldn’t deploy a vibecoded app into my production day job or expose it to the internet without significant vulnerability and security testing first.

I’m not claiming everything AI generates is production-ready out of the box. I’m saying that you need to put in the effort to validate that what you’re creating aligns with its intended use case. That’s the same thing we’ve been doing with software and hardware for years. Nothing about that responsibility changes just because AI helped write the code.

What’s Next for Mikrotik Manager

I have no current plans to release it publicly. If there’s enough interest in the community, open source and free is the only way I’d do it. But I’m realistic about my bandwidth — being a dad, an engineer in my day job, and a YouTuber doesn’t leave a lot of room for maintaining a public GitHub repository.

That said, never say never.

Final Thoughts

I opened this by telling you I was 50% excited and 50% uneasy. Honestly? I’m still sitting right there. I don’t think that feeling fully goes away, and I’m not sure it should. But what I do know is that for the first time, I can see a path to make my ideas real in a way I didn’t have before. For my homelab, that means more things made by me, built exactly the way I want them.

Whatever the future looks like for all of us in tech, leaning into these tools feels like the right response.

I’d genuinely love to know where you stand on all of this — what you think about AI in software engineering, what it means for your career, your homelab, and your future. Drop it in the comments. This is a conversation worth having.

Thanks for reading, folks, and thank you to the fine people who support us through Patreon and the YouTube Membership program. If you’d like to support what we do here, consider checking those out. Join our community Discord and chat with me and like-minded homelabbers, geeks, and nerds — and as always, we’ll see you on the next one!

Most people hear “remote workspaces” or “VDI” and immediately assume I’m about to talk about some giant enterprise stack that costs a fortune, requires a ton of hardware to run, and has absolutely nothing to do with the homelab. But that is not the case this time. Kasm Workspaces is one of those platforms that kind of breaks that mold, because once you start looking at what it can actually do, there are some very real use cases here for homelabbers and businesses alike. So, let’s dig in!

What Is Kasm Workspaces?

How many times have you wanted to look at something that might be a little bit sus — like a link or a website that gives you that not-so-safe feeling — or wanted to quickly spin up a Linux desktop to test something without having to spend a ton of time building a VM you’re just going to throw away after? Or maybe you want a way to RDP into Windows machines as quickly as possible from any system with a web browser?

Well, Kasm Workspaces is the answer. Fully featured and completely free to run in your homelab, and enterprise-ready for your day job as well.

Let’s get the formalities out of the way first — this video is sponsored by Kasm Technologies, the company behind Kasm Workspaces, which is awesome for me because I’ve been using Kasm Workspaces in my homelab for a long time now, and I love working with companies that actually use their software at home!

In this post, I’m going to walk you through what Kasm Workspaces is, show you how to spin it up in your homelab, do a general walkthrough of the UI, its features, and configs, and then we’ll deploy our first workspace to show you how easy it is to use. But first, let’s take a quick look at Kasm Technologies, the company, and its background.

Kasm Technologies: The Background

Kasm Technologies was founded in 2017, and their origin story is a little different from your typical software startup. The founding team came out of US Federal and DoD cybersecurity work, and the core problem they were solving was: how do you give people secure, isolated workspaces without the whole thing becoming an expensive, brittle mess? They figured that out for some of the most paranoid security environments on the planet, and then in 2020 they asked: why should only government agencies get access to this?

So they spun up the commercial entity, made it free for individuals and the homelab community, and built out enterprise tiers for businesses that need the full feature set. They’ve never taken outside funding either, which tells you something about how they’re building this. It’s engineers who built something for real-world security needs and decided to make it available to everyone.

The Sweet Spot: Homelab and Enterprise, Same Technology

Kasm Workspaces hits a really interesting sweet spot. In the homelab, it gives you an easy way to spin up clean, isolated browsers, apps, and desktops completely on demand — great for testing, sandboxing, or just keeping your main system clean. But here’s the thing: those same capabilities don’t stop being useful when you walk into the office. Secure remote access, streamed apps and desktops, browser isolation that protects endpoints, all of it delivered through nothing more than a web browser. The homelab use case and the enterprise use case are literally the same technology. You’re just scaling the stakes.

I’ve been using it in my homelab in three different ways:

• Disposable browsers — I use their disposable browsers as a way to test links and websites that I don’t feel comfortable visiting on my main PC. If you get what I mean.
• On-demand Linux distros — I regularly spin up different Linux distributions to play around without having to go through the effort of building a VM, installing the distro, and so on. That immediacy of being able to, with a few clicks, start a Debian distro — for example — is great because I don’t have to do a bunch of work just to check a thing and then throw it away.
• Browser-based RDP — This may upset you, so be prepared to clutch your pearls. I use it to access my Windows VMs and desktops via RDP. Accessing those systems through my browser, again with just a few clicks, is so much easier and streamlined than starting the Windows app and going that route.

Hardware Requirements

Let’s talk about the hardware requirements for running Kasm Workspaces in your homelab. The minimum requirements below are a solid starting point, but remember: the more concurrent sessions you plan to run, the more resources you’re going to need.

Kasm can be installed on physical hardware or within a VM and supports modern versions of Ubuntu, Debian, and Red Hat Linux, on both x86_64 and ARM64 architectures. Kasm does not support installation in an LXC container or on Windows via WSL/WSL2.

The recommendations above are what I recommend for a solid homelab deployment. There aren’t official recommendations from Kasm, but those are reasonable numbers to get you off to a great start.

One more thing worth noting: you can likely install Kasm on most any Linux distribution as long as bash, openssl, Docker CE, and Docker Compose are already installed. So give it a shot if Ubuntu, Debian, or RHEL aren’t your thing.

Installing Kasm Workspaces

I’m installing into an Ubuntu Server 24.04 VM that I’ve already created, following my own recommendations for hardware provisioning: 8 cores, 16GB of RAM, and 100GB of storage. Let’s get started.

The first thing I like to do before installing anything into a fresh VM is make sure it’s up to date on patches. Once that’s done, the Kasm install is incredibly easy. You can find the install command in Kasm’s documentation, but here’s what it looks like:

cd /tmp
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.18.1.tar.gz
tar -xf kasm_release_1.18.1.tar.gz
sudo bash kasm_release/install.sh

The command will cd into the temp directory, download the current Kasm release archive, untar it, and then execute the install script.

You’ll need a user with sudoers privileges, as you’ll be prompted for your password before the actual installation begins. Before the install starts, you’ll also be hit with the Kasm Workspaces EULA — answer Y and press enter.

As the process runs, the installer takes care of everything: installing all necessary services and daemons (like Docker CE), downloading all necessary containers, and so on. This can take a while to complete, so let it run.

Once finished, the installer outputs a list of user and service account usernames and passwords that were generated during the install. Copy these and save them somewhere safe — you’ll need them to log in for the first time. Don’t worry, the user account passwords can be changed from within the platform once you’re in.

First Login and Admin Dashboard

Pop open your browser and enter https:// followed by the IP address or hostname of your VM and press enter. By default, Kasm Workspaces is deployed with a self-signed certificate — head to Advanced and proceed to the site to bypass that screen.

Log in with the admin account (admin@kasm.local) and the generated password from the installer. Once in, you land on the Admin Dashboard, which gives you a top-level overview of the status and health of your Kasm Workspaces — cards for users and login status, created sessions, and current statistics and image usage. Fresh install, so it’s all empty for now.

Workspaces and the Registry

Expand Workspaces on the left and select the Workspaces subsection. This is where all of your created workspaces can be managed. With a fresh install, it’s empty.

Over in Registry is where the good stuff is. Kasm Technologies has created essentially an app store-like experience where they list ready-to-download-and-run workspaces that they continually maintain and add to. They have a ton of different Linux distributions — AlmaLinux, Alpine, Debian, Oracle, RHEL 9, and more — as well as dedicated apps you can run: everything from your favorite browser in a box to Visual Studio Code. Everything sandboxed, contained, and adding them to your workspace is as easy as installing an app.

This one feature really brings it all together for the homelab. The ease with which you can install what you need and start using it is hands-down one of my favorite parts of Kasm Workspaces.

Sessions Management

The Sessions section is where you manage session activity:

• Sessions — See active sessions currently running.
• History — A historical list of previously run sessions.
• Session Staging — Pre-provision workspace containers ahead of time instead of creating them only when a user clicks launch. Users can be handed a session from a ready-made pool instead of waiting for a fresh container to spin up.
• Session Casting — Create a special URL that launches a Kasm session directly for a specific workspace. That link can be used for normal authenticated users or opened up for anonymous access if you want a fast, frictionless way to hand someone a ready-to-go Kasm environment.

Access Management

Users — Create users, edit account information, assign them to groups, manage login-related details, and tie in things like file mappings and other per-user settings. This is also a good time to change your admin password from the randomly generated one created on install.

Groups — Instead of configuring permissions and behavior one user at a time, you assign users to groups and apply policies, workspace access, and feature controls at the group level. By default, Kasm includes system groups like Administrators and All Users, with All Users acting as the baseline policy layer for everyone.

Authentication — Kasm supports LDAP, SAML, OpenID, and physical tokens, giving you the ability to tie Kasm into your identity stack. This lets you control SSO, security requirements, and group-based access mapping from your existing IdP — a huge deal for enterprise deployments.

Infrastructure

Docker Agents — Where you manage the worker nodes that actually run user sessions. This is the infrastructure layer that determines where workspaces launch, how much CPU, memory, or GPU capacity is available, and how session workloads are distributed across your environment.

Servers — Where you define and manage actual servers your users can connect to, whether that’s RDP, VNC, SSH, or KasmVNC-based systems. I have all of my Windows computers and VMs defined in my production instance so I can use Kasm to connect to them via RDP through the browser. It makes it trivial to connect without having to deal with RDP clients for different OSes.

Server Enrollment Tokens — Kasm’s way of securely adding remote systems into the platform. Instead of manually trusting a server, you use a token to enroll it, which helps Kasm verify and manage that system before users can access it.

Pools — Where you group and manage compute resources that sessions can launch on, whether that’s Docker agents, server pools, or autoscaled infrastructure. Kasm can tie into VM platforms like Nutanix, Proxmox, VMware, and OpenStack, as well as numerous cloud providers, so it can automatically spin up and manage virtual machines behind the scenes to scale workloads as needed.

Managers — The orchestration layer that coordinates the platform behind the scenes, handling things like session placement, communication with agents, and overall control of how workspace resources get assigned. Essentially the control plane that ties the whole environment together.

Deployment Zones — How you define where sessions should run based on location, infrastructure, or other operational requirements.

Connection Proxies — Manages the proxy layer that brokers traffic between users and remote resources like RDP, VNC, or SSH targets.

Egress Providers — How you control how a workspace accesses the internet. Instead of every session using whatever default route the host has, you can send traffic through a different gateway or exit point. Want a specific workspace to use a VPN connection to access the internet? Set up that connection, assign it to your workspace, and any internet browsing in that workspace will use only that connection. This is incredibly useful — if you want to test something from a different location in the world, set up your favorite VPN as an egress provider and launch a browser workspace configured to use it.

Settings

Global Settings — Platform-wide defaults that affect the whole environment rather than just one user or group.

Banners — Place notices inside user sessions so people can immediately see things like user identity, workspace context, or security and classification warnings while they’re working.

Web Filters — Control what websites users can and cannot reach from browser-based workspaces using allow lists, block lists, category filtering, and safe search controls.

Branding — Customize the look and feel of the platform to match your company’s branding. A paid feature focused towards businesses.

Storage Providers — Configure backend storage that users and admins can map into workspace sessions: Google Drive, Dropbox, OneDrive, Nextcloud, S3, or custom volume-backed storage.

API Keys — Generate credentials for scripts, integrations, and external systems to talk to the Kasm API without using a user login.

Logging — All of your Kasm Workspace logs and events, filterable and searchable.

System Info — The admin view of the platform’s health and identity, showing details about the deployment, installed version, licensing, and other status information.

Deploying Your First Workspace

Alright, let’s run through a quick deploy of a workspace so you can see how fast and easy it is. From the Admin dashboard, expand Workspaces on the left and click on Registry.

The list of available workspaces is large. Let’s add a Chrome Browser workspace. Select it in the list and click Install. Kasm will download the workspace and prepare it for use in the background — swing over to the Workspaces tab to monitor the progress.

You’ll notice a small red alert triangle in the top right corner of the new workspace tile. Hovering over it shows a message that it’s still downloading. Give it a moment, refresh the page, and once the alert icon is gone, click on it to launch.

Before it launches, you’re asked how you want to open the session: current tab, new tab, or new browser window. Click Launch Session.

Spawning new sessions is incredibly quick, and once it starts, you have a fresh Chrome browser in a sandboxed container — ready to test risky links, browse the web safely, or check out your favorite YouTuber’s latest videos. Not biased or anything.

Every session window also includes the Control Panel widget on the left side. Inside it, you can pass through a webcam, enable/disable sound and microphone, go fullscreen, copy/paste text, redirect printers, upload and download files, manage multiple displays, adjust stream quality, share your session, manage advanced settings, leave a workspace, log out of Kasm, or delete a session entirely.

Autoscaling: Beyond the Homelab

For your homelab, a single Kasm deployment is likely all you’ll need to run a few concurrent sessions. But the instant you need to scale beyond that, Kasm has a great answer: autoscaling.

Kasm can fully integrate with a ton of different on-prem and cloud virtualization platforms. Recently, Kasm Technologies kicked off a partnership with Nutanix to help businesses running Nutanix get all the modern isolated, ephemeral, zero-trust workspaces Kasm brings — fully automated and orchestrated in their own virtualization stack.

Autoscaling integrations live in the Pools section under Infrastructure. In my own configuration, I have Kasm set up to start up to four separate servers as needed to handle demand. Docker Agents shows the spun-up worker nodes in real time, and in Nutanix Prism Central, those worker VMs appear automatically — named kasm-dynamic-agent with a unique identifier — cloned from a kasm-ubuntu-template VM. All of this happens automatically based on demand. It’s a great example of just how capable this platform is at scale.

Final Thoughts

Alright, let me just say it plainly: Kasm Workspaces is fantastic, and that’s true regardless of the sponsorship.

Let’s start with the company. Kasm Technologies gives Kasm Workspaces away free, almost entirely unrestricted, to homelabbers. I’ve had conversations with them, and they not only care about their product — they’re homelab geeks to the core, and that shows. This is how you build a business. You share it with the geeks and nerds, engineers, and IT pros to use at home, and then they go straight into work and say “I know how to solve our VDI problem!” or “Here’s how we can let people test suspicious links without touching company assets!” and that’s meaningful.

I’ve been using Kasm for a long time. I use it to RDP into my Windows systems, spin up disposable browsers to safely check links and sites I don’t fully trust, and regularly spin up Linux distributions on demand without having to build and tear down VMs. It’s one of those indispensable tools that everyone should have running in their stack. If you aren’t using it, you should be.

One additional thing worth calling out: Kasm has one of the best knowledge bases I’ve seen for any software product. If you get stuck on something, or want to figure out how to configure Kasm to use your VPN as an egress provider, it’s all there and incredibly easy to understand. If you want to see how to set up autoscaling for your hypervisor of choice, this is where to go.

And then there’s the business side. Kasm is a mature platform that can solve real problems in a meaningful way. Its ability to integrate into your company’s IAM for single sign-on, its support for autoscaling worker nodes across practically every virtualization platform (on-prem or in the cloud, including Kubernetes), its browser isolation capabilities for protecting endpoints, and its ability to deliver all of it through nothing more than the web browser you already use — makes it a genuinely compelling platform for businesses of any size.

So the next time someone tells you that remote workspaces and VDI are just expensive enterprise headaches, send them this video. Because Kasm Workspaces is proof that it doesn’t have to be that way.

Special thanks to Kasm Technologies for sponsoring this video and for building a platform that’s as at home in a homelab rack as it is in an enterprise data center. Head over to kasmweb.com to get started — it’s free for the homelab, and the enterprise tiers are there when your use case grows into them.

Thanks for watching!

We talk a lot on this channel about on-premises virtualization and building your own private clouds. But there’s a whole other side of the world that doesn’t live in a rack in your company’s server room — it lives in public cloud and hosted private clouds.

Late last year, I had the opportunity to meet the company OpenMetal.io, whose entire focus is on helping organizations regain control of their cloud infrastructure, especially when their public cloud costs start drifting towards unaffordable, and the benefits of their closed-source system start to look more like risks. OpenMetal delivers dedicated hosted private clouds built on OpenStack and Ceph, designed for teams that want performance consistency, architectural clarity, and cost boundaries they can actually plan around.

So, in this video, we’re going to take a look at what that model looks like in practice, and how to recognize when your organization has reached the tipping point where elasticity stops being the advantage and predictability becomes the priority. Let’s get to it!

What Is OpenMetal?

Hey there homelabbers, self-hosters, IT-pros, and engineers. Rich here! When OpenMetal reached out to see if I’d be interested in checking out what life is like in a real hosted private cloud — where the servers, storage, and networks you’re running on are dedicated to only you, and not shared with other tenants like in a public cloud — I couldn’t turn it down!

When I think about the “cloud,” I immediately think of being one of many users, all sharing the same hardware. But with OpenMetal, dedicated means dedicated to only you, down to the root-level of your environment.

Before we get into the good stuff, let’s get the formalities out of the way. OpenMetal.io is sponsoring this video, and I have to say, I’m excited they have, because it’s been a really eye-opening experience — not only to see what they’ve created, but also to learn how their hosted private cloud solves a lot of problems companies in public clouds face.

OpenMetal’s Infrastructure-as-a-Service platform delivers a hosted private cloud built on OpenStack and Ceph, running on dedicated, single-tenant servers. They provide all of the cloud-native components you’d expect — compute, networking, block storage, APIs, and automation — with a focus on:

• Fixed capacity and predictable performance
• Transparent costs with no per-resource billing surprises
• Full root access to workloads, cluster configuration, and networking
• Hardware visibility — you know exactly what’s running where and how it’s performing

Unlike a traditional hyperscaler where every resource you deploy has an individual cost, OpenMetal provides your own private cloud on a hardware stack that isn’t shared with anyone. This approach simplifies budgeting, planning, and forecasting of your cloud spend. It’s infrastructure for businesses with steady workloads who want all the benefits of being in the cloud, but with ownership, consistency, and the ability to actually plan.

OpenMetal launched its IaaS platform in 2022 and has datacenters across three continents — US, Europe, and Asia — with key regions including Los Angeles, Ashburn, Amsterdam, and Singapore.

The Inflection Point: When Public Cloud Stops Making Sense

There’s an inflection point that almost every growing engineering team hits with their cloud infrastructure. In the beginning, the public cloud makes perfect sense. You move fast, you don’t think about hardware, you spin things up, experiment, and iterate. But after that point, things change.

Workloads stabilize, usage and production move towards a steady-state, and you realize you’re paying for elasticity you’re not really using. Then your management starts asking harder questions about where your workloads are running, what they’re actually consuming, and how predictable the bill is going to be.

That’s really the problem OpenMetal was built to solve. It’s not that AWS, Azure, or GCP are bad. Quite the opposite — they’re incredible for the early growth and experimentation phase. But there’s a stage at which predictability, visibility, and cost boundaries matter more than raw elasticity.

Here’s a good example: in the public cloud, every single resource you deploy has a cost associated with it. Each VM, virtual disk, network interface, and each gigabyte of data sent and received. Something goes sideways, and all of a sudden you have a massive unexpected bill you didn’t account for. In contrast, in a hosted private cloud, you’re buying defined capacity on dedicated hardware, so your costs are going to be the same regardless of utilization in your stack. For those with more steady-state infrastructure, it’s financially smarter to repatriate those workloads out of the public cloud and into a hosted private cloud.

The OpenStack Advantage

Then there’s the broader shift happening in the closed-source ecosystem — like we saw with the acquisition of VMware by Broadcom. For years, many teams built their operational muscle memory around VMware-style infrastructure. Those recent shifts have prompted a lot of organizations to re-evaluate their long-term strategy and rethink what platform stability actually means.

Moving towards a more open-source platform like OpenStack gives you the flexibility to move your workloads anywhere you please. OpenStack supports common VM image formats such as VMDK, QCOW2, and more, so you can migrate your workloads instead of rebuilding them.

Building on a widely adopted, API-driven, community-supported foundation where no single vendor controls your roadmap means greater certainty, future stability, and flexibility for your workloads — with no rug-pulls.

OpenMetal’s Three Offerings

OpenMetal has three offerings that allow companies to choose the right way to serve their business.

1. Hosted Private Cloud

The flagship offering — and the one we’re going to dig into here — is their Hosted Private Cloud. Built on top of OpenStack and Ceph on dedicated servers that only serve your workloads, you pay for the service you want, you decide how to size your VMs, and you control workloads while OpenMetal takes complete care of the physical infrastructure.

OpenMetal has a Private Cloud Deployment Pricing Calculator to help you choose various flavors of the cloud, attach compute and storage, and see what your costs can look like.

2. Bare Metal

OpenMetal’s bare metal offering gives you raw, dedicated hardware with full access down to BIOS/IPMI, predictable pricing, high-bandwidth networking, and a big list of modern server hardware options — everything from lots of RAM and multi-core CPUs to NVMe-heavy storage configurations.

It’s built for heavy workloads like virtualization clusters, big data, high-performance computing, or anything that needs consistent I/O and no noisy-neighbor interference. OpenMetal also offers dedicated GPU infrastructure you can deploy standalone or integrate with your private cloud.

3. Ceph Storage Clusters

OpenMetal’s storage clusters are standalone Ceph storage built for performance and scale — not an abstracted blob store or S3 bucket with hidden limits. You get a distributed storage cluster with block, object, and file capabilities that scales horizontally and keeps data replicated and highly available. You can tune performance and redundancy, add capacity on demand, and connect it back to your private cloud or bare metal environment over high-speed networking.

Building Blocks, Not Silos

The best part is these aren’t siloed products — they’re building blocks. You can start with Hosted Private Cloud, add Storage Clusters when you need more capacity, and drop in Bare Metal for things like edge services, specialized appliances, or heavy compute — all interconnected over OpenMetal private networking so it feels like one unified infrastructure footprint.

Diving Into OpenMetal’s Horizon Interface

One of the big things that has always annoyed me about hyperscalers is how disconnected we’ve become from what’s actually happening behind the scenes. As an infrastructure architect in my day job, it’s always eaten at me that, as customers, we’ve given up the control of choosing what hardware and platforms our cloud workloads run on.

Up until I met with OpenMetal, I thought that’s just the way it is. Turns out, that’s not the case — and that’s a big value add. When you know exactly what hardware your workloads are running on and how your networking is built, you can actually model performance and capacity. You’re not guessing how many hidden metered services are attached to your architecture; you’re running inside a defined infrastructure boundary.

Since OpenMetal’s hosted private cloud is built on OpenStack, they give you direct access to Horizon — OpenStack’s native management interface. You can also manage your environment through the OpenStack APIs, CLI tools, SDKs, and infrastructure-as-code workflows. For those familiar with OpenStack, you’re going to feel right at home — other than some simple branding, you’re getting direct access to Horizon with no abstracted UI to mess with.

Let’s run through the key sections.

Compute

API Access — This is where you work with OpenStack from the outside using CLI tools, SDKs, or automation. It lists the service endpoints for your project and gives you the option to download your OpenStack RC file so you can authenticate from the command line or scripts.

Overview — Your project’s status dashboard. It gives you a concise summary of how many instances you’re running, how much vCPU, RAM, and storage you’re consuming, and how that usage compares to your quotas.

Instances — The primary view you’ll live in. Here you manage virtual machines — their status, flavor, IP addresses, and power state. From this page you handle day-to-day lifecycle tasks: launching new instances, starting and stopping them, rebooting, connecting to the console, creating snapshots, and deleting workloads you no longer need.

Images — Your catalog of boot sources for new instances, including base OS templates, golden templates, and snapshots you’ve turned into reusable images. This is also where you’d manage workload migrations from other platforms. If you’re moving off VMware or another platform, you can import converted images, turn them into templates, and redeploy your workloads inside your private cloud in a controlled, phased way.

OpenMetal has a solid list of pre-made images to start building from right out of the gate — CentOS Stream, Rocky, Debian, Fedora CoreOS, and Ubuntu. You can also create your own images and import a variety of image formats.

Key Pairs — Where you manage SSH keys used to log in to your instances without passwords. Create a new key pair to generate a private key for download, or import an existing public key. When you launch an instance, you attach one of these key pairs so the public key is injected into the guest.

Server Groups — Where you define placement policies for related instances. Create affinity and anti-affinity rules that govern where the scheduler places instances based on what groups you place them in. For people who’ve been using on-premises virtualization, affinity is one of those things that is incredibly important, and I’m glad to see that feature exists here.

Volumes

Volumes — Where you manage block storage for your deployed instances. Create, resize, and delete volumes, view which instances they’re attached to, and create snapshots for backup or cloning purposes.

Backups — Where you manage block storage backups for your volumes. These backups are stored in a separate Ceph pool. Ceph natively has a replication of 3, so there are always 3 copies of the data, giving you redundancy in case of node failure.

Snapshots — Point-in-time copies of your volumes. View, edit, and delete existing snapshots, use them as a source to create new volumes, or launch new instances from them. If you’ve spent any time in virtualization, you know the value of snapshots as a means of short-term recovery when testing updates or system changes.

Groups — Manage logical collections of related volumes so you can operate on them as a unit. Useful for applications that use multiple volumes and need consistent handling, such as a database and its log volume. Create group snapshots to capture consistent point-in-time copies across all volumes at once.

Containers (Kubernetes)

OpenMetal’s OpenStack platform also features container infrastructure, which means you can bring your Kubernetes right into your hosted private cloud and manage everything in one place.

Clusters — Manage your container orchestration clusters. Create new clusters based on predefined templates, scale worker nodes up or down, and download kubeconfig credentials.

Cluster Templates — Define the blueprint for how container clusters are built. OpenMetal provides a ready-to-use Kubernetes cluster template so you can spin up clusters quickly. This is native OpenStack container integration — not a custom OpenMetal layer. OpenMetal publishes Kubernetes guides on their documentation site for those who want to dig deeper.

Networking

The networking section is where the “private cloud” part gets real. You’re not just clicking buttons — you’re designing networks the same way you would on-prem: segmentation, isolation, routing, and controlled exposure, but in software.

Network Topology — A visual map of how your OpenStack networking is wired. It shows routers, networks, and subnets along with connected instances and floating IPs. You can quickly see how traffic flows in and out, and the graph tab creates a clear network diagram that helps you get the full picture. Love it.

Networks — Manage virtual networks available to your project. Create and edit networks and subnets, choose whether they are shared or project-scoped, and control IP ranges, gateways, and DHCP settings. Want a typical setup with a public-facing network for load balancers and a private application network behind it? You can model that cleanly.

Routers — Manage Layer 3 routing for your project’s networks. Create and configure virtual routers, attach internal subnets as interfaces, and connect those routers to an external network for north-south traffic. These act as a simple NAT so that internal networks can access the Internet without burning through public IP addresses.

Security Groups — Virtual firewall rules that control traffic to and from your instances and ports. Rules are enforced at the virtual NIC level, letting you define clear, reusable access policies for different workload types. OpenMetal includes a few pre-created security groups right out of the gate as great examples.

Load Balancers — Configure and manage L4 and L7 load balancing for your applications. Create load balancers, define listeners on specific ports and protocols, and build pools of member instances. Perfect for exposing a service behind a single virtual IP and distributing traffic across multiple instances.

Floating IPs — Manage public IP addresses that can be mapped to instances or ports. Allocate new floating IPs from an external network, associate them with specific instances or ports, and release them when no longer needed.

OpenStack also includes VLAN trunking for carrying multiple segmented networks over a single interface, Network QoS for shaping traffic policies, and built-in VPN support for creating secure IPsec tunnels between your cloud networks and external environments.

The depth and flexibility in networking is something I have to admit I was pretty impressed by. In hyperscalers, every layer of networking feels like a separate product with a separate billable line item. In OpenMetal’s private cloud, the tooling is part of the platform. And on the bandwidth side, OpenMetal’s outbound traffic is typically billed using a 95th percentile model rather than per-gigabyte micro-metering — making bandwidth costs far more predictable as you scale.

Orchestration & Object Store

Orchestration (Heat) — Manage infrastructure as code. Work with templates that define instances, networks, volumes, and other resources as a single stack. Launch, monitor, update, and delete those stacks — and inspect individual resources and events when something goes wrong.

Object Store (Swift) — Work with object-based storage instead of block volumes. Create and manage containers (like buckets), upload, download, and organize objects, and control access by making containers private or public. Ideal for durable, scalable storage for files, backups, logs, or application assets.

Admin & Identity

Admin — The control plane for the OpenStack cloud as a whole rather than a single project. Watch overall usage, manage global resources, work with hypervisors and host aggregates, define shared flavors and images, and review quotas and usage across projects.

Identity — Control who can access the cloud and what they’re allowed to do. Manage domains, projects, users, and groups, and assign roles that define permissions for each. Work with application credentials and, in some deployments, federation or external identity sources.

Workflow (Mistral) — Manage multi-step operational task automation. Define workflows for common or complex operational procedures — provisioning, maintenance actions, or integrations that touch several OpenStack services — and run them in a controlled and auditable way.

Final Thoughts

I gotta say, I’m really impressed with what OpenMetal has built here. The way they’ve combined ease of deployment and the performance of their hardware with the power of OpenStack makes for a very compelling offering.

The public cloud feels like it’s getting less and less reliable as time goes on, while getting more and more expensive to operate in — which feels like it’s moving in the wrong direction. OpenMetal’s real value is giving you back the control, flexibility, and freedom that we all gave up by moving into the public cloud. You get your workloads in the cloud and the flexibility that provides, without losing any of the infrastructure primitives, root access, network segmentation, and more — while gaining predictable performance on dedicated hardware. To me, that’s the perfect cloud scenario.

Then there’s the cost structure. I know from personal experience that every single thing in the public cloud has a charge. The VM costs money, the network interface for the VM costs money, the disk costs money, the virtual network you connect the VM to costs money — and that’s just one workload, not counting ingress and egress fees, VPN connections, and everything else. Hosted private cloud is the answer to that. You’re operating inside defined infrastructure capacity on dedicated hardware. Performance is consistent, budgeting is predictable, and scaling decisions are deliberate, not reactive to billing alerts.

As an engineer whose heart is in infrastructure, this is the closest you can come to having the best of both worlds. You control every part of how you provision and deploy your private cloud. You understand exactly what hardware your environment runs on, so you can model capacity and make decisions with a lot more confidence. And on top of that, you get all of the benefits of being in the cloud, engineering support from OpenMetal when you need it, and no worries about the physical hardware.

And finally, being based on OpenStack means you have all of the API-driven Infrastructure as Code functionality, automation, true multi-tenancy, and — the biggest value — a standard open platform with no vendor lock-in.

Closing

Special thanks to OpenMetal for giving me the opportunity to really dig into their hosted private cloud platform and see the possibilities for myself. It’s really changed my views on how the cloud can actually benefit your business!

If you’re a business that’s heavily invested in the cloud and looking for how you can take back control of costs, avoid public cloud lock-in, and build the private cloud that works best for your business, head over to openmetal.io and get started today! They have also provided a generous offer just for my channel — link and details in the description below.

Thanks for watching!

Introduction

Proxmox Datacenter Manager might already be dead, and an open source project may have just killed it. Buckle up, friends, cause this is going to be wild!

Hey there homelabbers, self-hosters, IT-pros, and engineers. Rich here! I get a lot of emails from vendors, software makers, and people who are hoping I’ll create a video about their product, and as much as I appreciate the emails, I don’t usually do so because, well it’s either not in my niche or it’s not something I want to put my name next to if you get what I mean. Earlier this week I got an email from the creators of an open source project called PegaProx introducing me their work.

I did want I normally do, I read the email, then I went to take a cursory look at their site. What I found was something that truly blew me away. PegaProx may single handedly just not only have killed PDM, but also also changed the game for what a modern PVE GUI should be. Enough hyperbole, let’s dig into PegaProx and it’s features, see if this is something you should be running if you’re using Proxmox, and at the end I’ll show you how to deploy it. Let’s get to it!

What is PegaProx?

PegaProx is an open-source, web-based management platform for Proxmox environments that gives you a single plane of glass for multiple clusters, nodes, and workloads. It provides:

• Centralized Monitoring: Overview of all your clusters and workloads from one dashboard
• VM and Container Management: Complete lifecycle management of your virtual machines and LXC containers
• Automated Load Balancing: Distribute workloads across your cluster automatically
• Cross-Cluster Migrations: Move workloads between clusters seamlessly
• High Availability Orchestration: Advanced HA functionality beyond standard PVE capabilities
• Role-Based Access Control: Fine-grained permissions management through a unified dashboard

All this is designed to reduce operational complexity and give administrators better visibility and control over distributed infrastructure.

PegaProx vs Proxmox Datacenter Manager

If you thought this sounds a lot like what Proxmox Datacenter Manager does, you’d be right. But unlike PDM’s limited feature set, PegaProx, with the exception of PBS visibility, can do practically everything a Proxmox user would want to do and more.

Key Advantages Over PDM:

• Create and customize VMs and containers directly in the interface
• Manage PVE host configurations
• Set up automated load balancing across your cluster
• Carry out cross-cluster migrations
• Beautiful, modern user interface
• No “No Valid Subscription” warnings (it’s open source!)

PegaProx Feature Walkthrough

Dashboard and Overview

This is the login screen for PegaProx. Once logged in, we land on the All Clusters Overview page. Which, can we just take a moment to take in the UI here? Seriously, beautiful!

This page is full of cards that provide you with macro details about all of the hosts and clusters you’ve added to PegaProx, including:

• All clusters added
• Top resource consumers in a scrollable list

You can also sort this information by name, health, nodes, VMs, CPU, and RAM.

Cluster Overview

Clicking on a cluster lands you on the overview page, with:

• Cards for each node in your cluster in the middle left
• Overall cluster health and last migrations cards on the right

Clicking ‘show all’ in the card gives you the full details of the current state of your node’s resource usage.

Resources Tab

The Resources tab is where we get a complete look at all of the workloads running. Both VMs and LXC containers are listed here, and while the cards view is nice, PegaProx provides helpful filters:

• State Filters: All, Active, Stopped
• Type Filters: VMs, LXC containers
• View Options: Cards view, list view, and the awesome compact view

In the compact view, once you select one of your workloads, you get:

• Macro details (CPU, RAM, Disk, Uptime)
• Quick actions (shutdown, reboot, console access)
• Configuration modification - all configurable options available in PVE are accessible here

You can:

• Change hardware and disks
• Manage network settings
• Manage snapshots, backups, and replication
• View history and change options
• Access historical graphs
• Trigger migrations between nodes or across clusters
• Clone, force reset, or delete workloads
• Create new VMs and containers with the same fields as PVE

Snapshot Management

The snapshot overview is something that PVE has been missing forever. The snapshot view shows you all of the snapshots in your cluster. This is one of those quality of life features that exist in enterprise virtualization platforms to make admins’ lives easier and help you clean up wasted space due to forgotten snapshots.

Datacenter Management

Summary

The summary page gives you macro information about the datacenter including:

• Cluster quorum status
• Node state
• Guests and container state
• Macro resource usage

Cluster Tab

Details about your cluster configuration and status.

Options

View and edit all of your datacenter options configured.

Storage

Detailed view of all storage configured, including:

• Name, type, content, and path
• Connected nodes
• Shared storage status
• Storage operations (add, modify, delete)
• Multipath redundancy configuration with a single click

SDN (Software-Defined Networking)

Manage all your software-defined networking:

• Add, change, and remove zones and VNets
• Apply settings to all nodes in your cluster

Backups

• Manage configured backups
• Create new backup jobs
• Delete backup jobs

Replication

Same functionality as backups but for replication jobs.

Proxmox Native HA

• Manage and control your PVE HA functionality
• Add and remove resources to HA
• Create HA groups

CPU Compatibility

Change the default CPU compatibility mode for your datacenter.

Firewall

Create and manage firewall rules for your datacenter.

Datastore Management

The Datastore tab allows you to browse your provisioned datastores and see what’s held within them:

• VM and container disks
• Backups
• ISOs

Storage Balancing (Experimental)

Enable automated balancing of your workloads across storage for better performance. (Use at your own risk!)

Automation Features

The Automation tab allows you to:

• Configure scheduled actions
• View tags and labels
• Create email alerts when thresholds are exceeded
• Create affinity and anti-affinity rules for workloads
• Configure and run custom scripts on cluster nodes

Reports

Get usage information over time, selectable by hour, day, and week, to see historically who the heavy-hitters are.

Settings

Configure:

• Workload balancing for your cluster
• Node updates
• Rolling cluster updates
• And more

UI and Design Philosophy

I’ve said this before, and I’ll say it again - I’m not a fan of the PVE UI. I think it’s dated, difficult to find the actual settings you want, and it’s downright ugly. In contrast, PegaProx has kinda blown away by its entire reimagining of what the Proxmox user experience could be like.

Important Notes

I don’t mean to paint PegaProx as a production-ready replacement for all your PVE and PDM activities. At the time this video was made, PegaProx is considered beta, and there are things that may behave differently from the production version.

Known Issues:

• Some UI elements may appear in German even with English selected
• Still missing PBS (Proxmox Backup Server) visibility

Additional Features Not Covered:

• Multiple user-selectable themes
• Extensive security and user management
• AD domain integration
• OIDC for single sign-on
• Two-factor authentication
• Granular permissions for users and groups
• Tenant creation for logical segmentation

How to Deploy PegaProx

Step 1: Create the Container in PVE

1. Log into your PVE host and click the Create CT button in the top right corner
2. Give the container a hostname (e.g., “PegaProx”) as an FQDN
3. Set a root account password
4. Select your preferred Linux template (Ubuntu 24.04 recommended)
5. Disk Space: Default 8GB is fine, but 16GB provides room for OS updates
6. CPU Cores: Minimum 1 core for small homelab, but 4 cores recommended
7. RAM: Minimum 1GB required, but 4GB recommended
8. Network: Set a static IP address (don’t use DHCP for servers)
9. DNS: Configure as needed or use host settings
10. Check “Start after created” to have the container ready
11. Click Finish

Step 2: Prepare the Container

1. Open the container console in PVE
2. Log in with root and your set password
3. Install curl: apt install curl -y
4. Clear the console: clear

Step 3: Download and Run the Install Script

1. Visit https://pegaprox.com/
2. Click any of the 3 download buttons
3. Copy the install script link
4. In the container console, paste and run the install command
5. Wait for supporting packages to install

Step 4: Configure Installation

When prompted (Step 6), choose your port configuration:

• Option 1: Default ports
• Option 2: Professional setup (standard SSL ports) - Recommended
• Option 3: Custom ports

The installation will complete and provide you with the web interface URL.

Step 5: Access and Login

1. Copy the web interface URL from the installation completion message
2. Open it in a browser
3. Accept the self-signed certificate warning (you can add a valid cert later)
4. Login with:
   • Username: pegaprox
   • Password: admin
5. Change the default password when prompted

Step 6: Add Your Proxmox Cluster

1. Click “Add Cluster” in the top right
2. Enter a cluster name (e.g., “2GT-PVE”)
3. Enter the IP address or DNS name of your Proxmox cluster/host
4. Enter login credentials (root@pam recommended with root password)
5. Click “Add Cluster”

You can now drill down into your cluster’s usage, health, and manage all your VMs and containers!

Sizing Recommendations

I’m using generous resources in this walkthrough, but PegaProx has a comprehensive docs site with minimum sizing requirements and prerequisites. Highly recommend checking their documentation to properly size PegaProx for your environment.

Final Thoughts

Holy shit. PegaProx effectively replaces both PVE and PDM’s user interfaces, and does it in style! I can’t say enough nice things about what PegaProx is building here.

Message to Proxmox Server Solutions

Proxmox Server Solutions, listen up… This is the GUI I want for PVE, PDM, and PBS. Reach out to these people, pay them a ton of money, and adopt this as your next-generation UI, seriously.

PegaProx as a PDM Replacement

PegaProx looks like it effectively kills PDM as it exists at this time entirely. There’s no need to use PDM when PegaProx does everything it’s doing, and does it so much more beautifully. But saying it’s a PDM replacement doesn’t really do it justice. PegaProx kills the PVE GUI as well since you can do practically every single thing you’d do there, here.

Real-World Impact

I’ve done test deploys of Proxmox in business settings, and one of the biggest issues I have to overcome with non-technical people who have to administer PVE is the UI of Proxmox. One of the biggest barriers to entry is the dated interface, and after seeing PegaProx, I realize my previous suggestions for UI redesign were insufficient.

Current Limitations

Eye candy aside, PegaProx brings you cluster load balancing as a standard feature - something that is not available in PVE, still…after all of these years. And gives you PDM features like cross-cluster migration functionality as well.

Missing Features:

• PBS (Proxmox Backup Server) support

Beta Considerations:

• Some features may break
• Continue to monitor for updates

Bottom Line

It’s open source and free to use, and you won’t see anymore ‘No Valid Subscription’ warnings! Spin up a container, deploy PegaProx right now, kick the tires on it, use it, find bugs, and report your findings to the community.

Closing

Thanks for watching this video, folks, and thank you to the fine people who support us through Patreon and the YouTube Membership program. If you’d like to support what we do here, consider checking those out. Join our community Discord and chat with me and like-minded homelabbers, geeks, and nerds, and as always, we’ll see you on the next one!

Back in October 2024, I introduced you to VergeOS as a compelling alternative to VMware, covering its architecture, user interface, and overall user experience. This time, we’re going to walk through the installation of VergeOS — step by step — from burning the ISO and installing the OS all the way to spinning up your first virtual machine. Let’s get to it!

Hey there, homelabbers, self-hosters, IT-Pros, and Engineers. Rich here! It had always been my plan to take you through the installation process, start to finish, for VergeOS so you could try it out for yourself. Thanks to this video’s sponsor, Verge.IO — the makers of VergeOS — I’m able to bring this to you right now!

Before we get into the step-by-step how-to, let’s get a quick recap of VergeOS out of the way first.

What Is VergeOS?

VergeOS is essentially a data-center operating system that collapses compute, storage, networking, backup, and even DR into one unified platform. Unlike traditional HCI or the classic VMware stack, VergeOS is one unified codebase with one UI and one lifecycle — and is not a cobbled-together pile of different products. That’s what makes it special: it’s a true private cloud operating system, which massively simplifies operations and slashes costs. And in a post-VMware world, that actually matters.

VergeOS is compelling because it lets you:

• Modernize your private cloud
• Reuse existing hardware
• Migrate off VMware at your own pace
• Run the whole data center like a single system instead of babysitting a stack of products

This install how-to is going to walk you through every part of the installation and setup process, so by the end you should have VergeOS completely set up and ready to use. Our first stop on the installation journey is hardware requirements.

Hardware Requirements for VergeOS

Let’s get the minimum and recommended hardware requirements out of the way first.

CPU

VergeOS requires a 64-bit x86 CPU with a minimum clock speed of 2.7 GHz. Both AMD and Intel CPUs are supported, and hardware virtualization must be enabled in the BIOS.

Memory

VergeOS requires a minimum of 16GB of RAM per node dedicated to VergeOS itself. You’ll need an additional 1.5GB of RAM for each terabyte of raw vSAN storage, and on top of the base requirements, you’ll also need additional RAM for your virtual workloads.

Storage

VergeOS requires NVMe or SSD disks for metadata and workload storage, with NVMe direct-attached storage recommended for optimal performance. For systems with storage controllers, Verge.io recommends a dedicated HBA configured in IT mode or JBOD mode for direct disk access. Mechanical disks are only recommended for use in an archive tier and never for primary storage.

Networking

• Minimum 1 GbE per node for management UI access and guest VM external network access
• Minimum 1 x 10 GbE per node for the internal core network used for storage replication and synchronization

One of the nice things about VergeOS is that it’s designed to run on vanilla x86 hardware and doesn’t require a specific vendor’s HCL — meaning you can often deploy VergeOS on servers you already own and it’ll work great.

For those who don’t have hardware available, Verge.io offers a free test-drive lab where you can explore VergeOS without needing physical hardware or committing to an install: verge.io/the-ultimate-test-drive/

Alright, prereqs out of the way. Before we kick this off, make sure you have a USB stick of at least 8GB in size. Let’s get to it!

Step 1: Download the VergeOS ISO

Open your browser and head over to updates.vergeos.com/download/ and press enter. The download should start automatically. Once the download is complete, we’ll move on to creating the bootable USB stick.

Step 2: Create a Bootable USB Stick with Rufus

There are a variety of tools for building bootable USB sticks from ISOs. On Windows, my go-to is the free tool Rufus. Head over to rufus.ie and click Download at the top, then select the top link in the list to start the download.

Once Rufus is downloaded:

1. Open Rufus and plug in your 8GB or larger USB stick
2. Click the Select button and choose the VergeOS ISO you just downloaded, then click Open
3. Click Start to begin
4. When prompted, select “Write in DD image mode” and click OK
5. Rufus will warn you that all data on the USB stick will be wiped — if you’re good with that, click OK

Sit back and let Rufus build the bootable USB. This can take some time to complete. Once it’s done, click Close and we’re ready to install!

Step 3: Install VergeOS

Now it’s time to install VergeOS on hardware. Booting from a USB stick is typically straightforward, though the exact method depends on your system’s manufacturer. I’ll be using a Supermicro server in this walkthrough, but the general process is the same across most systems.

Insert the bootable USB stick, power on the host, and tell the system to boot from the USB. Once the initial boot completes, you’ll see the VergeOS boot loader screen — wait the 10 seconds or press Enter to continue. The installer will take a moment to start up depending on your hardware.

Node Type

The first step is choosing the type of node you’re deploying. Regardless of whether you’re deploying a single system or a multi-node cluster, the first system must be a controller. In a multi-node cluster, your first two nodes must both be controllers for redundancy and fault tolerance. Press Enter to select Controller.

New Install or Join Existing?

You’re asked if this is a new install or if you’re joining an existing system. Since we’re deploying a new cluster, leave this on Yes and press Enter.

Timezone Configuration

1. Region — Select your region (e.g., America) and press Enter
2. Timezone — Scroll to your timezone (e.g., Los_Angeles) and press Enter
3. NTP Servers — VergeOS offers official NTP servers by default, which work for most setups. If you have dedicated NTP servers on your network, enter them here. Otherwise, leave the defaults and press Enter
4. Date — Verify the year, month, and day are correct and press Enter
5. Time — The system expects 24-hour clock format. Adjust if necessary and press Enter

Cluster Name and Admin Account

• Cluster Name — This is the name of the cluster itself, not an individual node. Choose accordingly (e.g., 2gt-cluster) and press Enter
• Admin Username — VergeOS defaults to admin, which is fine for most setups. Press Enter to accept
• Admin Password — Set and confirm your admin password, then press Enter
• Admin Email — Enter an email address for the admin user and press Enter

Network Configuration

Your host needs at least two network interfaces. The first configuration is for the core network, used for inter-node storage replication and cluster health management.

On my system, the first NIC is connected to my LAN and the second is on a dedicated layer-2 VLAN for the core network. To select the correct interface:

1. Press Spacebar to deselect the first NIC
2. Arrow down to the second NIC and press Spacebar to select it
3. Press Enter to continue

Next, configure the physical switch settings for the core network interface. I recommend giving switches descriptive names. Press Enter, clear Switch 1, type Core Network, and press Enter. Arrow to Finish and press Enter.

VergeOS will check the interface for an existing core network, then move on to the remaining network interface. Select it and similarly rename Switch 2 to LAN. Then, arrow down to the Core-Network field, press Enter to edit it, clear yes, type no, and press Enter. Arrow to Finish and press Enter.

External Network

VergeOS will now ask which physical network provides external access to the UI, LAN, and WAN. Since we named our switch LAN, VergeOS can easily identify the right one — leave it set to LAN and press Enter.

Now configure the external network interface:

• VLAN ID — If your external connection doesn’t use a tagged VLAN, leave this blank and press Enter (most home/lab setups fall here)
• IP Address — I strongly recommend a static IP. Enter your address in CIDR notation (e.g., 172.24.1.50/24) and press Enter
• Default Gateway — Enter or confirm your default gateway (e.g., 172.24.1.1) and press Enter
• DNS Servers — Verify and add any additional DNS servers for redundancy, then press Enter
• IPMI — If your server has IPMI and you’d like to configure it here, do so. Otherwise, press Enter to skip

Disk Configuration

• Disk Encryption — Choose whether to enable disk-level encryption for vSAN storage based on your security requirements. We’ll leave this set to No and press Enter
• Storage Layout — VergeOS automatically builds storage tiers based on the disks in your system. You can accept the default configuration (which is what I’ll do) or customize. Press Enter to continue
• Manual Tier Assignment — If you want to reorganize disks into different tier groups, say Yes here. I’m happy with the VergeOS suggestions, so I’ll arrow to No and press Enter
• Over-Provisioning Tier — Select a storage tier to use for over-provisioning and failover in the event of memory overcommitment. I’ll select my Tier 3 (largest capacity) and press Enter
• Over-Provisioning Per Drive — Define the storage space per drive to allocate. The default of 4GB per drive is fine, so press Enter
• Confirm Total — Review the total over-provisioning space and press Enter to accept

VergeOS will now format the drives, prepare them for vSAN, and complete the vSAN implementation. This can take a while depending on how many disks you have, so give it time. Once vSAN is built, VergeOS will install and prepare the OS packages — also potentially time-consuming.

Final Steps

When installation completes, you’ll be asked if you want to register the EFI boot partitions with your system’s BIOS. Leave this on Yes and press Enter.

Congratulations! You’ve completed the initial installation of VergeOS. Remove the bootable USB stick and press Enter to reboot. After the system restarts and VergeOS starts up, you’ll land on the VergeOS console screen. Great work!

Step 4: Access the Management UI

Pop open a browser and navigate to the IP address you configured during setup. For me, that’s 172.24.1.50.

Fresh installs use a self-signed certificate, so your browser will alert you. Click Advanced, then Proceed to the website. You’ll land on the VergeOS login page. Enter the admin username and password you set during installation and click Sign In.

Welcome to the VergeOS web management UI! By default it’s in Light Mode — head to the top right corner, click the sun icon, and select the Dark Theme. Much better.

UI Overview

The VergeOS UI is broken into three main sections:

• Top navigation — Organizes the major sections of the platform
• Main content window — The primary working area
• Left sub-menu — Subcategories, options, and configurations for the current section

The main dashboard is your high-level overview of the entire VergeOS cluster, broken into easy-to-understand cards covering VMs, networks, nodes, alerts, storage health and performance, and logs.

Here’s a quick tour of the major sections:

• Virtual Machines — Build, run, and operate workloads end-to-end. Spin up VMs from ISOs or templates, assign CPU, RAM, and storage tiers, attach networks, and manage lifecycle actions like snapshots, cloning, live migration, and HA.
• Files — Upload data including ISOs, manage downloaded marketplace images, create and share data hosted in the cluster.
• Tenants — True multi-tenancy with completely isolated logical tenants — their own users, quotas, networks, and workloads. Ideal for MSPs, service providers, or teams needing separated environments.
• NAS — Leverage cluster storage for shared network storage — Windows file shares, NFS shares, and more, just like a dedicated NAS appliance.
• Networks — Define VLANs, bridges, and network segments and attach them to VMs, tenants, and services.
• Backup / DR — Configure snapshots and replication for VMs and storage. Platform-level, agent-free recovery and availability focused on replication to another VergeOS system.
• Infrastructure — Manage the underlying cluster: nodes, disks, networks, capacity, and hardware health.
• Import/Export — Move workloads in and out of VergeOS. Import from external platforms or export existing VMs as portable images.
• Repositories — Store install media and images like ISOs and VM templates. Add catalogs or manage third-party repos from the marketplace.
• AI (New in v26) — Private AI features built into the platform. Pick a model, start chat sessions, and use an OpenAI-compatible API so existing tools can point at your VergeOS system.
• Logs — All platform logging combined and searchable in one place.
• System — Configure the platform itself: users and roles, licensing, updates, time settings, notifications, certificates, and system-wide behavior.

VergeOS has a lot of depth, and I highly recommend digging into their public docs for any features you want to explore further. VergeIO has also added an AI assistant right inside the platform that can answer real questions like “How can I configure my VM to access the Internet?” — quick, accurate, and helpful.

Step 5: License the Cluster

Before VergeOS will allow you to start virtual machines, you need to license the cluster. I’m using a trial license here, but the process is very similar for production licenses as well.

1. Head to System → Settings
2. On the left, select Updates Settings
3. Enter the username and password supplied with your license in the User and Password fields
4. Click Submit to apply the license
5. Verify by heading to System → Updates — you should see confirmation that your credentials were accepted and access to the update server has been granted
6. Head back to Settings and in the License card, confirm your system is licensed and valid

Right on! Let’s build our first VM!

Step 6: Create Your First VM

Head over to the Virtual Machines section from the main dashboard, then click New VM on the left.

VergeOS offers multiple VM creation methods:

• New VM Wizard / Advanced / Clone — Start from scratch
• Import — From a media image, shared object, or volume
• Catalogs / Recipes — Pre-prepared templates (my favorite)

Catalogs is the fastest and easiest approach. Templates are organized into sections including:

• Applications — Ready-to-go deployments for Docker, Grafana, Kubernetes K3S, LAMP stack, and OpenVPN-AS
• Operating Systems Marketplace — A large list of ready-to-deploy Linux distributions

Let’s deploy an Ubuntu Server 24.04 VM using a marketplace template. Select it from the list and click Next.

VM Configuration

• VM Name — Enter a name for the VM inside VergeOS (e.g., Ubuntu Server VM)
• CPU Cores — 4 cores is plenty for our purposes
• RAM — I’ll bump this up to 8GB
• Hostname — The actual hostname of the VM. I’ll match the VM name for simplicity

User Configuration: Create an admin user and set a password for it.

Network: Leave set to DHCP and select External for the network to give the VM direct access to your LAN.

Drives: Set the OS disk size (50GB is fine) and select your storage tier. I’ll leave it on Tier 1 for the fastest disks.

Click Submit to kick off the VM build.

You’ll see the disk being initialized in the Drives section. Once complete, head up and click the Play button in the top-left of the content window to power on the VM and confirm.

The dashboard will start populating with CPU, RAM, disk, and network throughput stats as the VM comes to life. Click the Console button in the upper-left to open the VM console in a new browser tab.

Once the VM boots, log in with the user credentials you set. Verify the IP address looks correct for your LAN, then run a quick ping to confirm internet access.

Congratulations on creating your first VM in VergeOS!

Closing

Thanks for watching this video, folks, and thank you to everyone who supports the channel through Patreon and the YouTube Membership program. If you’d like to support what we do here, consider checking those out. Join our community Discord to chat with me and like-minded homelabbers, geeks, and nerds — and as always, we’ll see you on the next one!

Hey there homelabbers, self-hosters, IT-pros, and engineers. Rich here! Just recently, I left pfSense for UniFi. It was a tough decision, but the right one. In a previous video, I landed on and purchased the UDM Pro Max as a replacement for my homebrewed pfSense firewall. Late last year, an opportunity came up to get my hands on an EFG at a great price, and of course, I jumped on it.

Now that I have it, I thought it’d be a great time to compare these two top-end products against each other. Since I don’t answer to Ubiquiti, I’ll give you my honest opinions on whether the EFG really is worth over twice the cost of the UDM Pro Max. Let’s get to testing!

Hardware & Specifications Comparison

CPU Performance

• UDM Pro Max: Quad-core ARM Cortex-A57 CPU @ 2GHz
• EFG: 18-core Marvell/Cavium ThunderX2 ARM v8.2 CPU @ 2GHz

Memory

• UDM Pro Max: 8GB RAM
• EFG: 16GB RAM

Storage

• UDM Pro Max: 128GB integrated SSD, dedicated eMMC, and two 3.5” hot-swappable drive bays for additional UniFi applications
• EFG: No internal storage specifications (does not support running applications other than Network)

Connectivity

• UDM Pro Max: 8× 1-gig RJ45, 1× 2.5-gig RJ45, 2× 10-gig SFP+
• EFG: 2× 2.5-gig RJ45, 2× 10-gig SFP+, 2× 25-gig SFP28

Both systems support dynamic WAN assignment to any port.

IDS/IPS Throughput

• UDM Pro Max: 5 Gbps
• EFG: 12.5 Gbps

Redundancy & Failover

• UDM Pro Max: Shadow Mode, gateway failover, DC Power Backup connection
• EFG: Shadow Mode, gateway failover, dual hot-swappable PSUs

UniFi Application Support

• UDM Pro Max: Network, Protect, Access, Talk, Connect
• EFG: Network only

Understanding the Target Market

The UDM Pro Max is the highest-end all-in-one gateway and controller Ubiquiti has to offer. The additional support for Protect, Access, Talk, and Connect applications, combined with good throughput and plenty of connectivity, make it a reasonable choice for a medium-sized business looking to take advantage of all of Ubiquiti’s offerings.

The EFG, however, is really targeting the enterprise segment with a much more powerful CPU, more RAM, significantly higher throughput, and enterprise features like built-in SSL inspection and hardware redundancy. It lacks the extra application support you get with the Pro Max—an interesting decision on Ubiquiti’s part, as I’m sure this system could support it.

The Reality of Throughput Claims

In my previous video, I mentioned choosing the UDM Pro Max because I have a 5-gig Internet connection and wanted to fully utilize it. Fast forward to today, and I’ve noticed some things about that 5-gig throughput rating that have made me question whether the UDM Pro Max can actually move 5 gigabits per second through itself.

I’ve been testing the UDM Pro Max in production, and I have the receipts to prove that it can’t actually do 5-gig—either in firewall packet filtering or in inter-VLAN routing. Now that I have the EFG for comparison, this is the perfect time to shed light on the realities of actual throughput on these systems.

Network Architecture: Router on a Stick

To understand why throughput performance matters for my setup, it’s important to discuss my network configuration: a design commonly called a “Router on a Stick.”

The concept is simple: my firewall acts as both edge protection for the network and as a router that passes packets between VLANs. This allows me to:

• Control access North to South (to and from the Internet)
• Control access East to West (between VLANs on my network)

This design allows me to place traffic rules around network traffic flows between different VLANs. For example, I want my IoT network to access the Internet, but I also want to reach into my IoT network from my server network so my smart home services can access those IoT devices. By passing everything through the firewall, I can create rules that control these flows exactly how I want them.

Performance Testing

Internet Throughput: UDM Pro Max

Starting with firewall throughput to the Internet through the UDM Pro Max:

Result: 3.79 Gbps download / 4.71 Gbps upload

These aren’t bad numbers, but it’s not the 5 Gbps Internet speed I’m paying for.

Internet Throughput: EFG (Fresh Installation)

Testing the EFG before deploying it into my network with clients:

Result: 5.29 Gbps download / 5.51 Gbps upload

Clearly much better, but was this because there were no clients connected?

Internet Throughput: EFG (Production with Clients)

After importing my configuration and putting the EFG in production with clients:

Result: 5.08 Gbps download / 5.41 Gbps upload

Despite production traffic and connected clients, the EFG maintains strong throughput. The difference between these units is clearly significant.

I want to reiterate that I ran these tests repeatedly, and the results were consistently similar each time. The EFG is demonstrably capable of handling more throughput to the Internet than the UDM Pro Max.

Inter-VLAN Routing Throughput

Using iperf3 to test routing traffic between a VM on my server VLAN and a VM on my client VLAN (both connected via 10-gigabit connections):

UDM Pro Max Result: 3.02 Gbps

Considering the 10-gigabit connections, that’s not great.

EFG Result: 5.06 Gbps

Over 2 gigabits per second faster than the UDM Pro Max—a significant improvement.

Analysis

There’s clearly a performance difference between the two units, which I’d expect given the hardware differences and cost disparity. Fundamentally, it appears both units suffer from the same issue pfSense has with routing: they use the CPU to handle moving packets between networks, tying performance to CPU clock speeds and thread counts.

I had hoped that with the EFG, Ubiquiti might have added an ASIC or dedicated silicon for routing tasks, but it doesn’t appear they did.

Honest Assessment

The UDM Pro Max

At $599, the UDM Pro Max’s ability to be your all-in-one controller for all UniFi products is its big selling point. For small or medium businesses, this price tier is reasonable. Having dual redundant storage for video and additional SSD storage for Ubiquiti apps makes it a solid choice on the higher end.

For homelabbers with slower Internet speeds, you can get a UDM Pro for $379—perfect if you have 1Gig Internet or less.

However, I don’t think Ubiquiti is being honest about the unit’s 5-Gig throughput capability. I’ve never been able to fully utilize my 5-gig Internet connection, and before comparing with the EFG, I thought my ISP was the bottleneck. Turns out they aren’t, and the UDM Pro Max was.

Since that performance rating was a key selling point for choosing the UDM Pro Max over the regular UDM Pro, I’m frankly a little upset about this. Combined with its lackluster inter-VLAN routing capability, it’s left me feeling somewhat cheated.

The Enterprise Fortress Gateway

At $1,999, the EFG’s price is on another planet entirely. Ubiquiti is clearly targeting a different market segment, one I’m not entirely certain they understand how to sell to yet—and I think that shows.

Yes, it has server-class silicon. Yes, it has 25-gig connectivity. Yes, it’s clearly able to handle faster Internet connections. Yes, it can move more bits than the UDM Pro Max. But its inter-VLAN routing is only incrementally better and nowhere near even 10 gigabit performance.

It does have enterprise-level features like SSL inspection (typically only seen in enterprise firewalls) and redundant power supplies, but outside of that, I’m not really seeing anything that makes it enterprise-grade.

The Real Story

If you’re buying either of these systems, you’re probably not doing so because you want the best hardware performance possible. You’re buying them for the UniFi user experience. And that’s not nothing! Most of us buy into their hardware stack because of the dashboard, tight integration, and that sweet, sweet single pane of glass.

The biggest takeaway here is that there is more performance available the more money you spend on their hardware. But knowing that while you might be connected at 10-gig or 25-gig, your actual throughput will be significantly less.

Closing

Thanks for reading, and thanks to everyone who supports this work through Patreon and YouTube Memberships. If you’d like to support what we do, consider checking those out. Join our community Discord and chat with fellow homelabbers, geeks, and nerds.

See you on the next one!

When Veeam began expanding beyond just VMware and Hyper-V, I was ecstatic. Backup is the long pole in the tent for enterprise virtualization, and that expansion finally gave us real freedom in where we could run — and move — our workloads.

But there was still a catch. Running Veeam meant running Windows. And for many organizations, that was a hard stop.

On November 19th, 2025, that finally changed. Veeam version 13 removed the Windows requirement entirely, or did they?

Let’s dig in and take a closer look.

Understanding Veeam v13

Hey there homelabbers, self-hosters, IT-pros, and engineers! Rich here. Now, before we get into feature lists or release notes, I want to level-set what Veeam v13 actually represents. This isn’t about flashy UI changes or minor performance tweaks. This is about architecture.

For the first time, Veeam Backup & Replication no longer requires a Windows Server to run. You can now deploy Veeam as a Linux-based appliance, dramatically reducing overhead, complexity, and license costs — especially in environments that have already moved away from Windows wherever possible.

And that matters a lot right now. Because as organizations continue shifting away from VMware toward platforms like Proxmox, XCP-ng, HyperCore, and VergeOS, the backup layer needs to evolve right alongside them.

So in this article, we’re going to look at what’s new in Veeam v13, how to deploy the new Linux Backup and Replication appliance, build out a simple backup job for Proxmox users, and just as importantly, where the gaps still are.

Headline Features of Veeam v13

Let’s get the headline features of Veeam v13 out of the way first.

First, the biggest feature of v13 is the new Linux-based Veeam Software Appliance. This hardened Linux appliance means you no longer need to have a dedicated Windows Server to run VB&R. The appliance handles security patching and hardening updates automatically as well.

Second, alongside the Linux appliance, version 13 also brings a new next-generation WebUI. This browser-based management UI aims to reduce platform dependencies, adds modern filtering and search, brings an accessibility-ready design, and a built-in dashboard.

Third, Veeam now supports active/passive backup-server clustering to keep backup management available through outages and disasters. This feature only applies to the Linux appliance version and brings redundancy to critical backup operations that were unavailable to the Windows-only version.

Fourth, since we’re focused on Proxmox here, Version 13 now has Application-aware processing support for backing up Windows VMs that run MSSQL, Oracle, and PostgreSQL. And also introduces malware detection for Proxmox VMs as well.

Fifth, V13 sees native support for Scale Computing HyperCore. Now customers running HyperCore can natively backup and restore VMs via Veeam without needing an agent and v13 also includes vTPM support for HyperCore as well.

Additional Features

There are a lot of additional features in v13 that are nearly too numerous to really cover in detail, including:

• Full support for vSphere 9.0
• Universal CDP
• Improvements to agent-based backups
• Support for LTO-10 (36 terabytes per tape!)
• Immutability in GCP
• Instant recovery to Microsoft Azure
• And so many more

Licensing Options

Before we deploy, let’s talk licensing. I’m going to be using the Veeam NFR license, which gives me a total of 20 workloads for backup. If you qualify for the NFR for your homelab, you should get it. But for those who don’t, Veeam still provides a free license for homelabs that’s good for 10 workloads only.

Minimum & Recommended Requirements

Before we install v13, we should probably get the minimum and recommended requirements out of the way first, right?

• CPU: Multi-core x86-64 processor (Recommended: 8-16 cores)
• Memory: 8GB RAM minimum (Recommended: 16GB + 500MB per concurrent job)
• Storage: 120GB OS disk minimum (Recommended: 240GB)
• Backup Storage: Additional local disk of at least 120GB required
• Network: 1Gb Ethernet minimum (Recommended: higher throughput for large environments)

Deploying Veeam v13 Linux Appliance in Proxmox

Alright, we’re going to be deploying this in Proxmox, as I mentioned earlier. I’ve already downloaded v13 and uploaded the installation ISO to my ISO storage in PVE, so let’s build the VM.

Head over to the top right corner and click “create VM”. We need to give our VM a name — I’ll call mine “Veeam” — and hit next.

System Configuration

1. OS Tab: Select your boot ISO for installation and hit next
2. System Tab: Change BIOS to UEFI from default, select a location to store your UEFI storage, and hit next
3. Disks Tab: We need to create two physical disks based on the software requirements
   • OS disk: 240GB (as recommended by Veeam)
   • Backup storage disk: 1TB
4. CPU Tab: Provision 16 cores (as recommended by Veeam)
5. Memory Tab: Allocate 16GB RAM (as recommended)
6. Networking: Add the VM to your server VLAN with planned static IP and DNS
7. Summary: Select “Start after created” and hit finish

Installation Process

Now we’ll head over to the console tab for our freshly built VM to continue the installation. We want Veeam Backup & Replication, so we’ll hit enter to kick that off, and we’ll choose “install - fresh install” and hit enter.

Now we wait while the installer starts up. This can take a bit depending on your hardware. We’ll get a warning stating the installer will irreversibly wipe any data on the drives attached to this VM. Yes to continue.

Now comes the best part of this installer — if you’ve met the minimum requirements for Veeam v13 all the way through, the installer will automatically build the VM. Seriously, just sit back, relax, and wait for the installer to complete. This will take time depending on your hardware, so chill out and let it complete.

Once the automated installation is complete, the VM will reboot, and we’ll get to configuring the basics:

1. EULA: Read it or not — tab to Accept and press Enter
2. Hostname: Set to match your VM name (e.g., “veeam” as an FQDN), then tab to Next
3. Networking: Don’t leave it DHCP by default. Tab to “static” on the right, press Enter, fill in the addressing, then tab down to “apply”
4. Timezone & NTP: Set your timezone (e.g., America/Los Angeles) and run a sync, then tab to Next

Security Configuration

Now let’s talk passwords. Veeam is serious about passwords for this hardened Linux appliance. They’ve aligned their password policy to the DISA STIG password ruleset, which means you’re going to be forced to set a very complex password for the veeamadmin account.

You’ll struggle trying to find an acceptable complex password that works. The requirements are pretty strict — you can’t use more than four of the same characters in a row. Once you find one that works, you’ll move on.

After the password hurdle, Veeam requires you to setup MFA (Multi-Factor Authentication) for this account as well. While I appreciate the emphasis on security and agree it’s important, I do have bones to pick about this, which we’ll discuss later.

In any case, grab your MFA app of choice, scan the QR code, and enter the 6-digit PIN in your app, then tab down to OK.

Veeam v13 also has the concept of a Security Officer for approvals of admin actions in line with Zero Trust principles. If your organization requires this or actually has a designated security officer, you can set this up. Thankfully, you can choose to skip this function and use veeamadmin as the sole account. We’ll check “skip setting up Security Officer” and tab to next.

Finally, we’re shown the summary of our configuration. Tab to finish and press Enter. Veeam will now apply the settings, restart services, and start the web interfaces.

The Installation Experience

You know, I find it kinda funny that the actual v13 installation process was so magically hands-off in the first half of the deployment, and then you’re hit with the password requirements and having to repeatedly fumble through that, only to get hit with a mandatory MFA, completely erasing the efficiency gains in the first half of the install. But as an old English friend of mine used to say, “Into life a little rain must fall.”

The Veeam appliance provides two different webUIs that have very different functions and purposes: the Host management console (used to manage the VM itself, updates, configurations) and the Veeam Backup & Replication webUI (for backup operations).

Host Management Console

You can find the URL to the host management console by looking at the actual console of the v13 Linux VM itself. Once you toss that URL into a browser, you’ll be greeted with a login. Since we opted to only have the veeamadmin account, that’s the account we’ll use. Enter your one-time PIN that you set up during the install.

The Host Management Console is refreshingly straightforward. Let’s get through this quickly:

• Overview: Details on Remote Access, Network configuration, and time settings
• Network: Manage hostname, join Active Directory Domain, add DNS suffixes, modify the IP address of the Veeam host
• Time: Change timezone and manage NTP for your host
• Remote Access: Control access to local SSH and to the Host management GUI itself
• Users and Roles: Create local users and manage their roles in a granular RBAC fashion; apply roles to domain-joined sources
• Backup Infrastructure: Configure remote monitoring, configure high-availability, enable lockdown mode, and run configuration restore
• Updates: Manage updates (requires valid license; more on this later)
• Logs and Services: Status of running services, host configuration files, installed components, audit trail of events, and ability to create a support bundle

Host management is incredibly straightforward, and outside of troubleshooting, you’ll spend very little time there.

Veeam Backup & Replication WebUI

Similar to the Host management console, you can find the URL for VBR on the console of the active v13 VM. Unlike the management console that uses port 10443, the VBR console uses the default SSL port of 443.

This site, like the last, has a self-signed certificate, so click through it to get to the login page.

Once logged in, we land on the overview page and are greeted with a rather crucial message:

“If you notice features missing, it likely hasn’t made its way into the Web UI just yet. For now, feel free to use the Windows-based console whenever you need to manage settings that aren’t available in the Web UI. We will iterate quickly and bring more features over to the new UI with every minor release, prioritizing workloads and features based on their actual usage.”

The Reality of the WebUI

I’m going to jump in here and get to the point: the WebUI is not feature-complete to their full ‘fat’ client. Right now, you can really only manage VMware and Hyper-V backups from the WebUI. You need to download and install the full client, ON WINDOWS ONLY, to configure and back up Proxmox, Nutanix, Scale Computing, and any agent-based backup jobs.

The next popup alerts you that you don’t have a valid license installed in Veeam. Go ahead and take care of that by clicking “Install” on the left and double-clicking on your license file.

Veeam will import your license and start checking for updates. Once done, you land on the Overview page which provides detailed information like:

• Resiliency Overview
• Threat hunting
• Infrastructure Health
• Protected Workloads
• Protection Overview
• Top Repositories

Since this is a fresh install, it’s all looking very blank.

WebUI Sections

Jobs: See your currently configured backup jobs and backup copy jobs. Keep in mind that currently only VMware and Hyper-V jobs will show in this view. You can add new jobs by clicking “Add” in the middle.

Backups: See a list of backed up jobs that you can restore from — instant VM recovery, regular restore, access guest files, or delete.

Repositories: Create and manage your backup repositories. In Veeam language, a repository is a storage location for backups. You’ll have a single default repository auto-generated during install. You can also manage Scale-out repositories and configure Veeam’s Data Cloud Vault (Veeam’s cloud storage offering).

Proxies: In Veeam, a Proxy is used to move data between VMs and the backup storage. Proxies increase concurrent backup capacity and distribute load across multiple systems. By default, the Linux system is also a VMware backup proxy. The current WebUI only supports VMware and Hyper-V proxy management.

Managed Servers: See your deployed Veeam server. This section is where you’d add virtual hosts and Linux hosts. Currently, the WebUI only supports adding Hyper-V, VMware, and individual Linux and Windows hosts.

Logs and Events: Full audit trail of backup job status, Authorization events for change control requests, and any discovered malware events. It’s nice to have these easily accessible via the web.

Veeam ONE: Veeam ONE is Veeam’s monitoring suite for their software. At this time, VeeamONE requires a Windows host to install, so it’s behind on Veeam’s VB&R track. You can integrate it into your Linux v13 deployment here.

The WebUI Limitation

I’m just going to come out and say it now: the Veeam WebUI is woefully lacking feature completeness at this time. Now it makes sense why they hit us with that pop-up on first login. To say that I wasn’t disappointed by the sheer lack of any backup management support for anything BUT VMware and Hyper-V was a pretty huge letdown, frankly.

So what do we do now? We need to install the v13 fat client on a Windows system and backup Proxmox since that’s the only way to do it currently.

Installing the Windows Console

To download the Windows v13 console, head over to configuration on the top right, then down to About, and then click on “Download Windows-based backup console.” Once that’s downloaded, run through the install.

The install takes some time to complete, but it’s basically a next, next, finish sort of installation.

Using the Windows Client

Once you’ve installed the fat client and launched it, you’ll need to enter the IP address or hostname of your VBR Linux and click Connect.

Now enter the veeamadmin user and complex password, and click sign-in below.

For existing Veeam users, this is going to look and function essentially the same as version 12, so we won’t spend a ton of time going through all the nuances of the full client. But let’s do a quick once-over for completeness.

Interface Overview

When we log in, we first land on the Home section, which gets straight to business with backup jobs and their status. Obviously, this is a fresh install with no backup jobs setup yet.

Inventory Tab: Shows discovered infrastructure and protected objects. Finally, we can see all of the virtual platforms that version 13 supports — from VMware and Hyper-V to Nutanix, Proxmox VE, and SC HyperCore.

Backup Infrastructure Tab: Where you design, register, and manage the components that do the backup work. If the Inventory tab is what exists, the Backup Infrastructure tab is how backups happen.

History: A history of the events that have occurred on your VBR host.

Adding Proxmox & Creating Backup Jobs

Let’s get our Proxmox host added to Veeam. Head back to the Inventory tab, then to the Proxmox VE section. Click “Add Server” in the top left.

First, tell Veeam the DNS name or IP address of your Proxmox server. I’ll add “Proxinator” and hit next.

Veeam needs root credentials to interact with the Proxmox host. Click “add” on the far right, enter your root user and password, give it a description, and click OK. Note: starting in version 13, you can add non-root accounts that can do privilege escalation when needed.

Click “Next” to continue. Veeam will call out and connect to your host. Since this is the first time, you’re asked if you wish to trust the SSH RSA key. Say yes to continue.

Next, you’re asked if you’re willing to trust the SSL certificate for your Proxmox host. If you’re using a self-signed SSL cert (as I am), this message will appear. If you’re using a publicly trusted cert, it won’t. Click Continue.

Now select a storage location to save snapshots in case the original VM’s storage doesn’t support snapshotting. You can leave this set as-is or manually select a storage location. Once done, click Apply.

Sit back and let Veeam complete the server add process. The next screen shows a summary, and finish completes the wizard.

Deploying the Worker Node

Veeam requires a worker node to move data from the PVE host to the backup system. A worker node is a lightweight VM that will be added to your PVE host. Click Yes to kick this off.

1. Give your worker a name
2. Choose which storage location on your PVE host this VM will live
3. Click next
4. Choose a network to attach the worker VM to. Click “add,” select your PVE SDN network, leave the network config set to DHCP, and click OK
5. Click Finish to kick off the deployment

This can take a bit to complete. And boom, done!

For reference, this is essentially identical to how we added PVE to Veeam in v12, so no surprises at all.

Building the Backup Job

Now we see the newly added “Proxinator” under the Proxmox VE section. If we click on it, we see the full list of virtual machine workloads running on the box.

Important Note: Veeam v13 still does not support backing up LXC containers. Even in version 13, there’s no way to backup LXC containers in Proxmox. PBS can backup LXC containers all day long, but Veeam still doesn’t have complete support for all workloads.

Let’s build our backup job for Proxmox. Head over to Home, then at the top, click “Backup Job” and select “Virtual Machine.”

Give your backup job a name (e.g., “proxmox backup”) and head down to Next.

Now select the VMs you want to backup. Click “add” on the right, expand your PVE host, and select the backups you wish to add. Once done, click OK. Everything looks good, so click Next.

Choose where you want to store these backups. We only have one backup repository that was provisioned automatically during deployment. Next, decide how long to retain your backups — I’m a fan of 15 days, so I’ll enter in 15 and then click next.

Next is guest processing. V13 brings guest processing to PVE backups, which is a big deal. Administrators of SQL and others know the importance and sensitivity around being able to have the backup system reach into a VM and tell it to do something before backups run to guarantee the data being backed up is valid and correct. This is fantastic for PVE. If you don’t have any applications requiring application awareness, click Next.

Now set up a schedule for the backup job to run automatically. I’ll set this to run nightly at 4 AM. The default retries are fine as-is, so click Apply.

The final page is just a summary of your settings. There’s a checkbox to kick off the first backup when you click finish. Check that as well, then hit finish to complete this work.

Now we can see the backup job was created and because we checked the box, it’s running the backup job now.

This is all very much typical of the PVE experience in version 12 of Veeam Backup and Replication.

Final Thoughts: The Good and the Bad

Let’s get into the good and bad and final thoughts about Veeam v13 and its new native Linux appliance.

The Good

Veeam is doing the right thing here. Divesting of their dependence on Windows is a smart thing to do, and I applaud them for making the effort. Version 13 really does raise the bar for Veeam as the premier enterprise backup platform of choice.

Getting application awareness into the backup process for PVE backups is huge. SQL needs transaction log truncation to happen or the backups created are worthless. This opens the option to move workloads that require application awareness into PVE, which I’m all for.

The biggest deal here is what Veeam is becoming with v13. Backups, yes, all day long. But I don’t think many people realize the add-on advantage of using Veeam and the freedom it gives you.

Let me explain: VMware blows up, people leave — for good reason — and they all land somewhere, but their workloads were still in VMware. Every single alternative hypervisor on the market has an import tool or system to get your workloads OUT of VMware and into their platform, easy. But none of these alternative platforms import from any platform other than VMware. See the problem?

Where I think Veeam’s true future is, isn’t just backup — it’s also being a universal workload migration platform for virtualization. One of the big things we learned with the Broadcom disruption of VMware was that we’d all become complacent and trusted that our infrastructure platforms would stay the same. It didn’t. These days, the smart decision is to have a diverse virtualization plan. Maybe have Nutanix and Proxmox, or XCP-ng and VergeOS, but the point is don’t have all your eggs in one basket.

Veeam becomes the universal bridge between all of these different hypervisors, and ultimately gives you the freedom to move your workloads anywhere. And that’s a really big deal.

The Bad

First off: I don’t consider the webUI production-ready yet. At least not for anything but VMware and Hyper-V. I’m not sure if it was just easier for Veeam to knock out those two or if there was more customer pressure behind those platforms. Still, the tailwinds are not in VMware’s or Hyper-V’s favor.

All of the effort going into natively supporting Proxmox, Nutanix, SC HyperCore, and in the near future, VergeOS and XCP-ng — I feel it would have been better to release the webUI when you could support ALL of the current hypervisor platforms.

Next, specifically a gripe for PVE: it’s not a full-featured backup solution for PVE until Veeam can support backing up and restoring LXC containers, which it still can’t. If you’re a PVE shop that has a lot of LXC containers and you’re looking for backup solutions, PBS is still your best bet — hands down. Veeam, do both, please.

Finally, a minor gripe: I was very annoyed with Veeam’s presumption that I need this level of password security and mandatory MFA for the Linux appliance. I understand the reasons behind it, and I’m not bagging on increased security — I’m advocating for customer choice. Ask me if my environment requires enhanced security configurations and let me make that choice. This isn’t a problem with the Windows server version of Veeam, so don’t make it one for the Linux appliance.

Final Verdict

All of this said, Veeam is on the right track and they’re doing great things. I’ve said it a thousand times now, but backup really is the long pole in the tent. With Veeam’s native support for VMware, Hyper-V, Proxmox, and SC HyperCore — with even more coming online very soon — it really is becoming the backup and workload migration tool for business!

And that’ll do it. A special thank you to a certain Discord member for the continual push to get this v13 article out. If you have feedback on anything I’ve said here, leave a comment below, subscribe to the channel, and join our free Discord.

YouTube link: https://youtu.be/IUsywSK9Miw

Canonical MicroCloud Setup and Walkthrough Summary

🧩 Overview

• MicroCloud is a lightweight, self-hosted private cloud by Canonical (the makers of Ubuntu).
• It combines LXD, MicroCeph, and MicroOVN into one automated stack.
• Designed for edge computing, homelabs, and small enterprise environments.
• Provides high-availability compute, storage, and networking — without the complexity of OpenStack or Kubernetes.

⚙️ System Requirements

Minimum

• 8 GB RAM per node
• One local disk (no partitions)
• One network interface
• Ubuntu 22.04 LTS or newer

Production Recommended

• 3 physical nodes for HA
• 32 GB RAM per node
• 3 disks per node (OS, local storage, distributed storage) — NVMe recommended
• 2x 10Gb network interfaces per node (cluster + uplink)

💡 For production: deploy on bare metal, separate networks for Ceph and OVN.

🧠 Planning the Deployment

1. Prepare a worksheet noting each node’s:
   • IP address
   • Network interface assignments
   • Disk setup
2. Configure your nodes’ base OS and networking before installing MicroCloud.

🚀 Installation Steps

Pre-Work

Your installation targets must have at least Ubuntu 22.04 LTS or newer installed and updated before attempting to install MicroCloud

1. Install MicroCloud Components

sudo snap install lxd microceph microovn microcloud --cohort="+"

2. Prevent Auto-updates

sudo snap refresh lxd microceph microovn microcloud --hold

3. Initialize the First Node

sudo microcloud init

• Configure internal network.
• Select local and distributed storage disks.
• Assign Ceph subnets (internal/public).
• Wait for initialization to finish.

🧩 Expanding the Cluster

1. On first node:

   sudo microcloud add
   

2. On each new node:

   sudo microcloud join
   

3. Provide cluster passphrase, select network interfaces, and assign disks.
4. Wait for nodes to sync and complete setup.

🖥️ Accessing the GUI (LXD UI)

• Access via: https://<node-IP>:8443
• Accept self-signed certificate.
• Authenticate using certificate-based identity:

  lxc auth identity create tls/lxd-ui --group admins
  

• Copy the generated token and paste it into the web UI.

🔍 LXD UI Tour

• Dashboard Layout
  Left navigation panel with detailed sections per service area.

Core Sections

• Instances: Manage containers and VMs.
• Profiles: Define hardware and configuration templates.
• Networks: Manage bridges, VLANs, and ACLs (acts as firewalls).
• Storage: Manage pools, volumes, and S3-compatible buckets.
• Images: Base OS templates for launching workloads.
• Clustering: View nodes, groups, operations, and warnings.
• Permissions: Manage identities, groups, and IDP integrations.
• Settings: Control global options (including dark mode).

🧱 Creating Your First Instance

1. Click “Create Instance.”
2. Name and optionally describe it.
3. Choose an image (e.g., Ubuntu 24.04 LTS).
4. Set as container or VM.
5. Select desired cluster node or group.
6. Apply a profile (e.g., custom disk size).
7. Click “Create and Start.”

You can then:

• Manage configuration (disks, network, GPU passthrough).
• Use Terminal or Console to access the instance.
• View logs and snapshots within the GUI.

💬 Final Thoughts

👍 Pros

• Easy to deploy — runs with a few commands.
• Intuitive, clean LXD UI.
• Huge catalog of Linux images (even Windows supported).
• Supports GPU, USB, PCI passthrough.
• Great for homelab and small-scale production environments.

👎 Cons

• Documentation clarity needs improvement.
• Lacks built-in monitoring — requires Prometheus/Grafana.
• GUI only supports certificate-based login (no basic user/password option).

🔗 Learn More

Visit Canonical MicroCloud for details, documentation, and setup guides.

Summary:
Canonical’s MicroCloud is a simplified yet powerful private cloud platform. It provides automated setup for compute, storage, and networking using familiar Ubuntu tools, making it ideal for homelabbers and IT professionals seeking private cloud efficiency with minimal complexity.

Am I a TRAITOR to pfSense?! Switching to the UniFi UDM Pro Max

For years, I’ve been one of the loudest pfSense advocates around. I’ve built firewalls, tested hardware, and shown you every trick I’ve learned along the way. But sometimes, even the most loyal of us have to stop, take a breath, and ask: is it time to move on?

That’s what this post is about — evaluating where pfSense stands today, and whether the UniFi UDM Pro Max has finally earned a place in my homelab rack.

The Backstory: My Long-Term Relationship with pfSense

If you’ve followed 2GuysTek for a while, you know I’ve been running pfSense for years. My trusty Sophos SG330, which I picked up off eBay and upgraded myself, has been my daily driver for over three and a half years.

It’s been solid, reliable, and powerful — but it’s also getting old. The SG330 came out in 2014 and it sounds like a jet engine under load. Between the age, the noise, and the growing list of newer alternatives, I decided it was time to evaluate what’s next.

Before jumping to conclusions, I started like I always do — with a requirements analysis.

Defining My Needs (and My Wants)

When it comes to network infrastructure, I break things down into two categories: Necessary and Nice-to-Have.

✅ Necessary

• 5 Gbps Internet throughput for firewalling, packet filtering, and IDS/IPS
• 10Gig network support with SFP+ connectivity
• Must handle router-on-a-stick Layer 3 routing
• Needs to support IPsec, WireGuard, or similar site-to-site VPN
• Must be rack-mountable
• Quiet or fanless design

💡 Nice-to-Have

• A modern, easy-to-use UI
• DHCP & DNS handling for multiple VLANs
• Built-in URL/ad filtering
• GeoIP blocking capabilities
• Native Tailscale VPN integration

With that list in hand, I started exploring what the market had to offer.

pfSense Hardware Options from Netgate

I first looked at Netgate’s official hardware line. Prices range from:

• $190 for the entry-level Netgate 1100,
• up to $3,600 for the powerhouse Netgate 8300.

But once I factored in my need for 10Gig SFP+, the realistic contenders narrowed to:

• Netgate 6100 – $850
• Netgate 8200 – $1,500
• Netgate 8300 – $3,600

The 8200 caught my eye immediately — it checks every box.

Netgate 8200 Specs:

• 8-core Intel Atom C3758R (2.4GHz)
• 128GB NVMe M.2 storage
• 16GB DDR4 RAM
• Dual 10Gig SFP+, four 2.5Gig, and two 1Gig combo ports
• Up to 18.6Gbps L3 forwarding and 3.24Gbps IPsec throughput

It’s a beast. But it’s also expensive. So before committing, I wanted to see what “the dark side” had to offer.

The Challenger: Ubiquiti UniFi UDM Pro Max

Ubiquiti has exploded with new offerings recently. Their UDM Pro Max immediately stood out — not just for specs, but for how it could simplify my life.

UDM Pro Max Specs:

• Quad-core ARM Cortex-A57 (2.0GHz)
• 8GB RAM
• 128GB SSD + 32GB eMMC
• Dual 10Gig SFP+, one 2.5Gig, and eight 1Gig ports
• Supports IPsec, OpenVPN, and UniFi’s own Site Magic VPN
• Built-in UniFi Network and Protect controllers

Ubiquiti claims up to 5Gbps of IDS/IPS throughput, which perfectly fits my requirements — and at $600, it’s far more affordable than the pfSense options.

pfSense vs UniFi: Breaking Down the Experience

User Interface

Both pfSense+ and UniFi have modern, clean UIs — but UniFi wins on polish and user experience. Its dashboard is gorgeous and intuitive.

DHCP & DNS

Tie. Both systems handle this natively and effectively.

DNS Filtering

pfSense wins here, hands down. pfBlockerNG is still the gold standard for free, configurable ad and spam blocking. UniFi’s built-in filtering works, but can be overly aggressive.

GeoIP Blocking

Both platforms handle it well.

Tailscale VPN

pfSense supports Tailscale natively. UniFi doesn’t — though you can work around it with a small Proxmox VM running Tailscale.

Overall, both systems satisfy the core needs, but the price-to-feature ratio begins to tilt in Ubiquiti’s favor.

Consulting the Experts

Before making a decision, I reached out to Tom Lawrence — someone who’s already walked this path. His insights helped confirm my suspicions: UniFi’s innovation curve and user experience have outpaced pfSense in recent years.

If you want to see our full conversation, let me know in the comments or reach out — I’ll post the entire chat as a standalone video if there’s interest.

My Decision: Joining the Dark Side

After weighing everything, I made the switch.
Here’s why:

1. Unified Experience – All my production networking gear is already UniFi. Adding the UDM Pro Max completes the “single pane of glass.”
2. Cost – Even compared to the Netgate 6100, the UDM Pro Max is cheaper by around $150.
3. Innovation – Ubiquiti is moving faster in terms of features and software improvements.
4. No Licensing Fees – Once you buy it, you’re done. No annual pfSense+ renewals.

Sure, there are trade-offs — like the lack of native Tailscale or pfBlockerNG-level filtering — but I can solve those with small workarounds.

Migration and Setup

Setting up the UDM Pro Max was painless.

• I racked it up, powered it on, and used the UniFi mobile app to onboard it.
• The setup flow felt Apple-like — simple and elegant.
• Firmware updated automatically, and within minutes, the system was live.

Next came the migration from my self-hosted UniFi controller. After downloading and restoring my backup (and updating software versions to match), the import went smoothly. A quick shutdown of my old controller fixed some connection conflicts, and soon everything was talking perfectly.

Within about an hour, my network was fully migrated.

Final Configuration and First Impressions

My UniFi dashboard now shows full visibility — LAN and WAN data unified.
My devices, SSIDs, VLANs, and icons all imported perfectly. I also activated CyberSecure for regional blocking and added zone-based firewalling.

One quick pro tip: enable east-west traffic logging under Syslog settings — it’s off by default but essential for troubleshooting VLAN-to-VLAN communication.

After tuning everything, the system looked rock-solid.

Final Thoughts: Loyalty vs Evolution

Do I feel like a traitor? Maybe a little.
But I remind myself that brand loyalty isn’t the goal — good engineering is. Evaluating alternatives and adapting when it makes sense is what any good technologist should do.

I still have a soft spot for pfSense. I hope Netgate continues to innovate because competition is healthy for all of us. But for now, the UDM Pro Max has earned its place in my rack.

And that’s the beauty of the homelab: we can experiment, evolve, and share what we learn with the community.

Special Thanks

Huge thanks to Tom Lawrence for sharing his insights and helping me through the decision process.

If you’ve made the switch (or are thinking about it), drop a comment below — I’d love to hear your experience.

Written by Rich Teslow — Founder of 2GuysTek, Senior Security Engineer, and lifelong homelabber.