Consider traefik as a replacement to Caddy

[sobolevn]

https://github.com/containous/traefik

[sobolevn]

Nope, it is not a replacement.
It is a companion.

[hermanocabral]

Sorry to reopen this, but have you given any thought to replacing caddy after the whole debacle with their license?

[sobolevn]

@hermanocabral yes, I am also not quite happy with their plugin system and telemetry.

I am open to any suggestions.

[hermanocabral]

Well, I'm using traefik in prod on several small to mid size projects and so far got no problems, it's stable and I've had no issues with it whatsoever.

What were your reasons for initially looking for a replacement for Caddy?

[sobolevn]

@hermanocabral my favourite thing about Caddy is its simplicity.
You install it with one command, write 10 lines of config. And you are getting a fully working https website.

The things I don't like:

• license, you can only use "compile-from-source" for open-source projects
• how it is built: plugins should be added or removed at the compile time
• governance: we already had a case of ads in headers and telemetry by default

[hermanocabral]

Well, in that case Traefik should be as simple or even simpler than Caddy, with the added benefits of having better* (safer) defaults, a better license overall and no ads.

[sobolevn]

@hermanocabral do you have any code samples that you can share? Or maybe some tutorials / best practices with django and docker?

[hermanocabral]

The project docs are pretty good, I usually just reference https://docs.traefik.io whenever I need, but they have documentations for most of the common scenarios:

• Docker: https://docs.traefik.io/configuration/backends/docker/
• Docker with Let's Encrypt: https://docs.traefik.io/user-guide/docker-and-lets-encrypt
• Kubernetes: https://docs.traefik.io/user-guide/kubernetes/
• Consul, etcd, zookeeper, etc.: https://docs.traefik.io/user-guide/kv-config/

Aside from that, I had a few bookmarks from when I first researched it, the most up to date seems to be this one: https://beenje.github.io/blog/posts/running-your-application-over-https-with-traefik/

[sobolevn]

@hermanocabral thanks I will check it out.

[sobolevn]

One major issue with traefic is that it does not serve static files. https://stackoverflow.com/questions/46503797/is-there-a-way-to-serve-static-resources-with-traefik
Discussion: traefik/traefik#4240

You have several ways to serve your static/media files with it:

1. Use django to do it with whitenoise or similar. But, I would not rely on it
2. Use extra nginx container to serve your files. But, in this case you can ask yourself: why not just use nginx for everything?

I am still not sure how to fix this problem. Other things looks fine.

[sobolevn]

Performance: https://docs.traefik.io/v1.5/benchmarks/

[sobolevn]

I am also still not sure about either we need a load-balancer in front of traefic or not.

[sobolevn]

Caddy@2 is broken as hell: no more config files. We should 100% migrate.

[lpellegr]

Broken as hell because a configuration format has changed... looks like a quick analysis:

https://github.com/caddyserver/caddy/wiki/v2:-Documentation#config-adapters

[sobolevn]

Related:

• switch to caddy cookiecutter/cookiecutter-django#1282 (comment)
• cookiecutter/cookiecutter-django@b312d51#diff-e1e4b3088f1565fc3df91d0e4075bdef
• Replace Caddy with Traefik cookiecutter/cookiecutter-django#1714

It can be paired with whitenoise for serving static files with the docs to use CDN with collectfast in production.

[vladox]

Caddy seems to have backed up from commercial licensing: caddyserver/caddy#2786

[sobolevn]

Awesome news!

[damienallen]

Caddy@2 is broken as hell: no more config files. We should 100% migrate.

I've played around with it a bit for a personal project. Caddyfile format is still supported through an adapter, and seems to work alright. Also, it seems that they have abandoned telemetry in v2!

I like the caddy project from a usability standpoint but open to alternatives and very interested in what the consensus will be here.

[mholt]

Wow there's a lot of misinformation in this thread! Where are you getting your information from?? Where is the actual research? Are you reading tabloids?

@sobolevn

license, you can only use "compile-from-source" for open-source projects

You can compile from source for any use that is in compliance with the Apache 2.0 open source license, which has no usage or redistribution restrictions (as long as you preserve copyright, license, and state changes, etc). We have several official distributions for convenience as well: https://caddyserver.com/docs/install#official-packages

how it is built: plugins should be added or removed at the compile time

This is important for maintaining the static nature of the binaries, making deployment smoother. Would you rather bork your server at build-time or in production at deploy-time? Besides, adding plugins is easy with xcaddy:

$ xcaddy build --with module@version

governance: we already had a case of ads in headers and telemetry by default

