LxdMosaic: a browser front end for a fleet of LXD or Incus instances

LXD has to be reachable before LxdMosaic can talk to it

The getting started section is short, and its first step is not about LxdMosaic at all. You are pointed to the documentation to set up LXD, and then to the same documentation to make LXD available over the network. That second link is the one that matters for planning, because a management UI is useless against an LXD daemon that only listens on a unix socket on the machine it runs on. The project treats network exposure of the LXD API as a prerequisite you satisfy deliberately rather than something the application arranges for you, which is the right shape for a tool that can create and destroy guests. The documentation is hosted on Read the Docs and the readme links to the installation section by name, so the setup sequence is documented outside the repository.

Installing through snap is one command

There are two documented installation routes, and the first is a single command.

sudo snap install lxdmosaic

The second route is a script, and the readme links to the installation page for Ubuntu and Debian specifically, so the script path is documented per distribution rather than as one universal command. The snap route is the one that reads as supported for everybody else. The repository carries a snap directory, and the rest of the tree is set up for a self-hosted deployment with a node directory, a src directory for the application, a db directory, an sql directory and a docs directory built with mkdocs, the configuration file for which is mkdocs.yml. There is also a .env.dist file at the top level, which is the conventional way to ship a configuration template that the deployer copies and fills in.

A terminal and a console in the browser, via Xterm.js and SpiceHtml5

The key open source libraries the project names tell you what the interface actually is. Xterm.js provides the terminal emulator in the page, and SpiceHtml5 provides the browser console, which is how a graphical console for a guest is delivered without a client-side VNC or SPICE stack of your own. Bootstrap provides the styling. The package manifest confirms all three in the dependency list, with @xterm/xterm, @xterm/addon-attach and @xterm/addon-fit as separate packages, ace-builds for the code editor, chart.js for the graphs, dropzone for uploads, and jquery with a set of jquery plugins, masonry-layout and moment for the interface layer. This is a JavaScript front end served by a PHP back end, and the readme calls the project a web interface to manage multiple instances of lxd/incus, with both LXD and Incus named in the project description.

The node agent is a separate process with its own service file

The examples directory is the most informative part of the tree, because it shows how the pieces connect. There is an lxdmosaic_node.service file, so the node side of the system runs as its own systemd service rather than being part of the web request, and an lxd_manager.conf file for its configuration. The install_with_clone.sh script and test_setup.sh script cover the clone-based install and a test setup, and there is a tests_lxd_init.yaml file that appears to drive an LXD initialisation for testing, all under an examples/README directory that also holds the two screenshots the readme shows, one of the home view and one of the instance view. The top level also has a phinx.php file, which is the migration tool for the database schema, alongside the db and sql directories, so schema changes are handled by versioned migrations rather than by hand.

MySQL and SQLite both ship as drivers, and the choice is not uniform

The package manifest lists mysql at 2.18.1 and sqlite3 at 6.0.1 as dependencies, and the presence of both tells you the project supports either backend. That matters more than usual in this kind of application because the split is between tiers. The web interface is PHP, and the node component is a Node process, and both sides talk to a database. The MySQL driver is the older 2.x line, which is the version of the node mysql package that is long deprecated, so a deployment that selects MySQL is choosing a driver that upstream no longer maintains. The SQLite driver at 6.x is the current one. If you are choosing a backend for a fresh install, the sqlite3 dependency is the less surprising choice, and if you need MySQL, the practical risk is in the node tier rather than in the PHP tier.

The manifest still carries the old project name

The package.json in the repository root is a leftover and it is worth noticing. Its name is lxdmanager, its description calls it an application for basic management of multiple instances of lxd, and the repository, bugs and homepage fields all point at turtle0x1/LxdManager rather than at LxdMosaic. The version there is 1.0.0, and the test script is the npm placeholder that echoes an error and exits. None of that describes the current project. It suggests the Node component was carried over from an earlier repository under a different name and the manifest was never updated, and it also means the package.json in this tree is not a reliable description of the build. The tree carries the current build configuration in other places, with composer.json and composer.lock for the PHP side, a gulpfile.js for the front end assets, and crunz.yml plus runCrunz.sh for the release automation.

A 2022 release tag against a 2026 push

The maintenance picture needs stating carefully, because the two signals disagree. The repository is not archived and the last push was on 2026-09-25, so work is still landing in the tree. The release tags, on the other hand, are old: v0.16.0 from 2022-09-06, v0.15.0 from 2022-08-06 and v0.14.1 from 2022-05-15. So there is no dated, taggable release for the code that is actually in the branch today, and the CHANGELOG file and the UPGRADING.md file at the top level are where you would look for what changed between the version you remember and the version you are running. The project is GPL-3.0 licensed, publishes a SECURITY.md, and points to a roadmap through the repository milestones page. A deployment that needs a pinned, dated artifact has to treat the branch as the deliverable and read UPGRADING.md carefully before replacing an existing install.

Editorial conclusion

LxdMosaic fits an operator who runs several LXD or Incus hosts and wants a browser interface instead of a command line, particularly if the hosts are reachable over the network and a terminal in the page saves a second tool. It does not fit a deployment that needs a signed, dated release you can pin, because the most recent tag is v0.16.0 from 2022-09-06 while the last push to the repository was on 2026-09-25, so you are tracking a moving branch rather than a version. Before you install it, make sure LXD itself is initialised and available over the network as the documentation requires, decide whether the snap or the script route suits your distribution, and check which database the node agent and the web tier are configured to use, since the tree ships both MySQL and SQLite drivers and they are not interchangeable across components.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. turtle0x1/LxdMosaic on GitHub