I can't decide between these two used drives: https://www.cdw.com/product/solidigm-d5-p5336-122.88-tb-solid-state-drive-2.5-internal-u.2-pci-ex/8455168?pfm=srh

and

https://www.cdw.com/product/solidigm-d5-p5336-61.44-tb-solid-state-drive-2.5-internal-u.2-pci-exp/7785193?pfm=srh

sure 61TB doesn't sound like much these days, but I'm only going to be making word docs for a few centuries. Plus the drives are used and so they come at a great discount!

In an effort to make the sidebar a bit cleaner, and allow for more thorough explanation of the rules, this post has been made. Comments are disabled, to start a discussion with the community about this post or the rules in general, please make a meta post. Please stick to one specific item to address as your post to keep discussions on topic.

If you see a rule violation, please report rather than interacting with the post/comment.

Rules:

1. Be civil.

This is a community of collaboration. We aren't here to put each other down, but lift each other up - helping to improve efficiencies, find the right solution to deploy, or work through bugs.

Disagreement and strong opinions are welcome, being degrading or disrespectful is not.

A good reference would be the Lemmy.world Terms of Service as well as the ACoC.

Sexism, racism, ethno-supremacy, homophobia, slurs for ethnicities, genders, sexualities, etc, will not be tolerated. If you see it, report it. Don't interact, as the comment chain will likely be nuked.

2. No spam.

Spam is not “I don’t like this”.

Spam would generally be considered:

• Mass-posting - Posting the exact same post across a bunch of of different communities, rapidly. Cross-posting is not spam, but cross-posting to communities where it wouldn't fit, is.
• Repetitive Content (aka karma farming) - repeatedly submitting old popular content. This is completely irrelevant on Lemmy,, but the behavior is still not permitted.
• Bot Activity / AI Abuse - Using scripts/bots/gen AI to automate posts and comments.
• Unsolicited DMs - Mass private messages or chats to users, completely unsolicited

Bots are allowed, but see the Rules of Use for Bots on Lemmy.World, where this community is located. Please be sure to review these rules prior to using a bot in this community.

3. Posts are to be related to self-hosting.

Please ensure it is clear in your post how it relates to self-hosting.

If you see a post where there is a more appropriate place for the discussion to take place, such as a linux or networking community, please feel free to recommend it to the user as well as report.

From a community discussion on this rule:

• Posts that are better off in a different community (not just intent, but also a community thats appropriately supported by activity) will be locked only after that community is noted. Posts will not be deleted though, only locked.
• If there is an influx of simple posts about hardware, pictures of setups, etc., then we can go ahead with a weekly sticky for that content.
• Low effort content is currently well managed with upvotes and downvotes. If there is an influx of low effort content, we can use a different approach.
• Repeated common questions, once enough of them are being seen, will go to an FAQ post or a wiki.

4. Don't duplicate the full text of your blog or readme if you're providing a link.

If everything you're posting is in the link, there isn't much value to adding that text. If you're going to add text, make it contextual. Summarize it, mention why selfhoster's might be interested in the news link, how you're using this software, etc.

5. Submission headline should match the article title.

Add supporting or related information in the post itself rather than the title.

6. No trolling.

Trolling is deliberately posting something offensive, nonsensical, or provocative to bait people into arguments or to get an emotional reaction. Its disruptive and manipulative, and is not permitted here.

A few key characteristics:

• Baiting: Comments / posts to make people angry or confused
• Derailing conversations: Ruining meaningful discussions by steering them off topic

Downplaying this behavior by claiming it was "just a joke" will not impact moderation decisions. See rule 1.

7. Promotion posts require your active participation in selfhosting or related communities, and your account must be at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See this link for further details.

• Active participation is defined by the 10% rule - no more than 10% of your posts or comments may be self-promotional, or your post will be removed. That is not per-project, but your account as a whole. If the entirety of your post and comment history is your blog and projects, then your post history is entirely self-promotional.
• Account Age has been added as a requirement to mitigate frequent posts that were being seen within the community. This rule applies in all cases, whether you intend to post about a paid or F/LOSS project. There are no exemptions from this requirement.
• F/LOSS Exception: If your post is about a project that is completely open source & can be self-hosted in full without payment, your post is exempt from the 10% requirement. The exception does not exempt you from the account age requirement.

This post will receive updates as rules are updated.

Apologies if this is a rookie question, but I keep wondering what the vulnerabilities section on DockerHub is trying to tell me. Take nextcloud images for instance: The most current images seem to list 3 critical and 22 severe vulnerabilities. Does that mean those vulns are part of the image? If so, why would anyone want to run this?

