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.
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.
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.
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.
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.
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.
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?
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.
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!
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.
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.
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.
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. :)
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?
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).
88 comments
[ 2.8 ms ] story [ 161 ms ] thread(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)
Your docs page 404s for me every other refresh and doesn't load with any CSS. I'm guessing this is a load problem?
Edit: Managed to load it with styling this time, it looks great :)
Feel free to open an issue about it!
We do not have any locations offshore yet, however we are looking to expand and open new datacenters in the years to come.
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.
Additionally, we have 24x7 chat, ask for Jonathan! :-)
Around two years ago a SolusVM zero day allowed attackers to:
- Partially or fully wipe most VPS, many of which could not be recovered
- Gain access to the database, including plaintext root VPS passwords, first name, last name, email
Not saying DigitalOcean is a fortress or anything but it hasn't been compromised on anything like this kind of scale.
Sources:
- http://blogs.ixiacom.com/ixia-blog/the-speed-of-a-zero-day-s...
- https://clientarea.ramnode.com/announcements.php?id=183
One recommendation I would make is the addition of some simple load balancing, even round robin would be great.
Is this the first http2 server released?
There exists a native Go package to render GFM, see second from the top at https://github.com/avelino/awesome-go#text-processing.
Someone has already opened an issue about it at https://github.com/shurcooL/go/issues/19, and I'm planning to take care of it.
Edit: Oh, I guess that was you.
https://tshannon.bitbucket.org/freehold/
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!
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.
1. https://github.com/Mashape/kong/
Edit: Following the link from the homepage works, but hitting F5 or loading it without a referrer provides a 404. Weird.
https://github.com/mholt/caddy/blob/master/server/server.go
That the actual web server in use is:
https://github.com/bradfitz/http2
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.
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.
https://www.youtube.com/watch?v=yG-UaBJXZ80
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.
Thanks for the rest of your feedback. I agree that a list of advantages needs to be more available. I'm looking forward to making that soon!
With Caddy or another solution.
Nginx+ claims it does so (I didn't purchase it). HAProxy can be configured to use sticky sessions.
Looks good otherwise!
It has random load balancing, glob patterns for hosts, SSH proxying (like sslh) and, most importantly, proxying to UNIX sockets. And less code.
Maybe you could use my code to implement some of these features :-)
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.
[1] https://caddyserver.com/docs/faq