Tool for reproducible dev environments on Bazzite (looking for feedback)

Contributing
1

Hi everyone!

I’ve been working on a tool to simplify development workflows on immutable systems like Bazzite, where setting up dev environments can quickly become messy and time-consuming.

I wanted to share it here to get some feedback from people who are actually using these setups.

Repo here.

Here is a quick showcase (from the README):
baarchitectgifpysetup

1. The Problem: Dev Environments feel “unnatural” on Immutable Systems

When I switched to Bazzite, I ran into a pretty frustrating reality:

You can’t just install toolchains the “normal Linux way”.

Instead, you end up juggling:

  • Distrobox containers
  • Toolchains inside those containers
  • VS Code DevContainers
  • Storage issues (especially on smaller SSDs / handhelds)

For me, this turned into a fragile, time-consuming setup process — especially when working with Python/AI tooling.

2. What I built: A native Dev Environment Orchestrator

Bazzite Architect is a Tauri (Rust) desktop app that orchestrates:

  • Podman (rootless)
  • Distrobox environments
  • VS Code DevContainers

The goal is simple:

:backhand_index_pointing_right: Turn environment setup into a reproducible, one-click workflow

Example:

  • Select a stack (Python, React, Rust, etc.)
  • The app creates and bootstraps a Distrobox environment
  • Installs required tooling
  • Opens VS Code directly inside the environment

In practice, this brings setup time down to ~45 seconds for a full working environment

3. Key Idea: Manifest-driven Environments

Instead of manually maintaining environments, the system uses a declarative:

.bazzite-architect.json

This acts as a single source of truth, keeping:

  • Distrobox environments
  • DevContainer state

in sync and preventing drift.

4. Storage Problem (Handhelds / small SSDs)

One very real issue on Bazzite:

Rootless Podman storage fills up the system partition fast.

The app includes a guided storage relocation feature:

  • Moves GraphRoot safely to another drive (SD / secondary SSD)
  • Keeps the immutable base system clean
  • Avoids manual Podman config hacks

5. Why I built this

This came out of a real problem:

Coming from a React/TS background, I tried moving AI workflows (OpenCV, ResNet training) to Bazzite — and hit a wall.

  • Python setups broke
  • Conda environments didn’t integrate well
  • Toolchains felt disconnected from VS Code

I ended up in what I’d honestly call a “nightmare setup”

So I started building a tool that makes this feel native instead of hacked together.

6. Current Scope

Right now the project supports:

  • Python
  • Node / React
  • Rust
  • Java
  • C / C++

with automatic scaffolding + VS Code integration.

7. Looking for Feedback

I’d really appreciate input from people using Bazzite / Universal Blue:

  • Does this solve a real pain point for you?
  • How are you currently handling dev environments?
  • Would you actually use something like this?

Appreciate any feedback, especially critical perspectives!

2

What’s the normal way? What are you trying to install?

3

By the “normal way” I mean the traditional mutable distro experience - my background is mostly Ubuntu.

For example: If I wanted to start a Node project or compile something (back when I was really into developing mobile apps with React-Native) I would just run sudo apt install npm directly inside a new terminal, and then globally install whatever packages I needed.

Honestly, I got Bazzite because a friend introduced me to it and told me the benefits of gaming on Linux. Unfortunately, when I applied at my uni to a “Data Challenge”-module, I needed to work with Computer-Vision and locally trained small AI models like ResNet or EfficientNet (with Python), things I could not get to work at all for multiple days, I could not just sudo pip install xxx my required toolchains on the host anymore.

I learned that the “proper” way here is using Distrobox for the terminal and DevContainers for the IDE (I use VS Code), but manually setting both up for every single project and keeping their dependencies in sync felt like a concept with a lot of friction.

This is the specific manual setup my app tries to automate.

4

Those instructions need to be updated, you don’t install development packages with the system tools anymore. If you want to work outside containers brew install npm python brings in node and pip3. Container dev is the same on every OS, that’s why people use it (and why we picked it).

Using distrobox for development is an anti-pattern, you’re just making microenvironments to manage, now you have a bunch of mini installations to manage (that sucks worse lol).

Do you have links to resnet? I can only find the edu network software. How do people dev on this stack on windows and mac?

(This isn’t to discourage you, making your own solutions is always awesome!) - I just find it perplexing why people insist on making dev workflows based on “immutability”, which doesn’t matter (MacOS has a read only /usr too!)

