Nginx, servingwhat the runs wrote
Every artifact on the volume, reachable at a URL.And the configuration is a file on that volume too.
$ dxflow workflow create --identity web hub://nginx --start --link
An output directory,with an address
It is pointed at the volume, so what a run left behind is a web resource.
Directory listings, byte ranges and downloads that resume where they stopped.
A .log, .csv or solver input reads in the browser — the MIME table knows them.
CORS=on lets a notebook or a dashboard fetch a result set cross-origin.
The config liveson the volume
Write a location file, wait a few seconds, and it is serving. No restart, no redeploy.
$ dxflow artifact upload reports.conf nginx/server.d/
$ dxflow artifact download nginx/state/status.log ./
$ dxflow workflow start web --override env.app.SITE_DIR=reports --link
Configurationas an artifact
conf.d and server.d sit on the volume, and the step watches them.
A broken confignever reaches disk
Every candidate is tested before it is installed, so the running server keeps serving through your mistakes.
nginx -t runs against a temporary path first. Only what passes is written, so a restart mid-edit still comes up.
state/status.log says what happened to your last edit, and state/effective.conf holds what nginx actually resolved.
A browser refuses a wildcard origin on a credentialed request. Leave the password empty, or turn auth off on the one location being fetched.
Pulled once,then it stays
Nginx arrives as one image. This is what comes down the first time, and what the disk should have free for it.
What it wants,and what it needs
The definition asks for 2 cores and 1 GB. The image comes up on less than that, and a start given --fit trims the ask to whatever the machine actually has.
Machines that fit it
Nginx asks for 2 cores and 1 GB. Cheapest first.