traefik VS Caddy

The main goal of this guide is to establish a streamlined process for deploying web applications with minimal effort. Using Amazon EC2 with Docker and Traefik as a reverse proxy, we will create a flexible server environment that supports multiple web applications and services, including databases like PostgreSQL, on different ports. This setup will ensure smooth deployment workflows, easy vertical scaling, and adaptable management of routing for various services, allowing for efficient expansion and integration of additional components as needed.

Treafik as Reverse proxy

apparently "traffic" https://github.com/traefik/traefik/issues/795

Pronounced "traffic", Traefik is a modern HTTP reverse proxy and load balancer aimed at making deploying microservices easier. It integrates with your existing infrastructure components such as Docker, Kubernetes, and others, and configures itself automatically and dynamically. The latest version adds lots of new options and enhancements such as adding healthcheck options, support for custom headers, and more. Read the migration guide on how to update to the latest version which is now required due to breaking changes.

> I think etcd is basically a k8s only project now

I hate etcd with the best of them, but etcd is used in a lot more places than just kubernetes:

https://github.com/apache/apisix/blob/master/docs/en/latest/...

https://github.com/traefik/traefik#:~:text=Etcd,

https://github.com/zalando/patroni#patroni-a-template-for-po...

https://github.com/purpleidea/mgmt/tree/0.0.26/etcd (this one shows up on HN quite a bit)

https://github.com/sorintlab/stolon#features

It's actually one of the major reasons I wouldn't touch those projects

However, it's very unlikely that .NET developers will directly expose their Kestrel-based web apps to the internet. Typically, we use other popular web servers like Nginx, Traefik, and Caddy to act as a reverse-proxy in front of Kestrel for various reasons:

Not as good though. Case in point: https://github.com/traefik/traefik/issues/5472#issuecomment-... (that's just from this morning)

I'm speak objectively here. Of course, any built-in auto HTTPS that works (more or less) is better than none. Traefik uses an ACME library that was originally written for Caddy. After the original author left that project, Traefik team started maintaining it. Caddy's users' requirements exceeded what the library was capable of, but unfortunately there was friction in getting it to achieve our requirements. So I ended up writing a new ACME client library in Go and, together with upgrades in CertMagic (Caddy's auto-TLS lib), Caddy has the more flexible, robust, and capable auto-HTTPS functionality.

That is to say, not all auto-HTTPS functionalities are the same.

We'll use Traefik, an open source cloud native gateway that can plug into a Kubernetes cluster. It has the concept of "middleware" that can process API requests before passing them through to a backend. We can configuring a rate limit for all of our API endpoints by matching on the request path:

Caddy

Similar in functionality with extensive more features

Caddy server has proven to be a very promising project. Not only is it fast, but it also has many built-in features that greatly simplify configuration. One example is the automatic issuance of SSL certificates. Moreover, it's very easy to set up a service using Caddy.

I recommend checking out [Caddy](https://caddyserver.com/), which replaces both Nginx and Certbot in this setup.

[Tailscale](https://tailscale.com/) can remove the need to open port 22 to the world, but I wouldn't rely on it unless your VPS provider has a way to access the server console in case of configuration mistakes.

Caddy [1] can act as a static file server that will default to HTTP 2 if all parties support it. No configuration required.

If you allow UDP connections in your firewall, it will upgrade to HTTP 3 automagically as well.

I highly recommend it

[1] https://caddyserver.com/

After testing the dockerization, the next thing to work on was the Load Balancer. There are a number of tools to choose from, but I chose to work with Caddy

It's a glorified local setup, running in a cloud free tier.

- Oracle Cloud Free Tier[1] for a Ubuntu VPS (4 ARM cores, 24 GB RAM). Surprisingly pleasant and reliable, given who's offering and for how much ($0). It used to be a FreeBSD VPS on DigitalOcean, until they kept screwing up their FreeBSD support and bricking my machines.

- Caddy[2] web server with Let's Encrypt certificates, working as reverse proxy.

- A Go server for HTTP (static files, uploads, maintaining server-sent-event channels).

- A Python server for the widgets, communicating with the Go server via events exchanged in a socket.

- Source code edited manually in-place (SSH or SSHFS[3], with Git) and restarted as needed. I know, I know, awful practice. But as I'm the only user, uptime during development is not a concern.

- Startup is handled by a @reboot cronjob and a bash one liner.

- Text files for "structured storage" (RSS feed items, authenticated sessions, mapping of uploaded file names).

As horrible as it might all sound, it has survived ten years and two cloud vendors. Nowadays I might containerize it, or rewrite as one Rust server, but I think I made the right choices at the time.

8/10 given the unusual requirements.

[1] https://www.oracle.com/cloud/free/

[2] https://caddyserver.com/

[3] https://github.com/winfsp/sshfs-win