I've tried giving screenshots of phishing emails to a local Qwen instance and so far it always correctly detected it as scam, even points out the exact elements that it based its judgement on. Sending screenshots to it ad-hoc isn't too scalable for family and friends. I'd like to be able to either forward emails for screening, or perhaps have it screen everything from a mailbox.

Has anyone done anything like this? Is there anything self-hostable that does this?

cross-posted from: https://sh.itjust.works/post/67490052

Is it possible to use joplin on my phone and desktop with syncthing?

I cannot figure out how to sync Joplin with anything, but I do use syncthing to basically back up my whole phone to my desktop whenever I'm on WiFi. Can I use desktop Joplin to access the syncthing folder and edit notes?

wanderer is a self-hosted trail database and route planner connected to the fediverse, a bit like a Komoot or AllTrails you run yourself. Starting today there's a native app for it, in public beta.

What the app does

• Find trails: search your instance and any instances it federates with. Filter by category, difficulty, distance or elevation.
• Plan routes: tap anchors on the map and the router connects them along paths, for hiking or one of four bike profiles.
• Record: GPS tracking with live distance, elevation gain, speed and moving time. It keeps recording in the background and needs no network.
• Offline maps: download whole map regions and trails before you leave.
• Turn-by-turn navigation: works offline too, and records your track while you navigate.

For admins: what your instance needs

Please read the guide on how to make your instance comaptible with the app: https://openwanderer.com/run/backend-configuration/mobile-app/

It's a beta. Do not rely on the app alone for navigation! Always carry a backup map (digital or physical). The goal is full parity with the web UI, but some things are still web-only for now. There's a full comparison here: https://wanderer.to/app/what-works-where

Install

• iOS / iPadOS 15+: TestFlight: https://testflight.apple.com/join/6VCR4QpV
• Android 8+: Google Play open test: https://play.google.com/apps/testing/com.openwanderer.wanderer
• Android without Google Play: APK on GitHub Releases: https://github.com/open-wanderer/wanderer/releases/tag/app-v0.1.0-beta.16

Get the full tour: https://wanderer.to/app

Please report bugs with the app bug template, which asks for your device, OS and instance version: https://github.com/open-wanderer/wanderer/issues/new?template=app_bug_report.yml

Happy to answer questions in the comments.

Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.

AI disclosure

The app was developed with Claude Code as a coding assistant. Involvement by area:

• Design (architecture, system design): Pair
• Implementation (production code): Generated
• Testing (tests, test plans, QA): Pair. Tests are largely generated; QA is done on real devices.
• Documentation (docs, changelogs, this post): Generated
• Review (code review): Human
• Deployment (CI/CD): Pair

Hey everyone, Daniel here!

A lot has happened since the v5.3.0 post, so let's skip the version numbers and go straight to what's new.

What is Reitti? "Reitti" (Finnish for "route") is a self-hosted, privacy-first alternative to Google Timeline. It turns raw GPS points into visits, trips and a timeline of your life — stored exclusively on your own infrastructure.

First things first: a security fix

@kgaut responsibly reported a vulnerability in the setup flow: on an already-configured instance, the setup filter could be bypassed to grant admin rights. Fixed in v5.3.2, with tests added. If you've been skipping updates, now is a good time to catch up.

The main page, reworked

The date selection element drew its fair share of critique over the months, and honestly, the critique was fair. This release finally tackles it:

• Pick your date picker style. In Map Settings → Date Picker Style you can now switch to a traditional picker with one or two plain input fields instead of the band.
• Type your way through time. On the main page, just start typing a date: your locale's format, a range like 2025 - 2026, or simply today and yesterday. A popup appears showing what Reitti understood. As a heavy keyboard user myself, this is my favorite little addition in a long time.
• One clean bar at the top. The time scrubber is no longer a floating panel that jumps around the screen, and the action buttons moved into the same bar. The main page finally has a much calmer look.

Street Photos: step into your own tracks

The feature I'm proudest of this month: Reitti now integrates with Panoramax, the open, community-built answer to Google Street View. Enable the Street Photos layer, click a photo sequence along your tracks, and look around at street level. Walk the route, pan around, and finally see the places your timeline only ever showed as dots.

Take your timeline back

• No-Visit Zones: draw a boundary around your bus stop or the post office queue and Reitti will never create a visit there again. Deleted visits now stay deleted (suppressed, restorable anytime) without touching your raw data.
• Smoothed view mode: stationary GPS jitter filtered out, and a Kalman filter on the move. All render-time only; your raw coordinates stay 100% intact.
• Custom start of day: your 2 AM walk home belongs to the evening it felt like, not to the calendar. This also keeps your Memories intact as one story.