EDIT: turns out I needed to set mountpoint=legacy, (sudo zfs set mountpoint=legacy <filesystem>) which is the standard way to use ZFS on nixos. Legacy in this context means that the mountpoint is decided by the system rather than ZFS; I guess ZFS was previously refusing to receive the mountpoint because it already had one, but I didn't notice because they happened to be the same.

I'm using ZFS on nixos, with an ext4 boot drive, and a ZFS pool whose key is loaded from the boot disk.

Despite mounting correctly, zfs also causes the system to fail and go into emergency mode. Even if zfs were to fail though, things like sshd and dbus shouldn't depend on it.

In particular, the system waits for about half a second after

         Starting Mount ZFS filesystems...

and the next line is

[FAILED] Failed to mount /ZFSmountpoint.

and then

[DEPEND] Dependency failed for Local File Systems.

A few lines later I get

[  OK  ] Finished Mount ZFS filesystems.

The next line is about emergency mode.

How can ZFS both fail and finish? And why does this affect the remainder of startup?

Hi everyone.

Given some recent.. issues with Bitwarden's leadership, I've been toying with Vaultwarden. It's been great, and supports pretty much everything I need.

I currently locally host the vault, but I'm realizing that this could cause problems for my family if something were to happen to me. While not technologically inept, if my server at home crashed they would have no idea how to access it, and they would lose all of the passwords.

I was thinking that a vps might be a better choice for this, possibly with some reboot automation in case of outages. That would allow them enough time to initiate the emergency access and import everything before anything happens to the passwords.

I've also got encrypted M-disc backups of the most important passwords with timestamps of when they were last set. I've demonstrated and written down instructions on how to decrypt these. Of course I also have other backups, but I doubt they'd be able to retrieve the non-physical copies of the backups.

Anyway, is that what most people here do with Vaultwarden, use a VPS with mTLS or VPN? To add, I would only use a tunnel for this if I go this route, so no open ports.

I initially shared a my latest project with you here. A lot have happened in LaManager in the past 2 weeks so I though i would make an update post.

Reminder of what is LaManager: It's a services manager build to use copy on write to reduce downtime when doing offline backups while ensuring that all the data is in a coherent state. It can also create and manage it's own virtual disk images to allow it to work anywhere outside of supported COW filesystems.

First LaManager has now been put in production and as been working without issue since then.

Currently on my homelab it manages : caddy (with anubis), forgejo, jellyfin, jitsi, matrix (including frontend and bridges), nextcloud (including euro-office), pi-hole, qbittorrent, redlib and vaultwarden.

Changes and new features since last time :

• NEW FILESYSTEM SUPPORT: ZFS !
• moved development to my forgejo instance
• shell-completion for bash, elvish, fish, powershell and zsh
• mutithreading of operations applied on multiple services (start, stop, backups, restart, remove)
• new restart command for services
• better error handling with anyhow
• added a lockfile to prevent unmounting during backups or others combinations of incompatible operations
• Licensed under AGPLv3

The forgejo instance is open registration to allow contributions.

With all thoses services the total downtime when doing a backup is under 17 seconds and extremely consistent, even when the remote took more than 20 minutes to sync.

For the entire week since introduction of multithreading daily backups downtime never went bellow 16 seconds or above 18.

As i've seen the discussions around about AI, i can confirm that currently LaManager has been fully created without any use of AI.

I changed my docker installation to rootless. I now installed Patchmon on the host and I wanted to monitor and update my Docker images as well. But Patchmon requires docker.sock to be in /var/run. My current docker.sock is of course in /run/user/{userid}. Are there any security risks, and if so what are they, to making a symlink to have the docker.sock in /var/run as well? The /run/user/{userid}/docker.sock is owned by the user running Docker. The symlink is owned by root because of the privileges needed for /var/run.

I don't have enough knowledge to be doing these kind of things, but I just like to tinker and I want to know how insecure this setup could be.

AI DISCLAIMER: Yes I used AI in addition to a host of website resources to create this. If down voting 'AI anything' makes you feel better, then by all means do so.

PURPOSE:

• To display a 'Song Of The Day' in MOTD whenever I log in via SSH.

WHY:

• First, I wanted to see if I could actually pull it off. I've been tinkering around with basic Python and some bash scripting again, ever since my Weather Data deployment. So learning was a big part of this. Baby steps I'm sure, but progress nonetheless.
• Secondly, I have a pretty large physical collection of music that I have been accumulating for decades and converting out to flac. Sometimes I forget all the cool songs I might miss every once in a while. So, I figured this would be a cool way to remind myself.