Ah, so no hate for Firefox, Windows, Ubuntu, Chrome, VS Code, Brave, and other software which does the same thing, but for commercial benefit (whereas our telemetry was for the non-profit research community)? Regardless, this hasn't been the case for about 3 years now. Get with the times.

@hermanocabral

Traefik should be as simple or even simpler than Caddy, with the added benefits of having better* (safer) defaults, a better license overall and no ads.

Citations needed, yeah? What defaults are safer in Traefik? Why is their license better than Apache 2.0? Where are the "ads" in Caddy? Show me the evidence.

@sobolevn

Performance: https://docs.traefik.io/v1.5/benchmarks/

Is your web server really your bottleneck? Are you really maxing out tens of thousands of requests per second that only a server written in C can handle, which Traefik or Caddy are truly incapable of serving? Google, Netflix, and Cloudflare run Go on their edge, surely you can too.

Besides, web server benchmarks are mostly meaningless.

Caddy@2 is broken as hell: no more config files. We should 100% migrate.

This is absolutely untrue and it was never part of the plan to get rid of config files.

Caddy 2 does not require config files. Otherwise, it's the same as v1: plop a Caddyfile down on disk and run caddy run and you're good to go. You can of course change the name and path of the config file using the --config flag: https://caddyserver.com/docs/command-line

Docs for the Caddyfile: https://caddyserver.com/docs/caddyfile

It's very similar to v1, with many improvements. You may use the API to adjust Caddy's config, but the CLI wraps up the API calls for you so you can still use files.

Caddy's config API allows for on-line changes with graceful reloads in production. You can use it with or without files. We go over this very thoroughly in the Getting Started guide -- you should try it! https://caddyserver.com/docs/getting-started

Caddy's native config format is JSON but any other config format can be used, to your liking.

@damienallen

I've played around with it a bit for a personal project.

Thank you for actually trying it and doing a little research, instead of just listening to the hype.

I am disappointed. I expected more due diligence from a professional team such as wemake-services.

Edit: I know this all comes off as harsh. Due to an unfortunate vocal minority and some mob/hype mentality (e.g. bad takes headlining on Hacker News and other outlets), misinformation and negativity have plagued our project, and I don't know what else to do to stop it except to nip it in the bud. We (and yes, there's a small community of us) want to make the project better, but what I'm reading here is a lot of FUD that won't help us do that, and I don't want that to be a detriment to your project or our efforts to improve the software.

So, that said: are you happy with Caddy or are you looking for reasons to use something else? Reading this thread, it looks like you've been trying to get rid of it for about 3 years now. Why haven't you switched yet? What do you want to be better, and why not open feature requests or ask on our forums instead of complaining here?

[hermanocabral]

Wow there's a lot of misinformation in this thread!

Yes, starting with your comments. You do realize that most of the comments here were made when Caddy wasn't even 1.0 yet? Just look at the dates my dude.

I'm disappointed. I expected more from the author of Caddy, a truly nice piece of software that makes my life real easy on a daily basis.

Caddy changed so much from the time this ticket was open that pretty much all issues raised here were resolved. All the points raised here were valid at the time, now they are not.

Edit: I know this all comes off as harsh. Due to an unfortunate vocal minority and some mob/hype mentality (e.g. bad takes headlining on Hacker News and other outlets), misinformation and negativity have plagued our project, and I don't know what else to do to stop it except to nip it in the bud.

What you should do is say that most or all of the issues raised here were fixed in recent versions, offer your help to clarify any lingering doubts and point people to your help/support pages/forums/slack/whatever else. That's what you should do. No snarky comments, no sarcasm, no cheap shots, just a polite reminder that those issues are no longer valid.

You have a good product, let it speak for itself.

So, that said: are you happy with Caddy or are you looking for reasons to use something else? Reading this thread, it looks like you've been trying to get rid of it for about 3 years now. Why haven't you switched yet?

I can't speak for wemake-services, but I'd assume the reason why they didn't replace Caddy was because it wasn't worth it?

and why not open feature requests or ask on our forums instead of complaining here?

🤦‍♂️

[mholt]

@hermanocabral Well, you're totally right. And I totally had a reply like that comin' I suppose.

This issue was brought to my attention in connection with several other unreasonably negative pieces of feedback I had received all in the same day/weekend, and I wrote the post before looking at the dates on the comments. I didn't notice them until my later edits when I was too tired to do anything else about it.

The strains of negativity as is depicted in this thread is still a heavy burden we carry with this project, though. I would have appreciated being contacted about your (<-- plural) thoughts/questions regarding those issues rather than just having them fester here in a thread.

