Caddy HTTP/2 Web Server

Welcome back everyone. This is the changelog. I'm your host, Adam Stikoviak. This is episode one at 79.

And on today's show, Jerry went solo talking to Matt Holt and Sebastian Erhart talking about Katie, the H2 web server written and go made for everyone. And a special thanks goes out to Justin Dorfman for creating the issue and Karly Sio Campos and many others for thumbs-uping this suggested show. So thanks for your support. And if you want to suggest a show, go to our ping repo on github at the github.com slash the changelog slash ping.

You will find issues there, submit one, and add mention and develop out there on a project and we'll do our best to dig deep and hit them on the show. We have four awesome sponsors making the show possible, co-chip, top towel, emojics, and also the node. Our first sponsor is co-chip a hosted continuous delivery service focused on speed, security, and customizability. Easily set up continuous integration for your app today in just a few steps and deploy with all your test paths.

Co-chip has great support for a lot of languages, test frameworks, and notification services. They even integrate with github and bitbucket and you can deploy the cloud services or even your own servers. You guys started today with their free plan when you upgrade to a premium plan, use the code, the changelog podcast, and save 20% off any plan you choose for three months. Again, the code is the changelog podcast head to co-chip.com slash the changelog to get started and now on to the show.

All right, everybody, we are back and we are excited today. This show actually came to us by popular demand. Two of our members, Justin Dortman and Carlissia Campos, were advocating for a show on the Caddy web server. They opened up a issue in ping and didn't stop there.

I think they were tweeting about it. Many plus ones came in and we finally relented and said, man, I guess we have to have a show about Caddy. So we're excited. We're here going by Matt Holt and Sebastian Erhart.

Guys, welcome to the changelog. Thank you. Hello here. So Matt, were you surprised that you had such a group of people excited to hear all about your fledgling web server?

Yeah, it seems to excite a lot of people. And I mean, I'm glad. I'm surprised because it's a web server. It didn't seem that exciting on the surface.

Well, you know, as developers, we get excited about all sorts of things. And by the way, I'm quite excited as well as a bit of a web server nerd as well. I do geek out on these things. So I'm quite excited about Caddy had not actually even heard of it previous to them open up that issue.

And I think I even had a little bit of a back channel conversation in our members only slack room about it. And they just didn't, Carlissia, ganged up in the site. They were going to bombard our GitHub issues. So let's learn a little bit about you guys and then we'll get into Caddy and we'll find out all about it and why it's cool, why some of you folks are interested in it.

Matt, let's start with you. Can you go ahead and give a little bit of your background and just tell us who you are? Sure. So I'm currently a student at Brigham Young University and we'll be graduating here in December actually with a computer science degree.

I love getting outside hiking in the mountains. It's great bicycling down mountain road. It's really fun and programming when I'm not doing homework. So I look forward to the day when I don't have to do homework after a day of programming.

And I actually started Caddy during my hardest semester at college here. It was just earlier this year, the winter semester January through April when I was in four really intense programming, senior level programming classes. And I just had to step away from that for a while and work on a side project. So it actually brought me a lot of sanity as well.

So you were slacking, so to speak, or you were distracting yourself from all your programming tasks by starting up a web server, is that what you're saying? More or less. I mean, I did all right in classes. Well, that's good to hear.

Most people, when they want to relax, they'll watch TV or play video games, but they're also not here on the changelock. So I guess it's paying off for you. Very cool. So you're still in college, you have plans post-graduation or you're still just feeling things out?

Still feeling things out. All right. Well, maybe I'll have to catch back up with you here after a while and see what happened. Yeah.

Sebastian. Yeah. Nice to meet you. Welcome to the changelock.

Once you go ahead and introduce yourself to the listeners. All right. I'm an information technology security student. I'm from Austria and I'm going for my bachelor's degree at the moment.

I started programming when I was about nine or ten years old and doing that when I've got nothing other to do. And I got into Caddy because I was looking for a cool open source project to join. And I started off with a pretty small full request for adding something to a middleware. And then Matt asked if someone wants to do the Let's Encrypt thing for Caddy and I volunteered and well, here I am.

Just like that. Yeah. Just like that. So you were just looking for some open source to contribute to?

Yeah, right. What sparked that interest, that desire to get an open source? Well, I worked as a programmer for about three years and there is nothing really I could show up to somebody who asked me what have you done with your life? So I figured trying an open source project to have something to show off.

Yeah. Good reason to do open source right out there. In the open, people can see your technical jobs. Matt, same question.

So, you know, I'd be while you're doing computer science things. When were you first exposed to open source software and what got you interested and involved? I think I started doing open source in 2011. It's about my sophomore year of college.

And I don't know. I think I just started writing code and putting it up on GitHub and then I realized that coding could be a very social thing to do. And I really like that because I grew up on a farm in Iowa, kind of away from people. And it was neat to be able to work with people remotely and doing this kind of work.

And so I really enjoyed the collaboration aspect once I started putting some code out there and contributing to a few projects in little ways. It was just very satisfying. Caddy, notably, is a Go project. I'm curious, you're interested in Go and how that got started.

I picked up Go and my last job, we were looking to just swap out our .NET code base with some leaner technologies. And Go was definitely a good match. And so, I was assigned to write a new service in Go for our company. And so that was really fun.

That's how I started it. But I just, I love the language. It's very productive. It's very simple, elegant, in most ways.

It's not perfect, but I found that using it in school and my assignments, I've had kind of a competitive advantage over other students because I can crank out code, productive code, more quickly than my classmates were using Java, for example. So, your classes are just to let you pick your own language. I think when I was in school, you pretty much did what they told you to do. Yeah, in the senior level classes, a lot of it is kind of to you.

