Provide context on the stack components and deployment scenarios

[freephile]

Canasta uses Caddy and Varnish, but the documentation doesn't offer context on how these are used in the overall platform architecture. I.e. Caddy is simultaneously the reverse proxying web server and TLS termination endpoint. Varnish is an external cache layer for performance.

Also, Caddy provides a major feature not found in other web servers: automatic TLS support through ACME CA such as Let's Encrypt or ZeroSSL but that is not mentioned as a "feature" of Canasta. Since users will undoubtedly be trying to figure out how to use and deploy the Canasta stack in 3 different scenarios (listed below), the documentation should address these at a minimal level of detail for proper orientation.

1. local development (with the site served at "localhost") for "kicking the tires" or development of Canasta features;
2. corporate/cloud "split brain" or "split horizon" DNS environments. For example a private Amazon EC2 instance with perhaps DNS provided by Amazon Route 53 and a VPC that allows "internal (enterprise) users" to "see" the private DNS name of the instance; or else some other combination of "company DNS service provider"; and
3. public deployments with a predetermined domain name. For example, "I've got a domain name and a host at Digital Ocean, I want to setup Canasta."

This issue aims to create some minimal guidance on how Canasta meets these use cases. The info would likely be best in some "preamble/setup" section; introductory text; and/or FAQ to provide the correct guidance for the new user.

From the Caddy docs

Local HTTPS is handled via incorporation of a self-signed certificate into the local PKI settings of the host machine.

I don't think Canasta has any problems with 'localhost' setup, when run via sudo and using the Docker Compose orchestrator because the necessary PKI configuration is stored via the Docker daemon into the Caddy container and persistent data directory.

For public domain names, Caddy guides you to ensure the following before running Caddy:

• your domain's A/AAAA records point to your server,
• ports 80 and 443 are open externally,
• Caddy can bind to those ports (or those ports are forwarded to Caddy),
• your data directory is writeable and persistent,
• and your domain name appears somewhere relevant in the config

Canasta handles all but the first step (set your DNS), so Canasta users can easily get their instance running on a public domain name via a DNS A/AAAA record (for IPv4 and IPv6 respectively).

Open Questions

An open question is "How do I setup Canasta to use my already obtained CA Certificate?" For example, somebody purchased an SSL certificate from GoDaddy or Verisign, or whatever.

Additional concerns

Since Let's Encrypt is a default CA for Caddy, and LE has rate limits, we should caution users or provide a mechanism to avoid hitting those limits which can block your HTTPS for up to a week.