dokku-scheduler-kubernetes VS Caddy

Compare dokku-scheduler-kubernetes vs Caddy and see what are their differences.


Scheduler plugin for deploying applications to kubernetes (by dokku)
Our great sponsors
  • SonarQube - Static code analysis for 29 languages.
  • Scout APM - Less time debugging, more time building
  • SaaSHub - Software Alternatives and Reviews
dokku-scheduler-kubernetes Caddy
4 219
120 41,412
0.8% 1.7%
3.2 9.3
5 months ago 4 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.


Posts with mentions or reviews of dokku-scheduler-kubernetes. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-05-14.


Posts with mentions or reviews of Caddy. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-06-29.
  • C++ (or C, I guess) application server that's QUIC/HTTP3 ready?
    4 projects | | 29 Jun 2022
    Caddy is a pretty good server/reverse-proxy and it has an experimental support for HTTP3.
  • Kestrel as a reverse proxy?
    3 projects | | 23 Jun 2022
    Caddy is a great web server/reverse proxy, and very easy to configure. I prefer it over nginx for my personal stuff.
  • What's everyone working on this week (25/2022)?
    16 projects | | 20 Jun 2022
    Two line compilation and deployment with Docker Compose + Caddy for HTTPS / reverse proxy cargo-chef for fast Dockerfile builds (i.e. doesn't recompile dependencies unless they change) and a few complications re: pulling private dependencies with SSH+git
  • How can I make my laptop into the server I don't want to pay for hostiinger anymore.
    3 projects | | 16 Jun 2022
    I do exactly this with both of my old laptops. Recently switched one out for a proper server + raspberry pi though. It entirely depends on what you want to do, but easiest option is to use a service like caddy or one of the many alternatives available. From there install all the services you're after, forward them correctly in caddy, job done.
  • Show HN: Umbrel – A personal server OS for self-hosting
    7 projects | | 7 Jun 2022
    Re 3: What you really need is Caddy [0] with this dynamic DNS module:

    Caddy has state-of-the-art certificate automation and TLS support, and with that module, it automatically updates DNS records if users have non-static IPs. It'll also serve certs for localhost domains (use *.localhost IMO).

    [0]: (I'm the author, for disclosure)

  • I need the simplicity of serverless hosting, but it's too expensive
    2 projects | | 29 May 2022
    You should check out Caddy: Way easier to use than nginx if https is your sticking point, you don’t even really have to do anything except write a short 3-4 line config file. Pretty sure there’s also a docker image available. It’s a great project, automatic https be the default for most (all?) reverse proxies. Nginx needs to catch up with the DX
  • Problem with fetching data from localhost API
    1 project | | 23 May 2022
    I use caddy server as a proxy for a physical android device, should work with emulated too.
  • Public and Private IP Addresses blocked
    2 projects | | 23 May 2022
    Unable to connect. Also, when I was hosting code-server, I used Caddy to reverse proxy my traffic on localhost:8080 to a domain of my choice. It worked at first, but eventually Eero blocked the domain I was using. When I attempted to proxy it to a different domain, Eero immediately blocked it making me think it has now blacklisted that specific server.
  • NGINX Proxy Manager
    15 projects | | 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.









  • Caddy 2
    2 projects | | 20 May 2022
    Caddy 2 is an enterprise-ready, open-source web server with automatic HTTPS. Takes care of TLS certificate renewals, OCSP stapling, static file serving, reverse proxying, Kubernetes ingress and more. Since it has no dependencies, it works great in containers and can run almost anywhere. Its REST API makes it easy to automate and integrate with your apps. Features a hardened TLS stack with modern protocols to preserve privacy and expose MITM attacks. ZelenskyyInPandoraPp lists it among the "most underrated selfhosted software."

What are some alternatives?

When comparing dokku-scheduler-kubernetes and Caddy you can also consider the following projects:

traefik - The Cloud Native Application Proxy

Nginx - An official read-only mirror of which is updated hourly. Pull requests on GitHub cannot be accepted and will be automatically closed. The proper way to submit changes to nginx is via the nginx development mailing list, see

HAProxy - HAProxy documentation

envoy - Cloud-native high-performance edge/middle/service proxy

caddy-docker-proxy - Caddy as a reverse proxy for Docker

RoadRunner - 🤯 High-performance PHP application server, process manager written in Go and powered with plugins

Squid - Squid Web Proxy Cache

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.

Apache - Mirror of Apache HTTP Server. Issues:

Lighttpd - lighttpd2 on github for easier collaboration - main repo still on

Simple CRUD App w/ Gorilla/Mux, MariaDB - Simple CRUD Application with Go, Gorilla/mux, MariaDB, Redis.

consul - Consul is a distributed, highly available, and data center aware solution to connect and configure applications across dynamic, distributed infrastructure.