caddyserver/caddyPublic

Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS

AI summary: Fast, multi-platform HTTP/1-2-3 web server with automatic HTTPS.

Stars
76.5K
Forks
5K
Watchers
865
Open issues
197
Open PRs
81
Contributors
~445
Commits
2.7K
Branches
43

GoApache-2.0Created Jan 13, 2015Last push todayLatest release v2.11.7

Quick answers

What is caddy?
Fast, multi-platform HTTP/1-2-3 web server with automatic HTTPS.
What does caddy do?
Caddy is a powerful, extensible web server built in Go that automatically manages TLS certificates for all your sites by default. It supports modern web protocols including HTTP/3 out of the box. The server acts as a reverse proxy, load balancer, and static file server with a simple configuration syntax via the Caddyfile. Its modular architecture allows for extensive customization through plugins.
Who is caddy for?
Developers, system administrators, and DevOps engineers looking for a modern, secure web server with minimal configuration overhead.
How do I get started with caddy?
caddy run
How popular is caddy on GitHub?
caddyserver/caddy has 76,454 stars and 5,041 forks on GitHub.
What license does caddy use?
caddyserver/caddy is released under the Apache-2.0 license.

Star history

since Jun 30, 2019
020K40K60KJun 2019Nov 2021Apr 2024Oct 2026
76.5K stars as of Oct 4, 2026. Before Oct 4, 2026, reconstructed from public GitHub event archives (checked against the repository's real star total); since then measured daily.

Signals and awards

derived from tracked data
  • Landmark project

    76,454 stars

  • Battle-tested

    11 years of history

  • Actively maintained

    Pushed within 48 hours

  • Community-driven

    ~445 contributors

  • Well documented

    High community health score

  • Permissive license

    Apache-2.0

  • Continuous integration

    Automated checks passing

  • Top 10% tracked

    Rank 109 of 1135

What caddy does

Caddy is a powerful, extensible web server built in Go that automatically manages TLS certificates for all your sites by default. It supports modern web protocols including HTTP/3 out of the box. The server acts as a reverse proxy, load balancer, and static file server with a simple configuration syntax via the Caddyfile. Its modular architecture allows for extensive customization through plugins.

Developers, system administrators, and DevOps engineers looking for a modern, secure web server with minimal configuration overhead.

  • Automatic HTTPS: provisions and renews TLS certificates automatically via Let's Encrypt and ZeroSSL.
  • Caddyfile configuration: simplifies server setup with an intuitive, human-readable configuration language.
  • HTTP/3 support: serves traffic using the latest QUIC-based protocol for improved performance.
  • Reverse proxying: handles load balancing, health checks, and intelligent routing for backend services.
  • Extensible architecture: supports a wide ecosystem of modular plugins and custom modules.

Where teams use it

Serve static sites

Deploy static files quickly with automatic HTTPS and HTTP/3 support.

Reverse proxy APIs

Route traffic to backend microservices with built-in load balancing and automatic TLS.

Local development

Run secure local development servers with automatically generated trusted certificates.

Edge load balancing

Distribute incoming traffic across multiple instances with active health checking.

Getting started: caddy run

README

master branch

Caddy

a project


Every site on HTTPS

Caddy is an extensible server platform that uses TLS by default.

Releases · Documentation · Get Help

      @caddyserver on Twitter   Caddy Forum
Caddy on Sourcegraph   Cloudsmith

Powered by
CertMagic


Menu

  • Easy configuration with the Caddyfile
  • Powerful configuration with its native JSON config
  • Dynamic configuration with the JSON API
  • Config adapters if you don't like JSON
  • Automatic HTTPS by default
    • ZeroSSL and Let's Encrypt for public names
    • Fully-managed local CA for internal names & IPs
    • Can coordinate with other Caddy instances in a cluster
    • Multi-issuer fallback
    • Encrypted ClientHello (ECH) support
  • Stays up when other servers go down due to TLS/OCSP/certificate-related issues
  • Production-ready after serving trillions of requests and managing millions of TLS certificates
  • Scales to hundreds of thousands of sites as proven in production
  • HTTP/1.1, HTTP/2, and HTTP/3 all supported by default
  • Highly extensible modular architecture lets Caddy do anything without bloat
  • Runs anywhere with no external dependencies (not even libc)
  • Written in Go, a language with higher memory safety guarantees than other servers
  • Actually fun to use
  • So much more to discover

Install

The simplest, cross-platform way to get started is to download Caddy from GitHub Releases and place the executable file in your PATH.

See our online documentation for other install instructions.

Build from source

Requirements:

For development

Note: These steps will not embed proper version information. For that, please follow the instructions in the next section.

$ git clone "https://github.com/caddyserver/caddy.git"
$ cd caddy/cmd/caddy/
$ go build

When you run Caddy, it may try to bind to low ports unless otherwise specified in your config. If your OS requires elevated privileges for this, you will need to give your new binary permission to do so. On Linux, this can be done easily with: sudo setcap cap_net_bind_service=+ep ./caddy

If you prefer to use go run which only creates temporary binaries, you can still do this with the included setcap.sh like so:

$ go run -exec ./setcap.sh main.go

If you don't want to type your password for setcap, use sudo visudo to edit your sudoers file and allow your user account to run that command without a password, for example:

username ALL=(ALL:ALL) NOPASSWD: /usr/sbin/setcap

replacing username with your actual username. Please be careful and only do this if you know what you are doing! We are only qualified to document how to use Caddy, not Go tooling or your computer, and we are providing these instructions for convenience only; please learn how to use your own computer at your own risk and make any needful adjustments.

Then you can run the tests in all modules or a specific one:

$ go test ./...
$ go test ./modules/caddyhttp/tracing/

With version information and/or plugins

Using our builder tool, xcaddy...

$ xcaddy build

...the following steps are automated:

  1. Create a new folder: mkdir caddy
  2. Change into it: cd caddy
  3. Copy Caddy's main.go into the empty folder. Add imports for any custom plugins you want to add.
  4. Initialize a Go module: go mod init caddy
  5. (Optional) Pin Caddy version: go get github.com/caddyserver/caddy/v2@version replacing version with a git tag, commit, or branch name.
  6. (Optional) Add plugins by adding their import: _ "import/path/here"
  7. Compile: go build -tags=nobadger,nomysql,nopgx

Quick start

The Caddy website has documentation that includes tutorials, quick-start guides, reference, and more.

We recommend that all users -- regardless of experience level -- do our Getting Started guide to become familiar with using Caddy.

If you've only got a minute, the website has several quick-start tutorials to choose from! However, after finishing a quick-start tutorial, please read more documentation to understand how the software works. 🙂

Overview

Caddy is most often used as an HTTPS server, but it is suitable for any long-running Go program. First and foremost, it is a platform to run Go applications. Caddy "apps" are just Go programs that are implemented as Caddy modules. Two apps -- tls and http -- ship standard with Caddy.

Caddy apps instantly benefit from automated documentation, graceful on-line config changes via API, and unification with other Caddy apps.

Although JSON is Caddy's native config language, Caddy can accept input from config adapters which can essentially convert any config format of your choice into JSON: Caddyfile, JSON 5, YAML, TOML, NGINX config, and more.

The primary way to configure Caddy is through its API, but if you prefer config files, the command-line interface supports those too.

Caddy exposes an unprecedented level of control compared to any web server in existence. In Caddy, you are usually setting the actual values of the initialized types in memory that power everything from your HTTP handlers and TLS handshakes to your storage medium. Caddy is also ridiculously extensible, with a powerful plugin system that makes vast improvements over other web servers.

To wield the power of this design, you need to know how the config document is structured. Please see our documentation site for details about Caddy's config structure.

Nearly all of Caddy's configuration is contained in a single config document, rather than being scattered across CLI flags and env variables and a configuration file as with other web servers. This makes managing your server config more straightforward and reduces hidden variables/factors.

Full documentation

Our website has complete documentation:

https://caddyserver.com/docs/

The docs are also open source. You can contribute to them here: https://github.com/caddyserver/website

Getting help

  • We advise companies using Caddy to secure a support contract through Ardan Labs before help is needed.

  • A sponsorship goes a long way! We can offer private help to sponsors. If Caddy is benefitting your company, please consider a sponsorship. This not only helps fund full-time work to ensure the longevity of the project, it provides your company the resources, support, and discounts you need; along with being a great look for your company to your customers and potential customers!

  • Individuals can exchange help for free on our community forum at https://caddy.community. Remember that people give help out of their spare time and good will. The best way to get help is to give it first!

Please use our issue tracker only for bug reports and feature requests, i.e. actionable development items (support questions will usually be referred to the forums).

About

Matthew Holt began developing Caddy in 2014 while studying computer science at Brigham Young University. (The name "Caddy" was chosen because this software helps with the tedious, mundane tasks of serving the Web, and is also a single place for multiple things to be organized together.) It soon became the first web server to use HTTPS automatically and by default, and now has hundreds of contributors and has served trillions of HTTPS requests.

The name "Caddy" is trademarked. 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". Caddy is a registered trademark of Stack Holdings GmbH.

Caddy is a project of ZeroSSL, an HID Global company.

Debian package repository hosting is graciously provided by Cloudsmith. Cloudsmith is the only fully hosted, cloud-native, universal package management solution, that enables your organization to create, store and share packages in any format, to any place, with total confidence.

View on GitHub

Recent activity

commits and pull requests

Recent open issues

view all

Releases and announcements

138 total
  1. v2.11.7v2.11.7Oct 3, 202612.8K downloads

    This patch release fixes regressions from 2.11.6, including a crash when proxying over HTTP/2 and streams that were cut off after a minute. **If you're on 2.11.6, we recommend upgrading.** It also adds support for the brand new `Incremental` header field (RFC 10036). **Huge thank you to our sponsors for keeping the project alive with resources, and for our maintainers who triage and assist tirelessly in this relentless new age of AI.** ## Highlights - **Fixed: crash and dropped streams caused by the new idle timeouts.** 2.11.6 introduced default idle read/write timeouts, which caused some problems: - In 2.11.6, the request body's idle deadline could outlive the handler that set it: - Over HTTP/2, Caddy could panic with a nil pointer dereference when the reverse proxy was still reading a request body after the handler had returned. (#8101) - Over HTTP/1.1, streaming responses to requests with a body, such as SSE clients that open the stream with a `POST`, were cut off exactly 60 seconds after the body was read. (#8103) Both are fixed in #8107. Thanks @steadytao! - Over HTTP/2, streaming responses that paused between writes for longer than [`write_idle

  2. v2.11.6v2.11.6Oct 1, 202623.8K downloads

    This patch release contains a large number of minor and some noticeable enhancements and bug fixes. Thank you to everyone who contributed or spent their LLM tokens responsibly to help with this release! We have much more in the pipeline still, as AI has made contributions of all quality levels cheap and easy. We will be trying to go through them as quickly and efficiently as we can. **Huge thank you to our sponsors for keeping the project alive with resources, and for our maintainers who triage and assist tirelessly in this relentless new age of AI.** :warning: **Please read the breaking changes below before upgrading.** Most of them come from security hardening, and most configs won't notice. If you were relying on one of the old behaviors, though, you'll want to know about it. ## Highlights - **New [`url_pattern` request matcher](https://caddyserver.com/docs/caddyfile/matchers#url-pattern):** Match requests with the [URLPattern](https://urlpattern.spec.whatwg.org/) standard, the same syntax used by browsers (JS) and many web frameworks. It supports named groups, wildcards, and regexp components. Captured groups become placeholders (`{http.url_pattern.<component>.<g

  3. v2.11.4v2.11.4Jun 3, 20261.3M downloads

    This release patches more security, security-adjacent, and normal bugs. The FrankenPHP project has collaborated on PHP-adjacent patches, which we are grateful for. The recent surge of patches is mostly attributed to token predictors. We have had to reject more than 75% of "security" reports because they were AI slop spam (or just lazy/incorrect). Please use LLMs and agents wisely to avoid wasting precious maintainer resources. We have started blocking offending accounts that spam slop reports. Thank you to all who submit responsible reports following our security policy to make the project better. We appreciate that the community deems the Caddy project worthy of contribution to improve the broader ecosystem! Security-related patches: - caddyhttp: Normalize Windows backslashes in path matcher (thanks @Vincent550102) - rewrite: Prevent placeholder re-expansion in injected query (thanks @WhiskerEnt) - templates: Improved `stripHTML` action to more reliably remove malformed HTML (thanks to @jmrcsnchz) - caddyhttp: Ignore header fields with underscores to prevent collisions (thanks @Vincent550102 for the report and @dunglas for the patch) :warning: These security patches m

  4. v2.11.3v2.11.3May 12, 2026407.2K downloads

    This release improves several aspects of Caddy with minor features, bug fixes, and security patches. Thank you to everyone and their bots who contributed to help make this release the best one yet! **Security patches:** - fastcgi: Carrying over a patch from FrankenPHP for a bug that could allow non-PHP files to be executed; collaborated on by @dunglas, @KC1zs4, and @chenjj. - vars: A more thorough fix for https://github.com/advisories/GHSA-m2w3-8f23-hxxf, collaborated by @everping and @vnxme. - admin: Array index normalization to prevent remote admin socket auth bypass, by @Amemoyoi and bot. - admin: More rigorous path prefix matching to prevent remote admin socket auth bypass, by @Amemoyoi and bot. We've also merged a couple PRs that fix upstream security bugs in other projects like quic-go and CertMagic. Thank you to @marten-seemann for maintaining quic-go so diligently! ## What's Changed * caddyhttp: Sync placeholder expansion in `vars` and `vars_regexp` by @vnxme in https://github.com/caddyserver/caddy/pull/7573 * caddytls: Avoid ACME fallback for implicit Tailscale *.ts.net policies by @steadytao in https://github.com/caddyserver/caddy/pull/7577 * chore: Reso

  5. v2.11.2v2.11.2Mar 6, 20261.3M downloads

    Caddy 2.11.2 contains numerous bug fixes and enhancements! I know that's a lame summary but it's really all over the place. ## Highlights - Reverse proxy got a lot of love with certain edge cases related to PROXY protocol, health check port, and closing body on retries. Dynamic upstreams are now tracked which enables passive health checking. - Performance improvements for metrics. - New `tls_resolvers` global option to control DNS resolvers for all sites when using the ACME DNS challenge. - Log rolling now supports `zstd` compression; deprecated `roll_gzip`, which will be removed in the future. Use `roll_compression` instead. - Refined logging and some error messages. - Fixed a bug in rewrite handler that could cause some URIs to not be rewritten when URI path is an escaped form of target path. Thanks to @MaherAzzouzi for the report. ## Security fixes This release fixes two CVEs. - @NucleiAv reported a bug in the `forward_auth` directive that could permit identity injection and potential privilege escalation. - @sammiee5311 reported that `vars_regexp` double-expanded placeholders, allowing some unusual configs to reveal secrets. In addition: - Built on Go

When work happens

weekday and hour
SunMonTueWedThuFriSat036912151821Sun 0:00 — 7 commitsSun 1:00 — 11 commitsSun 2:00 — 8 commitsSun 3:00 — 3 commitsSun 4:00 — 5 commitsSun 5:00 — 2 commitsSun 6:00 — 3 commitsSun 7:00 — 4 commitsSun 8:00 — 3 commitsSun 9:00 — 4 commitsSun 10:00 — 2 commitsSun 11:00 — 3 commitsSun 12:00 — 4 commitsSun 13:00 — 10 commitsSun 14:00 — 7 commitsSun 15:00 — 3 commitsSun 16:00 — 9 commitsSun 17:00 — 7 commitsSun 18:00 — 3 commitsSun 19:00 — 5 commitsSun 20:00 — 7 commitsSun 21:00 — 14 commitsSun 22:00 — 8 commitsSun 23:00 — 10 commitsMon 0:00 — 9 commitsMon 1:00 — 3 commitsMon 2:00 — 3 commitsMon 3:00 — 2 commitsMon 4:00 — 1 commitsMon 5:00 — 1 commitsMon 6:00 — 2 commitsMon 7:00 — 2 commitsMon 8:00 — 12 commitsMon 9:00 — 14 commitsMon 10:00 — 27 commitsMon 11:00 — 33 commitsMon 12:00 — 63 commitsMon 13:00 — 54 commitsMon 14:00 — 37 commitsMon 15:00 — 34 commitsMon 16:00 — 40 commitsMon 17:00 — 27 commitsMon 18:00 — 27 commitsMon 19:00 — 18 commitsMon 20:00 — 16 commitsMon 21:00 — 19 commitsMon 22:00 — 16 commitsMon 23:00 — 27 commitsTue 0:00 — 18 commitsTue 1:00 — 17 commitsTue 2:00 — 11 commitsTue 3:00 — 10 commitsTue 4:00 — 2 commitsTue 5:00 — 9 commitsTue 6:00 — 2 commitsTue 7:00 — 9 commitsTue 8:00 — 20 commitsTue 9:00 — 12 commitsTue 10:00 — 34 commitsTue 11:00 — 30 commitsTue 12:00 — 38 commitsTue 13:00 — 34 commitsTue 14:00 — 41 commitsTue 15:00 — 27 commitsTue 16:00 — 43 commitsTue 17:00 — 26 commitsTue 18:00 — 16 commitsTue 19:00 — 23 commitsTue 20:00 — 20 commitsTue 21:00 — 21 commitsTue 22:00 — 21 commitsTue 23:00 — 16 commitsWed 0:00 — 18 commitsWed 1:00 — 15 commitsWed 2:00 — 10 commitsWed 3:00 — 8 commitsWed 4:00 — 6 commitsWed 5:00 — 3 commitsWed 6:00 — 3 commitsWed 7:00 — 6 commitsWed 8:00 — 10 commitsWed 9:00 — 25 commitsWed 10:00 — 35 commitsWed 11:00 — 39 commitsWed 12:00 — 28 commitsWed 13:00 — 44 commitsWed 14:00 — 26 commitsWed 15:00 — 27 commitsWed 16:00 — 29 commitsWed 17:00 — 19 commitsWed 18:00 — 22 commitsWed 19:00 — 31 commitsWed 20:00 — 18 commitsWed 21:00 — 23 commitsWed 22:00 — 18 commitsWed 23:00 — 21 commitsThu 0:00 — 15 commitsThu 1:00 — 7 commitsThu 2:00 — 13 commitsThu 3:00 — 5 commitsThu 4:00 — 6 commitsThu 5:00 — 5 commitsThu 6:00 — 6 commitsThu 7:00 — 5 commitsThu 8:00 — 8 commitsThu 9:00 — 22 commitsThu 10:00 — 24 commitsThu 11:00 — 39 commitsThu 12:00 — 43 commitsThu 13:00 — 30 commitsThu 14:00 — 34 commitsThu 15:00 — 31 commitsThu 16:00 — 25 commitsThu 17:00 — 21 commitsThu 18:00 — 16 commitsThu 19:00 — 9 commitsThu 20:00 — 14 commitsThu 21:00 — 21 commitsThu 22:00 — 19 commitsThu 23:00 — 17 commitsFri 0:00 — 12 commitsFri 1:00 — 7 commitsFri 2:00 — 6 commitsFri 3:00 — 3 commitsFri 4:00 — 5 commitsFri 5:00 — 6 commitsFri 6:00 — 9 commitsFri 7:00 — 5 commitsFri 8:00 — 18 commitsFri 9:00 — 23 commitsFri 10:00 — 26 commitsFri 11:00 — 37 commitsFri 12:00 — 40 commitsFri 13:00 — 30 commitsFri 14:00 — 25 commitsFri 15:00 — 26 commitsFri 16:00 — 24 commitsFri 17:00 — 26 commitsFri 18:00 — 27 commitsFri 19:00 — 18 commitsFri 20:00 — 19 commitsFri 21:00 — 9 commitsFri 22:00 — 17 commitsFri 23:00 — 12 commitsSat 0:00 — 11 commitsSat 1:00 — 10 commitsSat 2:00 — 8 commitsSat 3:00 — 5 commitsSat 4:00 — 3 commitsSat 5:00 — 9 commitsSat 6:00 — 9 commitsSat 7:00 — 2 commitsSat 8:00 — 8 commitsSat 9:00 — 12 commitsSat 10:00 — 8 commitsSat 11:00 — 12 commitsSat 12:00 — 11 commitsSat 13:00 — 15 commitsSat 14:00 — 8 commitsSat 15:00 — 5 commitsSat 16:00 — 14 commitsSat 17:00 — 19 commitsSat 18:00 — 11 commitsSat 19:00 — 13 commitsSat 20:00 — 7 commitsSat 21:00 — 7 commitsSat 22:00 — 12 commitsSat 23:00 — 9 commits
Commit volume by weekday and hour (UTC). Larger dots mean more commits.
DateListRankStars gained
Oct 4, 2026daily#7+31