I’ve tried unsuccessfully to get Valutwarden working without a proxy. See here. Any request with https leads me to the SSL_ERROR_RX_RECORD_TOO_LONG error, while via http I get the “Loading wheel” running indefinitely.
Despite the top of the page here suggests you can run Valutwarden without internally without proxy, my experience suggest that this is not the case and have tried on different VMs getting the same error. So seems like the only way is going via proxy. From what I’ve read, people seem to suggest that Traefik is the way to go. So I’m thinking of setting it up on my same VM as Valutwarden.
Note that my network is behind a pfsense install on another hardware machine. DNS forwarding is enabled with unbound. Will installing Traefik require changes to pfSense config? Looks like it may be the case from here. For now all I want is getting Vaultwarden going; later down the line I’ll learn how Traefik can benefit the rest of my homelab.
I’m trying to work out the simplest way of getting Vaultwarden going using a minimalistic proxy, as there seems to be no alternative to not having a proxy going. Thoughts?
100%. I go even further and explicitly advise against traefik these days, and I was a huge proponent of it when it launched.
Caddy is just the best reverse proxy, period. When the experiments for using it as a Kubernetes ingress succeed, it’s going to change everything.
I am curious, what are the advantages of caddy over traefik?
When Traefik was rewritten, the documentation became a disgusting outdated mess and stayed that way for too long, maybe still is? The configuration needed for doing things right, and doing advanced things, was crazy verbose and clogged up any compose file you used. Same with Kubernetes annotations. As I recall, debugging misbehavior was ulcer inducing due to lack of feedback.
I don’t even remember what pushed me over the edge but it took me probably one evening to rip out traefik and stick caddy in the mix. My compose file shrank by 50%, and the caddy file is a few dozen lines. All of the right behavior is just baseline. No, it’s not as slick as putting an annotation on a container and getting a configuration, but it was never just one annotation in my experience, and caddy is just so much more usable than the alternatives like nginx and even haproxy.
Ah, that’s fair. Their documentation is fully up to date now, but imo their example configs suck for beginners.
I will note that anything that can be done in the compose file can be done as a config file instead, with the exception of traefik.enabled=true if you are using a container whitelist instead of a blacklist.
It took me ages to set up, but i now have auto configuration of 95% of containers that need to be reverse proxied, without binding ports (just use the ‘expose’ option instead of ‘ports’ in docker compose).
But yes, all the guides and example configs insisting on using container labels instead of the dynamic config files make it feel way more bloated and confusing than needed.
Why would it need experiments? Can you just run it and see if it works? Are you talking about testing it at scale?