TinyWebGallery?

https://www.tinywebgallery.com/en/demo2.php

If you’re talking about remote access specifically, I use tiers.

“Public” is open, but goes through crowdsec and anubis, and is on a DMZ network. This is my website, blog, Fediverse, etc.

“Private” is either secured with mtls or wireguard. This is stuff that’s only for me or family, like media or home assistant.

“Sensitive” is wireguard only. This is infrastructure management, Paperless, etc.

Rsync.

You could leave the drive plugged in and schedule a daily/hourly sync, or you could have the system trigger a sync whenever you plug the drive in.

I’d mount it as a second storage location in Steam, then, within Steam, use the storage option to move the files over to the main library. That will ensure that they all get moved properly and reduce any potential issues.

Oh, maybe I misunderstood? It sounded like he didn’t understand what advantage a “tunnel” could provide.

If your server is behind CGNAT, you need a TURN-style “tunnel” to allow incoming connections. If you have your own remote server with a public IP, then you can absolutely use that and create the tunnel using wireguard (or openvpn, ssh, etc).

I just mentioned CF in my blog post because it’s probably the most popular solution.

The point is, if you have CGNAT, you need to create that “tunnel” somehow if you want to allow incoming connections.

That’s exactly the use case for “tunnels”: allowing public, incoming connections behind CGNAT.

Wireguard requires a public IP on at least one side of the connection and only allows private access. If you want to host a blog or website AND you’re behind CGNAT, then a “tunnel” service is a very easy solution.

Edit: my previous blog post on the topic: https://blog.k3can.us/posts/2025/feb/2025-02-21_cloudflarefort/

Sounds like you’re fairly invested in this, so why not reach out to the maintainer? It shouldn’t be difficult for them to offer a signed hash.

…But keep in mind that most images are built using base images and various other dependencies, which could all also be compromised. It might be better to eliminate docker entirely.

This was recently posted on Reddit and might be helpful.

https://www.reddit.com/r/openwrt/comments/1vwq1ey/google_nest_wifi_router_h2d_board_mistral_qcs404/

I use mTLS for Home Assistant and Navidrome.

It’s very secure, the only limiting factor is that the client apps need to support them (or you use a PWA).

Sorry, I think I misread the comment when I made my initial reply.

Edit:

If you mean the key provided for the demonstration, you could ensure that you get the correct one by checking the signature (it’s signed by my personal key) or by doing the initial download through i2p or tor. Once it’s added to your keyring, you maintain that same key for all the subsequent checks. Or, if you don’t want to do either, you could consider it as a Trust-on-first-use system.

The important point is that it’s a layered system, rather than a single point of trust, and that once you trust it, it cannot be compromised.

deleted by creator

Not often, but there’s a niche. I wish I could remember the details, but I saw someone earlier this year that was hosting a public BBS on a c64.

Same experience. 🫤

Personally, whenever I need to process anything text-based, I use perl.

Read the json into a hash, parse the values if desired, then plug the values into an html template.

It’s pretty quick to write, much easier to learn than python (in my opinion), and super powerful.

I’m a bit torn on the hardware bit, myself.

On one hand, hardware is a fundamental aspect of self hosting. There’s already a portion of the community who considers self-hosting to include using commercially-hosted cloud services (as long as it’s not Google), so prohibiting hardware discussion just reinforces that concept. Plus, it can be really fun to see what creative hardware people come up. I’m pretty sure I posted about my Fediverse server running on a WiFi router here, for example. The focus was on the unusual hardware, but it was also clearly related to self-hosting.

On the other hand, looking at what is posted in other communities, I don’t think there’s a ton of value in seeing a dozen photos of a bone-stock rpi or a closed laptop sitting on a desk. Same with the nth post asking if their 30-year-old 1u would be a good choice for Jellyfin; so I see why the rule exists.

Overall, though, I think hardware should be allowed, but maybe add a rule along the lines of “if you’re posting a question, please include what resources you’ve already reviewed or troubleshooting steps you’ve already taken.”

Heck, that might be a good rule for all questions, regardless of topic…

The first one. The service is owned by root, but the application is running as an unprivileged system user.

Quadlets work like any other systemd service.

You create the user/group you want to run as on the underlying system, then just specify that user/group in the quadlet file.

If you look at my *arr examples, you can see the user and groups they’re running as.

Podman quadlets can also auto-update and auto rollback, if needed.

It’s a function of a “pod” within podman.

I wrote the podman examples for AudioMuseAI using a pod: https://github.com/NeptuneHub/AudioMuse-AI/tree/main/deployment/podman-quadlets

And I have an example *arr suite on my GitHub page: https://github.com/K3CAN/podman-arr-quadlets

I’ll second podman quadlets. Good security, full integration with systemd, pods allow applications to easily share a namespace, and you can manage graphically through Cockpit if you really want to.