There’s nothing wrong with just using a VPS for this. Despite what some mouth-frothing hobbyists will tell you, it’s still well within the realm of self hosting. There’s just no reason or difference for hosting a blog on your UnRAID server vs a VPS.

If you really want to be some kind of purist and only use your own hardware, then you could configure a web server that can reverse proxy on your UnRAID server and forward port 443 in your router to your UnRAID box, but you’d have to change your UnRAID access port to something else. You’d want to keep this web server docker container up to date, and preferably see if you can implement some kind of WAF with it or in front of it. You’d then forward the requests from this web server to your ghost container.

A better idea would be to use a different piece of hardware for this web server reverse proxy, like a raspberry pi or something, and put it on a different subnet in your house. Forward 443 to that, then proxy the connection back to UnRAID, in whatever port you bind the ghost container to. Then you can tighten access that raspberry pi has. Or hell, host the blog on that hardware as well and don’t allow any traffic to your main LAN.

There are half a dozen better ways to do this, but they all require you to rely on a third party service to some extent.

Getting all the functionality of Pihole into Unbound would be a good deal more than “a little work” lol. And for no real practical reason when all you’re trying to do is set up secure DNS with some ad blocking on your network. And this is coming from a professional who wouldn’t have to “learn” anything to do it. If it was really that little work, Pihole + Unbound wouldn’t be the go-to solutions for so many people.

I mean if you want to build something around Unbound to do ad blocking and set up a monitoring stack for metrics and all that jazz that’s great, more power to you. But you already have two things built for purpose, there’s no reason to go out of your way to do that. And I don’t think OP here is prepared to do all that.

For the same reason you’re running AdGuard and not just pointing all your devices at the recursive upstream.

You’re using AdGuard / Pihole as an ad sinkhole, not just to cache and forward DNS requests. Like if you really wanted to you could hack together something in Unbound to do that, but why would you do that when Pihole already exists? You have two things built for purpose.

If you want to run your own recursive DNS server, why would you run two separate DNS servers?

I’m not sure I understand your question. A recursive DNS server and a local DNS cache/forwarder/are two different things with two different purposes. You will always need both. You yourself are using AdguardHome and that is just connecting to recursive DNS server upstream. In my scenario you’re just running both yourself instead of you running one and then letting a 3rd party run the other for you.

Your outbound queries will still be unencrypted, so your ISP can still log them and create an advertising profile based on them.

You can encrypt the recursive queries through your ISP if you want to. Though the effectiveness of any profiling your ISP would do to you are minimized by Qname minimization that Unbound does by default.

If you’re just using DoH then you’re just shifting who’s making that advertising profile on you from your ISP to whoever is hosting your upstream recursive DNS server. It doesn’t matter how much encryption you do because on the other end of that encrypted connection is the entity who you’re giving all your queries to.

I would say Pihole is a better choice than AdGuard home because PiHole just runs on top of dnsmasq. Throw Unbound on there too as your upstream recursive resolver and you’re set. You don’t even need to worry about an encrypted session to your upstream anymore because your upstream is now your loopback.

I think you are right but I wasn’t sure. Like technically you’ll still see the details if you open the certificate but… who’s doing that?

The point of paid SSL at this stage in the game are the higher tiers of verification. Instead of just verifying that you own the domain, you can verify that you are who you say you are. These are called Extended Validation and Organizational Validation certificates. This has historically been desirable by businesses. It used to be that these higher tier certs would not only give you a lock icon in the address bar of a web browser, but also a little blurb confirming your organization is legit. Not sure if this is still the case though. You will see the extended validation when you check the sites certificate though for sure.

As far as encryption and security, there’s no difference. Also side note, the Comodo brand still technically exists but it was bought by Sectigo like 7 years ago.

Yeah but also even when you’re paying, you’re still the product.

LMAO yeah right. If it wasn’t for learning to tell analogue time, I wouldn’t have had enough brain plasticity to finish college, oh thank god for being able to tell round time. I think you might need to keep chipping away at your own brain plasticity friendo because I don’t think learning analogue time was enough for you.

In what way am I better off for being able to read time in more than one way?

Litter box thing? I thought it was just my half wit town who believed in that bullshit.

Probably not. I can read an analogue clock and I am no better or worse for it.

As you look through these recommendations, keep in mind that source code storage will become in-scope for PCI DSS certification in the very near future.

I don’t think you read the TOS. I think you read the out of context snippet and assumed that it applied to your VPS. They removed that bit because it was confusing, not because it was not limited.

Being forced to agree to a TOS change without an opt out is scummy, but that’s not limited to Vultr. Companies are not out there with multiple versions of TOS based on what people agree to or not. At that point you’re better off not using a VPS.

Incorrect. It applies only to the forums. It does not apply in any way, shape, or form to your VPS or the content on it. It’s one thing to be mistaken, but let’s not spread misinformation on purpose.

A Reddit post incorrectly took portions of our Terms of Service out of context, which only pertain to content provided to Vultr on our public mediums (community-related content on public forums, as an example) for purposes of rendering the needed services – e.g., publishing comments, posts, or ratings. This is separate from a user’s own, private content that is deployed on Vultr services.

Since our inception, Vultr has been committed to upholding and adhering to the strictest data privacy and protection standards across the world (including HIPAA, GDPR, and DPDPA). Our customers own 100% of their content.

That only applies to posts on their forums. Not the content on your VPS

EDIT: As I suspected, the changes that u/mesamunefire is referencing are the ones that taken out of context awhile back and incorrectly assumed to apply to user VPS’ and the data on them, which is not the case. Those terms only apply to information posted publicly to their website, like the community forums.

What changes would those be

To piggy back on your “You don’t need k8s or high availability”,

If you want to optimize your setup in a way that’s actually beneficial on the small, self hosted scale, then what you should aim for is reproducibility. Docker compose, Ansible, NixOS, whatever your pleasure. The ability to quickly take your entire environment from one box and move it to another, either because you’re switching cloud providers or got a nicer hardware box from a garage sale.

When Linode was acquired by Akamai and subsequently renamed, I moved all my cloud containers to Vultr by rsyncing the folder structure to the new VM over SSH, then running the compose file on the new server. The entire migration short of changing DNS records took like 5 minutes of hands-on time.

Caddy is so simple you don’t really need configuration examples. The extra configuration many docker services have you configure in Nginx are already done by default with Caddy. Though I have seen Caddy config examples around sometimes.

If all you’re using it for is reverse proxying, you don’t need config examples for Nginx or Caddy, just understand how to configure them.