Dubnium: A Super Server That Stays Understandable
A machine that does everything usually explains nothing.
That failure mode is what Dubnium is trying to avoid.
Dubnium is one NixOS machine that can be a workstation, a local AI node, an automation host, a secure remote access point, and, when needed, the base for an experimental lab.
That usually ends in accretion: random daemons, forgotten ports, shell history as documentation, and a system that only makes sense to whoever last touched it.
Dubnium is an anti-sludge project.
It is closer to a personal distro than a homelab box: an opinionated system shape for local AI, developer work, explicit operating modes, and optional experimentation without letting any one of those roles consume the whole machine.
The project comes from a few specific frustrations: supply-chain trust erosion, watching disks slowly disappear into OS bloat, and the familiar experience of a machine becoming stronger while also becoming less reproducible. Once a system cannot be rebuilt with confidence, every upgrade starts feeling like a wager.
Common scenarios
The most common Dubnium scenario is not exotic. It is ordinary desktop work that turns into remote compute.
I might be doing development work at my desk, switch the machine into compute mode, then leave with a laptop and keep using local AI over Tailscale from a library. The heavy models, runtimes, and GPU posture stay on the home machine. The laptop stays thin.
The second common scenario is background work: CareerOps automations, research collection, scheduled jobs, and bounded workflows that should keep running without turning the host into an opaque automation box.
Another common scenario is project-local development through a dedicated shell. The project gets the tools, dependencies, and environment it needs. The host does not slowly become the project.
Those scenarios sound different, but they need the same thing: one machine, multiple postures, explicit boundaries.
The core idea
The most important distinction in Dubnium is also the easiest one to blur:
Mode = what the machine is doing right now
Profile = what the machine is capable of doing
That sounds like bookkeeping. It is not.
Once those collapse, desktop stops meaning a current posture. It starts
quietly meaning a GUI, personal config, background automation, model services,
and whatever else happened to get installed. compute stops meaning a runtime
state and starts meaning an entire bundle of assumptions.
Dubnium keeps the split explicit.
Profiles define what can exist. Modes define what is active now. Services stay operator choices.
That is how one machine can do a lot without turning mysterious.
Why NixOS matters
Without NixOS, Dubnium would already be landfill.
The machine has too many responsibilities to live on habit alone. Packages, users, services, hardware assumptions, desktop components, AI runtimes, and network posture all need one declared spine.
NixOS provides exactly that: a reviewable source of truth for a machine that is bigger than a workstation and smaller than a platform.
AI helps build and iterate on that shape faster.
NixOS is what stops the result from dissolving into improvisation.
Default must be boring
The default state of personal infrastructure is not elegance. It is accretion.
So Dubnium starts with a simple rule: the base install should be safe, useful, and boring.
That means:
- no secrets required to get a healthy baseline system
- no surprise network exposure
- no model-serving daemon required just to boot a workstation
- no hidden scheduler, runner, or workflow engine smuggled in as “convenience”
The machine should work as a workstation first.
Power is opt-in.
That boundary matters more than any individual feature because it determines whether the system stays governable as it grows.
Declarative systems need a writable edge
This is where many otherwise good systems become annoying.
Purely declarative configuration is excellent for servers. Development machines are messier. Editors write state. CLIs update config. AI tools expect mutable provider files. Desktop software assumes writable directories.
If everything points into the Nix store, the system is pure and obnoxious. If everything is mutable, the machine drifts.
Dubnium handles that with layered mutability:
generated base config
+ writable local overrides
+ promoted custom fragments
+ runtime state outside managed config
That is why configctl exists at all.
More than a helper command, it is the boundary that makes a declared system behave like a usable workstation.
One machine, multiple postures
Dubnium is not always the same machine.
Sometimes it is an interactive desktop. Sometimes it is a throughput-oriented compute node. Sometimes it needs to bias toward studio work, lower latency, or fewer background distractions.
Mode matters for exactly that reason.
Capability is not posture. Installed is not active. Present is not permitted.
This is the difference between a machine that has several roles and a machine that has become a pile of unresolved intentions.
A small control surface
Dubnium stays legible by keeping its control surface narrow.
modectlchanges runtime posturedubctlchanges persistent capability stateconfigctlmanages the writable edge of the declared system
Each tool has one job.
modectl should not quietly rewrite long-term configuration. dubctl should
not become a generic orchestration layer. configctl should not turn into a
second dotfiles manager.
When a system starts growing command surfaces faster than capabilities, it is usually hiding complexity rather than controlling it.
use developer shells for projects
install deliberately for the system
expose and automate securely
rebuild and redeploy confidently
Machine vs User
The separation between the machine and the person matters.
The system flake owns the host: NixOS modules, services, workloads, installer behavior, AI integration, mode control, and system policy.
The dotfiles repo owns the user layer: Home Manager, Hyprland, Waybar, shell and editor tooling, wrappers, and local workflow ergonomics.
That split is not aesthetic. It keeps machine policy from collapsing into user preference.
Mix them and the whole thing turns personal and brittle. Separate them and both layers can evolve without confusing each other.
The desktop is not the machine
Hyprland is not there just to look nice.
Dubnium needs a desktop because it is still a workstation, but the desktop cannot consume the identity of the host. It is one runtime surface, not the machine itself.
The GUI should expose useful state: current mode, service health, GPU pressure, memory pressure, network state, recovery information.
It should help the operator see the machine, not distract from it.
A desktop is not the machine. It is one way of standing in front of it.
Local AI only works if the layers stay separate
Local AI becomes dangerous when convenience outruns boundaries.
Dubnium needs different AI usage profiles for different kinds of work:
- local assist for quick prompts, summaries, shell help, and small coding tasks
- automation for bounded scheduled or event-driven work
- governed agentic work with memory, audit, approval, and replay
- escalation to stronger local or hosted models when the small path is not enough
That only works if the layers remain distinct.
A model runtime is not a control plane. A gateway is not governance. Memory is not authority. Automation is not permission.
The goal is not local-model purity. The goal is choice under policy.
Memory also has to stay humble.
Persistent memory is useful because small models improve when they stop waking up blank, but a memory store should retrieve candidates, not silently manufacture truth. Source code, runbooks, ADRs, and human decisions still outrank stale context with confidence.
Automation needs owners
Automation is where personal infrastructure becomes either powerful or unattended.
Dubnium works best when ownership stays clear:
- timers trigger work
- the scheduler owns local jobs
- n8n orchestrates workflows
- GitHub Actions owns repo-governed mutation
- AI control planes handle reasoning within the selected profile
- governance owns approval and audit
That layering is the difference between automation and a machine that quietly starts making decisions no one assigned to it.
Reachable does not mean public
Dubnium should be reachable.
Most of its services should stay private.
Local runtimes and gateways should bind to localhost by default, with Tailscale or LAN exposure only when deliberately enabled. That matters because these surfaces may expose local files, provider credentials, prompt context, agent execution, or expensive compute.
The rule is simple: bind locally, expose deliberately, document the assumption.
Hyperion is the environment layer
Project Hyperion is the experimental surface that sits on top of Dubnium.
Hyperion is where Micrantha gets rebuildable, reproducible staging and development environments above the host.
Here k3s, FluxCD, GitOps, secrets management, health checks, rollbacks, and ingress become useful.
Not because every personal machine needs Kubernetes, but because some ideas do not become real until they can be deployed, restarted, observed, upgraded, and recovered.
That is a deliberate constraint: lower cost, lower complexity, and fewer local operational responsibilities at a point where time and priorities are elsewhere.
Dubnium provides the host.
Hyperion provides the environment layer.
Keeping that boundary intact is what lets experimentation stay ambitious without making the base machine fragile.
Rebuildability is the standard
A super server that cannot be rebuilt is not infrastructure.
It is a pet with backups.
Dubnium should be deployable onto different machines without turning the old machine into a sacred artifact.
That means separating the portable system shape from the machine-specific edge. Hardware detection changes per box. The host definition should not.
It also means treating local AI bring-up as part of reconstruction, not as a manual afterthought. If the machine is supposed to be an AI-capable host, then runtime enablement and model seeding belong in the rebuild story together.
The reconstruction path looks more like this: installer, hardware detection, host config, user layer adoption, private network rejoin, local AI runtime and model seed reconcile, and explicit service enablement.
The target is reconstruction, not preservation.
The point
Powerful local infrastructure usually becomes opaque.
Dubnium is an attempt to build the opposite: a machine that can do several serious jobs without losing the ability to explain itself.
Power is easy to accumulate.
Reproducibility is the harder discipline.
References
Project
System
AI and agents
- Model Context Protocol Introduction
- Anthropic: Building effective agents
- MemGPT: Towards LLMs as Operating Systems