acme-companion VS cloudflare

Compare acme-companion vs cloudflare and see what are their differences.

acme-companion

Automated ACME SSL certificate generation for nginx-proxy (by nginx-proxy)

cloudflare

Caddy module: dns.providers.cloudflare (by caddy-dns)
Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
acme-companion cloudflare
32 10
7,229 351
0.9% 6.8%
7.6 5.0
about 1 month ago 8 days ago
Shell Go
MIT License Apache License 2.0
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
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.

acme-companion

Posts with mentions or reviews of acme-companion. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-07-10.
  • Wireguard (docker-compose) has stopped being able to connect to the internet.
    2 projects | /r/WireGuard | 10 Jul 2023
    My hunch is that because I decided to include the acme-companion image in this nginx setup, that maybe it has something to do with the SSL certs? The only other thing I could think of is that I had to combine the networks in order for nginx-proxy and Sonarr both to be able to see my transmission instance via:
  • Add https to docker app
    2 projects | /r/docker | 24 Jun 2023
    Probably want acme with nginx https://github.com/nginx-proxy/acme-companion
  • Beginner questions about deploying node.js app on Beanstalk
    2 projects | /r/aws | 19 May 2023
    setting up letsencrypt with nginx-proxy and acme-companion
  • Further investigating 403 – access forbidden by rule
    2 projects | /r/nginx | 20 Mar 2023
    I'm experiencing a weird situation, and am not sure how to go about finding a solution. I am running the nginx-proxy container (https://github.com/nginx-proxy/nginx-proxy) together with the acme-companion container (https://github.com/nginx-proxy/acme-companion) to provide https connections to all my different applications under different subdomains on the same host (currently, for testing purposes: only two other nginx containers with a plain html page).
  • What is the correct way to have my webapp in one container and the webserver in another?
    2 projects | /r/docker | 8 Mar 2023
    We use the nginx-proxy docker image with its acme-companion to have an auto configuring SSL reverse proxy, so it's really easy to deploy images (we do it based on a merge PR into protected release branches).
  • dockerfile for httpd
    2 projects | /r/docker | 30 Dec 2022
    Just use nginx-proxy and the LetsEncrypt companion as reverse proxy to handle TLS/SSL in front of your web server.
  • nginx-proxy-manager abandoned?
    5 projects | /r/selfhosted | 7 Nov 2022
    You can simply use this proxy container which automatically generates nginx config based on envs set in your containers. There is also a companion container which takes care of your certs. https://github.com/nginx-proxy/nginx-proxy https://github.com/nginx-proxy/acme-companion
  • Tools for automation and daily tasks
    12 projects | /r/automation | 31 Oct 2022
    https://github.com/nginx-proxy/acme-companion https://github.com/nginx-proxy/docker-gen https://github.com/projectdiscovery/dnsx https://github.com/projectdiscovery/httpx https://github.com/projectdiscovery/mapcidr https://github.com/debauchee/barrier https://github.com/stedolan/jq https://github.com/ddosify/ddosify https://github.com/kubernetes-sigs/kind https://github.com/mailcow/mailcow-dockerized https://github.com/motiv-labs/janus
  • Trying to figure out how to update our SSL certificates for a couple of docker webapps using nginx
    2 projects | /r/docker | 4 Oct 2022
    If you use Docker anyway, have a look at nginx-proxy and it's acme companion. When running on the same host, it will automatically find other containers via docker.sock and then route and create Let's Encrypt certificates for the (sub-)domain you add via env.
  • Help for Iran: How to host the signal-tls-proxy for iran behind a nginx
    3 projects | /r/selfhosted | 26 Sep 2022
    For the signal proxy, they are using nginx and letsencrypt already and the ports 80 and 443. My current setup already involves an nginx proxy as well as a certbot, so how can I host this signal proxy in my infrastructure?

cloudflare

