Edit: Solved! See solution in comments
I’ve setup a self hosted lemmy docker and it works when accessing directly on the same subnet.
I don’t have ports opened in my firewall and my ISP don’t offer static IP so I rely on Clouflare tunnel as an alternative.
I’m able to load the front page, but can’t sign in. I don’t cache JavaScript through Cliudflare so I believe it’s relating to Websockets, but curious if anyone else has been able to get this working?
OK, so for anyone who might stumble across this in the future; I solved it. Kinda.
Basically, what’s happening is that lemmy is using the site URI for the human-readable content and /api for api stuff (including login, loading and a bunch of other stuff).
I tried setting up two sites in the tunnel; one to lemmy.mydomain and one to lemmy.mydomain/api but that didn’t seem to work. Presumably due to websocket calls not being re-routed.
What I opted to do was to setup lemmy.mydomain to my Nginx Reverse Proxy (I manage it using Nginx Proxy Manager). From there I added a proxy host pointing to my lemmy ui docker container and created a custom location for /api, pointing to the backend at port 8536.
The result is working great and all functions (that I’ve tested so far) is working without a hitch! Certificates are automatically managed by Cloudflare and I also get the adde dbenefit that Cloudflare offers on DNS and filtering while allowing access to my lemmy instance.
Hi, I’m hoping you can help me as it seems our setups are very similar and the documentation around this project is abysmal.
Using their packaged nginx, I have successfully launched lemmy instance accessible to the public net, but I can only get it without SSL/HTTPS and it’s not federated.
Using Nginx Proxy Manager, I can of course get a correctly SSL certified site but for the life of me I can’t forward correctly through to the Lemmy server.
Question when you have a moment…
- In NPM, is the Forward Hostname the machine IP (in my case, the external IP of my VPS) or is it the internal Docker-assigned IP for the Lemmy container?
- What external hostnames do you have set in your docker-compose.yml? Is it the full typed DNS domain (Cloudlfare in your case, mine’s DDNS) or is it the raw external IP again?
Thanks for whatever you can provide!
Are you able to authenticate locally, bypassing CloudFlare?
Haven’t used cloud flare tunnel, but is it basically like a dydns provider with cloud flare security?
Does it have it’s own domain or is url some crazy hash looking string
[…] is it basically like a dydns provider with cloud flare security?
It’s similar but with dyndns clients are connected directly to your own IP address (which may occasionally change). Cloudflare Tunnel is what the name implies, a tunnel: you run a process (
cloudflared
) on your machine that connects to Cloudflare, and clients will connect to Cloudflare as well. Cloudflare does its thing with the connection, then sends it tocloudflared
which forwards it to your actual server process.Benefits compared to dyndns:
- Your IP address is not publicly available (except to Cloudflare).
- You don’t need to open a port in your firewall/NAT (because it uses outgoing connections instead of incoming ones).
- This is especially useful if you’re behind CGNAT and can’t open a port.
- Supports all Cloudflare features (automatic HTTPS, available over both IPv4 and IPv6, security checks, etc.)
Downsides:
- Cloudflare can see everything.
Does it have it’s own domain or is url some crazy hash looking string
Cloudflare provides two options: quick tunnels and permanent ones.
Quick tunnels are temporary but quick to set up: you just run
cloudflared tunnel --url http://localhost
, it tells you your URL is something likehttps://some-words-strung-together.trycloudflare.com
, and when you stopcloudflared
(or it loses the connection) that URL is gone and you can’t get it back.Permanent tunnels require more configuration, and you need to already own or control a (sub)domain for Cloudflare to manage. Internally it uses a “crazy hash looking string” domain, but that’s just for configuration and not really user-visible. The main differences compared to quick tunnels:
- You control what domain name it uses (
yourdomain.com
orsub.yourdomain.net
or whatever).- This also means that domain name will stay the same if you ever need to restart the tunnel.
- Much more configurable.
- There appears to also be support for raw TCP, SSH and a few other protocols. I haven’t used those and they may or may not be available in the free version.
Thanks it sounds interesting