1 Like
5

Thanks for your kind feedback j0rge!

I think we actually talk a bit past each other here (I hope this is the right term in english :smiley: ) - because I fully agree that container-based dev is the standard across platforms - thats exactly why DevContainers exist.

The issue I ran into (and what this tool tries to address) is specifically the gap between DevContainers and a usable terminal workflow on immutable distros. If you use Ubuntu or MacOS, you have this smooth “host-level” dev experience but on Bazzite/Kinoite that layer is intentionally restricted, so you end up juggling

  1. DevContainers (inside IDE), and
  2. Distrobox inside Terminal

Keeping those in sync manually is where the friction comes from. Thats exactly what I try to address with automating that sync, not trying to reinvent the workflow.

I think where we disagree slightly is the impact of immutability itself, because on macOS even though parts of it are readonly, tools like Homebrew provide a smooth and widely accepted hostlevel workflow. On immutable Linux systems, that layer is much more restricted and you end up relying on containers much more heavily in practice.

Regarding ResNet and the dev workflow: I am not an expert on this topic and dived into cold waters here past semester at my university, but ResNet (Residual Network) is just a foundational deep learning model for image classification, to use this - on Windows devs rely on WSL2, on mac or ubuntu they use conda-environments amongst other things.

I also used conda, not primarily as a package manager, but for the ability to quickly switch between specific Python versions and strictly isolate my environments (different modules were for different py versions). brew install python does not give you this isolated control. I had issues on my setup where a simple pip install without further configuration would fail, forcing me to use surgical terminal commands with absolute paths just to get basic libraries to work.

You are 100% right that using Distrobox can become a massive anti-pattern if you leave a bunch of orphaned mini installations lying around. That’s actually the exact nightmare my app tries to prevent!

Bazzite Architect spins up a temporary Distrobox where I can safely set up whatever messy toolchain or Python version manager I need, links it to the IDE, and most importantly ensures I can cleanly nuke the whole thing when the project is done. No zombie containers left behind.

So while it might be a niche tool for those heavier workflows where simple brew packages hit their limits, I completely agree with your philosophy for standard development. Thank you again for taking the time to reply and discussing this with me!

1 Like
6

Does the terminal inside vscode work correctly?

7

Yes, the integrated VS Code Terminal is working without problems, and for most projects thats totaly sufficient.

My problem back then was the lifecycle and IDE-independence of the environment. For heavy AI projects, training scripts can run for multiple hours and therefore I would prefer to run these inside a dedicated tmux session in a standalone terminal. That way the process is completely decoupled from the editor lifecycle.

On Ubuntu, I can just open my host terminal, start a tmux session, run my Python script and can safely close the IDE. Somestimes other usecase could be to spin up a Jupyter server without launching a heavy Electron IDE first.

To get that exact same “native” workflow on Bazzite for project specific dependiencies without polluting the host I need a Distrobox. My app basically ensures that whether I open the project in VS Code (DevContainer) or drop into a quick terminal (Distrobox) to run a background script, both environments are guaranteed to be synced, sharing the exact same toolchains and providing me the same outcome - which is what I need.

1 Like
8

I haven’t used it in a long time, but I’m sure there’s a CLI for devcontainers you can run in your terminal. That ought to give you the terminal/IDE independence you’re looking for while also preserving consistency.

Though perhaps it misses something you need?

1 Like
9

Hi Paul, thank you for the suggestion! :grinning_face:

You are right, the DevContainer CLI could cover part of this usecase.

The issue for me is that relying on it alone loses the tight host integration that Distrobox provides on Bazzite. I want both:

  • native terminal workflow (Distrobox)
  • IDE isolation (DevContainers)

The tricky part is state divergence between those two environments. For example, installing something via dnf in Distrobox is not reflected in the DevContainer.

My approach is to use a central manifest and sync layer to keep both in sync automatically. Beyond that, Bazzite Architect also handles a few OS-specific things (like safe Podman storage relocation) and provides quick project scaffolding. It currently supports 5 different project setups that are just 3 clicks away, getting you from zero to “ready-to-code” in under a minute, very attractive for coding-beginners without major Linux knowledge.

The project itself is less about replacing the CLI and more about acting as a bridge between those workflows. Thanks again for taking the time and bouncing ideas around with me!

1 Like