Stop installing clients. Here’s how you can access your remote computers from anywhere, using just a standard web browser.

Have you ever been away from your main computer, maybe on a friend’s laptop or just using a tablet on the couch, and suddenly needed to access something on it? Maybe it’s a file, an application, or just to check on a running process. The usual solution involves installing a dedicated Remote Desktop client, but what if you can’t, or don’t want to, install software on the device you’re using? It turns out there’s a wonderfully elegant solution: using a browser-based RDP client.

It’s a simple but powerful idea. Instead of a dedicated app, you just open a web browser, navigate to a local URL you’ve set up, and get a full remote desktop session right there in the tab. It feels a little like magic the first time you see it work. You get all the power of a remote connection without needing to install anything on the client machine. This is perfect for home lab enthusiasts, IT professionals, or anyone who wants a more flexible way to manage their machines.

So, What Exactly Is a Browser-Based RDP Setup?

Normally, to connect to a Windows machine remotely, you use the Remote Desktop Protocol (RDP). This requires a client application, like the one built into Windows (MSTSC) or Remmina on Linux.

A browser-based RDP solution adds a middleman—a web server that you host yourself. Here’s the flow:

1. You open a browser on any device (a laptop, tablet, or even a phone).
2. You navigate to the web app’s URL (e.g., `http://remote.yourhomenetwork.com`).
3. You log into the web app.
4. The web app presents you with a list of your configured computers.
5. You click one, and the server opens the RDP connection for you and streams the desktop session directly to your browser as if it were a video.

All the heavy lifting is done by your server. Your browser just needs to render the HTML5 stream, something every modern browser is great at.

The Best Tool for the Job: Apache Guacamole

When it comes to self-hosted, browser-based remote access, one name stands above the rest: Apache Guacamole. Don’t let the quirky name fool you; it’s an incredibly powerful and mature open-source project.

Guacamole is a “clientless remote desktop gateway.” In simple terms, it’s a web application that provides access to your desktops. Because it’s “clientless,” you don’t need any plugins or client software. Just a web browser.

While we’re focused on RDP for Windows machines, Guacamole’s flexibility is one of its best features. It also supports other common protocols, including:

• VNC: A popular alternative for remote desktop on Windows, macOS, and Linux.
• SSH: For secure command-line access to servers.
• Telnet: An older command-line protocol.

This means you can create a single, unified web portal to access all of your devices, whether they’re graphical desktops or headless servers.

Getting Started with a Browser-Based RDP Gateway

Setting up a tool like Apache Guacamole might sound intimidating, but it’s more accessible than ever, especially if you’re familiar with Docker. The official Apache Guacamole documentation provides a fantastic guide for getting it up and running with Docker Compose.

At a high level, the setup involves running a few Docker containers that work together:
* guacd: The core proxy daemon that translates connections.
* guacamole: The web application itself.
* A database (like PostgreSQL or MySQL) to store user and connection data.

Once it’s running, you log into the web interface, and from there you can configure all your connections. For each one, you’ll specify the protocol (RDP, VNC, etc.), the IP address or hostname of the target machine, and the authentication credentials.

Are There Any Alternatives?

While Guacamole is the most popular choice for this specific task, the world of open-source remote access is vast. A few other projects offer similar, browser-based functionality, though they often have a broader focus. Tools like MeshCentral and RustDesk are excellent remote management suites that also include browser-based access as a feature. They are fantastic projects worth exploring if you need features beyond simple session proxying.

But for a dedicated, self-hosted gateway to access your existing machines right from a browser tab, it’s hard to beat the focused power and simplicity of a browser-based RDP setup using Apache Guacamole. It’s a game-changer for managing a home lab or just having convenient access to your digital life from anywhere.

Rethinking my home lab setup and the classic debate: one beefy server or two specialized machines?

My Home Lab Is a Mess. Is It Time to Split It Up?

I’ve hit that classic crossroads that many tech tinkerers eventually face. My all-in-one server, which started so simply, has become a bit of a tangled mess. It’s got me seriously thinking about my home lab setup, and whether it’s time for a major restructure. I have two machines—one new and powerful, one older and gathering dust—and I’m trying to figure out the best way to use them both. Maybe you’re in the same boat.

