xcaddy
Nginx Proxy Manager
xcaddy | Nginx Proxy Manager | |
---|---|---|
3 | 651 | |
786 | 19,760 | |
3.7% | 3.0% | |
6.5 | 8.9 | |
3 days ago | 2 days ago | |
Go | JavaScript | |
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
xcaddy
-
A Blazingly Fast Open-Source Federation V1/V2 Gateway
This approach offers a level of customizability similar to what xcaddy does for the Caddy server, eliminating the complexities associated with writing Rhai scripts to customize a precompiled binary, as is the case with the Apollo Router.
-
NGINX Proxy Manager
I appreciate the reply. I took some time to look at your example so I can give some feedback on where I end up when I think about building / maintaining my own image.
My immediate reaction is that the example is nice as a one-off build, but it's much more complex if I need to set up something I can maintain long term. I might be overthinking it, but in the context of thinking about something I can maintain my thought process is below. The questions are mostly rhetorical.
First, what versions am I getting? Does using `2.5.1-builder` result in a customer built binary that's version `2.5.1`? The command usage [1] of the `xcaddy` command says it falls back to the `CADDY_VERSION` environment variable if it's not set explicitly. Since it's not set explicitly, I go looking for that variable in the Dockerfile [2].
That's some templating language I'm not familiar with and I can't track down where the variable gets set, at least not quickly. I'd probably have to spend an hour learning how those templates work to figure it out. To make a quicker, educated guess, it most likely matches the builder version. The docs said the version can be set to any git ref, so I can explicitly set it to v2.5.1 on the command line [3] to be certain.
Now, what version of `caddy-dns/cloudflare` am I getting? The xcaddy custom builds section of the docs [4] says the version can optionally be specified, but it's not specified in the above example. There aren't any tags in the repo, so it's probably building off `master`. The doc says it functions similar to `go get`, but doesn't explain what the differences are and the default behavior isn't explained either.
The docs for `go get` [6] say it can use a revision, so maybe a specific commit can be used for that, but I'd need to test it since I'm not super familiar with Golang.
What other risks come along with building and maintaining my own custom image? I could end up with a subtly broken build that only occurs in my environment. Portability doesn't guarantee compatibility [7] and building custom images increases the risk of compatibility issues beyond what I get with official images (building and running vs just running). That blog post is a really cool read on it's own BTW.
I need to consider the potential for breakage even if it's miniscule because my Docker infrastructure is self hosted and will be sitting behind my custom built Caddy image. If my custom image breaks, I need a guaranteed way of having access to a previous, known good version. This is as simple as publishing the images externally, but adds an extra step since I'll need an account at a registry and need to integrate pushes to that registry into my build.
If I build a custom image, do I let other people I help with the odd tech thing use it or is all the effort for me only? I don't want to become the maintainer of a Docker image others rely on, so I can't even re-use any related config if I help others in the future since they won't have access to the needed image.
To be fair, I also see things I don't like in the NGINX Proxy Manager Dockerfile [7]. The two that immediately jump out at me are things I consider common mistakes. Both require unlucky timing to fail, but can technically cause failure IMO. The first is using `apt-get update` which will exit 0 on failure and has the potential to leave `apt-get install` running against obsolete versions. The second is using `apt-get update` in multiple parts of a multistage build. If I were doing it I'd run `apt-get update` in a base image and avoid it in the builder + runtime images to guarantee the versions stay the same between the build container and the runtime container.
It took me about 1h to work through that and write this comment, so it's not just a matter of building a Docker image and plugging in the config. There's a lot of nuance that goes into maintaining a Docker image (I'm sure you know that already) and not having an image with the DNS plugin(s) baked in is a show stopper for anyone like me that can't justify maintaining their own.
Also, a 4 line Docker file looks nice in terms of being simple, but explicitly declaring or even adding comments describing some of the things I pointed out above can save people a lot of time. Even comments with links to the relevant portions of the docs would be super useful.
My reason for wanting the Cloudflare DNS plugin is that I have some things I want to run 100% locally without ever exposing them to the internet. The desire for wildcard certificates is to keep things from being discoverable via CTLogs.
I hope that's useful feedback. I realize someone bemoaning the difficulty of running your stuff at home lab / small business scale isn't exactly the target audience in terms of picking up customers that pay the bills. Thanks again for the reply / example.
1. https://github.com/caddyserver/xcaddy#command-usage
2. https://github.com/caddyserver/caddy-docker/blob/master/Dock...
3. https://github.com/caddyserver/caddy/tree/v2.5.1
4. https://github.com/caddyserver/xcaddy#custom-builds
5. https://github.com/caddy-dns/cloudflare/tags
6. https://go.dev/ref/mod#go-get
7. https://www.redhat.com/en/blog/containers-understanding-diff...
8. https://github.com/NginxProxyManager/docker-nginx-full/blob/...
-
bouncer for caddy / crowdsec
Another option is to create the build yourself. In the repository an example of such a custom Caddy build is available in https://github.com/hslatman/caddy-crowdsec-bouncer/blob/main/cmd/main.go. You'll need Golang to be installed to be able to create a build this way. You can also use the xcaddy tool to build custom Caddy builds.
Nginx Proxy Manager
-
Ask HN: What Underrated Open Source Project Deserves More Recognition?
I discovered these 3 amazing projects recently:
Cryptpad, essentially google docs/sheets/forms e2e encrypted. It does include collaboration. https://github.com/cryptpad/cryptpad
Immich, google photos self hostable, with share options https://github.com/immich-app/immich
Nginxproxymanager manages certificates and proxies to self hosted stuff through nginx https://github.com/NginxProxyManager/nginx-proxy-manager
Great self hosting stuff!
-
DevOps Simplified: Easy-to-Use Container Projects Deployment
Nginx Proxy Manager
- Baserow Behind Nginx Proxy Manager - Error Connot Connect to API SERVER
-
Can I put multiple services on one web domain using subdomains?
Take a look at NginxProxyManager. This would give you the opportunity to put everything in the form of service1.domain.com , service2.domain.com ,etc.
-
:latest or :version for supporting services?
Prime example: Nginx Proxy Manager is often recommended in the sub. The latest minor release came with breaking changes (so already ignoring semver). I bet you many people were running on latest and then had broken stuff: https://github.com/NginxProxyManager/nginx-proxy-manager/releases/tag/v2.10.0
-
NPM: How to keep and maintain a dynamic IP (like your public IP) in an access list.
I started looking into how to make add dynamic IPs to NPM access lists. I came across a couple of GitHub issues (1, 2) on the topic. It looks like people have solved the problem, but not in a complete way without modifying the NPM docker image. I did not want to do that, so decided looking into writing a separate script.
-
Has anyone been able to set up dockerized CrowdSec in front of dockerized NPM using official images only?
Here is the (NPM) GitHub issue where the "fork of a fork" image came into existence (lepresidente/nginx-proxy-manager). It has some interesting discussions about the challenges of having NPM and CrowdSec coexist and cooperate.
-
MyQ's horrible take on open access to their devices
Agree with this, myQ is such a dumpster fire. It needs to have an the ability to be managed over the local network instead of requiring the garage door and app connect to their server.
My very first experience with myQ was figuring out that their IP blocklist provider, brightcloud, blocks anything with the word "proxy" - including the default "it works" page for Nginx Proxy Manager [1]. And they have no way of overriding this to actually provide service if someone turns out to be a legitimate customer.
[1]: https://github.com/NginxProxyManager/nginx-proxy-manager/dis...
-
LetsEncrypt over a forwarded link?
Edit: If you're using Nginx Proxy Manager there seems to be open PR for support for proxy protocol https://github.com/NginxProxyManager/nginx-proxy-manager/pull/1882 however in the comments there's a name of repository with this PR merged.
- Bug in nginx-proxy-manager v2.10.4 on RouterOS 7.11.2
What are some alternatives?
caddy-crowdsec-bouncer - A Caddy module that blocks malicious traffic based on decisions made by CrowdSec.
traefik - The Cloud Native Application Proxy
caddy-authorize - Authorization Plugin for Caddy v2 (JWT/PASETO)
docker-swag - Nginx webserver and reverse proxy with php support and a built-in Certbot (Let's Encrypt) client. It also contains fail2ban for intrusion prevention.
caddy-ratelimit - HTTP rate limiting module for Caddy 2
socks5-proxy-server - SOCKS5 proxy server
forwardproxy - Forward proxy plugin for the Caddy web server
acme-dns - Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely.
souin - An HTTP cache system, RFC compliant, compatible with @tyktechnologies, @traefik, @caddyserver, @go-chi, @bnkamalesh, @beego, @devfeel, @labstack, @gofiber, @go-goyave, @go-kratos, @gin-gonic, @roadrunner-server, @zalando, @zeromicro, @nginx and @apache
BunkerWeb - 🛡️ Make your web services secure by default !
cosmo - The open-source solution to building, maintaining, and collaborating on GraphQL Federation at Scale. An alternative to Apollo Studio and GraphOS.
docker-pi-hole - Pi-hole in a docker container