Smarter tracking for battery savers

Many of you run trackers like OwnTracks in significant move mode. The tradeoff: your phone reports when something happens, then goes quiet, and Reitti used to read that silence as "phone off," missing visits. The pipeline now recognizes stationary stretches in sparse data and fills the gaps: No settings change needed on your phone.

Other updates

• 40x faster H3 cell updates when importing into spatial coverage
• Redis/Valkey over Unix sockets (REDIS_SOCKET)
• Upgrades no longer break pending background jobs
• Workbench polish: precise point selection, calmer hover-panning
• Immich Integration: album filters (show photos from one album instead of the whole library) and per-user photo sharing. You can now share your photos along your tracks.

🎁 Stickers!

A little something on the fun side: I designed and ordered real Reitti stickers, and they've arrived. Seeing the project as something you can hold in your hand was a surprisingly good feeling. 49 sets are up for grabs, completely free: email daniel@dedicatedcode.com with subject REITTI STICKERS and your shipping address, and I'll send one over. I ship worldwide as a standard letter, so it doesn't matter where you live. Address is used for shipping only and deleted afterwards. Details (and photos) in the Ko-fi post.

Community & Support

• GitHub: Report issues & view source
• Docs: https://www.dedicatedcode.com/projects/reitti/latest/
• Release discussion: v5.6.0 discussion
• RSS: releases feed
• IRC: #reitti on libera.chat
• Support: Ko-fi

As always, I'm curious how you use Reitti so feel free to share your setup and stories in the comments. ❤️

AI Disclosure

• Implementation (Assisted): AI helps me generate boilerplate and work through specific problems, but the bulk of the code is written by me.
• Documentation (Assisted): I use AI as a writing tool to get docs and release notes into an appropriate state. The content, structure and decisions are mine.

— Daniel

CWA is an eBook manager, and it is popular in the selfhosted book space. Please see the changelog link for the full summary, it is well organized and so I didn't copy it here.

I'm not affiliated with this in any way but saw it posted at the other place & thought fellow Lemmyzens might like to take a look.

I always find it quite hard to answer "favorite" apps as some infrastructure critical self hosted apps aren't as sexy as others which sit front & centre so I feel they often don't seem to get as much credit or attention (such as NGinX/DuckDNS compared to Immich/Jellyfin etc)

Hi everyone,

Like in previous years, I'm running a survey about self-hosting. The focus is on your favorite self-hosted apps, but there are plenty of other (optional) questions too. The top five app lists are free response fields, you don't have to select the suggestions.

Link to take the survey:

https://survey.deployn.de/s/self-host-2026

Last year's results

More info:

• The survey is anonymous. Like last year, results will be published in aggregated form. I'm currently planning to publish them in December.

• It takes about 10-25 minutes.

• Some of you asked for more questions in the comments. I added a lot at first, then realized it took 45 minutes to fill out properly. So I threw some out again, but there are still quite a few. The survey now has a core section that mainly covers the MVPs (your 5 favorite apps), and you can switch on other modules if you want. Almost every question is optional and can be skipped. If you answer everything at a reasonable pace, it takes around 20 minutes.

• The proprietary survey tool caused new problems every year, so last year I switched to HeyForm while the survey was already running. That wasn't ideal for my purposes either, so this year the survey runs on a new app. It should also make entering your apps faster.

• It's still easier to fill out on a desktop computer.

Thank you in advance for participating.

It took me a while to figure out why many of my self-hosted services were intermittently failing to connect on my phone after updating to Android 17. I eventually figured out there's a new ACCESS_LOCAL_NETWORK permission which means the "Nearby devices" permission is now required to access devices on the same network subnet. For an avid self-hoster, this can be quite a bit.

I had my DNS configured so my public-facing server resolved to a local IP address when on my LAN. This meant that my web, immich, xmpp, NTP, jellyfin and DoH servers all resolved to a local IP address on wifi. On Android 17, it all broke without warning. No error messages. No asking for extra permissions. Just silent packet dropping.

I've solved it by configuring my public-facing services to resolve to my external (static) IP address, even when inside the network. I couldn't make any internal services resolve to the external address (SMB, CUPS etc) because they are (obviously) not bound to my WAN interface.

I get why the change was made. A lot of apps were snooping around people's networks to gather intel. A potentially massive privacy violation.

Has anyone else had this issue? Is this the cleanest solution?

I have messed around with NUT to trigger a graceful shutdown of my home server running Ubuntu Server. I have struggled with setting NUT up on bare metal, but would like a gui anyway. I saw PVE-UPS which looks good, but I think but I think it is meant for Proxmox. Any alternatives, or a spin of PVE-UPS for docker compose anybody know about?

