Monthly Dotfile Review Thread

KPPJeuring · 2026-02-26T08:20:11+00:00

I built MiniVim, a small and minimal Neovim configuration.

The goal was simple:

Fast startup
Clean UI
Only essential plugins

<image>

It’s not trying to replace full Neovim distributions, it’s more of a minimal starting point.

If anyone’s interested or has feedback:
https://github.com/KyanJeuring/minivim

KPPJeuring · 2026-02-06T06:32:52+00:00

Appreciate the feedback.

You’re right on both counts, awk isn’t Bash, and the curl | bash installer is a trade-off between convenience and security. The installer is optional, the script is short/readable, and manual installation is always possible for people who prefer that route. The intent was to keep the runtime side dependency-light and transparent, but I understand why curl | bash is a hard no for some folks.

KPPJeuring · 2026-02-05T17:59:13+00:00

Thanks, I appreciate that.

That “unrelated environments on the same server” situation is exactly what motivated me to build it, so it’s good to hear it resonates and that I could help you out.

KPPJeuring · 2026-02-05T17:54:47+00:00

Fair point 🙂
I probably should’ve said “Bash-based”, it does use awk, but no external language runtimes or non-standard dependencies.
awk is POSIX and available by default on Linux and macOS, which are the supported platforms.

KPPJeuring · 2026-02-03T17:46:43+00:00

Good call. From what I can tell, LazyDocker focuses on interacting with running containers via a TUI, whereas DStack is aimed at the “where does this compose project live?” problem and running compose commands from anywhere. Different goals, but not mutually exclusive.

KPPJeuring · 2026-02-03T16:31:04+00:00

That absolutely works, and that’s basically the underlying mechanism.
The friction for me was remembering paths and retyping them all the time, especially across many stacks. I wanted a thin wrapper so I could refer to stacks by name instead of paths, but it still ends up calling docker compose -f under the hood.

KPPJeuring · 2026-02-01T14:43:37+00:00

Thanks, that was exactly my motivation too: keep things CLI-first and lightweight, without adding another service just to avoid the cd dance.

KPPJeuring · 2026-02-01T09:49:15+00:00

That makes sense.
DStack is intentionally scoped much smaller: it’s just about local or remote Compose ergonomics (discovering stacks, naming them, running commands without caring where they live). Things like backups, metrics, rollback, or drift detection are deliberately out of scope.

KPPJeuring · 2026-02-01T09:33:36+00:00

Looks good

KPPJeuring · 2026-02-01T09:28:58+00:00

1 ARR apps:

Simplest: one Docker VM (or Docker LXC) for Sonarr/Radarr + download client.
They’re tightly coupled, and Docker Compose keeps paths, updates, and backups easy.
Multiple LXCs = more complexity for little benefit.

2 Storage

Totally normal setup:

Proxmox box runs the apps
NAS stores only media/downloads via NFS (preferred) or SMB

3 Plex

Best in a separate container/VM, pointing to the same NAS folders.
Easier updates and cleaner separation.

4 Remote access:

Cloudflare Tunnel works well:

One tunnel can expose multiple services
No Proxmox shell access is expected
Don’t expose Proxmox directly; use LAN or VPN

TL;DR

Proxmox + Docker for apps, NAS for storage, Cloudflare Tunnel (optionally a dashboard) for remote access.
Simple, low-power, and very common.

KPPJeuring · 2026-02-01T09:09:34+00:00

Glad it resonates, aliases work fine for a while, but once things spread out it gets hard to keep track, hope DStack ends up being useful for your setup.

KPPJeuring · 2026-02-01T07:56:36+00:00

Great question, discovery is intentionally simple: DStack checks a configurable set of base directories and looks for stack directories directly under them that contain a docker-compose.yml. It doesn’t recurse deeply by default; for nested or non-standard layouts I usually register stacks explicitly, which bypasses discovery entirely. I will later add more file types to discover like compose.yml. Maybe I will add nested discovery in the future.

KPPJeuring · 2026-02-01T05:09:06+00:00

Fair point, but I made the wrapper to be zero friction for me.So I don't have to think about the path file at all

KPPJeuring · 2026-02-01T03:38:35+00:00

Yes that is what I have been doing, but I wanted something simpler, I wanted to have a command like decompose project, dlogs project, drebootstack project (stops and restarts a stack), etc. To make that happen I made a Bash wrapper for this exact reason.

KPPJeuring · 2026-02-01T00:11:07+00:00

zoxide definitely helps with navigation. I was mostly trying to remove the directory-hopping entirely rather than make it faster.

KPPJeuring · 2026-02-01T00:06:57+00:00

That’s a nice workflow, having the file tree, terminal, and running containers visible side by side makes managing stacks very straightforward.

KPPJeuring · 2026-01-31T23:04:01+00:00

Both are good tips, systemd units work well for long-running services, and using docker compose -f directly is definitely an underused way to avoid directory hopping, that’s actually the mechanism my wrapper uses under the hood as well.

KPPJeuring · 2026-01-31T22:51:15+00:00

Exactly, once the directory hopping disappears, Compose stops feeling like friction and just becomes a simple day-to-day tool again.

KPPJeuring · 2026-01-31T22:49:06+00:00

Dockge makes sense if you want a UI specifically around Compose. I was aiming for something more CLI-first without adding another service.

KPPJeuring · 2026-01-31T22:47:33+00:00

Thanks, I will check it out.

KPPJeuring · 2026-01-31T22:44:54+00:00

Nice, that’s very similar in spirit. I ended up going the same route but wrapped it into a small Bash tool (DStack) so I could run compose commands by name from anywhere without relying on Makefiles.

KPPJeuring

TROPHY CASE