Hi HN. This was my hobby project over the last 4 months and it kept me sane through my hardest semester. Feedback and contributions are totally welcome. I know Caddy has a long way to go, but it's already replaced nginx and Apache for my own needs. I figured it was time to make this a community-driven project for all who are interested.
(Incidentally, I really hope my little Digital Ocean droplet can handle the load. Wouldn't that be ironic? Anyway, if you have trouble, try the plain HTTP/1.1 site or the GitHub project page: https://github.com/mholt/caddy)
Slightly off-topic: Try serverhub.com instead of digitalocean.com. They have much more flexible offerings and much more storage available for cheaper prices. I'm running a bunch of web sites off a single $18/mo plan VPS that gives me 120GB of SSD storage.
I have also found Ramnode to be cheaper than DO. Their support is also good and they have active IRC channel for quick help. Been using them from two years and no complaints so far.
That was indeed two years ago, with no further issues since. It was not most VPSs, though there were a few host nodes wiped. Regardless, we are in the process of fully replacing SolusVM with our own system.
OpenVZ is a container based virtualization solution. Among other things it means you can't run your own kernel or make changes to the existing kernel.
The biggest problem I've encountered with it is not being able to set up certain iptables rules without a particular setting on the OpenVZ host being enabled (which often requires a support ticket).
To put it simply, OpenVZ works similarly to Docker rather than VirtualBox or VMWare and comes with similar benefits and limitations.
Nope, it's just multi-threaded and, by default, will utilize all available cores. You can configure it to run commands at startup and shutdown, though, in which case yes, it would spawn processes.
Which isn't to detract from the Caddy project which offers a tidy set of configuration options so that the lib is more like an Nginx executable with config files.
Perhaps the README can be updated though, as "Caddy binaries are available for nearly every platform and has no dependencies" is a bit misleading. The binary produced by Go may not have dependencies, but the Go code itself has a few large dependencies.
That's a good way to describe it, I was having trouble explaining that succinctly on my own! And I will update the project on GitHub to give due credit to libraries utilized.
Seriously impressed with the amount of work you've put into it... I didn't want to otherwise detract from your work, but it is a good idea to declare which 3rd party dependencies do exist just so that anyone forking it can be aware of this and ensure that they vendor it (using whatever their preferred method is).
I'd probably opt to change the phrasing to be clear that you're using these other libs, simply because they are well-proven, have a lot of mindshare, and that you're standing on the shoulders of giants and bringing it all together in an out-of-the-box server that people can immediately use is actually a great story.
I'm a little put-off by the baked-in Markdown compiler. It's partly concerning because of the many dialects of Markdown, and the various configuration options available for each one (which a server shouldn't need to support).
But also, in terms of Separation of Concerns, it doesn't seem like the server should be responsible for compilation tasks when it doesn't need to be. It would be much better to move that out into a separate tool for compiling Markdown to HTML (perhaps on-save, for authoring) - many of those already exist. Or, if you really wanted to perform compilation during a request, it could at least be moved out of the server core, into a FastCGI script (perhaps something like https://menteslibres.net/luminos/).
Oh, and that whole method of using a `Caddyfile` at the root of the project, for configuration, is quite nice.
I actually agree with you. I wonder if the Markdown middleware will turn into more of a "static site generator" anyway. There's definitely some room for change in this area of its development, so if you'd like, I'd welcome your involvement.
Great job, but I noticed that the server gets just a B rating (ssllabs) due to:
- rc4 acceptance
- Session resumption (caching) No (IDs empty)
- no OCSP stapling
- Next Protocol Negotiation (NPN) Yes, but not signalling a http/1.1 fallback
I found no settings to change the TLS configuration. Is there any way to change it?
Not yet, but that's coming. Wanted to start simple and add more controls as needed. I'm cautious about changing any of the TLS stuff, especially with Let's Encrypt coming up soon.
As a designer who's been attempting to pick up some basic ops proficiency with apache over the past month or so, this looks brilliantly simple. Thanks!
There's a problem with your "For Designers/For Bloggers" section of the page rendering in Safari. The sections should be rendering side by side, I assume, but are vertically stacked instead.
Also, if you want to convince me to switch to Caddy from Nginx, perhaps a page with succinct explanation of its advantages would be helpful?
Lastly, this is just my opinion, but I don't want my web server to have a Markdown interpreter in it. That's not a job for the web server. It's very easy to put a very simple index file in front of Markdown to provide that functionality.
So when you say Caddy supports serving Markdown as HTML, is that normal, boring Markdown only, or does it implement CommonMark (or something else entirely)?
Also, do you have any plans to make Caddy support domain proxying (or whatever it's called) where you can specify that requests for certain sites should be proxied to a service running on another host + port combination (if it doesn't support that already)?
Definitely a cool project though. I'll keep an eye on it. Keep up the excellent work!
It could be extended to support other kinds of Markdown. Feel free to open an issue and suggest it!
Caddy does have basic reverse proxy functionality. Something like what you're suggesting could be `proxy / localhost:8005` - but this middleware will need more attention.
I like the support for markdown... I wonder if other web servers are thinking of supporting or already support that feature? Does it recognize GitHub Flavored Markdown (GFM)?
I've been looking at your GFM package, looks good! It's on my roadmap for possible future integration. I also want to see support for the kind of Markdown files that Hugo serves, with front matter. So there's lots of possibilities for the Markdown middleware right now.
Not to sound ungrateful. But would it be possible to split your GFM package into its own repo? Because it's currently a PITA to vendor because it pulls half the world with it?
There are a few directives I'm used to from Nginx which seem to be absent from a quick perusal of the docs, but perhaps you can help?
Returning a non 200 or 300 redirect code.
Stripping headers
Deciding status on more than server name and path
Finally, there was discussion earlier on HN on how to write plugins which communicate via sockets... Might be an interesting addition to consider adding to your middleware API.
Not yet. But I would love to know your thoughts about how you'd like header stripping to work, as well as more information about the others; feel free to open an issue so I don't forget. :)
Looking good! I really like the list of features in your roadmap, those will be some big wins that will really set Caddy apart from other web server software.
One recommendation I would make is the addition of some simple load balancing, even round robin would be great.
Love the idea. One of my long-term goals is for Caddy to be able to connect with other instances of Caddy, both for site deployment and load balancing.
You are probably aware of this. But on Windows and Chrome, when I try to open a documentation page for "templates", it downloads a templates.gz file to my computer. It does this for 90% of the documentation pages. Very annoying, I have to cleanup a few files now :)
Other than that the documentation is really lacking. I wanted to spend time looking into the work you've done but I haven't managed to do much besides having a static file server because of the bad documentation.
I starred the project on github, hopefully it will keep getting better.
Thanks for the info. Consider that you probably won't just be able to obtain this feature from http2 for free - you probaby also want to make your Caddyfiles support some smooth configs for setting these sorts of options.
Interesting project, starring it for the future. Especially like the custom headers, gzip and simple config file. I'm curious are there similar projects like this in Python/Ruby that are more mature? With auto-reload and more production-ready documentation?
This looks like a cool project. Is it just me or has Caddy carried on the grand web server tradition of using a config file format that is sort of like, but not quite any other existing format.
Yep. A client must declare that it supports HTTP/2, otherwise the server will fall back to HTTP/1.1. Also, any plaintext HTTP connection will not be HTTP/2 (major implementations of HTTP/2 don't support plaintext).
Thanks. And not really; I've seen others (like Algernon; on GitHub) around before this one. HTTP/2 barely hit the final spec a couple months ago so I expect we'll see more mainstream support later this year.
(Incidentally, I really hope my little Digital Ocean droplet can handle the load. Wouldn't that be ironic? Anyway, if you have trouble, try the plain HTTP/1.1 site or the GitHub project page: https://github.com/mholt/caddy)