This post is an update of the second part of my Moto server series: https://lemmy.zip/post/72142441

Rumor has it that keeping an 8-year-old phone permanently plugged in with its equally ancient Li-ion battery might not be the greatest idea ever conceived.

Some even claimed that a phone needs a battery to work.

Very negative people.

Anyway, I removed it.

Pettyl did not care.

nginx: UP PHP-FPM: UP MariaDB: UP WordPress: UP cloudflared: UP sshd: UP

The battery is currently sitting next to the phone, contributing absolutely nothing to the project.

Pettyl is now running entirely from USB power, at around 37°C, while continuing to serve the website like this is completely normal.

There is, however, one tiny detail the haters may enjoy:

It can’t boot without the battery.

So the official Pettyl disaster recovery procedure is now:

1. Insert battery
2. Boot Pettyl
3. Connect USB power
4. Remove battery
5. Pretend this is enterprise infrastructure

The battery is no longer a battery.

It is the starter motor.

I see no problems with this architecture.

Anyway, Part 3 is going great.

I'm curious as to which tools and technologies you all are using to keep track of all those services you are deploying, whether it be resource tracking, network traffic, logs, traces, or uptime.

As a bonus question, how have you organized your network or your services to reduce the overhead of implementing observability?

Fine, fine. You asked for it, here it is. I hope you're happy :)

I had to use GPT for the documentation and final spit-and-polish, because I had absolutely no intention of releasing this thing, let alone documenting it for wider consumption.

Ipso facto, for all the AI “Akshually” pedants, I’ve tagged this as AIP. Politely go fuck yourselves :)

Furthermore, here is the actual tale of the tape:

• Design - HUMAN
• Implementation - HUMAN
• Testing - BONE-FUCKING-CRUSHINGLY HUMAN
• Documentation - GENERATED
• Review - PAIR

A couple of notes:

• Remote access: outside the home, the nature of the beast means you need something like Tailscale to get back into your home lab. That’s a quirk I deliberately kept for the sake of simplicity, as the browser needs HTTPS for things like GPS/geolocation. The private Tailscale HTTPS path solves both problems neatly without me having to do shit.

• Portability: I didn’t build this for you; I built it for me. That said, I detangled the original home-lab-specific mess enough that you should be able to deploy it elsewhere.

The repo separates the application from the regional data bundle, and the documentation covers installation, other regions, routing, Wikipedia/Kiwix, Tailscale, updating and the various caveats.

In other words: it is now usable by other people (and immediately usable if you happen to live where I do), but you'll need to do the work. Additionally, that should not be mistaken for me volunteering to become your unpaid support department :)

"Fork it, fix it or fuck it" - dealers choice :)

I'm thinking about buying a Raspberry Pi to start my self-hosted journey. I have three usecases in mind: Navidrome server, Jellyfin server and a Pi-hole network ad-blocking. Can a single machine (like a Raspberry Pi) run these operations simultaneously? Thanks in advance!

I usually connect with my server via ssh in a terminal and run basic commands. What's a better, more efficient and modern way of doing that? Especially considering ai and documentation along the way? I wonder if there's a better approach than "connect from remote and act local". Is there a method to "code local and push to remote"?

I use a fedora server with podman, caddyfile and vi.

For a growing number of reasons, as with most people here, I am more desirous of self-hosted solutions to replace proprietary ones, yet, as with many others, I am not in a position to fully self-host with a server at home. Any comments on kinda-self-host, where you rent a server from a third party and do all the same shenanigans on it? Specifically, I'm thinking of data storage and streaming.

Please share any information resources if you can.

We did it boys! Battery is no more: https://lemmy.zip/post/72181546

This post is a follow-up to my original post: https://lemmy.zip/post/71885626

Surprisingly, it wasn’t that tough to set up.

My original plan was to install postmarketOS and turn the phone into a proper tiny Linux server. Unfortunately, my Moto E5 Play is the pettyl variant, while the available postmarketOS port is for james. I decided that turning the phone into a brick probably wasn’t an essential part of the project.

So I went with Termux instead.

It’s now running nginx, PHP, MariaDB, WordPress, SSH and cloudflared directly on the phone. Everything starts automatically on boot, and I even made a tiny WordPress plugin for anonymous Today / Total / Online visitor stats.

And yes, the website is being served by the exact phone in the photo.

1 GB of RAM. Somehow this thing is now a production server.

I named it Pettyl, after the device codename.

You can actually visit it at https://moto.dimitrium.org/.