That's awesome. Yeah. Sebastian, how about yourself? You have been doing Go for long?

Well, on and off for a few years, but as the major language to write code in, it's about since April this year. I followed the Go development since its initial release, but I just got really into it this year. Very cool. All right.

Well, let's get to the heart of the matter here, which is the Caddy web servers. So from the homepage, it says that Caddy is a lightweight, general purpose web server for Windows, Mac, Linux, BSD, and Android, which caught my eye. It is a capable alternative to other popular and easy to use web servers. Now Matt, I went back and I saw on your Twitter, you have a pinned tweet, which was your announcement of Caddy back in April.

And in that tweet, it says a capable alternative to Nginx or Apache. It seems like you've slightly altered your language there. Yeah, I figured it wasn't a good idea after I didn't actually expect it to get much attention. But I figured once it did, I probably shouldn't call out other products, my name.

They're actually great. Yeah. So they're actually great. I'm an Nginx fan myself, but I just wanted to make it more generic.

Yeah, so I'm also an Nginx fan and I've cut my teeth on Apache back in the day, got more than just teeth probably. We all have been there and very thankful for the Apache project. It's served many web pages over the years and done so badly, but also an Nginx fan. And curious, you know, this seems like an audacious project, even more audacious perhaps when you first launched it when you're like, I'm here to take on Nginx and Apache.

Now you've kind of sent it down from that a little bit. And I'm just wondering, you know, what, what, what, what, what got India when it's like, I'm going to write a web server. I think the, you know, I make a lot of little websites, either for myself or for software projects or for the people of your school. And I just needed a quick way to get a production capable web server up and running really quickly and easily.

And then genetics is pretty good. It just makes it can be a little tricky to configure sometimes. I don't know if you've ever had those half day projects where you set up your web server. And that's like all you do.

It can be hard to get it just right. And so I just wanted to kind of whip up something that I don't know if you've ever tried setting up like Nginx or FASCGI application for like a PHP site. Not the worst thing. Yeah.

Indeed. Yeah. Nginx is much better as a more pure reverse proxy. It seems like the FASCGI stuff.

I mean, there's, there's just more hoops to jump through with that particular setup. So whenever you have a situation or I've had a situation where I have perhaps the same server that's serving a Rails application and like a WordPress install or something like that for the blog section. And yeah, the WordPress side with Nginx, it's gotten better, but historically has been a bit of a pain to get set up. Yeah.

And so what I noticed is that a lot of my sites that use, for example, PHP back in the day, when I was a big PHP fan, I used the PHP mostly for simple things that were kind of like my new show that I kind of wish my web server would just take care of. But I just need a little dynamic element. But I feel like it was a pretty common use case. And then there were other complications, like again, Googling how to set up FASCGI with Nginx and PHP.

All the tutorials are different, it's a bunch of security, what we do is that you need to worry about. And I just didn't want to go there. But so I'm like, you know, I'll just write a web server and go. Go seems like a great language for this.

I'll just write something that's simple and I can just type in the name of the server on the command line and enter and bam, it just kind of works. And another thing that I really wanted, I wanted my configuration file, my website config to live with my website, not with my web server. So why do you want that? You know, because I just like to see the end of the directory where the site is, and then just run the web server from there, and then it'll just pick up the config file in the present routine directory.

It's found that so much more convenient than having to go over to a system folder or a central folder for the web server, and then change some config files there and worrying about including and ordering as well. Yeah, well, maybe getting ahead of us a little bit, but Caddy does support virtual hosts. So in that case, you know, you have multiple websites under the same host and that situation is it run from a Etsy directory or from some sort of common configuration directory. I mean, you can you can specify from the command line where you want to get the configuration file from.

But by default, it just pulls the Caddy file from the current directory. So it's just very convenient options. People love options. Of course, options lead to configurations and yeah, always love configurations.

Let's talk about your audience. You mentioned you make a lot of small, you know, somewhat, statics, somewhat dynamic sites. Who's Caddy built for? Is it built just for Matt Holt or other other audiences of mine?

It was built for me. That might mean it's pretty well. And then people start opening issues and they're figuring, well, it's a better get to work. And so I think that Caddy is really well suited for people who don't want to.

Well, there's sort of it's definitely suited for people who run lightweight, small websites. And you can use Caddy in production, not saying that it's perfect, but you can use it in production. If you have kind of a complex site or a site that runs on some dynamic platform like Rails or Django or something, it might be a little trickier to configure it. But you know, we're working on that.

My main focus right now is static websites and really bringing the power of the Go standard library out in making the web server do what you need it to do without having to make a dynamic website, if that makes sense. So if you can get away with a static website that just has a few dynamic functions that you need, maybe Caddy's a good fit for you. If you have like this really like dynamic and kind of heavy website going on, then you know, stick with that. If you're serving, you know, 100,000 requests a second, like definitely stick with something very, very high performing.

But Caddy, Caddy's pretty good. It's pretty competitive for most things, I think. You said bringing out the power of the Go standard library. Can you give me a, for instance, or an example of what exactly do you mean by that?

So, yeah, so EngineX and Apache, for example, I'm used to server-side includes. So if I want to make a static site, but I don't want to have to keep repeating the footer on all of these HTML pages, then I just do a little server-side include and the web server will kind of pull these pages in and serve them statically. Caddy can do this too, but it uses Go's template library, which is actually really powerful. And you can do some really cool stuff.