But I'm satisfied if you're satisfied that the issues are fixed.

[sobolevn]

@mholt first of all, thanks a lot for building Caddy. It is really great!

I really wanted to switch back at the time due to the issues listed here, but there was no alternatives. Zero. Because Caddy raises the bar very high. The simplicity in deploying, configuring, and usage is just insane!

And the main idea of this template is to be as simple as possible. But, to still include all the best practices like HTTPS, etc. Ones your project provides out of the box.

However, there was a serious issue for me that made me to switch our internal webserver to nginx: privacy. We work with large Russian corporations, their security teams know and trust nginx. But, when we were discussing Caddy as a replacement back in the days when the built-in telemetry was a thing (I don't know if this is still an issue), the discussion was quite short 🙂

I have seen that caddy@2 was released several days ago, I will totally give it a try! I hope that it will fit our needs and I can update https://github.com/wemake-services/caddy-docker and close this issue.

P.S. Extra points for taking your time to explain things that happened to the project! I was not following the CHANGELOG for a long time.

[mholt]

Thank you for understanding. 🙂

[dnk8n]

Caddy is my favorite web server that I have worked with. I reckon if you don't need Traefik, Caddy does all you could want.

But maybe it isn't as dynamic as Traefik can be? I'm not so sure.

In the second case, the two work very well together.

[damienallen]

@mholt Many thanks for this project! Honestly, I always felt like I was wasting my time messing around with nginx setup which was always a pain but especially so with SSL certs. In contrast Caddy (even v1) is really a pleasure to use.

I hope you can understand where folks were coming from with the default telemetry backlash in v1, it can be a touchy topic. It was an issue for us at the office and I'm very happy that v2 is ready for action (congrats on the release).

I have seen that caddy@2 was released several days ago, I will totally give it a try! I hope that it will fit our needs and I can update https://github.com/wemake-services/caddy-docker and close this issue.

@sobolevn Check out the official v2 docker image (https://hub.docker.com/_/caddy). I've only used it for one personal project so far but I was able to do all config from docker-compose and didn't need to extend the dockerfile. I could imagine the wemake setup could potentially work without a separate caddy repo, thus less to maintain.

[sobolevn]

@damienallen great news! Are you willing to contribute v2 caddy setup?

[damienallen]

If you're not in a hurry I can probably throw together a PR in the coming weeks.

[sobolevn]

No hurry at all, thank you!

[zwass]

Sounds like this upcoming PR would resolve #1049? Looking forward to it if so!

[damienallen]

Okay, so I was able to play around with caddy 2 this weekend to gain a bit more familiarity before making this PR. Every thing went quite smooth but I did come across this in the official docker image documentation:

Most users deploying production sites will not want to rely on mounting files into a container

It is then suggested to make this sort of Dockerfile:

FROM caddy:2.0.0

COPY Caddyfile /etc/caddy/Caddyfile
COPY site /site

However, I don't really see why this is necessary. I personally prefer to mount things like this in compose and not create my own dockerfiles if the dockerhub image can do what I need already. The current wemake-django setup seems to take docker-compose mounting approach too:

volumes:
  - ./docker/caddy/certs:/root/.caddy  # saving certificates
  - ./docker/caddy/Caddyfile:/etc/Caddyfile:ro  # configuration
  - django-static:/var/www/django/static:ro  # serving django's statics
  - django-media:/var/www/django/media:ro  # serving django's media

@sobolevn I know you have particular ideas with your setups, still okay with this mounting approach (and thus ditch wemake-services/caddy-docker if we can)?

[sobolevn]

I also prefer volumes over custom dockerfiles.

[francislavoie]

FYI in Caddy v2, the cert data is in /data and the autosave.json is in /config -- you should persist those as volumes like caddy_data:/data and caddy_config:/config. Also the default location for the Caddyfile is /etc/caddy/Caddyfile.

Regarding the following:

Most users deploying production sites will not want to rely on mounting files into a container

That's just a subjective suggestion/reminder about how many people like to deploy their sites, as a pre-built docker image that can just be run in production. It's typically done that way if you put it in some orchestration like Kubernetes or something. There's nothing wrong with using the mounted volume approach, it's really just a preferential decision based on the deployment strategy you plan on taking. I mount volumes for my PHP sites for example. That's all to say, keep on keepin' on.

[damienallen]

@francislavoie I appreciate the compose tips!

Props to you and the other folks working on the official caddy image. Really a lot more accessible now compared to v1.