98
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 06 Jun 2025
98 points (100.0% liked)
Selfhosted
61901 readers
782 users here now
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.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
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!
founded 3 years ago
MODERATORS
Few of them for most use cases, especially a VPS. My server have a couple of IPs each mapping to a different VM, they can all claim 22/80/443 as you'd expect, but that's just basically the same as having a bunch of VPSes anyway.
It's useful for some other uses like, I might want to dedicate an IP for VPN exit that doesn't expose any services.
Another use is sometimes you just want two things to stay entirely separate, even if on a technical level it could work with a reverse proxy. It can eliminate some class of exploits like request smuggling.
One use case I've had for a customer is they have a system that can only do TLSv1.0, which is wildly obsolete and exploitable. So that particular API endpoint was served from a secondary IP, that way I can continue to enforce TLSv1.2+ on the primary IP. It's possible with some reverse proxy magic with HAproxy, but I could also just make a new server block in the existing NGINX bound to that IP and call it a day.
You can also have different SSL settings per virtual host with nginx. No need to use different IPs for that.
I don't remember the exact details but it didn't work right. That was arguably a couple years ago on a server distro approaching EOL, may have been long fixed. It involved Android 4.4.