Here’s My Current Home Lab Setup

Right now, my entire operation runs on a slick little Beelink Mini PC. It’s a SER5 MAX with a Ryzen 7 6800U processor, and it’s been a fantastic workhorse. It’s running Unraid and handles everything: my NAS, Plex for media streaming, the whole suite of *Arr containers, a personal website, and a few home automation apps.

The storage is a bit… unconventional. The Beelink has two zippy 1TB SSDs inside, but all my media lives on four big hard drives in a 4-bay DAS (Direct-Attached Storage) enclosure that’s hanging off the mini PC via a USB cable. It works, but it feels a bit precarious. And in the corner, my old gaming PC—a respectable AMD Ryzen 7 1700—is sitting completely idle. It feels like a waste of potential.

The Big Idea: A Split Home Lab Setup

So, I’ve been sketching out a new plan. Instead of one machine doing everything, why not give each computer a specialized job? It seems cleaner and more logical.

1. The Dedicated NAS: My older Ryzen 7 1700 machine would be pulled out of retirement. I’d move the four hard drives from the DAS directly into the PC case. It has the space and the SATA ports, after all. Then, I’d install a dedicated NAS operating system like Unraid on it. Its sole job would be to store files safely and serve them over the network.

2. The Dedicated Virtualization Host: The powerful Beelink Mini PC would be freed from storage duties. I’d wipe it and install Proxmox on it. With its fast processor and internal SSDs, it would become a dedicated hypervisor, running all my virtual machines (VMs) and containers like Plex, my website, and other apps.

Is This a Better Home Lab Setup? Weighing the Pros and Cons

This is where the real questions come in. Splitting roles sounds great in theory, but is it actually a good use of my hardware? I’ve been weighing the pros and cons.

The Upsides:

• Simplicity and Stability: Each machine has one clear purpose. If I need to reboot my Proxmox server to test a new app, my NAS and all its files stay online, completely unaffected.
• Better I/O Performance: A DAS connected over USB is a classic bottleneck. By moving the hard drives into the older PC with native SATA connections, my storage performance should be much more reliable. No more worrying about a USB cable getting jostled.
• Focused Resources: The Mini PC’s fast CPU and SSDs are perfect for running applications, while the older PC is more than capable of handling file-serving tasks. Each machine gets to play to its strengths.

The Downsides (and My Rebuttals):

• Power Consumption: This is my biggest worry. The old Ryzen 7 1700 will definitely use more power at idle than the super-efficient 6800U in the mini PC. But how much more? After some research on sites like ServeTheHome, a great resource for this kind of hardware, the consensus is that while it will be higher, it might not be as dramatic as I think, especially at idle. The stability gains might be worth a few extra dollars on the power bill.

• Is 8GB of RAM Enough? The old machine only has 8GB of RAM. Is that enough for a dedicated Unraid NAS? For my plan, the answer is a resounding yes. Since all the heavy lifting (Plex transcoding, VMs, etc.) is moving to the Proxmox server, the NAS will just be… a NAS. It will serve files. Unraid itself is very lightweight, and 8GB is plenty for basic file storage and maybe one or two very lightweight utility containers.

My Verdict: I’m Splitting My Home Lab

After thinking it through, I’m going for it. The proposed home lab setup just makes more sense.

The current all-in-one approach is convenient, but it’s also a single point of failure and creates performance bottlenecks. Separating the roles of storage and services feels like a more mature, robust architecture for a home lab that’s growing beyond a simple hobby. The increase in power consumption is a valid concern, but one I’m willing to accept for the significant gains in stability, performance, and peace of mind.

The plan is set as of August 2025. The old Ryzen will soon be humming away as my dedicated Unraid NAS, and the Beelink Mini PC will become a pure Proxmox virtualization server. It’ll be a fun weekend project, that’s for sure.

Every home lab is a personal journey, a constant evolution of hardware and software. This feels like the right next step for mine. It’s about creating a system that’s not just powerful, but also resilient and easier to manage in the long run.