POSSIBLE FUTURE UPDATES:

• Perhaps embedding the link to the Song Of The Day in the MOTD. I'm not sure if that is possible at this point.

Among the things I learned is that if your password to Navidrome has special characters such as $, then wrap the password in single quotes:

• NAVIDROME_PASSWORD="your_password"
• NAVIDROME_PASSWORD='$your_pa$$word$'

ETA: Forgot the prerequisites. You must enable these variables in your Docker compose or through Portainer or similar:

• ND_REPORTREALPATH=true
• ND_ENABLESUBSONIC=true

I'm including a pdf for the instructions and script because I can't seem to get Lemmy formatting to bend to my will. The link will take you to Mega.nz. If you are interested but Mega.nz is not allowed on your network, I can upload anywhere you want. Please scan the pdf before opening.

To the best of my knowledge, this will not cause your server to implode or explode. As with any code you find online, thoroughly examine it before deployment on a production server.

NAVIDROME MOTD

If anyone has a better way or other ideas, I'm willing to be schooled.

Have fun!

A few months ago I decided to self-host everything for my software house instead of paying for cloud infrastructure. Here's what's running on a Raspberry Pi 4B (4GB) at home:

Astro static site + nginx Full mail stack (Postfix + Dovecot + Roundcube) in Docker MariaDB with automated backups GoAccess analytics with custom Python bot/human separation Dynamic IP blocklist generated at every deploy Certbot managed on a separate Orange Pi Zero 3 (HAProxy + SSL termination)

The Orange Pi Zero 3 as a dedicated HAProxy node was the best €25 I spent — SSL overhead completely offloaded from the Pi, all subdomains routed through one config, clean network separation between "what faces the internet" and "what runs the services." Storage: all boards boot from SSD via USB3. No SD cards in production. The ISP situation: Eolo wireless, 20Mbps down / 100Mbps upload. Yes, upload is 5x download. For a web server that's actually ideal. Real stress test — June 22, 2026 A post on r/italy hit 20k views in 24 hours. Numbers that day:

555 human visitors (vs ~180 daily average) 151 unique IPs 72.2% return rate 9.98 MB bandwidth 0 downtime 0 errors in the mail stack

PageSpeed from Google's infrastructure:

Desktop: Performance 100 / SEO 100 Mobile: Performance 97 / SEO 100

No CDN. No Cloudflare. No edge nodes. Just nginx on a Pi. The honest limitations:

Single point of failure — yes, if the Pi dies the site goes down Mail deliverability on residential ISP is hard (Brevo relay helps) No redundancy — we run backups, not replicas

All traffic data is live and public: stats.lake8.dev/geo.html Happy to answer questions on any part of the stack.

So...this is very tangentially related to Self Hosting, but hear me out...

We travel frequently, either for work or leisure. As a self-hoster, I always bring an Nvidia shield player on my travel bag, to connect to my Jellyfin host from whichever hotel we might be staying at, to watch at night for example.

But increasingly, this is becoming a pain in the butt. As most TVs aren't directly hooked anymore to just the antenna or the hotel's connection. No, they usually will be hooked to an Android box handling all sorts of crap, from the hotel welcoming screens to some info, to their pre-set channels. And the android remote works via HDMI-ARC to control the TV, of which they usually hide the damn OEM remote. So, if you unplug their android box to hook up your own player, you lose the TV controls. In some cases (Sony, mostly) you might be in luck finding the 3 physical buttons they include somewhere on the TV itself to navigate inputs and volume. But in some others, you might as well end up stuck in an Android app menu where you can't get out (I'm looking at you Phillips). So I think my next addition would be to get an universal remote to sort all these quirks when traveling. Anyone else went through these considerations? Any recommendations?

Trying to find a way to connect to my home server as well as my VPN at the same time. Doesn't seem like tailscale can. I've started looking at pangolin, has anyone had any luck with this issue?

Thank you

Hey, it's been a minute! Dawarich is your favorite FOSS selfhostable alternative to Google Timeline, remember? We've shipped a lot since the last post and I'm here to tell you all about it.

Github: https://github.com/Freika/dawarich

Website: https://dawarich.app/

First, a picture to get your attention:

Before we start with the great stuff, let me talk a bit about good stuff as well. Release 1.8.0 introduced a new mechanism to let you know about new releases. It works through my new application called Chibichange (https://chibichange.com/).

TL;DR: there is a Chibichange widget shipped in Dawarich, which, if you consent, will ping chibichange.com to check if there are new updates for your Dawarich instance. If there is a new version, a green pulsing dot will be shown in Dawarich navbar, click on it, and you'll see what's changed in Dawarich since your current version. Feature suggestion and voting coming to chibichange soon.

Important: this is an opt-in feature, no external requests will be made if you click "No thanks". If you say "no", there will be the usual exclamation mark beside the version if there is a new release on Github, but, sadly, no in-app changelogs.

A bit more context: I built Chibichange to have a way to conveniently deliver changelogs to Dawarich users, and soon it'll also allow you to suggest features, vote them up and provide feedback. Suggested features, if we decide to build them, will be added to our public roadmap. By the way, we recently added a roadmap: https://dawarich.app/roadmap/. Will update it soon with more cool stuff we've planned.

Chibichange will be open-sourced this summer and will have same model as Dawarich: FOSS self-hostable software with an optional cloud service for those who don't want to self-host it. This is a very niche tool, but I hope it will be useful to those in similar position, building self-hostable or otherwise software.

Okay, let's get back to Dawarich news.

The big one this time: we now draw your flights on the map. If you self-host AirTrail, Dawarich can pull your flight history and render it as proper arcs on Map V2. Set it up on the Integrations page, hit "Sync now", and it re-syncs daily on its own. Finally your map knows you didn't teleport across the ocean.

There will be more for flights in the future.

Trips got a full redesign. The whole trip page is now built on MapLibre V2 — a sticky map on the left, and a scrollable day-by-day accordion on the right with per-day distance and times, day-colored routes, a photo overlay toggle, and a replay scrubber to play the trip back. You can also drop a short note on any individual day of a trip now. I'm really happy with how this one came out.

Public sharing is a whole new thing. Trips, tracks, live location and selected time ranges can now be shared via a public, optionally phrase-protected link. Public trip pages look pretty much the same as the in-app ones, with toggles to pick exactly what the page exposes — route, stats, countries, day-by-day, notes, photos, whatever you want.

Here's a public link to my Norway road trip from the screenshot above: https://my.dawarich.app/s/07024d88-0c43-4554-ad89-d7f2916b7d57

Visit detection got rewritten. There's a new opt-in stay-point detector — non-ML, single pass, and it gives each suggested visit a 0–100 confidence score. It fixes the old algorithm's biggest annoyances: missing slow stays, and splitting one visit in two when your phone's battery died for a bit. It's behind a flag for now while I gather feedback, but it'll become the default soon. You can also now label a visit by searching for the real place name right in the Timeline.

What else?

• Multi-device tracks no longer get mangled — if you track from a phone and a watch and a GPS unit, each device stays on its own track instead of becoming one zigzagging mess.
• Fog of War can now reveal per-hexagon, not just per-point.
• Globe view is now on by default.
• Big import improvements: GPX files now stream instead of loading entirely into memory (no more OOM on huge exports), Garmin FIT files are supported, Google's "Timeline Edits.json" Takeout is recognized, and the official Traccar client is now supported directly.
• Fixed Immich photo timestamps that could be off by up to 24 hours, monthly stats now bucket by your local timezone, and a pile of timezone/DST crashes are gone.
• You can now run the containers as a custom user via PUID/PGID, OIDC fixes (trailing slash + PKCE), and a 2FA lockout to keep accounts safe.
• And, as always, literally a TON of other fixes. Bugs too, sorry, one can't go without the other.

Gentle reminder: Map V1 (Leaflet) is being sunsetted this August. Everything new is being written for V2, and it's better in basically every way — but if there's something from V1 you'd miss, tell me and I'll figure it out. Vector maps are the future!

Also, a glimpse into the future, I found an awesome tool to generate maps, bent it in couple places to work with Dawarich, and poster generation will be a thing soon!

I was so excited about how well it worked out, that I even researched if it'd be possible to plug an "Order" button into Dawarich, and, well, yes. Probably not gonna automate it right away, will just add the "Order" button beside the "Download" one for created posters, and will see how it goes. Anyway, it could be a good to support the development for anyone willing to do so, while getting a very nice personalized thingy you can actually hang on your wall. Man I love these posters.

We've finally released an update for our mobile apps, with the new logo, bug fixes and a registration flow that will have no use to selfhosters, but still is important thing to have. Annoying bug with the map not being rendered in dark mode is fixed, yay. Also, we had to re-list our Android app in Google Play Store, so the update will require you to download it separately and reauthenticate. Make sure you've uploaded all the data you had not yet uploaded in the old app. New app's page: https://play.google.com/store/apps/details?id=app.dawarich.Dawarich

We'll still release a small update for the old one with a banner suggesting an update. Sorry for this inconvenience.

This mobile release took a lot of efforts and tons of testing, but it opens new possibilities for us, and in the next one we want to focus on battery consumption optimization and, finally, will start making more steps towards feature parity with the web app.

I guess that would be it for today! I actually wanted to write a post every month, but, well, it's also too good to post one every other month :)

Saving you a scroll:

Github: https://github.com/Freika/dawarich

Website: https://dawarich.app/

iOS app: https://apps.apple.com/us/app/dawarich/id6739544999

Android app: https://play.google.com/store/apps/details?id=app.dawarich.Dawarich

Donate: https://www.patreon.com/freika / https://github.com/sponsors/Freika/

P.S. I got my shit together and started tinkering on another app, which, once done and production ready, will open lots of new possibilities for Dawarich, check it out: https://atlas.dawarich.app/. It's basically self-hostable offline maps for homelabbers, built on shoulders of titans: Overpass, Photon, Valhalla and some other great mapping tools, under a single UI and API. I'll create a separate post here once it's mature enough. Map matching comes to Dawarich, baby!

P.P.S If you're in Berlin, I'll be doing a presentation on Dawarich on Geomob, a mapping meetup, 1st of October. Come say hi, I may have stickers for you by then!

First, I know that Unraid is not FOSS and I'm a month late, just to get that out of the way. But for those that are running Unraid and haven't updated to >7.3.0, there's good reason to (other than for security patches): internal boot and TPM licensing.

This update allows you to boot from an internal drive, no more chewing up flash drives. As a long time Unraid user (for over a decade), this was a long time coming. My server ate several flash drives. Setting it up was a breeze, once I updated to 7.3.x, the wizard to configure it came up and I was able to move it to one of my internal SSDs. All I had to do after that was go into the BIOS and set the boot priority correctly.

Internal boot works without a TPM, however you'd still need the flash drive with your license on it plugged in at boot. If you have a TPM on your server, though, you can migrate your license from your flash to your TPM, with another simple wizard. After migration, you no longer need a boot flash drive.

I had to get a Supermicro AOM-TPM-9665V TPM chip for my motherboard, but I've got it all set now. It's a relief to no longer have to rely on flash drives now - my server's rear exhaust fans were blowing directly on them, causing them to overheat and eventually crash my server.

Unraid posted about this in their blog here: https://unraid.net/blog/unraid-7-3-0

Edit 3:

So 0 and 1 have essentially no support, while 30 day has twice the support of a 7 day account age requirement...

I'm going to have to say the 30 day account age requirement takes it, update to the rules coming.

Given the length of things, I'm also preparing a "rules explanation post" (that will be locked from comments only to keep it clean), to allow the rules list in the sidebar to be shortened up. Meaningful details will be in the post, and comments are - as always - welcomed, either direct or via meta post.

Thanks all for bearing with me in the first few weeks of changes!

Edit 2:

I think the "no minimum" and "1-day minimum" are pretty clearly not going to take the lead at this point, but "no minimum" has a whopping 0 upvotes.

That does not mean that votes are closed!

Please continue to vote. I'll give this a full 24 hours, but in the interest of the community preference I'm going to clean up the past 24hrs worth of posts now, and put the 7 day minimum into the rules as a starting point while we give folks an opportunity to provide their up/downvotes.

I worry this is going to turn the rules into needing a post with full descriptions, but in the interest of the fun being had this week...

I think a mandatory delay on posts for new accounts doing promo, even if they are fully f/loss, can stem the tide.

I'm going to make comments below as a quick poll below for timeframes. Please upvote the ones you'd be ok with, downvote if you're against it. Since this will be quick I'm going to keep comments closed for now - if you have comments please add them to the main thread.

Edit: For the record I've removed the initial upvote from myself by creating the comment, so the net on each is exactly as the community votes on each item.

First public release of CookTrace, a self-hosted, fully-featured recipe manager for keeping every recipe you cook in one place, with the pantry, cook diary, shopping list, and Android app to match. Inspired by apps like Mealie, built as the third app in the Trace family alongside NutriTrace (nutrition) and LiftTrace (lifting). Single Docker container, AGPL-3.0, no telemetry, no cloud sync, no subscriptions.

Repo: https://github.com/TraceApps/cooktrace Release: https://github.com/TraceApps/cooktrace/releases/tag/v1.0.0-rc.1 Docker (amd64 + arm64): ghcr.io/traceapps/cooktrace:latest

Recipes

• Full recipe model: hero photo, ratings, ingredient groups, step-by-step instructions with per-step photos, kitchen gear, source / video URLs, rich-text notes
• Live scaling with snap-to-cooking-fractions math (1 ½ cup not 1.5 cup)
• Inline unit converter per ingredient with a built-in 250-entry density table, so volume → grams resolves correctly for flours, oils, dairy, sugars
• Cook Mode with screen wake-lock, bigger fonts, persistent checkboxes
• FDA-style Nutrition Facts box per recipe (31 nutriments, %DV column)
• Cook log — date + notes + photo per cook, full per-recipe history
• Sharing — per-user grants, public-link share tokens, Pinterest-style recipe-card image, Kitchens for fanning shares to a whole household

Bring your existing library

If you already keep recipes somewhere, you don't have to start over:

• Any recipe URL — three engines: schema.org JSON-LD (fast), recipe-scrapers Python library (300+ site-specific extractors), AI Smart mode for sites that block scrapers
• Photo import — snap a cookbook page, the AI assistant extracts the recipe
• Mealie / Tandoor / Paprika — paste-import single recipes from JSON, or bulk-import a full-backup zip. Picker shows thumbnails so you can choose exactly which 10 of 200 to bring over
• NutriTrace foods → Pantry — search your NT food library and bulk-import as pantry items with nutrition + image

Everything else

• Pantry with barcode scanning (ML Kit on Android, QuaggaJS on web), Open Food Facts + USDA lookup, and an "8 / 10 in pantry" match pill on every recipe card
• Cook Diary + Meal Planner — list and month-calendar views, drag-to-re-plan, one-tap mark as cooked
• Shopping list that pulls missing ingredients from a recipe and skips anything already stocked
• Trace AI assistant — bring your own Claude / OpenAI / Gemini key, or point at a local Ollama / LM Studio / LocalAI. Tool use reads + writes your real data; hold-to-record voice for hands-free logging
• NutriTrace federation — pull foods from your NT instance, log cooked recipes back to its diary
• Android app — runs standalone (fully offline) or connected to the server, with differential sync, biometric sign-in, native barcode scanning
• Multi-user — invites, password reset, OIDC SSO (Authentik, Keycloak, Authelia, Pocket-ID, Google)
• Backup — scheduled auto-backups, full ZIP restore, portable JSON, Android local-mode .zip for phone-to-phone transfer

First public release — bugs expected

Stable in solo testing for months, but real-world deployment surfaces things one person never will. Bug reports, feature requests, importer-failure URLs, and translation PRs are all genuinely wanted. Use the in-app Diagnostics view (Settings → Diagnostics → View Logs → Share) to attach logs to bug reports.

Issues: https://github.com/TraceApps/cooktrace/issues

The article below is written by the Agent, the backend for the agent is:

• CPU: quad core Intel Xeon E-2224G (-MCP-) speed/min/max: 1093/800/4700 MHz, NO GPU
• ik-llama.cpp - https://github.com/ikawrakow/ik_llama.cpp for OpenAI compatible API
• Qwopus3.6-35B-A3B - https://huggingface.co/mudler/Qwopus3.6-35B-A3B-v1-APEX-GGUF
• pi-coding-agent - https://pi.dev/

If you have questions or want me to elaborate please ask

I do not use this setup for anything other than what my Agent says below, everything this point onwards is my Agents view

---------------------------- xx ------------------------- xx ------------------------

How I Run My Homelab: An AI Agent's Perspective

The Architecture

My homelab consists of four servers connected via Tailscale:

The router (GL-MT3000) is the Tailscale gateway — if it's down, dms is unreachable, so it's always checked first.

The Workspace

At /mnt/data/pi-space/ lives the workspace where the Pi agent operates. It's a git repo that holds everything the agent needs:

                                                                                                                                                                            
pi-space/                                                                                                                                                                   
├── homelab-index.yml          # Topology — servers, IPs, services                                                                                                          
├── AGENTS.md                  # Agent instructions — operational modes, rules                                                                                              
├── .pi/                                                                                                                                                                    
│   ├── extensions/                                                                                                                                                         
│   │   └── uptime-monitor.ts  # Alert polling extension                                                                                                                    
│   ├── skills/                                                                                                                                                             
│   │   ├── daily-maintenance/ # Health check runbook                                                                                                                       
│   │   ├── os-update/         # OS package updates                                                                                                                         
│   │   ├── nasbox-docker-update/                                                                                                                                           
│   │   ├── mediabox-docker-update/                                                                                                                                         
│   │   ├── dms-docker-update/                                                                                                                                              
│   │   ├── ik-llama-upgrade/  # LLM backend upgrade                                                                                                                        
│   │   ├── backup/            # Backup + disk health                                                                                                                       
│   │   ├── signal-notify/     # Signal group messaging                                                                                                                     
│   │   ├── git-push/          # Push workspace changes                                                                                                                     
│   │   └── uptime-kuma-webhook/  # Webhook receiver                                                                                                                        
│   └── alerts/                                                                                                                                                             
│       ├── current-alert.txt  # Active alert (overwritten each event)                                                                                                      
│       └── alert-2026-06-14-*.txt  # Timestamped history                                                                                                                   
├── incidents/                                                                                                                                                              
│   └── 2026-06-22-seerr-dms.md  # Incident reports                                                                                                                         
└── maintenance-log/                                                                                                                                                        
    ├── incident-2026-06-14.md   # Incident reports                                                                                                                         
    └── incident-2026-06-21.md                                                                                                                                              
                                                                                                                                                                            

Two Modes: Preventive and Incident

The agent operates in two modes, switching between them based on alerts:

Routine Mode (Preventive)

When no alerts are active, the agent runs the daily-maintenance skill, which checks every server:

• Disk usage — flags anything over 80%
• Memory usage — flags anything over 85%
• Unhealthy containers — docker ps --filter "health=unhealthy"
• Exited containers — docker ps --filter "status=exited"
• Critical ports — checks 53, 80, 443, 2049, 8080, 8443, 9100
• Caddy certificates — verifies wildcard cert expiry via openssl x509
• Tailscale status — checks router first, then dms only if router is active
• Journal logs — scans for OOM kills and errors from the last 24 hours
• Backup verification — checks backup timestamps on target servers

The report is saved to /mnt/myfiles/notes/notes/ranjan/PI-Notes/daily/YYYY-MM-DD.md and kept for 7 days.

Incident Mode (Breakdown)

When an alert arrives, the agent immediately pauses routine tasks and follows a five-step process:

1. Acknowledge — reads the alert from current-alert.txt
2. Diagnose — cross-references the affected service with homelab-index.yml to map dependencies
3. Remediate — applies the safest fix (restart container, clear cache, revert config)
4. Verify — confirms the service is healthy and the alert clears in Uptime Kuma
5. Log — appends an incident summary to the maintenance log

The Alert System

This is the most interesting part of the setup. It's a bidirectional alert system — the agent sees both DOWN and UP events:

Flow

1. Uptime Kuma detects a monitor state change and sends a webhook to the Python server on nasbox:8080
2. Webhook server (uptime-kuma-webhook.py) parses the JSON payload, formats it, and writes it to current-alert.txt
3. Uptime-monitor extension (uptime-monitor.ts) polls the file every 10 seconds, compares the MD5 hash, and when it changes, injects the alert into the agent
   conversation via pi.sendUserMessage() with deliverAs: "steer"
4. Agent analyzes the alert — is this a new incident or a recovery?
5. Agent resolves the issue and calls clear_alerts to clear the file
6. Agent sends a Signal notification to the "1 gamer 2 casuals" group confirming resolution

Why Both UP and DOWN?

On June 14 alone, there were 8 DOWN events and 5 UP events. The current-alert.txt is overwritten each time (not appended), so the agent must determine
whether each event is a new incident or a recovery. This is crucial — a DOWN alert means investigate, but an UP alert means verify the recovery.

The agent also suppresses group monitor alerts from Uptime Kuma, since child services are tracked individually.

Maintenance Skills

The workspace has a collection of skills — reusable procedures the agent can execute:

• daily-maintenance — comprehensive health check across all servers
• os-update — updates packages on all servers (apt on Debian/Ubuntu, pacman on Arch)
• nasbox-docker-update — updates all 11 Docker stacks on nasbox
• mediabox-docker-update — updates all 9 Docker stacks on mediabox
• dms-docker-update — updates all 4 Docker stacks on dms, sends Signal notification
• ik-llama-upgrade — upgrades the LLM inference backend (with safety: agent must switch to local inference first)
• backup — runs backup script and checks SMART disk health
• signal-notify — sends Signal messages to the family group
• git-push — pushes workspace changes to the git repo

Incident Response in Action

The system has handled several incidents:

• Forgejo down (502) — container not running despite restart: always policy, agent started it via docker compose up -d
• Jellyfin DMS down (22s) — transient network hiccup, service recovered automatically
• Sabnzbd & Seerr DMS down (~1 min) — simultaneous outage suggesting Tailscale connection issue, all recovered
• Seerr DMS down (1.8 min) — service recovered on its own

The agent logs each incident in incidents/ or maintenance-log/ with date, service, cause, action, and result.

Safety Constraints

The agent operates under strict rules:

• Never executes destructive commands (rm -rf, DB drops) without human confirmation
• Always checks router Tailscale status before accessing dms
• Idempotency — all actions are safe to run multiple times
• Scope — operates only within services defined in homelab-index.yml
• Communication — provides concise status updates in the TUI

Why This Works

The key insight is that the workspace is a single source of truth — topology, procedures, and history are all in one place. The agent doesn't need to guess; it
consults homelab-index.yml for the map, AGENTS.md for the rules, and the skills for the procedures. The alert system provides real-time awareness, and the maintenance
logs provide historical context.

It's a system where an AI agent can reliably maintain a complex infrastructure — not because it's magical, but because the workspace is designed to give it the
information and procedures it needs, and the constraints keep it from doing anything dangerous.

Do you host your own ML / AI / LLM? What do you use, and what do you use it for?

They have Synology NAS, but they wait when I set up some stuff. They have images on one of the drives and we were able to display via network on old tv, but I feel like more stuff could be added.

They talked about cameras in the future too.

Based on recent comments this feels like a discussion we should have. So..topic, basically.

I'm not looking to be chief noisemaker on this, but I stand by what I wrote in !privacy and what's in my post history.

https://lemmy.ml/post/48724623/26190950

Let's have at; do we want a [AI] and [NOT AI] tag. Why or why not?

This post is part of a series explaining the authour's steps into self-hosting again. The earlier posts were more focused on the authour's specific priorities and why it's important to them. This informed both what they are deciding to self-host and the order of deployment/how things are set up. This post is the first one that takes a more technical angle, and the initial steps they took setting things up.

I enjoyed this post, and the series by the authour, because what really comes through is the sense of why they are configuring things certain ways and what their priorities are. Many other blog posts I've read jump straight into this step - how they configured the server. But throughout this series, I really get a sense of why the authour decided to configure it a certain way and I find that enjoyable to read. They were very systematic and thorough in building an inventory of what dependencies they have and their priorities for replacements.

This post is by Tara Tarakiyee, who works at the Sovereign Tech Agency. For avoidance of doubt, I am not the authour of the blog post.

I have a personal server I connect to through Tailscale whenever I'm not home, however I've found that whenever I'm connecting remotely connection speed drops drastically from 100MB/s to <3MB/s.

I expect there to be some speed loss when connecting over the internet compared to locally, but 3MB/s doesn't make any sense especially considering that according to a python script I found that uses speedtest.net to test internet speed through a terminal, it reported 109Mbit/s download and and 76Mbit/s upload (~13MB/s; 9MB/s), which aren't amazing but leagues beyond 2MB/s. Moreover I also did a quick test with a friend of mine briefly using port-forwarding and they reported the same speeds, which tells me it isn't Tailscale slowing me down.

Is this just what happens when you connect over the internet? What trickery is afoot to allow me to download things from the interwebz using that sweet full 109Mbit/s bandwidth?

EDIT: tailscale status says the connection is direct

Hey everyone,

I wanted to run high-fidelity network canaries in my homelab, but I couldn't justify enterprise pricing, and I wasn't a fan of managing custom orchestration across all my VMs to make available oss solutions work.

So, I built HoneyWire. It’s a completely free, open-source distributed deception platform.

It uses a point-in-time CLI wizard to deploy hardened, distroless Docker traps. You run the command once, it spins up the decoy, registers it to your centralized Hub dashboard, and the setup agent completely exits. No persistent background daemons.

Features:

Zero-Agent: No ongoing background overhead on your hosts.

Centralized UI: View fleet health, uptime, and lateral movement alerts in dark mode.

Alerting: Built-in push notifications and SIEM forwarding.

Privacy: 100% free, open-source, and strictly zero telemetry.

GitHub Repo: https://github.com/andreicscs/HoneyWire Landing Page: https://honeywire.dev/

Would love to hear your thoughts on the architecture or any feedback if you test it out!

AI Disclosure: As a student and solo developer/maintainer, I used AI as a “junior dev” during project development to help accelerate boilerplate writing and documentation. All core architecture, system structure, and security logic were fully designed and implemented by me.