And it just parses the whole HTML file as a template. And so anything that goes template library, you can, let's you do, you can do with your HTML file without having to make a dynamic site, kind of. Okay. So it's akin to having a static site generator kind of built into the web server.

And if, yeah. Interesting. So it's built from that halt. It's built for people who have pretty simple sites that are, have a little bit of, you know, magic going on, but not too much.

It also seems like it's built for cross-platform as many things in Go, take advantage of that universal binary or that ability to compile cross-platform. Yeah. That's actually a good point. Ever tried setting up a web server, like a production web server, other than, you know, on Windows, like, IMS.

It can be a little weird. Yeah, it can be a little weird. Because these web servers are made for Linux, basically, Unix systems. But yeah, Caddy, like, first class support for Windows kind of thing.

So if you need to use Windows or, you know, Caddy's great too, for, we're not just targeting technical people here, but like designers and writers who just use Windows, that's the environment they feel comfortable in. They can use Caddy. It's a great fit for them. They don't have to learn the technical ins and outs of, like, a real hardcore web server.

Very cool. One thing I mentioned at the top of the show was that it promotes its Android support there. Can you speak to that, how that works and what that's all about? Yeah.

So Go Compile to Android. And actually recently it's Compile's way to iOS, which is kind of cool. But if you download the Caddy build for ARM Linux, you can sideload it onto your Android device and actually run it there. And that's kind of fun because you can have a folder with files that you want to share with your local AI network from your phone.

You can do that now. It's kind of a, it's kind of a cutting edge way to do it. Like this is not a refined feature or, you know, use case yet, but it can be done. Very cool.

That sounds like a place for a break. When we get back, we're going to talk about configuration as it seems like that was an area that you focused on quite a bit is getting that user experience just right. We'll take a break here from our sponsors. And on the other side of the break, we will talk about Caddy files.

We'll be right back. Say hello to top towel designers. Our friends at top towel have done something really, really awesome. They've expanded into a new market.

They're talking designers. Top towel has been known as a thriving network of some of the best software developers and engineers out there, many of the developers in their network, no extremely talented designers. And they've always had this sort of informal relationship with designer involvement in top town. They've done a little bit, you know, but it hasn't been an exact, you know, product, so to speak, or internal model.

And so they've expanded and they've evolved today. They're extremely excited to announce the official launch of top towel designers. What this means now is the same experience that you've had on both sides of the fence, whether you're someone that's looking for really awesome designers, or you're a really awesome designer looking for really awesome opportunities. This is the place for you, not only if you're engineers, but also if you're designers out there as well.

So designers, listen up. It is time to go check out top time.com slash designers. That's t-o-p-t-a-l dot com slash designers and telling the change all sent you. All right, we are back speaking with Matt Holt and Sebastian Erhart about the Caddy web server and HTTP to web server.

But before we get into the feature set, let's talk about configuration. That's where most people who are dealing with web servers live, sometimes die. You have a caddy file. So when I first saw this, I thought, oh, no, another file file.

Seems like this thing file, file naming convention meme continues to propagate. I'm not going to hold against you too much. But we got gem files and proc files and now caddy files, and there's all these file files. Just, we don't have to hang out here all day, but maybe just speak on where that inspiration came from.

You like that format? Yeah, I mean, as far as the name, caddy file, it just seemed to kind of flow off the time. But the idea for an actual configuration file is, in a way, it's actually kind of a stop-gap. But a configuration file is, and I'll get to that second, but an actual configuration file is kind of the standard.

It's the normal way to configure a web server. You make a file, you put some directives in there that tell a web server what to do. And then when you run the web server, it just loads a file and configures itself in memory and off, you know, on its way. And that was just really easy.

And I just wanted a configuration that can persist with my website. So I have my website folder, and then I have a caddy file in that folder, and I can just run caddy from there. And it'll read the contents of the file consistently every time on any platform, and pretty much every environment. And it'll work the same way.

And this config file, though, is not actually the end goal here. I don't intend for caddy to only be configurable via a file. Do tell us more. So in the future, and there's a roadmap here, but in the future, I do intend to write an API so that you can actually dynamically set up caddy while it's running and change its configuration while it's running without having to rely on just a file and file system.

So any, you know, give us a launch date, Christmas 2015, right? I wish. No, I don't know the date yet. I've actually started kind of stepping out an API on a branch, and you can try it.

It's a little racy, and it's a little clunky. So I think I need to redesign some things, but it will happen. I definitely want it to envision a nice web frontend for people to just open in the browser and be able to configure the server from there with this nice GUI and having maybe stats and monitoring built-in one day. You think what?

Yeah, I wasn't expecting an actual date. This is just an old hobby of mine, which is I asked developers to commit to a ship date, and I watched them recoil. Oh, it's nice of you. Oh, yeah, got to stay entertained somehow.

Very cool. So let's talk about the caddy file itself. The syntax inspiration, does it come up with your brand new, your own thing, is inspired by something. It looks like it's pretty simple.

You have some directives, but they're they're just like bare like keywords like you type in, I like this one browse, for instance, and then you give a path and that's like setting up directory indexes for a specific, I'm assuming, subfolder of your of your system there. Where was the inspiration for your syntax of the caddy file? The inspiration is me wanting not to type very much and not having to be very like clumsy with my typing. So not much punctuation.

I didn't want to think about syntax really. I just kind of wanted to flow. So when I got to set up a web server, what's the first thing I am thinking of? Well, probably the website address, the URL, the domain name.

So type that in. That's always the top of the caddy file. Enter a couple of times and then, okay, I want to serve clean URLs for HTML files, so vxt and then dot HTML. So it'll automatically serve HTML files without needing a dot HTML in the URL.

