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.
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
Looks like most of that install script is just creating a letsenceypt cert for you. If it's not working, you can probably just create one yourself or use a wildcard cert if you already have one.
The rest is just an nginx instance being used to proxy a connection. If you're already using NPM, anyway, you might as well just use that. No reason to run extra instances.
Or start with the signal one and add your other proxy config files to that.
NPM likes to eat the let encrypt requests which is what I'm assuming is breaking the cert gen inside the container. I believe you can work around this, but honestly I'd recommend just moving to a more advanced but more flexibile proxy solution.
Personally I recommend Traefik. There isn't a friendly gui to help you but once you wrap your head around it things just work. It also allows for defining proxy parameters right in your compose file via labels so it takes out the need to log into NPM and manage proxy entries there. Just deploy you're compose fils and you're off.
As far as making what you've got just work, you can either try to get NPM to stop intercepting the LE cert requests or hack up the signal-tls-relay container and jam the NPM certs into it. I wouldn't recommend either of these options though. I've been in a similar scenario and it's this among other reasons why I moved off NPM. I started with NPM because I thought it would be simple and easy and it is, right up until you want to do a thing even slightly outside of its fairly limited box.
I'll take a stab at the question. But I'll need to lay some foundational background information.
When an adversarial network is blocking connections to the Signal servers, the Signal app will not function. Outbound messages will still be encrypted, but they can't be delivered to their intended destination. The remedy is to use a proxy, which is a server that isn't blocked by the adversarial network and which will act as a relay, forwarding all packets to the Signal servers. The proxy cannot decrypt any of the messages, and a malicious proxy is no worse than blocking access to the Signal servers directly. A Signal proxy specifically forwards only to/from the Signal servers; this is not an open proxy.
The Signal TLS Proxy repo contains a Docker Compose file, which will launch Nginx as a reverse proxy. When a Signal app connects to the proxy at port 80 or 443, the proxy will -- in the background -- open a connection to the Signal servers. That's basically all it does. They ostensibly wrote the proxy as a Docker Compose file, because that's fairly easy to set up for most people.
But now, in your situation, you already have a reverse proxy for your selfhosting stack. While you could run Signal's reverse proxy in the background and then have your main reverse proxy forward to that one, it would make more sense to configure your main reverse proxy to directly do what the Signal reverse proxy would do.
That is, when your main proxy sees one of the dozen subdomains for the Signal server, it should perform reverse proxying to those subdomains. Normally, for the rest of your self hosting arrangement, the reverse proxy would target some container that is running on your LAN. But in this specific case, the target is actually out on the public Internet. So the original connection comes in from the Internet, and the target is somewhere out there too. Your reverse proxy simply is a relay station.
There is nothing particularly special about Signal choosing to use Nginx in reverse proxy mode, in that repo. But it happens to be that you are already using Nginx Proxy Manager. So it's reasonable to try porting Signal's configuration file so that it runs natively with your Nginx Proxy Manager.
What happens if Signal updates that repo to include a new subdomain? Well, you wouldn't receive that update unless you specifically check for it. And then update your proxy configuration. So that's one downside.
But seeing as the Signal app demands port 80 and 443, and you already use those ports for your reverse proxy, there is no way to avoid programming your reverse proxy to know the dozen subdomains. Your main reverse proxy cannot send the packets to the Signal reverse proxy if your main proxy cannot even identify that traffic.
Thank you for your answer. From what I can understand, the Stream settings in NPM do not allow for the function performed by ssl_preread_server_name. That means I would have to modify things in the NPM container itself, right?
Sadly, I'm not familiar enough with Nginx Proxy Manager to know. But I would imagine that there must be a different way to achieve the same result.
BTW, when I read "NPM", I first think of Node.JS Package Manager. The title of your post may be confusing, and you might consider editing it to spell out the name of Nginx Proxy Manager.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| HTTP | Hypertext Transfer Protocol, the Web |
| SSL | Secure Sockets Layer, for transparent encryption |
| TLS | Transport Layer Security, supersedes SSL |
| nginx | Popular HTTP server |
2 acronyms in this thread; the most compressed thread commented on today has 4 acronyms.
[Thread #57 for this comm, first seen 3rd Feb 2026, 08:10] [FAQ] [Full list] [Contact] [Source code]
Move your Nginx pets to something else. Pretty simple.