What do you think? Have you ever considered splitting your own setup? I’d love to hear your thoughts and experiences in the comments below.

What starts with a single server can quickly become a complex ecosystem. Here’s the story of how my passion project became a source of anxiety.

It all started from a simple place: a love for computers.

I’ve been running what you might call a “homelab” for over two decades. It didn’t start as some grand project. It was just a network hub, a couple of older computers, and a passion for tinkering. One machine handled network storage, and another, believe it or not, ran a Lotus Notes server for my email. It was simple, fun, and entirely manageable. But over the years, a slow, almost invisible force took over: homelab creep. What began as a simple hobby has gradually morphed into something that feels less like a passion and more like a small enterprise system I’m constantly trying to keep from collapsing.

It all happens one small step at a time.

The Slow March of Homelab Creep

You don’t just wake up one day with a rack of servers humming in your basement. It begins with a single, perfectly reasonable thought: “I can make this a little better.”

For me, it started with the basics. Why use my internet provider’s DNS when I could have more control? So, I set up a Pi-hole. But what if it fails? That led to setting up three Pi-hole instances for redundancy. Then came the DHCP server. A simple ISC server worked fine for years, but then I discovered KEA DHCP. It offered more features, so I set it up in a primary and secondary configuration with a Postgres backend.

Of course, managing that from the command line was a bit of a pain. The logical next step? Build a custom web front-end for it. Each solution created a new, slightly more complex problem, and I was all too happy to solve it.

Chasing Reliability and Adding Complexity

With a growing number of virtual machines and containers, I realized I was flying blind. I needed to know what was running, what was struggling, and what was about to fail. So, I added a monitoring solution. Then I needed a slick dashboard to see it all at a glance, so in came Glance. But what good is monitoring if you don’t know when something breaks? That meant I needed a notification system, so I set up NTFY.

This is the heart of homelab creep: every new layer of complexity is a solution to a problem created by the last layer.

The real turning point for me was when I decided I wanted to run my own Certificate Authority (CA) to issue SSL and SSH certificates for my internal services. I dove in and set up Smallstep, a powerful open-source CA. It was a fantastic learning experience, but it also added another critical piece of infrastructure I was now responsible for maintaining.

When Your Homelab Creep Demands Full Automation

Things were getting out of hand. Managing everything manually was becoming a chore. The updates, the configurations, the new VMs—it was too much. So, I decided it was time to learn Ansible.

I dove in headfirst, writing playbooks to automate everything:
* Updating all my VMs and containers.
* Spinning up new virtual machines from templates.
* Checking for available container updates.
* Renewing my internal certificates.

Ansible was powerful, and for a while, it felt like I had finally tamed the beast. But then, a new anxiety emerged: how do I know if my automation is actually working?

This was the final, almost comical, step. I set up my Ansible scripts to write their status to JSON files. Then I wrote a simple Python web server to parse those files and feed the data into my Glance dashboard. I had now built a monitoring system to monitor my automation system, which was built to manage the complex system that my simple hobby had become.

The House of Cards

Today, I find myself surrounded by six computers, five Raspberry Pis, a standalone NAS, and a web of VMs, containers, and scripts I built myself.

The simple joy of tinkering has been replaced by a low-level anxiety. I feel less like a hobbyist and more like a sysadmin for a small, quirky, and incredibly fragile business. It’s a house of cards, and I’m just waiting for one wrong move or one failed component to bring it all tumbling down.

It’s overwhelming. This intricate system I’ve poured years into now feels less like an achievement and more like a burden.

Does any of this sound familiar? Have you ever felt the pressure of your own homelab creep? I’m sure I’m not the only one who has gone down this rabbit hole. Check out communities like the /r/homelab subreddit to see you’re in good company. I’d love to hear your story in the comments below.

Tired of users seeing folders they can’t open? Here’s the simple fix for your TrueNAS SMB permissions to hide what they don’t need to see.