Then let's see. I want to be able to share files in my photos directory because I have this album of pictures. So then I do browse and then slash photos. You don't have to think about curly braces and colons and quotation marks typically in the caddy file, which is really nice.

Yeah. I think a recent trend with configuration files as well, we'll just type it out in Jason because we all love that format and it seems like that is more focused on implementation because it's really easy just to suck in the string of Jason and parse it. I'm sure Go has a built-in Jason parsing in the library. So you had to write your own parser for this or how's it going to go by?

Yep, it's a home brewed parser and I've actually gotten a little bit of flack for creating and yet another configuration syntax. This one's very specific to this use case though. This is not a general-purpose config syntax. It meets some needs that Jason doesn't, for example, using arrays as keys.

Ultimately, you have a set of server blocks in a caddy file where each server block configures one or more hosts. So instead of having to set up a host as a key and then have it point to some configuration because following pointers is confusing and you have to teach people about that and I just didn't want to go there. So just specify multiple hosts as a key and then they all share that same configuration is one example. So yes, I know that Jason's serialization and deserialization is very easy but I wanted to focus on the user here.

This is about the experience. I want to make it easy for people to create for the web and make the web better that way, more accessible. I'm all for that. So the aspect of this you have of the caddy file is placeholders.

I think that's part of the caddy file. Can you explain what placeholders are and what they're good for? Yeah, they're just little strings enclosing curly braces. This is one rare case where you would use a curly braces or punctuation but it just fills in a value specific to the request or the response usually.

So let's say that you're setting up your log directive. You can say log and then you can specify the file name and you can specify a format, a custom format if you wish. In that format you would use placeholders because you don't know the request time for all the requests and you can't hard code the method in the URL. So these are kind of like dynamic replaceable values.

They give you access to various things like the URL of the request and the time of the request or the response body link and stuff like that. Yeah, headers, host body method, so on and so forth. Pretty much anything that you pull out of a request, you can use it and key on that and basically modify your configuration based on that, correct? Yeah, kind of like a variable in an engine, engine, engine, engine, whatever, but not scriptable.

I don't want to go scriptable route. Why not? You know, as much fun as it is, it's kind of a can of worms. It's like a rabbit hole.

Well, I think it's kind of a fine line because what you have here is you have some you have some dynamicism, right? You have templating for your server site includes, you have you're like almost in a full on program environment, right? Like, you're almost there. And then it's like, where do you draw that line?

So where do you draw that line? It's a good question. Drawing the line at giving you just enough power to be dangerous, but not enough to kind of hang yourself. Not enough where the learning curve is beyond what someone who doesn't know how to program can do, not enough to the point where you have to like get super frustrated at things.

So I feel like if you're using it and something's not obvious, there's either debugging the documentation or in the implementation and that needs to be fixed. So if O'Reilly calls you to write a book about it, then you've probably taken it too far in this case. Right? Come write a book about how to program the Caddy web server.

Oh, yeah. At that point, you'll be like, oh, man, I think I went too far, but I got a book deal. Exactly. One post?

Okay. But yeah, you shouldn't have to script Caddy. I think that's a little far. Taking a little far.

I guess some of the features, playing the Caddy file, of course, because you're going to be enabling or disabling features. Your headline feature, of course, is H2 support out of the box. Maybe Sebastian, why don't you explain H2 support in Caddy and how it works and all that stuff? Well, we use a library.

So we didn't actually implement it ourselves, but we use Go library for it. But it was a beauty of open source, right? Yeah, it's open source. It's not good how I think.

It's supposed to be the better version of HTTP, but not everyone agrees on that, me neither. Oh, really? Yeah. Well, now we're getting interesting.

Tell us more. Why do you know that? Oh, Matt, dissension. You have dissension.

We really want to go down the rabbit hole. I kind of do. It sounds like you kind of don't. So let's just let me add.

You can turn off HTTP to if you want with Caddy. No, I don't. I don't. I don't.

In principle have a problem with it being there. Just it could have turned out way better than it has. I see. So it's just the lack.

It could have been better. Yeah. All right. Not that it's bad.

Just bad. It's not bad. It's just some features which got in and some features which didn't. Well, it could have been better.

We'll see. H2 should be much easier to improve upon than H1 was. Yeah, of course. Yeah.

With time. Yeah. And if you are interested in H2, the niggory details of the protocol, go back to changelog.com slash 161 with Ilya Grigrick. We did a kind of a comprehensive overview of all of its features, pipeline, multiplexing, hpack, all the things that H2 has.

And we will not talk about those today because we talked about them in detail there. And as you guys mentioned, the beauty of open source is that you're building on top of other people's work. And in this case, you guys got to use I think it was Brad Fitz's H2 library. Yeah.

And that's an awesome thing because now, you know, so many people get the benefit of it who are using Caddy without having to know those intimate details. So nothing wrong with that. Great. And actually, the Brad Fitz H2 library just got moved into the Go standard library on tip and is enabled by default now.

Now, obviously, Caddy is not using Go-Tip, but it will come soon enough. It will have full H2 to be to support. Whereas up to this point, it's been kind of experimental, but pretty soon, it will be a full production ready H2 to be to library. What's Go-Tip?

Is that like a master branch of the development or? Yeah, basically. Okay. Okay.

So you have H2, you can turn it off. It's on by default. Of course, it's only for clients, I assume, the support HTTPS or TLS. You also have some other things, IPV6, Markdown, we can talk about that a little bit, WebSockets, Virtual Hosts, as we mentioned before, server name indicators and extensions.

