93943a6a · marcel91200/caddy · siGit Code & Deploy

@@ -5,9 +5,9 @@ Caddy 2 Development Branch

5

6 This is the development branch for Caddy 2. This code (version 2) is not yet feature-complete or production-ready, but is already being used in production, and we encourage you to deploy it today on sites that are not very visible or important so that it can obtain crucial experience in the field.

7

8 -Please file issues to propose new features and report bugs, and after the bug or feature has been discussed, submit a pull request! We need your help to build this web server into what you want it to be. (Caddy 2 issues and pull requests will usually receive priority over Caddy 1 issues and pull requests.)

8 +Please file issues to propose new features and report bugs, and after the bug or feature has been discussed, submit a pull request! We need your help to build this web server into what you want it to be. (Caddy 2 issues and pull requests receive priority over Caddy 1 issues and pull requests.)

9

10 -**We want Caddy 2 to be the web server of the Go community!** We are looking for maintainers to represent the community. Please become involved (issues, PRs, [our forum](https://caddy.community) etc.) and express interest if you are committed to being a collaborator on the Caddy project.

10 +**Caddy 2 is the web server of the Go community.** We are looking for maintainers to represent the community! Please become involved (issues, PRs, [our forum](https://caddy.community) etc.) and express interest if you are committed to being a collaborator on the Caddy project.

11

12

13 ### Menu

@@ -121,7 +121,7 @@ Caddy 2 can be configured with a Caddyfile, much like in v1, for example:

121 example.com

122

123 templates

124 -encode gzip zstd

124 +encode gzip zstd

125 try_files {path}.html {path}

126 reverse_proxy /api localhost:9005

127 file_server

@@ -173,14 +173,14 @@ Note that breaking changes are expected until the stable 2.0 release.

173

174 ## List of Improvements

175

176 -The following is a non-comprehensive list of significant improvements over Caddy 1. Not everything in this list is finished yet, but they will be finished or at least will be possible with Caddy 2 or Caddy Enterprise:

176 +The following is a non-comprehensive list of significant improvements over Caddy 1. Not everything in this list is finished yet, but they will be finished or at least will be possible with Caddy 2:

177

178 - Centralized configuration. No more disparate use of environment variables, config files (potentially multiple!), CLI flags, etc.

179 - REST API. Control Caddy with HTTP requests to an administration endpoint. Changes are applied immediately and efficiently.

180 - Dynamic configuration. Any and all specific config values can be modified directly through the admin API with a REST endpoint.

181 - - Enterprise: Change only specific configuration settings instead of needing to specify the whole config each time. This makes it safe and easy to change Caddy's config with manually-crafted curl commands, for example.

181 + - Change only specific configuration settings instead of needing to specify the whole config each time. This makes it safe and easy to change Caddy's config with manually-crafted curl commands, for example.

182 - No configuration files. Except optionally to bootstrap its configuration at startup. You can still use config files if you wish, and we expect that most people will.

183 -- Enterprise: Export the current Caddy configuration with an API GET request.

183 +- Export the current Caddy configuration with an API GET request.

184 - Silky-smooth graceful reloads. Update the configuration up to dozens of times per second with no dropped requests and very little memory cost. Our unique graceful reload technology is lighter and faster **and works on all platforms, including Windows**.

185 - An embedded scripting language! Caddy2 has native Starlark integration. Do things you never thought possible with higher performance than Lua, JavaScript, and other VMs. Starlark is expressive, familiar (dialect of Python), _almost_ Turing-complete, and highly efficient. (We're still improving performance here.)

186 - Using [XDG standards](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables) instead of dumping all assets in `$HOME/.caddy`.

@@ -196,9 +196,9 @@ The following is a non-comprehensive list of significant improvements over Caddy

196 - Automation policy doesn't have to be limited to just ACME - could be any way to manage certificates

197 - Fine-grained control over TLS handshakes

198 - If an ACME challenge fails, other enabled challenges will be tried (no other web server does this)

199 - - Enterprise: TLS Session Ticket Ephemeral Keys (STEKs) can be rotated in a cluster for increased performance (no other web server does this either!)

200 - - Enterprise: Ability to select a specific certificate per ClientHello given multiple qualifying certificates

201 - - Enterprise: Provide TLS certificates without persisting them to disk; keep private keys entirely in memory

199 + - TLS Session Ticket Ephemeral Keys (STEKs) can be rotated in a cluster for increased performance (no other web server does this either!)

200 + - Ability to select a specific certificate per ClientHello given multiple qualifying certificates

201 + - Provide TLS certificates without persisting them to disk; keep private keys entirely in memory

202 - All-new HTTP server core

203 - Listeners can be configured for any network type, address, and port range

204 - Customizable TLS connection policies

@@ -219,7 +219,7 @@ The following is a non-comprehensive list of significant improvements over Caddy

219 - Highly descriptive/traceable errors

220 - Very flexible error handling, with the ability to specify a whole list of routes just for error cases

221 - More control over automatic HTTPS: disable entirely, disable only HTTP->HTTPS redirects, disable only cert management, and for certain names, etc.

222 - - Enterprise: Use Starlark to build custom, dynamic HTTP handlers at request-time

222 + - Use Starlark to build custom, dynamic HTTP handlers at request-time

223 - We are finding that -- on average -- Caddy 2's Starlark handlers are ~1.25-2x faster than NGINX+Lua.

224

225 And a few major features still being worked on:

@@ -336,28 +336,10 @@ Starlark performs at least as well as NGINX+Lua (more performance tests ongoing,

336

337 In summary: Caddy 2 config is declarative, but can be imperative where that is useful.

338

339 -### What will Caddy 2 be licensed as?

339 +### What is Caddy 2 licensed as?

340

341 Caddy 2 is licensed under the Apache 2.0 open source license. There are no official Caddy 2 distributions that are proprietary.

342

343 -### What is Caddy Enterprise?

344 -

345 -Caddy Enterprise is a collection of plugins for Caddy 2 which provide features and performance that are crucial in business settings. Caddy Enterprise is not a separate web server and does not even use a separate code base from Caddy 2; it is not even a separate branch that merges the open source core in every once in a while. In other words, open source users aren't missing out on a "better" web server, but Enterprise provides features that are used by businesses.

346 -

347 -Caddy Enterprise is for businesses that need more advanced features for higher scalability and easier management of clusters. It includes:

348 -

349 -- a web UI

350 -- performance improvements within a cluster

351 -- advanced TLS controls

352 -- fine-grained config changes (i.e. ability to change only certain parts of the configuration)

353 -- training and support

354 -- advanced HTTP handlers for authentication, metrics, debugging, and more

355 -- dynamic HTTP handlers and TLS handshakes with Starlark

356 -

357 -Caddy Enterprise can be customized for each customer according to their needs.

358 -

359 -Caddy 2 and Caddy Enterprise offer equal levels of security and, as mentioned, share the same open source code base.

360 -

343 ### Does Caddy 2 have telemetry?

344

345 No. There was not enough academic interest to continue supporting it. If telemetry does get added later, it will not be on by default or will be vastly reduced in its scope.

@@ -368,7 +350,7 @@ Yes. HTTPS is automatic and enabled by default when possible, just like in Caddy

350

351 ## How do I avoid Let's Encrypt rate limits with Caddy 2?

352

371 -As you are testing and developing with Caddy 2, you may wish to use test ("staging") certificates from Let's Encrypt to avoid rate limits. By default, Caddy 2 uses Let's Encrypt's production endpoint to get real certificates for your domains, but their [rate limits](https://letsencrypt.org/docs/rate-limits/) forbid testing and development use of this endpoint for good reasons. You can switch to their [staging endpoint](https://letsencrypt.org/docs/staging-environment/) by adding the staging CA to your automation policy in the `tls` app:

353 +As you are testing and developing with Caddy 2, you should use test ("staging") certificates from Let's Encrypt to avoid rate limits. By default, Caddy 2 uses Let's Encrypt's production endpoint to get real certificates for your domains, but their [rate limits](https://letsencrypt.org/docs/rate-limits/) forbid testing and development use of this endpoint for good reasons. You can switch to their [staging endpoint](https://letsencrypt.org/docs/staging-environment/) by adding the staging CA to your automation policy in the `tls` app:

354

355 ```json

356 "tls": {

@@ -385,14 +367,14 @@ As you are testing and developing with Caddy 2, you may wish to use test ("stagi

367 }

368 ```

369

388 -Or with the Caddyfile:

370 +Or with the Caddyfile, using a global options block at the top:

371

372 ```

391 -tls {

392 - ca https://acme-staging-v02.api.letsencrypt.org/directory

373 +{

374 + acme_ca https://acme-staging-v02.api.letsencrypt.org/directory

375 }

376 ```

377

378 ## Can we get some access controls on the admin endpoint?

379

398 -Yeah, that's coming. For now, you can use a unix socket that is properly permissioned for some basic security.

380 +Yeah, that's coming. For now, you can use a permissioned unix socket for some basic security.

readme: Remove mentions of Caddy Enterprise (as per #2786)