You’ve done it. You’ve set up your awesome TrueNAS server, you’ve created a bunch of datasets for things like photos, documents, and backups, and you’ve even set up individual user accounts for your family or teammates. You’re feeling pretty good about your new, organized digital life. But then you log in with one of those limited accounts and notice something… odd. They can see every single folder, even the ones they can’t open. It’s not a huge security flaw, but it’s messy and confusing. If this sounds familiar, you’re not alone. It’s a common hurdle when you first start dialing in your TrueNAS SMB permissions.

The good news is there’s a super simple fix that cleans this all up, hiding folders from anyone who doesn’t have the keys to open them.

Why Does TrueNAS Show Everything by Default?

First, don’t worry—your server isn’t broken. This is actually standard behavior for SMB (Server Message Block), the protocol Windows and other operating systems use for network file sharing. By default, it tells everyone what folders are available, and only when someone tries to open one does it check if they have permission.

For a home user or small business, this isn’t ideal. It creates visual clutter and can lead to questions like, “Hey, what’s in this ‘Admin_Backups’ folder and why can’t I open it?” It’s just… tidier to have people only see what they can actually access. Think of it as the difference between a building directory that lists every office, including the secret ones, versus one that only shows you the offices you have a keycard for.

The Magic Setting: Better TrueNAS SMB Permissions with ABE

The feature that fixes this is called Access Based Enumeration, or ABE. It sounds technical, but it’s just a fancy term for “if you can’t access it, you won’t even see it.” When you turn this on, TrueNAS will check a user’s permissions before showing them the contents of a share.

Here’s how to enable it. It takes less than a minute.

1. Log in to your TrueNAS web interface.
2. Navigate to Sharing on the left-hand menu, and then click on Windows Shares (SMB).
3. You’ll see a list of the shares you’ve created. Find the one you want to clean up, click the three dots on the far right, and select Edit.
4. A new screen will pop up with all the settings for that share. Click on Advanced Options at the bottom.
5. Scroll down until you find a checkbox labeled Access Based Share Enumeration. It’s usually about halfway down the advanced list.
6. Check the box!
7. Click Save.

That’s it. Seriously. Now, when a user connects to that network share, they will only see the folders and files that they have been granted permission to read or modify. The rest will be completely invisible.

Fine-Tuning Your TrueNAS SMB permissions

Enabling ABE is a share-level setting, but it works hand-in-hand with your dataset-level permissions. ABE decides what to show, while your ACLs (Access Control Lists) decide who can actually get in.

This is an important distinction. For ABE to work correctly, you still need to have your underlying permissions set up properly.

• Dataset Permissions: This is where you define the granular rules. On your Storage Pool, you can edit the permissions for each dataset, specifying which users or groups can read, write, or execute files within it. This is the foundation of your security.
• Share-Level ABE: This is the visibility layer on top. It simply respects the dataset permissions you’ve already configured and hides things accordingly.

If you’re new to setting up permissions, the official TrueNAS documentation on SMB Shares is an excellent resource. For a deeper dive into what ABE is doing under the hood, you can even check out the original Microsoft documentation on the feature.

After you enable ABE, always remember to test it. Log in from a computer using one of your restricted user accounts and browse the network share. The folders you wanted to hide should now be gone, leaving a much cleaner and less confusing experience for everyone. It’s a small change that makes your professional-grade server feel a little more user-friendly.

Choosing the right server storage design for your home lab doesn’t have to be complicated. Let’s talk Proxmox, ZFS, and TrueNAS.

You’ve got the hardware. It’s sitting there, a powerful server humming with potential. You’ve got a stack of hard drives ready to go. But then you hit the wall. Not a technical wall, but a mental one. The paralysis of planning. I’ve been there, staring at a pile of components, trying to map out the absolute perfect server storage design before I even install the operating system. It’s a common trap for anyone building a home lab, but getting it right from the start can save a ton of headaches later.

So let’s talk it through. You have a goal: to run a hypervisor like Proxmox, spin up some virtual machines (VMs) and containers, and start hosting cool applications like a self-hosted photo manager. But the big question looms: how do you handle the storage for all that data?

The Hardware and the Dream

