Caddy does certs by responding to ACME challenges on port 80 and 443. You need to forward those ports from the public internet back to Caddy, have you done that?

Edit: it seems like you’re doing DNS challenges. Did you compile Caddy yourself with the right plugins? Have you tested the API token work? Any Caddy logs?

It bundles WireGuard transport layer and a SNI reverse proxy natively, along with optional authentication. Good enough for beginners or people who need quick deployments.

Hi, the sourcehut seems to be pretty interesting. If I understand it correctly, this DANE-without-root provides a TOFU model as an alternative to the normal case of verifying up all the parts of the domain levels, right? If feasible, maybe that could be nice to extend with other methods for OOB verification and key rollover

Most of the software are old versions, Forgejo 7 is like years ago now. Why are you running benchmarks on these versions and not the latest ones?

I do this albeit with Tailscale. Netbird/Tailscale would act as a node of your VPN and you can configure reverse proxy routes (via tailscale serve or Netbird’s equivalent) from the VPS edge to the homelab. You can even do SNI passthrough and have TLS terminated at your home, if you want, though this can be a bit slower

Alternatively you can even expose stuff via their servers. Tailscale Inc calls this service Funnels, and Netbird should have similar offerings. It’s kinda like Tunnels but you gotta use their domains, so a VPS acts greater as a dedicated entrypoint.

Lastly yes you’d be exposing the service to the general public internet, so some basic security is needed. Netbird has a Crowdsec module integration, might wanna look at that one and set up rules/detections. Consider putting extra auth in front of Jellyfin, use Authelia or something with an auth screen. And only expose the stuff you need, not your internal dashboard or whatever admin UI.

yeah, it’s consuming. I believe a big part of this is due to Matrix’s HTTP sync-polling being more expensive than simply maintaining a TCP stream (which is what XMPP does)

In fact, since XMPP syncs in the background so well, I use Conversations as a UnifiedPush backend for Matrix. You can find another article here as well

Since this is a selfhosting sub can you actually explain how you’re hosting it?

Hi, ntfy/another unified push backend is the third party. As in: it doesn’t just go between you and your server

Android notifications are notoriously difficult to get right. May I ask how is Nextcloud Talk currently implementing notifications? Is it through ntfy, a background service, or Google’s Firebase? Have you allowed background usage for both the push app and the chat app?

I use Matrix with Continuwuity and Element X, and it’s doable most of the time except for small bugs. If you disable federation, the resource usage should be minimal too. But it also requires a third party for push service which can be unreliable.

On the XMPP side, there is also Snikket which you could look into. It offers both a server (running modified Prosody) and a mobile client (modified Conversations). XMPP can run as an efficient background service on Android, so it’ll receive in-band notifications.

Regardless of options, one of the main problem I’m aware of is that Android variants tend to overkill various background app, leading to missed notifications. I think it’s better to debug on that aspect as well

I don’t think geoblocking would be a great fit for Matrix, since you’d be contacted by servers from all over the world. It’s more suitable for something like a static website

There are various technical alternatives (ActivityPub-based stuff like PixelFed/Loops/Mastodon/GotoSocial/Sharkey/Akkoma/something else on the Fediverse)

But would you take the plunge of self-discovering different content, which might as well be none of your topics of interests? Would you be acquainted of vastly different UI/UX such as the lack of recommendations, a million client frontends, and the technicality of federation? And lastly, will you find it a place with communities to socialize and content to enjoy from in the long run?

I think trying out on a public instance would be a good way to answer those questions. PixelFed most closely resembles Insta, but the other ones can do too. Then you can consider selfhosting your own

How on earth do you have 54 release candidates, each of them adding significant feature, and not bumping your versions? Wouldn’t it be nicer to just put them on the main branch and cut a semver release every now and then? At least that’ll save on the frequency of posts here

When you say “on each device” you mean this configuration would refer to the services running on that device right? Not that every client device needs to have this set up?

The device that runs multiple services will set that up, yes. Not the client.

All my web services use apache or lighttd. Do I use caddy just for this or do I have to figure out how to move each of them to use this web server?

Apache and lighttpd can both do the same thing that Caddy does (multiplex many services via subdomain names on port 80). Caddy is just simpler and hence recommended.

You can move all services to use Caddy, takes some learning but overall better. Alternatively, if you already set up apache/lighttpd for each of your services, you can put Caddy in front and do something like

http://service1.devicename.lan/ {
    tls off
    reverse_proxy localhost:<port-that-apache-listens-on>
}

Also does it work for non-web services, like ssh or samba? (Which wasn’t in my original question, I only thought of it now.)

No. Also, those should be running on their dedicated ports anyways

Use Caddy on each device, with tls turned off. Basically

http://service1.devicename.lan/ {
    tls off
    reverse_proxy localhost:8000
}
http://service2.devicename.lan/ {
    tls off
    reverse_proxy localhost:8096
}

I use my own “solution” to host a WireGuard node inside a tailnet: https://github.com/stratself/tswg

You can also try https://github.com/juhovh/tailguard

Gluetun + Tailscale also kind of worked, but quite slow

Run tailscale ping if it’s using a DERP relay that means you’d get abysmal speed and bandwidth. Usually this is because the NAT can’t be punched through. Try opening proper ports and/or configure a peer relay

I custom-build the Caddy container since it is easy to do with xcaddy. It is automated to run every week via Forgejo Actions on a Forgejo repo, and one can pull the latest images from there using Portainer or whatever docker updater software there is.

You can also use any other CI/CD solutions you like as long as it churn out a regularly updated image. Github Actions is another good one if you don’t wanna set up Forgejo.

The caddy-cloudflare image is probably also enough for your use case, assuming they’re regularly updated. But if you like control, CI is one way to go.

The idea is to download the “project” down to a local machine, switch to the contributors’ PRs, and have those new files natively show up in their directories. Then they can use local software i.e. Inkscape/Illustrator/etc to edit those SVGs and commit the appropriate changes. This is really not feasible with a forge’s web UI.

The case of free CI/CD, visibility, and network effects are already said. So I wanna offer an anectode: someone I know is a graphic designer, who maintains a project that curate icons. Moving to Codeberg means he has to interact with PRs using the CLI, which he really does not have familiarity with. GitHub OTOH has a simple desktop client that allows natively switching across PRs, approving then in the UI, etc. It’s really, really convenient for someone who’s not a developer.

I think Forgejo-based platforms will need to work on a very good GUI client, in order to attract less technical contributors.

Use the --resolve flag e.g. curl --resolve matrix.example.com:8008:127.0.0.1 https://matrix.example.com:8008/