The website is barebones, I plan to push it to the limits. Also, this project will soon be available on my GitHub page https://github.com/tradicije

Next problem: figuring out how long an old Motorola can tolerate my bullshit.

TL;DR of the TL;DR: Private, self hosted, GPS enabled, local search and offline routing map engine in under a gigabyte, on a $55 SBC, accessible anywhere.

Ok...I've been working on this for a while and it is SO satisfying to see it to completion.

I'm calling it "Pi maps" (because the Pi hosts it) but it's really MapLibre GL JS, served locally by nginx. The Western Australia basemap is a single PMTiles archive, clipped from the Protomaps daily build to the WA boundary, zoom levels 0-15. The finished stack is about 300 MB.

300MB!

PMTiles is one of the bits I particularly like. Instead of running a tile server and maintaining millions of little tile files or a tile database, nginx just serves one archive with HTTP Range requests. Then MapLibre asks for the byte ranges it needs.

The map-serving path is:

Browser
  ↓
MapLibre GL JS
  ↓
PMTiles JS
  ↓
nginx HTTP Range requests
  ↓
WA.pmtiles

And the best part is that I needed no PostgreSQL, PostGIS or live calls to Google etc.

But wait...there's more! Search and routing!

Rather than install something heavy, I put together a small search service using Python, from the OSM extract.

The source data is converted into a SQLite FTS5 database and the current index contains about 300,000 source records, for a whopping...78 MB. The runtime search service uses about 11 MB RAM at idle.

Driving routes are calculated locally using BRouter, which runs as its own container and nginx proxies the route API internally to it.

The routing dataset for turned out to be remarkably small - roughly 20 MB, with a single worker and a 128 MB Java heap.

The browser gets route geometry, distance, ETA and turn instructions without calling an external routing service.

TL;DR: The current stack is basically three containers:

• pi-maps - nginx + the MapLibre frontend + PMTiles
• pi-maps-search - Python + SQLite FTS5 local search
• pi-maps-brouter - local driving-route engine

After testing, the individual Maps components were around:

nginx/frontend       ~7.3 MiB
search service       ~11.2 MiB
BRouter              ~168 MiB
--------------------------------
total                ~187 MiB RAM

The complete thing - map, search database, routing data, local web assets, metadata etc ends up at roughly 300 MB (excluding the optional ZIM file).

So - a Raspberry Pi 4 is locally serving a zoomable map, POI/address search and actual driving routes for comfortably under a gigabyte of application data.

What's more, I can use it remotely via Tailscale if I want and/or download the tiles directly to my phone and use it with something like GeoLibre or Atlas.

OSM / Protomaps data
        ↓
   Raspberry Pi
        ↓
 ┌───────────────┐
 │ WA.pmtiles    │ → map
 │ SQLite FTS5   │ → search
 │ BRouter       │ → directions
 └───────────────┘
        ↓
 Browser / phone / apps

It's not yet a Google Maps replacement. Yet. Right now the routing profile is driving-focused; there is no live turn-by-turn rerouting, spoken navigation, traffic data, or giant commercial address database. But...I have ideas and too much free time (actually, I think I can solve the 4 of those 5 pretty simply).

Case in point: there was a cool technical problem in that the the POI polygon centroid can be a valid map location but NOT a valid driving destination. That was fun to solve.

The next thing I'm going to try is adding a wikipedia layer - or rather, a self hosted ZIM wikipedia layer - so that POIs actually resolve to clickable entries.

There. For once, I win.

PS: This was much easier to do that the whole "family chat" bullshit. Never work with children or animals.

PPS: Also, I may have broken the family chat IRC server, or at least, misunderstood how IRC uses connection resets. So..XMPP might win after all, much to my chagrin.

EDIT: As requested - https://aussie.zone/post/36966090

Why isn't there one service that combines rss reader and bookmarking?
@selfhosted

I stumbled upon a post that tells about a project not by the author, and the project has signs of AI. The post is clearly saying the project is good, so I interpreted it as a promotion, but maybe I am wrong. Should that kind of post still be marked as [AIP] ?

The post is https://lemmy.world/post/52316345

cross-posted from: https://discuss.online/post/45939555

See my post on their forum, which I hope is well received.

Hi y'all looking for advice here

I selfhost a nextcloud server and a NAS for backups, and one of my challenges has been data corruption after power failures.

I went and bought some consumer UPS units about 5 years ago, which helped, but now the batteries are starting to fail, and I'm not protected from power outages until I replace them.

I have the router on UPS as well so the computers can communicate with each other that the power has failed and it is time to gracefully shut down (using NUT).

However the router itself uses quite a bit of power and I am hoping to make a smarter decision this time around when getting a UPS.