Why don't you pick your favorite of those, Mark? And we'll, I read Markdown and then just pronounce name Mark. And we'll talk about that. What's the most exciting thing beyond H2?

That's not, let's agree. I'm a huge fan of SNI server name indication, which is a TLS extension. And this is pretty standard. Like this is not a mind-blowing feature, but it's so convenient and important because now with the same socket, you can serve multiple host names that are over secure channel.

So that's a really important thing. In fact, Caddy's virtual host feature, which allows you to set up multiple sites in the same Caddy file and serve them from the same port, would not work for HTTPS sites without SNI. So that's pretty cool. So the big one there is, and correct if I'm wrong, is that if you're hosting a series of websites, perhaps on a digital ocean, VPS, you do not need a new static IP address for each of those hosts.

And you can secure those channels on even the same exact port, just with a single IP address and port combination. You have all these different HTTPS hosts. Love that. I think that is, like you said, that's not like a unique feature of Caddy, but definitely awesome to see it there.

It also doesn't work on Windows XP, which is finally, I guess, starting to become not too much of an issue. I know that was a blocker for some people. Yeah, that's pretty old now. It is.

It isn't still out there, unfortunately. I don't mind pushing the envelope a little bit. I think people need to upgrade. I absolutely agree.

I think there's, you know, your mileage may vary. There are certain people who are still supporting IE and whatnot, and some people on XP. So in those cases, yes, unfortunate soles. In those cases, they can't use SNI, but I think, especially if you're building a modern web server for the modern web course, you got to have that.

I think one of the other little technical features I want to point out to is that Caddy is a multi-core server. And so it's multi-threaded in the sense that it will spin up new go routines or lightweight threads per request. So it's very fast and efficient that way. It has a different model than, for example, which is multi-process.

But Caddy can utilize all the cores, just kind of like in GenX can, except that it doesn't have to rely on the operating system scheduler because the go scheduler actually understands go code and can make more intelligent scheduling decisions, which is really cool for high performance sites. And that's all on my default and just kind of works. Let's talk about extensions. Extension seems like an interesting one.

As you browse the docs and you're looking at the different directives, there's a handful of them that are marked as add-ons, such as the CMS support, Git, IP filtering, search. And as you click on those, it seems like these are using your extension feature. Can you speak about that? Sure.

Anyone can write an extension for Caddy. You can choose to publish it on the website like some of these are here or just use it internally. But basically the idea is we don't want Caddy's code base to grow too large and become a mealy and have a lot of craft that would kind of defeat the lightweight aspect of it, which really is a feature. It's easier to maintain.

So these add-ons is how we decided to deal with this because some people, including me, like for example, I wanted a built-in site search. We wanted to set up and maintain some other search infrastructure or use an external search service, which can get a little dicey. So what better way to do it than to have it written and go built into the web server having key access to the config as needed to the web server's internal configuration and to be able to generate an index of your site and then have it searchable. And so these are all built by, yeah, there's the Git add-on, for example, built by Ambiola, he built this Git add-on where you can deploy your site with Git push and your web server will automatically pull in the new changes.

Super convenient things that aren't making the code base unmanageable, but you can just check them when you download Caddy and it will do a custom build for you and you can use those. So how do those get into their ecosystem? Do they have to come in, you know, send you an email and say, hey Matt, throw me up on your website. What's the situation there?

It's just a pull request system. Just kind of open, it's pretty casual. You open an issue and say, I'm gonna work on this and then you can do that and there's some docs that kind of show you how to get started and a little template and then it's not too bad. And then you just submit a pull request to register your add-on in the build server repository and once we merge that in, deploy the new build server, then there you go.

Then you need to submit some documentation for the website. I think the search add-on is really rad. It's definitely something that comes up all the time with static sites is you just want to add a little bit of a search function on there and you either have to do like the Google insight search, which is wonky, or use a third party. I think on my website I use, I don't know, I'm forgetting their names, I'm gonna give them a shout out.

I don't know, a third party who provides, you know, the index or site and provide a search API that you can query with JavaScript, but having that build right in, that's pretty handy. Cool. Yeah, and it's a really good way to give some go libraries and exposure. The search add-on built by Pedro Nasser lets you use the bloody library which is written and go.

And yeah, so it's really, really nice. All right, anything else as far as the major features, we know there's one coming down the pipeline. Well, let's touch on Markdown. It seems like it kind of stands out a little bit.

It's like, well, you know, we support IPv6 and we support Markdown. It's like completely different things. What was the logic behind supporting Markdown as kind of a first class citizen? The fact that some people hate touching HTML and just left to write web pages in Markdown.

So with this, or with this, it's actually not an add-on. It's built into the core. You can serve Markdown files and they'll render HTML on the fly or you can pre-generate the HTML. Does this scratch any specific yet you had or was this thinking of more general users?

More general users initially, but I find myself using it more and more because you can specify an HTML template and still serve a really nice, authentic HTML pages using just Markdown. And then, of course, we have this Hugo add-on with Caddy. So you can actually, Hugo is a static site generator written and go. It's really popular.

And so that kind of does something similar. Markdown is just kind of a more very simplified, lightweight version. Very cool. Well, I think we've hit up against our next sponsored break.

So let's stop here. Take a break. On the other side, we will talk about Let's Encrypt, which is very exciting to me, and apparently to you all as a future awesome feature Caddy. We'll talk about that on the other side of the break.

ImageX is a real-time image processing proxy in CDN. And let me tell you, this is way more than image magic running on EC2. This is way better. It's everything your friend and developers have dreamt of output the PNG, JPEG, GIF, JPEG 2000, and several other formats.