Let’s imagine a common scenario. You have a server, maybe an enterprise-grade Dell or HP, with a handful of large capacity spinning drives (like 10TB SAS drives) for bulk data. You also have a couple of faster, smaller SSDs for things that need more performance, and maybe even a pair of tiny M.2 drives on a special card (like Dell’s BOSS card) intended for the operating system.

The dream is simple: run Proxmox as the base OS, and then use VMs and containers for everything else. This is an efficient, popular way to run a home lab. But the dream hinges on a solid storage foundation.

The Big Debate: A Good Server Storage Design

This is where things get tricky and where most of the overthinking happens. When using Proxmox, you generally have two popular paths for a robust server storage design:

1. ZFS Directly in Proxmox: You install Proxmox on your boot drives and then use its built-in capabilities to create a ZFS storage pool directly from your data drives.
2. TrueNAS in a VM: You install Proxmox, create a virtual machine, install a dedicated storage OS like TrueNAS SCALE inside it, and pass your HBA controller (the card your data drives are connected to) directly to that VM.

On the surface, the TrueNAS option sounds amazing. You get a beautiful, dedicated web interface for managing your storage, with tons of powerful, easy-to-use features for snapshots and replication. It’s a purpose-built tool for the job.

But here’s the catch: it adds a significant layer of complexity. To get your other VMs and containers to use that storage, you have to share it back to Proxmox over the network using something like NFS or SMB. This can create a performance bottleneck, especially for applications inside Docker containers that need fast access to their data. You’re also creating a single, critical point of failure. If your TrueNAS VM has a problem and won’t boot, your entire storage pool is offline.

Running ZFS directly in Proxmox, on the other hand, is beautifully simple. It’s tightly integrated, fast, and reliable. There’s less overhead and no network layer to worry about for accessing data. As the saying goes, “simpler is usually better.”

My Choice for a Modern Server Storage Design

After weighing the pros and cons, I’m a firm believer in the direct approach for most home lab scenarios. My recommendation is to manage your ZFS pool directly within Proxmox.

Here’s why:

• Simplicity and Stability: You remove an entire layer of abstraction (the TrueNAS VM and the network sharing). This makes your setup easier to manage, troubleshoot, and much more stable in the long run.
• Performance: Your containers and VMs have direct, block-level access to the storage they need. You avoid the potential performance penalty of running everything over a network share, which is a real concern for I/O-intensive apps.
• Proxmox is Powerful Enough: While TrueNAS has a slicker UI for storage, Proxmox’s own ZFS management is incredibly capable. You can still easily manage pools, datasets, and snapshots right from the Proxmox interface or the command line. For more information, the official Proxmox ZFS documentation is an excellent resource. For a deeper dive into this exact comparison, sites like ServeTheHome often have great discussions on the topic.

What about backups? The appeal of TrueNAS’s backup tasks is strong, but you can achieve the same result in Proxmox. You can set up scripts for ZFS snapshotting and replication, and for crucial data, using an offsite backup service like Backblaze B2 is a fantastic and affordable strategy anyway.

Don’t Forget The Boot Drives

What about those small M.2 drives for the OS? A mirrored pair of 480GB drives might seem small, but it’s typically plenty of space. The Proxmox OS itself uses very little. The key is to only store the operating systems for your VMs and the definitions for your containers on this fast storage. All the actual data—your photos, documents, and media—should live on the large ZFS pool you created with your spinning drives.

This setup gives you the best of both worlds: a snappy, responsive OS and fast-booting VMs, combined with a massive, resilient pool for your important data.

In the end, the goal is to build something useful, not to get stuck in a loop of “what-ifs.” Start simple, start stable. A clean Proxmox installation with a directly managed ZFS pool is a rock-solid foundation that will serve you well as you build out your home lab. Now go get that OS installed!

Expanding your setup from one server to two? Here’s how to handle your home lab networking without the headache.

So, your home lab is starting to feel a little cramped. That single server, once the pride of your setup, is now begging for a friend. You’re thinking of getting a second host, maybe for more complex projects or just to have a failover. But then it hits you: your entire network is virtualized, running as a VM on that first machine. This is a common growing pain for many of us in the tech community and a crucial moment in your home lab networking journey. When you add a second host, you need a network that lives outside both of them.