Posts with mentions or reviews of cloudflare. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-04-07.
  • Which reverse proxy are you using?
    16 projects | /r/selfhosted | 7 Apr 2023
    If you're using Cloudflare then you might need the Cloudflare module which is a little annoying because you need to rebuild the Caddy executable (or Docker image) to include it. I just set up a GitHub repo that uses GitHub Actions to build and publish a Docker image that includes the Caddy Docker Proxy and Cloudflare modules, but I haven't figured out how automatically update the image when a new version of Caddy is released so it's still a manual process for now.
  • Story on revisiting Svelte/Kit after moving to Solid, then Remix
    3 projects | /r/sveltejs | 17 Jan 2023
    I'm on Cloudflare now, so I build my own image based on this Docker image to use SSL from Cloudflare.
  • Caddy2 reverse proxy to pihole not working
    2 projects | /r/pihole | 25 Oct 2022
    Anyways, my end goal is to use cloudflare aswell, because I see that then you can get a wildcard DNS record. Have you tried that? Are you using https://github.com/caddy-dns/cloudflare ? Did you have to build it yourself, or is it included in dockerhub image?
  • NGINX Proxy Manager
    15 projects | news.ycombinator.com | 20 May 2022
    > 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].

    Yeah - the default version it'll build with is the version embedded in the builder image, so in that case, v2.5.1. But really, you can just use always use the latest builder image and specify the version you want in the xcaddy command, i.e. 'xcaddy build v2.5.1 --with ', or any other git ref if not a version (cause we're using Go to build and you can use any git ref, like a commit hash or branch name if you want to try a WIP pull request).

    We set it up with a good default so most users wouldn't need to ask that question, it should "just work" for them. But it's a valid question to ask.

    > 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.

    Yeah we're using Gomplate for generating the Dockerfiles for the official Docker Library builds, since we need to make builds for every CPU architecture, and even Windows docker images (I still have no idea why anyone would want those, but alas). Either way, that's an implementation detail of how we automate this stuff, doesn't matter to users.

    > Now, what version of `caddy-dns/cloudflare` am I getting?

    The latest, if you don't specify a version. The https://github.com/caddy-dns/cloudflare repo doesn't have tagged releases, so it'll just be the latest commit on the master branch. You can specify a specific commit like '--with github.com/caddy-dns/cloudflare@8ea1cff' for (as of this writing) the commit just before the latest.

    > What other risks come along with building and maintaining my own custom image?

    Honestly, none. Maybe problems with plugins not being compatible with eachother, but Caddy's plugin design means that should rarely happen, except if two plugins have the same module ID. But that's up to you to make sure you don't pick two plugins that try to do the same thing.

    Because of the way Go builds work, they can always be cross-compiled. We don't use CGO, so builds of Caddy are completely static and have zero dependencies. There's really no risk that it doesn't build in a specific environment, or whatever.

    > 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.

    Up to you. But that's the exact reason we don't maintain builds with plugins ourselves. There's literally an infinite amount of combinations possible. Some have suggested like "caddy-lite" and "caddy-full" sort of setups where we ship just a few vetted plugins or "yolo give me all the plugins" but that's silly. We don't have the time or resources to vet all the plugins.

    From your perspective it might seem like "duh, there should be an official build with Cloudflare", but really it's a pretty small percentage of users who need this.

    > 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.

    (as I wrote in my other comment, the docs for this are on https://hub.docker.com/_/caddy)

    > The desire for wildcard certificates is to keep things from being discoverable via CTLogs.

    It's really trivial for someone to scan until they hit subdomains that return a successful response, if they really cared. This doesn't really protect from anything. Using wildcards for that is a bit of an antipattern.

    15 projects | news.ycombinator.com | 20 May 2022
    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/...

  • Best Applications To Use For 2FA For VPN Connections Into Local LAN?
    6 projects | /r/selfhosted | 28 Apr 2022
  • 3 weeks ago I knew nothing about docker or selfhosting. Now I have my small home server and thanks to r/selfhosted I was able to setup it all by myself! Any recommendations on what should I install next?
    11 projects | /r/selfhosted | 28 Oct 2021
    As default it does need port 80 open to renew certificates, but you can use DNS challenge instead. https://github.com/caddy-dns/cloudflare

What are some alternatives?

When comparing acme-companion and cloudflare you can also consider the following projects:

Nginx Proxy Manager - Docker container for managing Nginx proxy hosts with a simple, powerful interface

docker-compose-letsencrypt-nginx-proxy-companion - Automated docker nginx proxy integrated with letsencrypt. [Moved to: https://github.com/evertramos/nginx-proxy-automation]

nginx-proxy - Automated nginx proxy for Docker containers using docker-gen

Docker Compose - Define and run multi-container applications with Docker

docker-letsencrypt-nginx-proxy-companion - LetsEncrypt companion container for nginx-proxy [Moved to: https://github.com/nginx-proxy/docker-letsencrypt-nginx-proxy-companion]

unbound

nginx-proxy-automation - Automated docker nginx proxy integrated with letsencrypt.

docker-letsencrypt-nginx-proxy-companion - Automated ACME SSL certificate generation for nginx-proxy [Moved to: https://github.com/nginx-proxy/acme-companion]

crowdsec - CrowdSec - the open-source and participative security solution offering crowdsourced protection against malicious IPs and access to the most advanced real-world CTI.

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-docker - Source for the official Caddy v2 Docker Image