And if you're like me, you've ever argued with your boss or a teammate about serving read the images to non-read devices, you'll appreciate their open-source dependency-free JavaScript library that allows you to easily use the ImageX API to make your image responsive to any device. Now, all this takes a platform, and the ImageX platform is built on three core values, flexibility and quality, performance, and affordability. When it comes to flexibility and quality, ImageX has over 90 URL parameters that you can mix and match to provide an unlimited amount of transformation that you need for your images. And they take quality very seriously.

And because of their commitment to quality, several top 1000 websites in the world trust them to serve their images. Now, when it comes to performance, ImageX operates out of data centers filled with top-of-the-line Mac Pros and Mac minis, and they're set up for a completely streaming solution. This means your images never hit the disc. Images are served by the best SSD-based CDN for delivery around the world anywhere extremely fast.

And while we're talking about speed, almost all the image processing happens on GPUs. This means transformations are super fast when compared to competing virtualized environments. And lastly, it's all about affordability. Everyone wants to save a buck.

That's how the world works. Because ImageX processes close to a billion with a B images per day, they're able to make certain optimizations at scale and pass those savings on to you. To learn more about ImageX and what they're all about, head to ingix.com slash changelog. Once again, ingix.com slash changelog.

Until then, Adam, for the changelog sent you. All right, we are back. And yes, I found out who's providing my site search. I think that's the kind of thing that you just know.

But they've been just quietly serving me for a year. So I will give them a shout out SwiftType, SwiftType.com. They will index your static site and provide a nice easy API for you to add search to your site. Unless you're so lucky to be using Caddy, at which point you have that built right in there as an add-on.

So moving on, let's talk about something that's coming down the pipeline, currently being worked on, which I'm excited about, which is let's encrypt support. Sebastian, can you first start off by telling us what let's encrypt is, and then we'll go into how that works into Caddy. Yeah, sure. So let's encrypt is a new thing where you can get value SSL certificates for your servers fully automatically without really going to a CA and throwing money on its throat to get your certificate.

They offer basic SSL certificates on no extended validation or something. But for the normal user, it's better. It's the best thing that could happen, in my opinion. Yeah, they're free, right?

Yeah, they're free SSL certs. Yup, free and valid. Free and valid. The green symbol in your browser.

I'm super excited about it. I think it's been something that EFF that's doing this. I can't remember who else involved with it's Let's Encrypt dot org. But it seems like they have had like, it's coming, it's coming, it's coming, and we're all sitting here waiting to save some money and get all of our sites on HTTPS, even the ones that right now it's like, it's my personal site, I really want to spend the next dollars a year to encrypt it.

Is it going to come? Is it going to come, or is it just going to keep coming? Yeah, so the last thing I've heard is that they went to launch officially mid-November. So it definitely is coming.

That's why we started to get pressure on for getting Let's Encrypt integrated into Caddy. So let's, we'll go into how that works. But first, let's talk about the perfect end user experience. Like when it's totally done, and I'm a Caddy user, tell me how it will work.

Like I just flip a switch and I'm encrypted, tell me how it will work. Yeah, you put your site into your Caddy file, get carry up, and there you go, you're our SSL encrypted without anything. Just shut up and take my money. You can't do that.

Well, figure out a way. You got a donate button because that's going to be amazing for a lot of people. I mean, I think, you know, SSL, but we talk about the free aspect of it, and that's part of it. But just the pain and the technical drudgery of setting up a certificate overall for years has been too much of a high bar for many people who otherwise would be happy to just flip that switch.

So this is going to be awesome. Maybe talk about the where you've been so far, where you're going with it, and give us some of the technical details of how this works. You sure? Well, I started a few months ago to implement it in Go because we wanted it in Caddy, and we just wanted it to be native in Go.

So we decided to write a new library in Go to handle it, the command line utility, which comes from the let's encrypt guys is in Python, and we can't really interface in a good and meaningful way with Python code from Go. So we thought it's a good idea to write our own. So had they published an API that you're coding against? Yeah, they published an RFC for their so-called ECME spec, ACME, automatic certificate management environment.

They are now at draft number four. I think I started at the initial draft, and there were a few changes all the course of the month. First, I started integrating it, writing it quite fast, and that's stopped a bit after the first two changes because I wanted to wait a bit until it gets more stable with the API. But basically the API for let's encrypt is a JSON API.

It operates with JSON web keys, JWK and TWS, JSON web signing. The technical details are that you, as a user, create a private key for yourself, and you tie the to an account on the script server. So you register with your email address, for instance, and that's private key, and from there on, you can request certificates with your private key. Of course, that's pretty insecure, so you have, of course, you have to somehow prove that the domain you want this certificate for is indeed yours.

And that's handled by a few challenges, where you have to fulfill certain tasks given by the server, in order to authenticate the domain that it's really yours. Is that clear what I'm talking about? Yeah, so these are things like about a file, or set a header, or a method in here. The easiest challenge is the so-called simple HTTP challenge.

So you tell the server, hey, I want to certificate for the domain example.com. And the server sends you back a token, which it expects you to serve at a certain URL path on that domain. And it will resolve the IP address of the server, and look if it's really there, if it's really there, then you pass this challenge. And that's it.

You got to do it. You got to challenge. Oh, well, it depends. As with many things in IT, it depends.

Usually, if you can fulfill the challenge without any problems, then yes, this was it. You just have to ask for the certificates and to get the certificates to download. But if for some reason this challenge does not work out for you, there are other challenges to do, and they are just coming in pairs. So the server decides what it wants to see from you.

