On the conflicting configuration side of things that you mentioned, you need to run your services isolated from each other. Docker is one way to do it, if everything you need runs in Docker containers. I personally use LXD to run lightweight system containers and isolate my services. I use one container, for example, to run Docker.
With that being said, there’s usually a lot of studying involved in learning each technology which helps your server setup. You are the one to decide if it’s worth it.
I’ve been testing photoview.github.io running locally on docker and it’s working just fine. Face recognition works amazingly well and fast.
Nextcloud also has a photo album app with face recognition (additional app) which I’ve been meaning to try. There is also the new memories.gallery also in my list of apps to test :)
I using hetzner as a VPS provider for hosting my kbin instance. There are probably cheaper hosting companies out there but they works and have never had any problem with them.
So you install your own server (apache or nginx or whatever) and also run your own postgresql from the same unmanaged space? And the server software serves both the php app and the database?
Thanks for answering my questions. I've always used managed hosting but it's becoming too limiting and I'm seeking to expand my options.
I use pfsense's HAProxy integration and a combination of Cloudflare or Lets Encrypt certificates for external stuff. For internal-only stuff I have a root CA I distributed to my computers that I use to sign certificates. My docker box that serves most of my internal stuff has an nginx-proxy-manager container with a wildcard certificate so that I don't have to sign one for every new subdomain on my docker host, and the various containers with services in it talk to it over a private docker network. Buying a cheap domain and managing it through Cloudflare simplifies a ton of stuff.
Why not use a self-hosted Nextcloud server? It has a lot of features that could make what you do a lot easier. Share notes, email, pictures, files, video. There's a lot of plugins available too.
I will take a look at nextcloud! Are file transfers to nextcloud robust against network dropouts? The reporters file video from remote villages so they need something that can take slow or interrupted connections.
As far as the money, you could use DuckDNS. It's free with the certificate. Not wanting to expose your network, I'm not understanding why you would want to use https. You could use wireguard instead.
Caddy reverse proxy handles that for me. I just set my domains' DNS to point to my public IP, where port 80 and 443 are forwarded to a server with Caddy listening.
I have free wildcard certs provided from my domain registrar. I host with Kubernetes, which allows for TLS secrets using Ingress. For external/public usage, I also have an NGINX reverse proxy in front of it.
LetsEncrypt provides free certificates. I would setup Nginx Proxy Manager and use DNS challenge with your dyndns provider to get HTTPS on your home services.
My problem - and I'm not alone - is that I really don't want to expose anything publicly. Is there a way to do this without exposing anything to the Internet?
I am new at this, but from my understanding, if you want to not expose anything to internet, you would need to create your own CA server to create your own certificates and have the necessary encryption certs for your own https on your home lab.
Gotta live on the edge, man. Open up your router. All ports. Firewalls are for pansies. Connect your laptop directly to the modem. Enable ssh and rdp. What could go wrong?
You can setup a VPS between the internet and your home network to limit the exposition of your home network. When a client pings yourdomain.com, it sees the ip of the VPS and not the IP of your home network.
Otherwise, a VPN + home CA server will make your home network accessible and encrypted as well
You don’t have to expose Nginx publicly. It can exist privately on your network. I have my own domain and DNS server internally. For example nginx.home.datallboy.com and jellyfin.home.datallboy.com will resolve to NPM server at 192.168.1.10. Then nginx can listen for jellyfin.home.datallboy.com, and proxy those connections to my Jellyfin VM at 192.168.1.20.
Since I own my domain (datallboy.com), I let Nginx Proxy Manager do DNS challenge which is only used to authenticate that I own the domain. This will insert a TXT record on public DNS records for verification, and it can be removed afterwards. LetsEncrypt will then issue a certificate for https://jellyfin.home.datallboy.com which I can only access locally on my network since it only resolves to private IP addresses. The only thing “exposed” is that LetsEncrypt issued a certificate to your domain, which isn’t accessible to the internet anyways.
I have a public domain that I only use internally on my home network. I have a local DNS server that handles all my internal DNS records. So I just point my DNS records to my nginx proxy manager's local IP address and let it create certs using DNS Challenge. So I don't need to expose anything external to make it work.
Look up Let’s Encrypt and their tool Certbot. They generate free https certs. Though I’m less sure about if you can use it on dyndns? You may need to buy a domain name and CNANE it to your dyndns name. I like nanecheap for domain names though if you’re new to the concept.
There’s a rabbit hole of consequences and alternatives to what I just wrote though. Does dyndns hide your home IP? I’m not sure tbh
It would come down to the specific DNS provider you’re using and what their GUI is like. in theory CNAMEs are dead simple though.
DNS names are just stored as text, so if you use tools like mxtoolbox you can see the DNS records for a given site. Following the standard text format, a CNAME formatted like below would create www.example.net that would use the IP address from www.example.com
I use letsencrypt for everything. It’s mostly simple to setup and you’ll get certs for free. If you set it up right, they’ll automatically renew forever too
selfhosted
Popular
Esta revista es de un servidor federado y podría estar incompleta. Explorar más contenido en la instancia original.