Sanic CLI to easily run a public server on all interfaces, standard ports

[Tronic]

Currently one has to run separate instances with fairly cumbersome parameters, e.g.

sanic --host 0.0.0.0 --port 443 --tls certs my:app
sanic --host :: --port 443 --tls certs my:app

Describe the solution you'd like

The proposal is a single CLI option, e.g. --public or --web that would make Sanic listen on all interfaces (IPv4 and IPv6), on standard ports.

Since in 2023 it doesn't make much sense to run non-TLS public servers, I suggest requiring for TLS to be defined. In this case the app would run on 443, and if 80 is available for binding, Sanic could run a redirection service there, as already described in our documentation https://sanic.dev/en/guide/how-to/tls.html#redirect-http-to-https-with-certificate-requests-still-over-http

All of this is to make Sanic an easily deployable full blown TLS web server in setups where no proxy is used. This would be vastly easier to setup than a similar Nginx config, for instance.

sanic --public --tls /etc/letsencrypt/live/example.com my:app

Additional context

This is not intended to replace proxy installs, where Nginx or other proxies can be used in front of Sanic, to run also non-Sanic services on separate vhosts, or to serve static files faster than Sanic can. But in many cases it would provide much needed convenience to run a Sanic app, without a proxy, with one simple command.

HTTP3 might also be enabled with this mode, with the intent of being a full server in all extents.

#2657 is a prerequisite for this.

[Tronic]

The above doesn't directly address the initial bootstrapping of the certificates, although the port 80 service certbot's HTTP verification (one can run certbot to obtain certs while it is running). Possibly Sanic could facilitate certbot usage in that situation until the certs are installed and the main app can be started (or the hostmaster may choose to use some other certs/verification method).

If anyone has ideas on how to make the bootstrap process as smooth as possible, please comment.

[ahopkins]

Interesting, I like this idea. I wonder if we should in addition to inferring host/port on --public also allow multiple bindings from the cli.

sanic server:app --port=1234 --port=5678

[Tronic]

Multiple host bindings on one CLI certainly would fit #2657 as well. I see much less use for binding (the same thing) to multiple ports. The suggestion to use port 80 here is for the HTTPS redirection and /.well-known server (cert updates), and the port of that doesn't really need to be configurable (rather the server should be disabled if something else is using port 80).

[ahopkins]

The port 80 with /.well-known pattern is its own use case because we need to come up with a pattern that only binds some portion of the app. This is accomplished by running two app instances.

[Tronic]

Yes, it is clearly its own app (shipped with Sanic, possibly customizable by user). So, are you heading to a direction where the sanic CLI could run multiple apps, listen multiple hosts and ports, and possibly mount different apps to different host-port combinations? Something like

sanic --port 1234 some:app --port 5678 another:app   # Runs some:app on 1234, another:app on 5678

Just a question, not saying that this would be good or bad. But I can see this turning into a bigger application server eventually, where one could actually run completely separate Sanic apps e.g. on different vhosts, without using Nginx for that as is currently done. And taking these up and down via the worker manager system...

[ahopkins]

But I can see this turning into a bigger application server eventually, where one could actually run completely separate Sanic apps e.g. on different vhosts, without using Nginx for that as is currently done. And taking these up and down via the worker manager system...

You just described snx 😉 This thread is quite timely. I am still a few more weeks out from a real proposal though.

The short answer is: yes. We already do this with the recent Inspector addition. A http-to-https app, and a proxy app are sort of the next two on my radar. Even the simple app that serves a directory could be handled this way including a basic HTML file tree browser.