Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Yes, Uptime-Kuma is running on the same domain as the other services, except the Nginx-Proxy-Manager, which runs on a VPS which I access via WireGuard. And yes, I'm using Docker. I tried curl'ing one of the domains from the Uptime-Kuma container and got the folllowing error:
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to service.datenprolet.duckdns.org:443
. So thanks, now I have an idea about what I should investigate.Are uptimekuma and whatever you're trying to monitor on the same physical hardware, or is it all different kit?
My first feeling is that you've got some DNS/routing configuration that's causing issues if you're leaving your local network and then going through two layers before coming back in, especially if you have split horizon DNS.
Well, I'm monitoring the GUI of Proxmox on which I run a Debian VM which itself runs Uptime-Kuma and Nextcloud in Docker, so yes that's on the same hardware.