I have a love-hate relationship with Virtual Desktop Infrastructure (VDI). Mostly hate. If you’ve ever tried to set up a proper VDI lab at home or for a small office, you know the pain. You usually need a stack of heavy VMs, a database server, a connection broker, a gateway, and enough RAM to power a small crypto farm. It’s exhausting.

So when I saw that Infinibay finally dropped a containerized deployment method using LXD, I stopped scrolling. I didn’t just bookmark it; I actually pulled my laptop out at 9 PM on a Friday to see if it was real or just another “simple” tool that requires three days of debugging.

Spoiler: It’s actually decent. But it’s not without some quirks.

Why LXD Makes Sense Here

For the uninitiated, LXD isn’t Docker. Docker is great for throwing a stateless microservice into the void and hoping it spins up. LXD is for system containers—basically lightweight VMs that share the host kernel. For something like Infinibay, which acts as a complex broker for remote desktop connections, system containers are the sweet spot. You get the persistence and “feel” of a VM without the massive overhead of emulating hardware.

Previously, running Infinibay meant dedicating full virtual machines to the management components. Now? We can shove the whole control plane into LXD containers. That means my lab server, which was wheezing under the load of KVM processes, can finally breathe.

The “One-Click” Promise (That Mostly Worked)

The repository promises a setup that essentially boils down to two scripts. I’m naturally suspicious of anything named setup.sh because usually, that translates to “I wrote this for my specific Arch Linux build and it will destroy your Ubuntu config.”

But I gave it a shot. The new approach relies on lxd-compose, a tool that brings that declarative docker-compose workflow to the LXD world. This is smart. Managing LXD profiles and networks manually via the CLI is fine for one container, but for a stack? It’s a nightmare.

Here is roughly what I ran to get the stack moving:

# First, I grabbed the repo. 
# (Always read the shell scripts before running them with sudo, please.)

git clone https://github.com/Infinibay/lxd
cd lxd

# The setup script handles the dependencies
# It pulls in lxc and the lxd-compose wrapper
sudo ./setup.sh

# Then the magic moment
./run.sh

I watched the terminal output, expecting it to error out on some obscure Python dependency or a networking conflict. Surprisingly, it chewed through the setup. The setup.sh script seems to handle the heavy lifting of getting the environment ready, while run.sh actually orchestrates the containers.

Under the Hood: lxd-compose

The real star here isn’t just Infinibay—it’s the usage of lxd-compose. If you haven’t used it, you’re missing out. It parses a YAML file to define your LXD containers, networks, and storage pools.

In this deployment, Infinibay defines the broker and gateway as separate services within the compose file. When you hit run, it spins them up, assigns the static leases on the internal LXD bridge, and mounts the necessary storage volumes.

I did run into one snag, though. My host machine already had a bridge interface named lxdbr0 with a different subnet than what the script expected. The script tried to create a new network but conflicted slightly with my existing iptables rules. I had to manually flush a few rules to get the traffic flowing. If you’re running this on a clean install, you probably won’t notice, but if you’re like me and have a “lived-in” server, keep an eye on your firewall.

Performance: Night and Day

Once the containers were up, I logged into the web interface. It was snappy.

Comparing resource usage was the fun part. I killed my old VM-based install of the Infinibay broker and compared it to this new LXD stack.

• Old VM Stack: Idling at about 4GB RAM (OS overhead + Java processes).
• New LXD Stack: Idling at roughly 600MB.

That is ridiculous. We’re talking about the same application logic, just stripped of the virtualization tax. For a VDI solution, where density is everything, saving 3GB+ on just the management layer is huge. It means room for another desktop instance or two on the same hardware.

Is It Production Ready?

Look, I wouldn’t deploy this to a bank tomorrow. The scripts are convenient, but they hide a lot of complexity. If something breaks inside the run.sh logic, you need to know enough about LXD internals to fix it. There’s no fancy GUI for the deployment error logs yet.

Also, persistence is handled via bind-mounts to the host. You need to make sure your backup strategy covers those specific directories on the host, or you’re going to lose your configuration when you inevitably blow away the directory to “try something new.”

But for homelabs, small businesses, or just developers who want to test VDI workflows without burning their CPU? This is a massive improvement. It turns Infinibay from a “weekend project” into a “lunch break project.”

If you’re still running your management plane on full VMs in 2026, you’re doing it wrong. The efficiency gains of LXD are just too good to ignore, and it’s good to see projects like Infinibay finally catching up.