Didn't know about the logger script, looks nice. Can it wrap the launch of the scrub itself so that it logs like logger too, or do you separately track its stdout/stderr when something happens?
update: figured how you can improve that call to add logs to logger
I am also slowly preparing myself to the world where there is no SSH into the server machine. I am following what's happening around IncusOS. Already sold on Incus for my containers, it does make sense on a paper: safe auto-updates, no manual key management, all you need is managed via API in a cluster (usually).
Can you tell me a bit more on how you use Incus.. is it just personal use, or otherwise? What type of workloads do you run on it, and how is your networking setup / experience?
I use it for professional use, running production services which don't require 99.999 availability and have relatively low traffic, basically some internal dashboards and tools.
I develop my programs as deb/systemd packages and deploy in "fat" ubuntu/debian incus containers.
I have a cluster with three machines where one is used for build-containers and second for production containers. I am looking forward having time to have ZFS streaming incremental backup of the containers.
For big servers I use Proxmox, which is great, but Incus (and IncusOS) feel a bit more futuristic, where Proxmox is more bullet-proof enterprise solution.
We need privacy-focused Obsidian alternative (which doesn't store unencrypted text files on disk), excited to see a potential player written in my tech stack, meaning it should be easy to extend!
Ferrite is privacy-focused in that it's fully offline — no telemetry, no cloud sync, no accounts, no network calls (even Mermaid diagrams render locally in pure Rust).
However, files are stored as plain text, same as Obsidian/VS Code/any text editor. Encryption at rest isn't currently on the roadmap.
For encrypted storage, you might consider:
- Using Ferrite with an encrypted volume (VeraCrypt, LUKS, FileVault)
- git-crypt for encrypted git repos
That said, if there's strong interest in built-in encryption (vault-style or file-level), I'd love to hear more about the use case. Would you want password-protected vaults? Per-file encryption? Something else?
I want cold storage encryption which is cross-platform and doesn't require FUSE and such. Current solutions are all either non-cross-platform or overkill, so I'm still using Obsidian non-encrypted. It's a matter of default and ease of use.
That said, I've checked Ferrite out – unfortunately there's a very long way to go before it becomes Obsidian-ish (left and right panel, add tabs, hide the top formatting bar), better focus on those features. If it becomes close enough – I'll implement the encryption myself :)
Fair feedback! You're right — Ferrite isn't Obsidian-complete. Those are reasonable additions:
- Left panel already exists (file tree + outline), but could use polish
- Right panel (backlinks?) would come with v0.3.0 wikilinks work
- Hiding toolbar is a quick settings addition — I'll add that to the list
What's your priority order for those? And if you do implement encryption later, I'd love to see the approach!
The TODO list cursor behavior is exactly the kind of polish detail that matters. I'll add this to the issue tracker — cursor should respect line start position, not jump past the checkbox syntax.
These "many small details" are what v0.3.0's custom editor widget will unlock. egui's TextEdit doesn't give us fine-grained cursor control, but replacing it will.
Awesome, initially it looked like a quick AI-generated project but I see you care about it and plan investing the effort into it. Will be following on Github!
Main priority would be the editor itself to be similar to Obsidian (with links etc.) but maybe better, Obsidian is annoying for example when you edit a TODO list (which is 99% of the time for me), go to the beginning of the line, then press down to go to the next item -- Obsidian jumps into position between "- [ ] " and "item text", instead of staying at line beginning. Long story short, many small details to make this right.
Thanks for sharing! We’re definitely aware that Incus + Proxmox are very mature and full-featured.
Containarium is more of a "purpose-built, single-VM, SSH-first dev environment" approach:
- Lightweight: 1 VM can host 50–100+ LXC containers
- Quick provisioning: seconds instead of minutes per environment
- Focused on SSH workflows and dev sandboxing, not full datacenter management
- Minimal infra overhead: no GUI, no HA cluster required
Tradeoffs we’re aware of:
- Shared kernel (not VM-level isolation)
- Linux-only
- Less built-in tooling compared to Proxmox
We designed it to *optimize for cost efficiency and rapid dev onboarding*, rather than full-featured virtualization.
Would love to hear if you see any pitfalls with this approach compared to using Proxmox/Incus in a single-host scenario!
Sorry, we want to understand your use case better. Did you provision *one VM via Proxmox* and then run *multiple users via Incus* inside it?
We’re curious how you handled provisioning, isolation, and resource limits in your setup. More importantly, what’s the maximum scale you’ve been able to push?
I understand that. I'm saying that wrapping all the dev containers up inside a single VM serves to further protect the host system from the dev containers.
That's because it is, just like how this entire project is.
In fact, it is just using the same technologies as LXC and Incus. (It is exactly LXC and Incus)
So really nothing special at all. Perhaps people looked at the title and rushed to the repo.
When I saw "IMPLEMENTATION-PLAN.md" and "SECURITY-CHECKLIST.md" filled with hundreds of emojis, I immediately closed the tab and now replying to you that it is total slop.
2026 is the year of abundant "not invented here syndrome".
Containarium does indeed build on LXC/Incus and isn’t trying to reinvent the wheel. If you’ve run multi-tenant sandboxes at scale, we’d love to hear what pitfalls or limitations you’ve seen.
I use atuin for the shell history as it seems to know when I've run a command in one tab/split while another is open where fzf doesn't seem to sync it all the time. But I still use fzf to find files.
(Bonus, I use Zoxide to replace the alt+d cd shortcut as it's much faster, and use https://github.com/Aloxaf/fzf-tab for tab completions in the terminal to become fuzzy, very very useful)
>it seems to know when I've run a command in one tab/split while another is open where fzf doesn't seem to sync it all the time.
On my machine this is handled in zsh, not fzf (but then fzf still benefits). You can configure your shells to sync without exiting. You may need to run one command (or just hit enter with nothing typed, maybe) for the shell history to catch up, but then it should all be there. Relevant options:
# share history among terminals
setopt share_history
# append to the history instead of overwriting
setopt append_history
# append to history incrementally instead of when the shell exits
setopt inc_append_history
I think finding out about this is why I originally switched from bash to zsh several years ago.
Atuin also has syncing and backups though I've never really felt the need to use it. I prefer keeping histories separate and when I need to share shell commands I just do the usual methods like putting it in a shared text file, send it to myself on a chat app or just looking at the command and typing it out
Yeah. It boils down to preferences. By the way, there is also an option to search only in current host and current directory as well (+current session).
Can't see the original comment, is that about my usage of the "astounding" word? I am Ukrainian (not a native speaker), and it popped up subconsciously, but now that I see it it another comment – very likely I just read it, that's why indeed! Amazing
I'm Ukrainian and my Apple Notes aren't searching case-insensitively. How could such large company not implement case insensitive search for Cyrillic?
reply