It’s a classic problem. Your current setup, likely with a virtual router like VyOS or pfSense running on ESXi, has been perfect. It’s efficient and self-contained. But the moment you introduce a second physical server, that elegant solution becomes a single point of failure. If your first host goes down for maintenance (or just for fun), your entire lab, including the new server, gets cut off from the network.

It’s time to move your networking from the virtual world to the physical one. It might sound intimidating, especially if you’re more of a software person, but I promise it’s a logical and rewarding next step.

Why Your Virtual Router Can’t Scale to Two Hosts

Think of your virtual router as an apartment building’s intercom system that’s wired to the superintendent’s apartment. It works great for buzzing people in, but if the super goes on vacation and turns off their power, nobody in the building can talk to each other or let guests in.

When your router is a VM on a single host, that host is the superintendent. Adding a second server is like building a second apartment building next door. You need an independent, standalone intercom system—a physical network—that can serve both buildings equally. This ensures that all your VMs and services can communicate with each other, and the internet, regardless of the status of a single host.

Your First Step into Physical Home Lab Networking

The heart of your new physical network will be a managed switch. You might be tempted by a cheap, simple “unmanaged” switch from a big-box store, but that would be a step backward.

• Unmanaged Switches: These are simple plug-and-play devices. They’re great for extending your home Wi-Fi to a TV and a game console, but they don’t understand complex concepts like VLANs (Virtual LANs). Since your lab is already using VLANs within VyOS, you need a switch that can handle them.
• Managed Switches: This is what you need. A “managed” switch is a smart switch that you can configure. Its most important feature for a home lab is support for VLANs. This lets you keep your lab traffic separate from your home traffic, or create different network segments for different projects (e.g., a “dev” network and a “testing” network).

For those new to physical gear, I’d strongly recommend looking into the Ubiquiti UniFi or TP-Link Omada ecosystems. They offer powerful managed switches that are configured through a clean, user-friendly web interface. You don’t need to be a command-line wizard to get started. You can find their product lines on their official websites, which are great places to compare models.

Finding a Router to Replace Your Virtual One

With a physical switch in place, you still need a router to manage the traffic between your VLANs and connect everything to the internet. You have a couple of great options here.

1. An All-in-One “Prosumer” Router: The easiest transition is to get a router from the same ecosystem as your switch. The UniFi Dream Machine (UDM) or a TP-Link Omada Router are fantastic all-in-one solutions. They act as a router, a firewall, and a controller for your switches and access points. It’s a seamless experience and the perfect entry point.
2. A Dedicated Router Appliance: If you love the power and flexibility you had with VyOS, you might prefer a dedicated router box. You can buy a small, low-power PC and install open-source routing software like pfSense or OPNsense. This gives you incredible control and is a direct, more powerful successor to a virtualized router. It’s a bit more hands-on but is the gold standard for many advanced home labs.

A Simple Home Lab Networking Setup to Get Started

Don’t overthink it at the beginning. Your goal is to get a stable, physical foundation built. Here’s a simple, reliable blueprint for your new home lab networking configuration:

1. Connect your Internet Modem to the WAN (internet) port of your new physical router (like a UniFi Dream Machine or your pfSense box).
2. Connect a LAN port from your new router to your new managed switch.
3. Connect your two ESXi hosts, your desktop computer, and any other wired devices to the managed switch.

That’s it for the physical connections! From there, you’ll log into your router and switch’s web interfaces to configure your VLANs, firewall rules, and IP address ranges. It’s the same logic you used in VyOS, just applied to physical hardware. For a visual guide, you can find excellent tutorials on YouTube or tech sites like ServeTheHome, which provides in-depth reviews and guides for this kind of hardware.

Taking the leap from a virtual to a physical network is a right of passage for any home lab enthusiast. It opens the door to more resilient, complex, and powerful setups. It might seem like a big jump, but by choosing beginner-friendly gear and starting with a simple layout, you’ll build a rock-solid foundation for whatever project comes next. Welcome to the next level of your lab!