The router's power supply is 12V5A with a barrel style jack, so i have been searching for "DC UPS 12V 5A" to try and find something compatible that wastes less energy converting from battery DC to AC for the power supply to then convert back to DC.

But the only thing I've been able to find are these units designed to power electric doors: https://www.amazon.com/dp/B0D8VLPRN2/

I'm not sure if this would even be safe to use with a router, and i don't know how i would wire it up to the router either.

I think i just don't have enough knowledge to know how to shop for an appropriate DC UPS, or if such a thing even exists.

Anyone been in a similar situation?

tl;dr: Proxmox or bare metal? Containers yes/no? What is your use case?

I used a Dell R710 when I first started self-hosting, it ran ESXi with one VM for each service I wanted. Restarting the server required me to first shutdown each VM in order and then the whole host. When setting up a new service to host I had to create a new VM (allocate RAM, disk etc), install the OS (I ran Debian) and then follow instructions for how to setup the service. This mostly was not a problem but one software I never managed to get working was Apache Guacamole.

Nowadays I have a Dell Optiplex I salvaged for parts, got a new case and all my HDDs from my R710. Because it has much less RAM and an old Intel i5 (6th or 7th generation), I decided to get into Docker. With Docker containers you write your compose file and it will just work. No more need to dig through documentation for which version of a dependency to use, how to handle if two services on the same host need different versions (this was part of the reason for one VM/service). With Docker, I can try out a software in seconds and have it configured to my liking in minutes.

Today I have NixOS (bare metal) and it comes with Podman which uses systemd. Hence restarting my OS (albeit not that often, almost never unless I mess up my config) is a no-brainer because Podman via systemd will manage everything. Adding, stopping or removing containers in general is easy. I have a script running as a service which will stop a container, create a BTRFS subvolume snapshot, start the service again and start borg backup to backup from the snapshot.

For me using Proxmox would just an extra layer of complexity I don't need. I only have one server and I am the only user.

Questions:

• Do you use Proxmox instead of a bare metal installation?
• Do you use containers or do you install manually?
• What is you use case that requires your setup the way it is?

Probably old hat to some...but documentation is important. Just for once...I am trying to keep documentation AHEAD of the inevitable bork that destroys everything... so that in 3 months time I don't have to reconstitute everything out of thin air and swearing.

Anyhow, I came across this lovely little repo a while ago and though "yes, next time, use this"

https://github.com/Zavy86/WikiDocs

And so I am :)

I'll let the author speak to the perks (no affiliation, I just like wikidocs and wanted to share it)

• Open source
• Plain text files
• No database required
• Markdown syntax
• YAML Frontmatter
• Editor full WYSIWYG
• Support for KaTeX math
• Support for Mermaid diagrams
• Unlimited page revisions
• Uploading and downloading attachments
• Uploading images (also from clipboard)
• Content can be categorized in namespaces
• Public and private browsing
• Desktop and remote sync
• Syntax highlighting
• Multiple languages
• Dark mode

While I show off a happy snap

Good news, a security issue that was blocking the draft for the new DNS-PERSIST-01 challenge mode for TLS certificates has been resolved, meaning the challenge can resume moving forward.

Some background for those who aren't up to date:

• TLS challenges are how self-hosters and many other TLS certificate users prove who they are in order to automate cert renewals.
• The most popular challenge methods are HTTP-01 (which involves having a live web server answering on port 80 somewhere) and DNS-01 (which involves putting a key given by the TLS authority in your DNS zone in a TXT record temporarily).
• All the current challenges are conducted "live" and require active online participation on the part of the domain owner each time a cert is approaching expiration.
• The new DNS-PERSIST-01 challenge would let owners keep a proof in their DNS zone indefinitely (or with self-imposed expirations), eliminating the need for those online sessions.
• DNS-PERSIST-01 was slated to come out in Q2 this year at the latest and all the popular tools (ACME bots, reverse proxies etc.) have been chomping at the bit to implement it.
• Unfortunately there's been a security snag. Trying to do things the way DNS-01 did (record only the server-provided proof in DNS) would open DNS-PERSIST-01 to middleman attacks, because unlike DNS-01 where the proof is only there temporarily for a few seconds or a few minutes at the most, in this case the proof would be long-term.
• Hence issue #64, which has been trying to come up with a way to keep only a partial proof in DNS, and combine it with something issued by the server and something issued by the domain owner to make the whole proof, thus rendering the stuff stored in DNS impossible to use for malicious purposes, yet still sufficient for verifying ownership periodically.

Hopefully now that this hurdle has been passed things will proceed faster and we'll get to use this in the near future.