diff --git a/v2:-Improvements.md b/v2:-Improvements.md
new file mode 100644
index 0000000..2b31b62
--- /dev/null
+++ b/v2:-Improvements.md
@@ -0,0 +1,57 @@
+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:
+
+- Centralized configuration. No more disparate use of environment variables, config files (potentially multiple!), CLI flags, etc.
+- REST API. Control Caddy with HTTP requests to an administration endpoint. Changes are applied immediately and efficiently.
+- Dynamic configuration. Any and all specific config values can be modified directly through the admin API with a REST endpoint.
+    - 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.
+- 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.
+- Export the current Caddy configuration with an API GET request.
+- 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**.
+- 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.)
+- Using [XDG standards](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables) instead of dumping all assets in `$HOME/.caddy`.
+- Caddy plugins are now called "Caddy modules" (although the terms "plugin" and "module" may be used interchangeably). Caddy modules are a concept unrelated [Go modules](https://github.com/golang/go/wiki/Modules), except that Caddy modules may be implemented by Go modules. Caddy modules are centrally-registered, properly namespaced, and generically loaded & configured, as opposed to how scattered and unorganized Caddy 1-era plugins are.
+- Modules are easier to write, since they do not have to both deserialize their own configuration from a configuration DSL and provision themselves like plugins did. Modules are initialized pre-configured and have the ability to validate the configuration and perform provisioning steps if necessary.
+- Can specify different storage mechanisms in different parts of the configuration, if more than one is needed.
+- "Top-level" Caddy modules are simply called "apps" because literally any long-lived application can be served by Caddy 2.
+- Even more of Caddy is made of modules, allowing for unparalleled extensibility, flexibility, and control. Caddy 2 is arguably the most flexible, extensible, programmable web server ever made.
+- TLS improvements!
+	- TLS configuration is now centralized and decoupled from specific sites
+	- A single certificate cache is used process-wide, reducing duplication and improving memory use
+	- Customize how to manage each certificate ("automation policies") based on the hostname
+	- Automation policy doesn't have to be limited to just ACME - could be any way to manage certificates
+	- Fine-grained control over TLS handshakes
+	- If an ACME challenge fails, other enabled challenges will be tried (no other web server does this)
+    - TLS Session Ticket Ephemeral Keys (STEKs) can be rotated in a cluster for increased performance (no other web server does this either!)
+    - Ability to select a specific certificate per ClientHello given multiple qualifying certificates
+    - Provide TLS certificates without persisting them to disk; keep private keys entirely in memory
+	- Certificate management at startup is now asynchronous and much easier to use through machine reboots and in unsupervised settings
+- All-new HTTP server core
+	- Listeners can be configured for any network type, address, and port range
+	- Customizable TLS connection policies
+	- HTTP handlers are configured by "routes" which consist of matcher and handler components. Match matches an HTTP request, and handle defines the list of handlers to invoke as a result of the match.
+	- Some matchers are regular expressions, which expose capture groups to placeholders.
+	- New matchers include negation and matching based on remote IP address / CIDR ranges.
+    - Placeholders are vastly improved generally
+	- Placeholders (variables) are more properly namespaced.
+	- Multiple routes may match an HTTP request, creating a "composite route" quickly on the fly.
+	- The actual handler for any given request is its composite route.
+	- User defines the order of middlewares (careful! easy to break things).
+	- Adding middlewares no longer requires changes to Caddy's code base (there is no authoritative list).
+	- Routes may be marked as terminal, meaning no more routes will be matched.
+	- Routes may be grouped so that only the first matching route in a group is applied.
+	- Requests may be "re-handled" if they are modified and need to be sent through the chain again (internal redirect).
+	- Vastly more powerful static file server, with native content-negotiation abilities
+    - Done away with URL-rewriting hacks often needed in Caddy 1
+	- Highly descriptive/traceable errors
+	- Very flexible error handling, with the ability to specify a whole list of routes just for error cases
+	- The proxy has numerous improvements, including dynamic backends and more configurable health checks
+	- FastCGI support integrated with the reverse proxy
+	- More control over automatic HTTPS: disable entirely, disable only HTTP->HTTPS redirects, disable only cert management, and for certain names, etc.
+    - Use Starlark to build custom, dynamic HTTP handlers at request-time
+        - We are finding that -- on average -- Caddy 2's Starlark handlers are ~1.25-2x faster than NGINX+Lua.
+
+And a few major features still being worked on:
+
+- Logging
+- Kubernetes ingress controller (mostly done, just polishing it -- and it's amazing)
+- More config adapters. Caddy's native JSON config structure is powerful and complex. Config adapters upsample various formats to Caddy's native config. There are already adapters for Caddyfile, JSON 5, and JSON-C. Planned are NGINX config, YAML, and TOML. The community might be interested in building Traefik and Apache config adapters!
\ No newline at end of file