fc2ff9155c
- Expose the list of Caddy instances through caddy.Instances() - Added arbitrary storage to caddy.Instance - The cache of loaded certificates is no longer global; now scoped per-instance, meaning upon reload (like SIGUSR1) the old cert cache will be discarded entirely, whereas before, aggressively reloading config that added and removed lots of sites would cause unnecessary build-up in the cache over time. - Key certificates in the cache by their SHA-256 hash instead of by their names. This means certificates will not be duplicated in memory (within each instance), making Caddy much more memory-efficient for large-scale deployments with thousands of sites sharing certs. - Perform name-to-certificate lookups scoped per caddytls.Config instead of a single global lookup. This prevents certificates from stepping on each other when they overlap in their names. - Do not allow TLS configurations keyed by the same hostname to be different; this now throws an error. - Updated relevant tests, with a stark awareness that more tests are needed. - Change the NewContext function signature to include an *Instance. - Strongly recommend (basically require) use of caddytls.NewConfig() to create a new *caddytls.Config, to ensure pointers to the instance certificate cache are initialized properly. - Update the TLS-SNI challenge solver (even though TLS-SNI is disabled currently on the CA side). Store temporary challenge cert in instance cache, but do so directly by the ACME challenge name, not the hash. Modified the getCertificate function to check the cache directly for a name match if one isn't found otherwise. This will allow any caddytls.Config to be able to help solve a TLS-SNI challenge, with one extra side-effect that might actually be kind of interesting (and useless): clients could send a certificate's hash as the SNI and Caddy would be able to serve that certificate for the handshake. - Do not attempt to match a "default" (random) certificate when SNI is present but unrecognized; return no certificate so a TLS alert happens instead. - Store an Instance in the list of instances even while the instance is still starting up (this allows access to the cert cache for performing renewals at startup, etc). Will be removed from list again if instance startup fails. - Laid groundwork for ACMEv2 and Let's Encrypt wildcard support. Server type plugins will need to be updated slightly to accommodate minor adjustments to their API (like passing in an Instance). This commit includes the changes for the HTTP server. Certain Caddyfile configurations might error out with this change, if they configured different TLS settings for the same hostname. This change trades some complexity for other complexity, but ultimately this new complexity is more correct and robust than earlier logic. Fixes #1991 Fixes #1994 Fixes #1303 |
||
|---|---|---|
| .github | ||
| caddy | ||
| caddyfile | ||
| caddyhttp | ||
| caddytls | ||
| dist | ||
| onevent | ||
| startupshutdown | ||
| vendor | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| appveyor.yml | ||
| assets.go | ||
| assets_test.go | ||
| caddy.go | ||
| caddy_test.go | ||
| commands.go | ||
| commands_test.go | ||
| controller.go | ||
| LICENSE.txt | ||
| plugins.go | ||
| README.md | ||
| rlimit_nonposix.go | ||
| rlimit_posix.go | ||
| sigtrap.go | ||
| sigtrap_nonposix.go | ||
| sigtrap_posix.go | ||
| upgrade.go | ||
Every Site on HTTPS
Caddy is a general-purpose HTTP/2 web server that serves HTTPS by default.
Download · Documentation · Community
Caddy is fast, easy to use, and makes you more productive.
Available for Windows, Mac, Linux, BSD, Solaris, and Android.
Menu
Features
- Easy configuration with the Caddyfile
- Automatic HTTPS on by default (via Let's Encrypt)
- HTTP/2 by default
- Virtual hosting so multiple sites just work
- Experimental QUIC support for those that like speed
- TLS session ticket key rotation for more secure connections
- Extensible with plugins because a convenient web server is a helpful one
- Runs anywhere with no external dependencies (not even libc)
There's way more, too! See all features built into Caddy. On top of all those, Caddy does even more with plugins: choose which plugins you want at download.
Install
Caddy binaries have no dependencies and are available for every platform. Get Caddy any one of these ways:
- Download page allows you to customize your build in the browser
- Latest release for pre-built, vanilla binaries
Build
To build from source you need Git and Go (1.8 or newer). Follow these instruction for fast building:
- Get source
go get github.com/mholt/caddy/caddyand then rungo get github.com/caddyserver/builds - Now
cdto$GOPATH/src/github.com/mholt/caddy/caddyand rungo run build.go
Then make sure the caddy binary is in your PATH.
Quick Start
To serve static files from the current working directory, run:
caddy
Caddy's default port is 2015, so open your browser to http://localhost:2015.
Go from 0 to HTTPS in 5 seconds
If the caddy binary has permission to bind to low ports and your domain name's DNS records point to the machine you're on:
caddy -host example.com
This command serves static files from the current directory over HTTPS. Certificates are automatically obtained and renewed for you!
Customizing your site
To customize how your site is served, create a file named Caddyfile by your site and paste this into it:
localhost
push
browse
websocket /echo cat
ext .html
log /var/log/access.log
proxy /api 127.0.0.1:7005
header /api Access-Control-Allow-Origin *
When you run caddy in that directory, it will automatically find and use that Caddyfile.
This simple file enables server push (via Link headers), allows directory browsing (for folders without an index file), hosts a WebSocket echo server at /echo, serves clean URLs, logs requests to an access log, proxies all API requests to a backend on port 7005, and adds the coveted Access-Control-Allow-Origin: * header for all responses from the API.
Wow! Caddy can do a lot with just a few lines.
Doing more with Caddy
To host multiple sites and do more with the Caddyfile, please see the Caddyfile tutorial.
Sites with qualifying hostnames are served over HTTPS by default.
Caddy has a command line interface. Run caddy -h to view basic help or see the CLI documentation for details.
Running in Production
Caddy is production-ready if you find it to be a good fit for your site and workflow.
Running as root: We advise against this. You can still listen on ports < 1024 on Linux using setcap like so: sudo setcap cap_net_bind_service=+ep ./caddy
The Caddy project does not officially maintain any system-specific integrations nor suggest how to administer your own system. But your download file includes unofficial resources contributed by the community that you may find helpful for running Caddy in production.
How you choose to run Caddy is up to you. Many users are satisfied with nohup caddy &. Others use screen. Users who need Caddy to come back up after reboots either do so in the script that caused the reboot, add a command to an init script, or configure a service with their OS.
If you have questions or concerns about Caddy' underlying crypto implementations, consult Go's crypto packages, starting with their documentation, then issues, then the code itself; as Caddy uses mainly those libraries.
Contributing
Join our forum where you can chat with other Caddy users and developers! To get familiar with the code base, try Caddy code search on Sourcegraph!
Please see our contributing guidelines for instructions. If you want to write a plugin, check out the developer wiki.
We use GitHub issues and pull requests only for discussing bug reports and the development of specific changes. We welcome all other topics on the forum!
If you want to contribute to the documentation, please submit pull requests to caddyserver/website.
Thanks for making Caddy -- and the Web -- better!
Donors
- DigitalOcean is hosting the Caddy project.
- DNSimple provides DNS services for Caddy's sites.
- DNS Spy keeps an eye on Caddy's DNS properties.
We thank them for their services. If you want to help keep Caddy free, please become a sponsor!
About the Project
Caddy was born out of the need for a "batteries-included" web server that runs anywhere and doesn't have to take its configuration with it. Caddy took inspiration from spark, nginx, lighttpd, Websocketd and Vagrant, which provides a pleasant mixture of features from each of them.
The name "Caddy": The name of the software is "Caddy", not "Caddy Server" or "CaddyServer". Please call it "Caddy" or, if you wish to clarify, "the Caddy web server". See brand guidelines.
Author on Twitter: @mholt6