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!
Start with basic diagnostics, see if apache is running inside the container, if it is can you curl from inside the container, if that works can you curl from the docker host, if that works did docker create the firewall rule to expose the port or is the VPS overriding things in some way?
If that all looks good, is there a VPS provider firewall in place outside the OS?
Gotta start with the basics.
Thanks for your reply. Yes, I can access with curl inside the container. The problem seems to be with SSL and I can't figure out why:
curl https://127.0.0.1:8000/
curl: (60) SSL: no alternative certificate subject name matches target host name '127.0.0.1'
I'm using the same certs that the host machine uses. When I bypass authentication with curl -k https://127.0.0.1:8000/ it outputs the contents of the page. I don't believe there's a VPS firewall since I have another service running on a higher-numbered port which is accessible from the outside.
Without knowing your config is hard... but let's try: Apache httpd needs "SSLProxyEngine on" directive to be able to proxy to https sites first (assuming you already loaded mod_proy and mod_proxy_httpd), and then when connecting it will check the name of the server as defined in the proxypass directive to see if the certificate on that server matches the name, it also looks for the date of expiration, if any of those fail it wont rev proxy, to ignore those you have to add directives for that, too, but better make sure names match and dates are fine.
Thank you so much! SSLProxyEngine was the key. This tutorial covered my usecase and it was just what I needed. Much appreciated!
An SSL error is expected because you're using localhost and not the common name that the cert is issued for. But the fact that it's connecting and showing the error means the server is working.
You need to provide a lot more information about your environment and how the server is configured, and any useful log info.
Yeah, You'll have to do a lot more troubleshooting than this. Did Docker successfully bind to port 8000? Can you curl it from the VPS itself? Does the container and the things in it run properly? Are there any error messages in the logs?
I'm not a Docker expert, but I'd start with the docker commands which show if a container is running and which ports it actually binds. Maybe a ss -at. then do a curl http://localhost:8000/ and see if it returns your webpage. If it doesn't, you need to fix your webpage container first. Or see if you can come up with an easier method to deploy your website.
A reverse proxy in any shape or form, will require your website to run, first.
First off, when you run a container without an outside IP set. Docker will bind that port, in your case 8000 to all ports. So hitting any of the domains on the vps on port 8000 should show your docker site.
Second, if your VPS is like my OVH VPS then it has only an internet IP. So any open ports are open to the internet at large.
If you want to host lots of sites on a single IP, then you will need a reverse proxy of some sort. I would recommend that your docker site is using 127.0.0.1:8000:8000 so that it's only visible on the VPS. (If your ports are different then use what you and prefix 127.0.0.1)
I run similar to your setup, nextcloud is in a VM and lots of docker sites. What do you need to know?
Thanks for the reply. I can see that the port is bound and I enabled the ports in UFW. I have a hybrid setup where the other two websites are run directly on the host without Docker and now I'm introducing a Docker container for the new deployment. All sites are running on the same ports with different domains, but the Docker one is the one with an issue. How can I have the reverse proxy acknowledge both the site on the Docker container and the sites run natively? Should I set different ports in the Apache site configs then use those ports in the reverse proxy?
Ok, the docker container will need to be on a different port to your proxy Something like 127.0.0.1:8080:80
In your proxy, the upstream will be 127.0.0.1:8080.
This should give you what you need
I am sick and slightly out of my mind anyway so I'm not going to be very helpful. One thing that stands out though, if you can SSH the machine and you can curl local host to Port 8,000 or whatever. This should help you troubleshooting the container while it lives on the VPS I think
I realized I didn't specify that the other two websites on the VPS are running directly on the host, without docker. I updated the post with that note.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| IP | Internet Protocol |
| SSH | Secure Shell for remote terminal access |
| SSL | Secure Sockets Layer, for transparent encryption |
| VPS | Virtual Private Server (opposed to shared hosting) |
4 acronyms in this thread; the most compressed thread commented on today has 5 acronyms.
[Thread #186 for this comm, first seen 23rd Mar 2026, 21:40] [FAQ] [Full list] [Contact] [Source code]