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
Yeah, but you're saying this is going to be used internal to you only, right? No public facing exposure?
I will need it to be available via a VPN or other means, but it's not going to be any more public-facing than it has to be.
Right, so if it's going to JUST be available over VPN, you don't need to use a public TLD, DNS, or HSTS at all. Why use the public TLD with these requirements and expose private IP address space over public DNS if it's sole purpose isn't going to be consuming it publicly?
So I should just host it with an IP address instead of using the domain?
I hadn't thought to do that, at least not for anything other than short lived internal-network-only projects and tests. An IT guy in the company I work for advised me to just get a domain and host with it/subdomains to make it easier to manage if I wanted to host multiple services.
Well, that's the simplest way in practice, but not usability. Let me explain:
You control the IP address space once you're connected to your VPN, and you control the various settings that connection makes, including DNS.
You have a network already, and a VPN of some sort, so that means you have a network device that is terminating that VPN. Is that a router you're familiar with, or a box on your network?
I haven't set up the VPN yet. I am getting as much info as I can before I start any work. For the sake of this discussion, it would be a box on my network.
Then you just need to run a DNS Forwarder, or something with a DNS forwarding capability. Your router most likely already has this.
DNS is essentially just a request and a response from a service. These can be public or private. A DNS Forwarder on your network will quickly respond if it knows that something is when asked, and return an IP address. If it doesn't know what it is, it will ask the public services available.
So if you have an internal-only network, a VPN into that network, and a forwarder or other DNS service on that network, you just tell your VPN client of choice to switch to using that DNS instead of public once it connects. It's a simple setting that every VPN solution supports, and actually makes you MORE secure by not using public DNS servers by default. You can add any record you want to said forwarder, and it will return whatever value you give it for a given domain name.
Here's a simple workflow as an example:
All contained within your local network and VPN by extension.
No need for public DNS entries or TLDs and HSTS requirements.