You're not the one deciding what you want to show the server. So how does the Go library and then Caddy there after know who I am, and who my lesson script account is? Do I have to set that in config or something like that? Well, we generate a config for the user.

So we have to get somehow the email address, for example, from the user. We haven't exactly worked out how we want to tie this into the user experience. But yes, we save a configuration file along with certain other things we need to interface with that script in a folder that's not Caddy, I think, or Matt? Yeah, there will be a .Caddy folder in the file system.

In this folder, there will be other subfolders per certificate and per user and also per host. So you can peek in there and copy stuff around, but actually it's all managed for you. That's the goal. Yeah, I was working on that this morning.

That's going to be fun. Yeah, you guys are moving along. Are you stuck? Tell us how it's going.

Well, I think it's going along well. I'm not stuck. Sebastian understands the ins and outs of the protocol spec pretty well. I'm just using his library now in Caddy on a private branch still.

It's pretty early days, but I have been able to successfully generate a new certificate at startup from a local folder. CABolders, the name of the lesson crypt certificate authority server. So in a purely test environment on my local machine, I have been able to get a certificate in a private key and then serve a site using that. So definitely making progress.

The rest of this is going to have to focus now on the user experience, making sure that it's as unobtrusive as possible, and managing the certificates and keys and taking care of renewals when the time is right. Yeah, have you guys even thought about renewals? Yeah, I mean, obviously thought about it. You just mentioned it, but I hadn't.

How's that going to work? Every certificate which is issued by that's encrypts. CA gets its unique URL on the server, so you can issue a simple get request which is signed by either your private key or the private key which was used to create the site certificate and to either get a renewed certificate back from the server, or you have to create an entirely new certificate. So that's the renewal story.

And as far as the Caddy integration of that, I have some ideas still kicking around the details about renewals. It will be automatic. It will be transparent to the user. It will involve probably a graceful restart of the server when renewal happens to plug in the new certificate.

But again, we expect it to be fully managed on by default. So I think all the pain, thanks to Let's Encrypt and Sebastian's work, I think all the pain of dealing with SSL certificates will finally be gone. Yeah, I think that's the kind of feature that will set Caddy apart, and hopefully other web servers and other software packages will start to integrate, because it's a huge thing. And I actually, I misspoke, I said, is it an EFF thing?

And I just want to clarify, Let's Encrypt is put on by the Internet Security Research Group, which is a California Public Benefit Corporation, and it's sponsored by the EFF and other major sponsors like Mozilla, Akamais, Cisco, and a few others automatic of WordPress. So it's a community effort with a lot of companies pouring resources into it. And I think it's hopefully arriving quarter for 2050. I remember when this said arriving summer 2015.

So I'm sure there's a lot of moving parts is even just integrating for you guys. There's a lot of moving parts, but hopefully it all comes together. And you guys, your goal, I suppose, would be you guys going to be ready to go, you know, kind of day one, November, or what your integration roadmap look like, time-wise. Well, I can speak for the Caddy integration, probably not before their launch date.

We don't expect any major changes to their protocol as far as underlying library goes. But regardless of that, I want to make sure that the management of the certificates is working well. So probably shortly after their launch, you'll probably have like a special download that you can do of Caddy or a special build that has Let's Encrypt. And so a few people can try it voluntarily without just kind of forcing it on everyone, all of a sudden.

Because it might be kind of jarring to some, because again, HTTPS by default, there's a lot of considerations. We redirect the plain text to the HTTP S and just making sure everything goes smoothly. We're going to work really hard for that. So hopefully, shortly after the launch.

So that's definitely a headline feature that is upcoming, of course, H2, requiring that encrypted connection. This allows lots of folks to easily get that optimized HTTP connection instead of having to fall back to H1. So let's take our final sponsor break. And when we come back, we will wrap up the conversation talking more about Caddy's roadmap, future features that you're interested in building and are currently building.

And then finally, how people can get started using Caddy and our closing questions. So we'll be right back after this break. We're excited about our new sponsorship with Leno. They're huge fans of the show and are excited to support what we're doing here.

And they will invite every single listener to try out one of the fastest, most efficient SSD cloud servers on the market, get a Leno cloud server up and running in seconds with your choice of Linux distro, resources, and node location. They've got eight data centers spread all across the world, North America, Europe, and Asia Pacific. Plans started just 10 hours a month with hourly billing and a monthly cap on all plans and add on services like backups, node bouncers, long view, and even Leno managed. And for those who were already familiar with Leno, they recently switched from Zen to KVM.

And the latest units benchmark showed a plus 300% performance increase will drop a link in the show notes for those benchmarks for you to check out, get photo to access for more control, run VMs, run containers, or even a private get server, enjoy native SSD cloud storage, a 40 gigabit network, and Intel e5 processors, use the code changelog 10 with unlimited uses, tell your friends, it doesn't expire this year, it expires the end of next year. So use it as much as you want. Again, that code is changelog 10 head to Leno.com slash changelog and tell them the changelog sent you. All right, we're back.

We've learned a lot about Caddy, what it's good for, what it might not be so good for, we've learned about letting crypt and the built in, flip a switch, get your site encrypted feature that is coming to a Caddy near you. Matt, what else is coming to Caddy down the road? Well, like I referenced earlier, I really wanted to make an API so that you can just run Caddy on a server bare bones or from scratch without a configuration and then be able to say log into some web based client and manage your server remotely with a nice GUI. I think that'd be really nice and actually give access to web servers to a lot more people who don't understand even the command line and SSH or whatever.

