LaticeVale Atomic started as a separate evolution of my older LatticeVale project, but it is not just the Windows/WSL version copied over to Linux. I recently converted from Windows to Bazzite Linux OS and wanted to install LatticeVale locally. So I had AI help me figure that out.
The original project was built around Windows, PowerShell, WSL2, Docker, and the problems that come with coordinating software across both Windows and a Linux VM. LaticeVale Atomic was redesigned around a completely different environment: immutable/atomic Linux, rootless containers, user-level system integration, SELinux, and hosts where modifying the base operating system is intentionally discouraged.
The goal is still similar: make a complicated Hermes setup much easier to install, repair, update, recover, and manage. The way it accomplishes that is now very different.
Instead of relying on PowerShell and WSL, the Atomic version uses Bash, Python, rootless Podman, Compose, user systemd services, and XDG-compatible desktop integration. It is designed to keep the operating system itself as untouched as possible and place LaticeVale's managed state in user-owned locations.
The current stack can manage Hermes along with Matrix/Synapse, PostgreSQL, SearXNG, Valkey, QMD, Honcho, Redis, and local Ollama inference. It also includes hardware-aware resource limits, AMD GPU acceleration support where available, recovery snapshots, state-aware repairs, migration logic, audits, desktop Start/Shut Down controls, and protection against accidentally modifying unrelated Podman workloads. It uses terminal triggers instead of built in user selection during script run. See documentation on that.
Bazzite is currently the only platform I have tested. The project also includes adapters and compatibility logic for other atomic or immutable Linux systems, but those environments have not all received any real-world testing.
The current Bazzite migration has been tested on my own system with SELinux enforcing, rootless Podman, AMD GPU acceleration, an external Obsidian vault, existing Podman workloads, and a full 12-service Hermes stack.
That does not mean I can guarantee it will work perfectly on every machine. Atomic Linux distributions differ quite a bit in how they handle containers, host tools, permissions, user services, and immutable system boundaries. If someone finds a failure or a weird edge case, I would genuinely like to know about it.
This is still a hobby project, it is free, and anyone is welcome to inspect it, fork it, change it, or build on it. If you do experiment with it, I would be interested in hearing what works, what breaks, and what you improve.
LaticeVale itself does not bundle the third-party projects it manages. The installer retrieves or builds those components from their respective upstream sources.
I strongly recommend reading the included README, installer documentation, security notes, and migration information before running it. There is a lot going on internally, so using an AI model to inspect the repository or explain individual parts of the documentation is also a perfectly reasonable way to understand the project before installing it.
One final warning: local AI can be demanding. Ollama models can use a significant amount of RAM and VRAM, especially with larger models or context sizes. LaticeVale Atomic includes adaptive resource calculations and limits to reduce the chance of the stack overwhelming the host, but hardware still matters.
LaticeVale Atomic v15.2.3 AT6 is live:
https://github.com/winagainfinigin/LatticeVale-Atomic
Original Windows WSL version:
https://www.reddit.com/r/SelfHostedAI/comments/1vtpfdr/latticevale_free_installerlifecycle_manager_for_a/