Convert Figma logo to code with AI

caddyserver logocaddy

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

56,905
3,978
56,905
144

Top Related Projects

22,139

The official NGINX Open Source repository.

50,061

The Cloud Native Application Proxy

3,525

Mirror of Apache HTTP Server. Issues: http://issues.apache.org

10,826

H2O - the optimized HTTP/1, HTTP/2, HTTP/3 server

4,812

HAProxy Load Balancer's development branch (mirror of git.haproxy.org)

Quick Overview

Caddy is a powerful, enterprise-ready, open-source web server with automatic HTTPS written in Go. It is designed to be easy to use, fast, and secure out of the box, with a focus on simplicity and modern web standards.

Pros

  • Automatic HTTPS with Let's Encrypt integration
  • Easy configuration with a human-readable JSON format
  • Highly extensible through plugins and modules
  • Cross-platform support and single binary distribution

Cons

  • Less widespread adoption compared to Apache or Nginx
  • May have a steeper learning curve for users familiar with traditional web servers
  • Some advanced features require additional configuration or plugins

Code Examples

  1. Basic Caddyfile configuration:
example.com {
    root * /var/www/html
    file_server
}

This configures Caddy to serve files from /var/www/html for the domain example.com.

  1. Reverse proxy configuration:
api.example.com {
    reverse_proxy localhost:8080
}

This sets up a reverse proxy for api.example.com to forward requests to a local server running on port 8080.

  1. Enabling HTTP/3:
{
    servers {
        protocol {
            experimental_http3
        }
    }
}

example.com {
    root * /var/www/html
    file_server
}

This enables HTTP/3 support for all sites served by Caddy.

Getting Started

  1. Download Caddy from the official website or use a package manager.
  2. Create a Caddyfile in your project directory with your desired configuration.
  3. Run Caddy using the command: caddy run

For more advanced usage, refer to the official Caddy documentation.

Competitor Comparisons

22,139

The official NGINX Open Source repository.

Pros of Nginx

  • Highly performant and efficient, especially for static content and high-traffic scenarios
  • Extensive ecosystem with a wide range of modules and third-party extensions
  • Well-established and battle-tested in production environments

Cons of Nginx

  • Configuration can be complex and less intuitive for beginners
  • Lacks built-in HTTPS and automatic certificate management
  • Requires manual restarts for configuration changes to take effect

Code Comparison

Nginx configuration example:

server {
    listen 80;
    server_name example.com;
    location / {
        root /var/www/html;
    }
}

Caddy configuration example:

example.com {
    root * /var/www/html
    file_server
}

The Caddy configuration is more concise and readable, with automatic HTTPS enabled by default. Nginx requires more explicit configuration but offers finer-grained control over server behavior.

Both Nginx and Caddy are powerful web servers with their own strengths. Nginx excels in high-performance scenarios and offers extensive customization options, while Caddy provides a more user-friendly experience with automatic HTTPS and simpler configuration syntax.

50,061

The Cloud Native Application Proxy

Pros of Traefik

  • More extensive service discovery and load balancing features
  • Better suited for complex microservices architectures
  • Supports a wider range of backends and providers

Cons of Traefik

  • Steeper learning curve and more complex configuration
  • Less streamlined for simple reverse proxy use cases
  • Larger resource footprint compared to Caddy

Code Comparison

Caddy configuration example:

example.com {
  reverse_proxy localhost:8080
}

Traefik configuration example:

http:
  routers:
    my-router:
      rule: "Host(`example.com`)"
      service: my-service
  services:
    my-service:
      loadBalancer:
        servers:
          - url: "http://localhost:8080"

Both Caddy and Traefik are popular reverse proxy and web server solutions, but they cater to different use cases. Caddy excels in simplicity and ease of use, making it ideal for smaller projects and quick setups. It also features automatic HTTPS by default. Traefik, on the other hand, shines in complex, dynamic environments with its advanced service discovery and load balancing capabilities. It's more suitable for large-scale microservices architectures but requires more configuration and resources.

3,525

Mirror of Apache HTTP Server. Issues: http://issues.apache.org

Pros of httpd

  • Extensive module ecosystem for added functionality
  • Highly configurable and customizable
  • Long-standing reputation and widespread adoption

Cons of httpd

  • More complex configuration and setup process
  • Higher resource usage compared to lightweight alternatives
  • Steeper learning curve for beginners

Code Comparison

httpd configuration example:

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Caddy configuration example:

example.com {
    root * /var/www/html
    file_server
    log {
        output file /var/log/caddy/access.log
    }
}

Summary

httpd (Apache) is a mature, feature-rich web server with extensive customization options and a large ecosystem. It's well-suited for complex setups and enterprise environments. However, it can be more resource-intensive and challenging to configure compared to Caddy.

Caddy, on the other hand, offers simplicity, automatic HTTPS, and modern features out of the box. It's easier to set up and maintain, making it attractive for smaller projects and developers seeking a more straightforward solution. The trade-off is fewer advanced features and a smaller ecosystem compared to httpd.

10,826

H2O - the optimized HTTP/1, HTTP/2, HTTP/3 server

Pros of H2O

  • Higher performance and lower latency, especially for static file serving
  • More flexible configuration options for advanced users
  • Supports HTTP/3 (QUIC) out of the box

Cons of H2O

  • Steeper learning curve and more complex configuration
  • Less active community and fewer third-party plugins
  • Not as user-friendly for beginners compared to Caddy

Code Comparison

H2O configuration example:

hosts:
  "example.com":
    listen:
      port: 443
      ssl:
        certificate-file: /path/to/cert.pem
        key-file: /path/to/key.pem
    paths:
      "/":
        file.dir: /var/www/example.com

Caddy configuration example:

example.com {
  root * /var/www/example.com
  file_server
  tls /path/to/cert.pem /path/to/key.pem
}

H2O offers more granular control but requires more verbose configuration, while Caddy provides a simpler, more intuitive syntax for basic setups. H2O excels in performance-critical scenarios, whereas Caddy is generally easier to use and configure for most common web server tasks.

4,812

HAProxy Load Balancer's development branch (mirror of git.haproxy.org)

Pros of HAProxy

  • High performance and scalability for large-scale deployments
  • Advanced load balancing algorithms and traffic management features
  • Extensive monitoring and logging capabilities

Cons of HAProxy

  • Steeper learning curve and more complex configuration
  • Limited built-in support for modern web protocols (e.g., HTTP/3)
  • Requires manual SSL/TLS certificate management

Code Comparison

HAProxy configuration example:

frontend http_front
   bind *:80
   default_backend http_back

backend http_back
   balance roundrobin
   server server1 192.168.1.1:80 check
   server server2 192.168.1.2:80 check

Caddy configuration example:

:80 {
  reverse_proxy server1:80 server2:80
}

HAProxy focuses on detailed, granular configuration for advanced load balancing scenarios, while Caddy offers a more streamlined, user-friendly approach with automatic HTTPS and simpler syntax. HAProxy excels in high-performance, large-scale environments, whereas Caddy is ideal for quick setup and modern web server features out of the box.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Caddy

a project


Every site on HTTPS

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


@caddyserver on Twitter Caddy Forum
Caddy on Sourcegraph Cloudsmith

Releases · Documentation · Get Help

Menu

Powered by
CertMagic

Features

  • 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
  • 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.

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

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, a Stack Holdings 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.