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
That's what everyone thinks for a while, and then they go back to Nginx.
Eh, my main reason for switching is that Caddy builds in LetsEncrypt. My Caddyfile is really simple, it's just a reverse proxy that handles TLS and proxies regular HTTP to my services. I don't have it serving any files or really knowing anything about the services. Here's my setup:
Each of these are separate Docker containers, which makes it really easy to manage and diagnose problems. The syntax for Nginx is more complex for 1&2, and the performance benefit of managing it all in one service just isn't relevant for a self-hosted system, so I use this layered approach that makes each level as simple as possible.
I went from NGinx to HAProxy for 5 years, now on Caddy for 2 and loving it. So much simpler and efficient.
As someone who just learned about Caddy, could you elaborate?
You usually want less integration, not more. Simple self-contained things. Nginx is good at that. That's also why you don't want to use Nginx Proxy Manager or Certbot's Nginx integration etc. It first looks like they make it easier, but there is too much hidden complexity under the hood.
Also, sooner or later you will run into some software that you would really like to try, which is only documented for Nginx and uses some sort of image caching or so, that is hard to replicate with Caddy etc.
How do you obtain ssl certs then?
I switched to Dehydrated (with dns-01 challenge), but Certbot itself is fine, the problem is the Nginx integration that tries to automatically change your Nginx config files.
Do you manually update the config every 3 months?
??? The location and the file name of the certificates don't change, so why would I have to do that?
On the contrary, before I disabled the certbot's Nginx integration, every three months certbot would "manage" to break my Nginx and I had to manually repair it.
I think we are not talking about the same thing. I mean the Certbot extension that automatically modifies the Nginx config files. A telltale sign are usually the comments "#managed by certbot” that it likes to leave behind all over your config files.
I've only really use caddy and my only experience with ngnix is ngnix proxy manager (which isn't really true ngnix).
I wasn't sure if hot swapping certs (even with same name was possible, kinda thought you would to reload it upon cert change).
Also regarding cert bot I have only used it in manual mode so it's managed mode is a bit foreign.
Not sure I agree about proxy manager. Anything you need to access is in the gui. You can easily add advanced configs to the entries. Been using it for 5 or so years, and there hasnt been anything I was missing from using straight nginx before that.
The benefit of using config files is easy version management via git.
Makes it easy to rebuild from scratch and easy to rollback a change that breaks something
Fair enough. I manage the same by backing up the vm its on.
I'm currently in the process of separating the certificate renewal service from the reverse proxy completely.
But if you're just starting out Nginx Proxy Manager makes it so easy.
Out of curiosity, what's the benefit of splitting those?
It lets you change reverse proxy or run a website with TLS completely independently of the certbot. The certbot deals with obtaining certs and leaves them in a dir, and the proxies or webservers just take them from that dir. If the proxy container breaks the certbot still does its thing etc.
It also makes it easier to do stuff like run different proxies in paralel for different things, chain proxies (for instance if you need to use a VPS because you can't forward ports) and so on.
But it's all for advanced setups, for basic stuff I'd still go with NPM.
Cool makes sense, thanks for the reply! And yeah, I don't think I'm quite there yet.
Apparently traefik might be better if you run docker compose and such, as it does auto-discovery, which reduces the amount of manual configuration required.
Silly question how safe are caddy plugins? (especially dns challenge modules like cloudflare, duckdns, etc).
https://github.com/caddy-dns https://github.com/caddy-dns/cloudflare/tree/master
Not sure if those plugins are covered by caddy's security disclosure policy
https://github.com/caddyserver/caddy/security
I maintain the DNS plugin for Vultr and I can say that it's "safe", but if you're worried you should check their source code.
I believe it's easier to have a vulnerability in the external provider's API (for example, caddy-dns/vultr uses govultr) than Caddy. But I wouldn't take things for granted if I was skeptical about these plugins.
LOL, as a noob I went with caddy, then traefik before settling on NPM. Ironically, all the "QoL" features people brag about just made base configs harder and lead to shit randomly failing.
NPM has been solid as a rock, even if I have to do slightly more work, it's more reliable and does what I want quicker and easier than the alternative.
I've been meaning to try Caddy, but I just can't even imagine something simpler than NginxProxyManager.