Skip Navigation

User banner
Posts
2
Comments
146
Joined
2 yr. ago

  • Very true! For me, that specific server was a chance to try out arm based servers. Also, I initially wanted to spin up something billed on the hour for testing, and then it was so quick to work that I just left it running.

    But I'll keep my eye out for some low spec yearly billed servers, and move sooner or later.

  • In addition to the other commenter and their great points, here's some more things I like:

    • ressource efficient: im running all my stuff on low end servers, and cant afford my reverse proxy to waste gigabytes of RAM (kooking at you, NPM)
    • very easy syntax: the Caddyfile uses a very simple, easy to remember syntax. And the documentation is very precise and quickly tells me what to do to achieve something. I tried traefik and couldn't handle the long, complicated tag names required to set anything up.
    • plugin ecosystem: caddy is written in go, and very easy to extend. There's tons of plugins for different functionalities, that are (mostly) well documented and easy to use. Building a custom caddy executable takes one command.
  • Gosh, that's cute. Probably how I'll end up too. Right now I'm not ready to let friends use my services. I already have friends and family on adguard and vaultwarden, that's enough responsibility for now.

  • Thank you! It's done in excalidraw.com. Not the most straightforward for flowcharts, took me some time to figure out the best way to sort it all. But very powerful once you get into the flow.

    If you're feeling funny, you can download the original image from the catbox link and plug it right back into the site like a save file!

  • Your first paragraph hits the nail on the head. From what I've read, bots all over the net will find any openly exposed ports in no time and start attacking it blindly, putting strain on your router and a general risk into your home network.

    Regarding bandwith: 100% of the traffic via the domain name (not local network) runs through the proxy server. But these datacenters have 1 to 10 gigabit uplinks, so the slowest link in the chain is usually your home internet connection. Which, in my case, is 500mbit down and 50mbit up. And that's easily saturated on both directions by the tunnel and VPS. plus, streaming a 4K BluRay remux usually only requires between 35 and 40 mbit of upload speed, so speed is rarely a worry.

  • If you're referring to the "LabProxy VPS": So that I don't have to point a public domain that I (plan to) use more and more in online spaces to my personal IP address, allowing anyone and everyone to pinpoint my location. Also, I really don't want to mess with the intricacies of DynDNS. This solution is safer and more reliable than DynDNS and open ports on my router thats not at all equipped to fend off cyberspace attacks.

    If you're referring to the caddy reverse proxy on the LabProxy VPS: I'm pointing domains that I want to funnel into my homelab at the external IP of the proxy VPS. The caddy server on that VPS reads these requests and reverse-proxies them onto the caddy-port from the homelab, using the hostname of my homelab inside my tailscale network. That's how I make use of the tunnel. This also allows me to send the crowdsec ban decisions from the homelab to the Proxy VPS, which then denies all incoming requests from that source IP before they ever hit my homelab. Clean and Safe!

  • I'm still on the fence if I want to expose Jellyfin publicly or not. On the one hand, I never really want to stream movies or shows from abroad, so there's no real need. And in desperate times I can always connect to Tailscale and watch that way. But on the other, it's really cool to simply have a web accessible Netflix. Idk.

  • Hey! I'm also running my homelab on unraid! :D

    The reverse proxy basically allows you to open only one port on your machine for generic web traffic, instead of opening (and exposing) a port for each app individually. You then address each app by a certain hostname / Domain path, so either something like movies.myhomelab.com or myhomelab.com/movies.

    The issue is that you'll have to point your domain directly at your home IP. Which then means that whenever you share a link to an app on your homelab, you also indirectly leak your home location (to the degree that IP location allows). Which I simply do not feel comfortable with. The easy solution is running the traffic through Cloudflare (this can be set up in 15 minutes), but they impose traffic restrictions on free plans, so it's out of the question for media or cloud apps.

    That's what my proxy VPS is for. Basically cloudflare tunnels rebuilt. An encrypted, direct tunnel between my homelab and a remote server in a datacenter, meaning I expose no port at home, and visitors connect to that datacenter IP instead of my home one. There is also no one in between my two servers, so I don't give up any privacy. Comes with near zero bandwith loss in both directions too! And it requires near zero computational power, so it's all running on a machine costing me 3,50 a month.

  • I sure hope they commit the work back into the main repo...

  • I haven't researched this, but my gut tells me one should be able to connect the two servers via Wireguard (direct tunnel, tailscale, zerotier, what have you) and discretely access the docker api without making it publicly available.

  • Email encryption, as far as I know, is to this day rarely implemented. So your host as well as any entity in between participants will be able to read your messages. SimpleLogin is also provided by Proton if that means anything to you.

  • I find there is less management overhead regarding inboxes with SL, compared to creating, managing and logging into multiple receiving addresses under a real mail server.

    Sure, you can set one mail account on your domain and define it as catch all, but then won't be able to send from these names.

    Or you can create accounts you want, but then cannot quickly create new inboxes without opening your control dashboard.

    Obviously, if you want to register with a service anonymously, you'd use one of the SL domains, which I do plenty too!

    And at the end of the chain, all messages run into the same singular Google inbox, making it easier for me to manage all messages from all domains.

    I'm sure paid email hosters will have their own advantages, but as I said at the beginning of my original comment, I want to show an alternative solution, not a better solution.

  • I've been using it for around 1.5 years, and so far I've received every message I've wanted to receive. Though I am always sort of aware that they are yet another party I depend on with my mail delivery, so I don't usually use them for crucial services.

  • Lots of people have said worthwhile things. Don't selfhost email for example. While going with an email hoster has been recommended a couple times, which is good and easy, I want to offer an alternative: SimpleLogin (or comparable providers). Essentially a "email alias generator", it forwards received emails to one or more mail addresses (Google, Hotmail, what have you). It also allows you to connect a domain and then create new inboxes on the fly by simply sending (or telling a service to send) an email to that non-existing inbox. Which is incredibly handy if you're faced with a situation that demands an email, where you don't want to give out an actual email.

    So say you have the domain doe.com, and you're in a physical shop at the register, faced with the question if you want to get 10% off by registering for their members club. You can simply give the cashier the email "coupon_walmart@doe.com" (which does not yet exist), the email will be sent, received bei SL, the inbox created and the coupon code forwarded to your Gmail account. Afterwards, you can disable or delete the inbox and never have to worry about newsletters or data breaches. Nifty!

    Every one of these boxes also has its own "sent from" address visible in your actual mail account. Which means that you can simply respond to incoming emails, and the recipient will see the mail address they sent a message to. This also means that you can set up filters in your mail account to move messages from certain sender addresses into specific labels, as if they were real separate email accounts.

  • On windows, the only features locked behind the paywall are required by professionals in film. This includes, but isn't limited to, larger than 4K timelines, 10 bit footage, advanced fusion filters and effects, niche export quality settings. As long as you're not working in the media industry, you won't need these.

    Try the free version first, before jumping into a crack. See if you even like it.

  • Once malware is VM aware it can also get outside a VM. Furthermore, malware can be written to seat itself comfortably in your PC and lay low for hours, days, weeks before becoming active. Installing in a VM and waiting for shit to hit the fan is not always reliable.

  • Are you too young to know the Bernie Sanders meme, or too old to know the Bernie Sanders meme?

  • This will work, but is not as nice as the official way to do it via a config file, as described by another comment here.

  • Change the ssh port to something with 4-5 digits, disable ssh password Auth and use certificates only, don't expose any port other than ssh and 443.

    If you're paranoid, use cloudflare as a proxy and set the VPS firewall to only accept incoming traffic from cloudflares ip list.

    That's about it really.

  • Or take github out of the equation and directly use cloudflare pages. It has its own pros and cons, but for a simple static blog it'll be more than enough, and takes out the CNAME hassle.