But it you already have an nginx or other web server otherwise required to start up (which is in all likelihood the case), you don't need any more auto startup, the "reverse proxy" already started can just serve it. I would say that container orchestration versioning can be helpful in some scenarios, but a simple git repository for a static website is way more useful since it's got the right tooling to annotate changes very specifically on demand.

That reverse proxy is ultimately also a static file server. There's really no value in spinning up more web servers for a strictly static site.

Folks have gone overboard assuming docker or similar should wrap every little thing. It sometimes adds complexity without making anything simpler. It can simplify some scenarios, but adding a static site to a webserver is not a scenario that enjoys any benefit.

Serving static app in Caddy:

sudo apt install caddy
sudo systemctl enable --now caddy

Then in /etc/caddy/Caddyfile:

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

That's all, really.

Because serving static files doesn't really require any flexibility in web serving code.

If your setup has an nginx or similar as a reverse proxy entry point, you can just tell it to serve the directory. Why bother making an entire new chroot and proxy hop when you have absolutely zero requirements beyond what the reverse proxy already provides. Now if you don't have that entry point, fine, but at least 99% of the time I see some web server as initial arbiter into services that would have all the capability to just serve the files.