e3f2d96a5e
This commit removes _almost_ all instances of hard-coded ports 80 and 443 strings, and now allows the user to define what the HTTP and HTTPS ports are by the -http-port and -https-ports flags. (One instance of "80" is still hard-coded in tls.go because it cannot import httpserver to get access to the HTTP port variable. I don't suspect this will be a problem in practice, but one workaround would be to define an exported variable in the caddytls package and let the httpserver package set it as well as its own HTTPPort variable.) The port numbers required by the ACME challenges HTTP-01 and TLS-SNI-01 are hard-coded into the spec as ports 80 and 443 for good reasons, but the big question is whether they necessarily need to be the HTTP and HTTPS ports. Although the answer is probably no, they chose those ports for convenience and widest compatibility/deployability. So this commit also assumes that the "HTTP port" is necessarily the same port on which to serve the HTTP-01 challenge, and the "HTTPS port" is necessarily the same one on which to serve the TLS-SNI-01 challenge. In other words, changing the HTTP and HTTPS ports also changes the ports the challenges will be served on. If you change the HTTP and HTTPS ports, you are responsible for configuring your system to forward ports 80 and 443 properly. Closes #918 and closes #1293. Also related: #468. |
||
|---|---|---|
| caddy | ||
| caddyfile | ||
| caddyhttp | ||
| caddytls | ||
| dist | ||
| startupshutdown | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| appveyor.yml | ||
| assets_test.go | ||
| assets.go | ||
| caddy_test.go | ||
| caddy.go | ||
| commands_test.go | ||
| commands.go | ||
| CONTRIBUTING.md | ||
| controller.go | ||
| ISSUE_TEMPLATE | ||
| LICENSE.txt | ||
| plugins.go | ||
| README.md | ||
| rlimit_posix.go | ||
| rlimit_windows.go | ||
| sigtrap_posix.go | ||
| sigtrap_windows.go | ||
| sigtrap.go | ||
Caddy is a general-purpose web server for Windows, Mac, Linux, BSD, and
Android. It is
a capable but easier alternative to other popular web servers.
Releases ·
User Guide ·
Community
Try browsing the code on Sourcegraph!
Menu
Features
- Easy configuration with Caddyfile
- Automatic HTTPS via Let's Encrypt; Caddy
obtains and manages all cryptographic assets for you - HTTP/2 enabled by default (powered by Go standard library)
- Virtual hosting for hundreds of sites per server instance, including TLS
SNI - Experimental QUIC support for those that like speed
- TLS session ticket key rotation for more secure connections
- Brilliant extensibility so Caddy can be customized for your needs
- Runs anywhere with no external dependencies (not even libc)
Quick Start
Caddy binaries have no dependencies and are available for every platform.
Install Caddy any one of these ways:
- Download page allows you to
customize your build in the browser - Latest release for
pre-built binaries - curl getcaddy.com for auto install:
curl https://getcaddy.com | bash
Once caddy is in your PATH, you can cd to your website's folder and run
caddy to serve it. By default, Caddy serves the current directory at
localhost:2015.
To customize how your site is served, create a file named Caddyfile by your
site and paste this into it:
localhost
gzip
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 to configure itself.
This simple file enables compression, allows directory browsing (for folders
without an index file), hosts a WebSocket echo server at /echo, serves clean
URLs, logs requests to 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.
To host multiple sites and do more with the Caddyfile, please see the
Caddyfile documentation.
Note that production sites 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 as root: We advise against this. You can still listen on ports
< 1024 using setcap like so: sudo setcap cap_net_bind_service=+ep ./caddy
Running from Source
Note: You will need Go 1.8 or newer.
go get github.com/mholt/caddy/caddycdinto your website's directory- Run
caddy(assuming$GOPATH/binis in your$PATH)
Caddy's main() is in the caddy subfolder. To recompile Caddy, use
build.bash found in that folder.
Running in Production
The Caddy project does not officially maintain any system-specific
integrations, 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.
Contributing
Join our community where you can chat with
other Caddy users and developers!
Please see our contributing guidelines
and 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/caddyserver.com.
Thanks for making Caddy -- and the Web -- better!
Special thanks to
for hosting the Caddy project.
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