There's a lot of potential there and it's not a unique feature. Other web servers have similar capabilities but I think that it's still necessary. So that's one. Yeah, so I also want to really work on, well, so we talked about that in crypt.

The API is not a user facing feature directly. The web based control panel would be something else and I don't know if that's going to be a third party thing or if I'm going to build one as well, but we'll see. I think we'll see what the demand is and what the audience becomes here as time goes on. Very cool.

You know, maybe one thing we should talk about briefly before we get into the getting started because I feel like it's the kind of question that many people will say, why didn't you talk about performance? I know you mentioned it briefly earlier on, but let's speak specifically to performance. I know you have a benchmark out there. Seems like a pretty basic one and you know, you have a very strong, well worded disclaimer about benchmarks.

But it doesn't seem like performance. It seems like there's two things. First of all, Go tends to be very performant, especially with its concurrency primitives. And then the other thing is you didn't seem like performance was one of your goals, right?

It was user experience. It was easy to use these things, modern feature sets. But where does it stand and what can you say about Caddy as far as its performance abilities? So it looks, so right now Caddy performs using a bare-bones configuration to, compared to default configurations of a couple other popular web servers, performs competitively well.

That's the word. And so by that, it does perform in my testing, again, this is just me, as far as requests per second tends to perform better than Apache, without, again, without tuning. And almost as well as Nginx. But if you're serving 30,000 requests per second or 50,000 requests per second, maybe performance should be your primary goal and maybe you aren't just the typical average show user.

So that is to be considered. I don't want to like put performance into the rug and totally forget about it, because if I wanted to do that, then this would be a much easier project, right? Because you just throw any amount of amount of code into this project and make it do all the things that you want it to do. Right.

I'm not going to go there. Definitely performance is going to be a concern, not in a bad way, but it'll be on our minds. It's going to take a front seat, I think, but not over the user experience. It'll be a fine balance.

And it's going to go up to figure it out as we go. Yeah, one thing I might mention is something that I read that you said, which is that if there are any people who are very interested in performance and are good with those things, A, you would appreciate if they brought benchmarks, do their own testing and publish those results, and then B, if they have specifics, especially if they have gochops and know of ways of making it faster, these are things that you're wide open to. Is that fair to say? Yes, that's exactly right.

Cool. I thought that was fair because I didn't read it. I didn't make it up. I'm glad you read it.

A lot of people always ask for performance. They want to know requests per second. They want to see the numbers. They want to see memory allocations.

And you know, go to your own testing for your own use case. In mine, I found it to be very quite sufficient. And there are several sites using caddy in production, even under load. And it's fine.

Go is a pretty competent language for that. And that's, I mean, they're sitting on port 80 or port 43 in production mode, right? There's no it's exposed to the wide open internet and it's running in production. Yeah.

Very cool. Well, let's let's close up with getting started. So say I'm sold and I'm interested in using caddy for my next website, server in production, maybe with some HTTP2 going on. How do I do that?

I'd say download it for your platform, deploy it to your machine and run it. You'll need a caddy file. So when you download caddy, you just create a caddy file. Typically, it goes again in the folder where your site is.

Very easy to set up. You can read the docs on the web page about how to do that. But once you've got a caddy file there, just run caddy and it'll just start serving your site. So is there any sort of demonization or backgrounding?

I mean, I'm not going there. Y'all have to do that on your own. I admit it's true. You'll have to do that on your own.

And also don't run caddy as root. I mean, you can, but probably not a good idea, just in case. So you can use the set cap utility and Linux to give caddy permission to bind to ports lower than 1024 without having to be root. So I do that in production works pretty well.

Okay. That sounds like some opportunities to contribute at least. Maybe not into caddy core, but even a tool around caddy, some sort of wrapper that would allow it to run as a system service or in the background and manage the demonization of it. Or I mean, there's two other things in general with binary.

So maybe even just a tutorial on that would be good for folks. Yeah, I agree. There are a couple blogs about it. And actually, that's a really great opportunity for your writer, technical writer.

Writing about ways to use caddy effectively in production is a really good post that you could do and probably draw some traffic to your site. I know people are searching for it. I see it in the analytics logs, so. Oh, there you go.

Analytic log driven development. The new development there. Yes. Yes.

Search your logs. Just people wanted. All right. Well, very cool.

I'm excited. I think this is a very cool young project. What's the status? Are you out of 1.0 yet?

Are you getting close? No, working toward it. We want, I honestly want lights encrypted. I want the API to be part of it.

So it's kind of an ambitious goal, but we'll get there. And caddy is a great, can I just put a shout out to all the contributors? Yeah. Caddy is a great project as far as the community goes.

It is a young project. It just launched in April this year. So it's only a few months old, but we have contributors from all over the world. Sebastian joining us today is in Austria.

We have contributors representing every continent, all sorts of skill sets and backgrounds. And the contributions, it would not be what it is today without them. There's no way I could do it. So huge thank you.

And feel free to get involved. There are definitely many opportunities for new developers, but also experienced ones to contribute in very meaningful ways without having to commit to doing too much, if that's a concern. I can echo those sentiments just seeing the community around you that even promoted you onto the changelog. We have a lot of people on our Ping repo coming out and telling us you should have this show or that show.

We appreciate all those requests and we try to fulfill all the requests that make sense for the show and timing and whatnot. But rarely do we have such support that you got so quickly with all the plus ones to get you on. And I think that's a testament a little bit to the Go community and to the people who are genuinely excited and involved with Caddy. So that's if nothing else, a very fun thing to be involved in.