grabowski
c6bec71442
Deploy test site / deploy (push) Successful in 37s
User, October 2026: calculations for the later business plan, starting from 2 Duplex + 1 Classic at 3 records a minute per Duplex and 2 per Classic, as an interactive tool on the website: pick the yearly output and the share of splatter/specials, get the machine mix and all the requirements (people, hydraulics, power, ...). docs/fleet-calculator.html (single static page, no dependencies): - target mode sizes the fleet (specials only on Duplex with its EX 35; grow with Classics or with Duplex systems; start fleet as the floor); fleet mode takes a fleet and gives its output at the specials share; - output, capacity, utilisation and the mix bar per machine type; - needs: people per shift and in total, galvanics operators, machines, connected kVA and average kW, MWh/yr, central hydraulics (flow, motor, oil, accumulator), steam, cooling and cooling water, compressed air, press floor, room climate, compound, trim, titles, electroformed parts and plating units; checks against the 400 kg/h boiler, 250 kW chiller and the 870 m2 Payap press hall; - ladder from the start fleet to a full Payap press hall, click to load; - every assumption editable with its source (Newbilt Duplex site requirements V14 and offer 240620-04, scale.md, galvanics.md, revenue model, Payap model; estimates labelled), shareable link via the hash. The Classic counts as one HRP 12 press plus one extruder until Newbilt states figures (Toolex Alpha leaflet as a cross-check). Site: DEMOS entry (/demos/fleet-calculator/) and landing-page entry. README bullet and layout line; backlinks from scale.md (capacity) and pressing-line.md (current plan).
Test site: cnxvinyl.lol
https://cnxvinyl.lol/ is the internal test site for this repository: demo
pages from docs/ (the plant operation page
first) and any static site we want to show by link. It runs on the same web
server as buildfor.life (Debian VPS s1, Caddy behind Cloudflare) and is
not a plant service; plant systems follow the
digital factory plan. Every page and file is
sent with noindex and robots.txt disallows everything; nothing is behind
a login unless basic_auth in the Caddyfile is switched on.
How it is built
public/is copied verbatim to the web root: the landing page (index.html),robots.txt, and any static site as its own directory (public/<name>/index.htmlis served at/<name>/).build.shassemblessite/dist:public/plus every entry in itsDEMOSlist, which copies a page out ofdocs/(for exampledocs/plant-operation.htmlto/demos/plant-operation/), so the docs stay the one source. It writesversion.txt(the commit) and fails on any internal link that does not resolve.- To add a demo: one line in
DEMOS, one entry on the landing page. To add a static site: drop its built output inpublic/<name>/and link it. - Local preview:
bash site/build.sh, then opensite/dist/index.html.
How it is deployed
.gitea/workflows/deploy-site.yml runs on every push to master that
touches site/, an HTML page under docs/, or the workflow itself, and on
demand (Actions tab, "Run workflow"). It builds, rsyncs site/dist into
the idle one of /var/www/cnxvinyl.lol and /var/www/cnxvinyl.lol-prev,
swaps them by rename (the blog's pattern), checks version.txt on the
server, purges the Cloudflare cache when the token is set, and finally
checks the public URL (warning only).
The deploy owns the whole web root: anything put into
/var/www/cnxvinyl.lol by hand disappears on the next deploy. Static sites
go into public/ instead.
One-time setup
- DNS in Cloudflare, both proxied (orange cloud):
cnxvinyl.lol CNAME s1.buildfor.lifeandwww CNAME cnxvinyl.lol(Cloudflare flattens the apex CNAME, so the site follows s1 if its address changes). SSL/TLS mode Full (strict): "Flexible" makes a redirect loop with Caddy. - Caddy on s1: append
Caddyfileto/etc/caddy/Caddyfile(the comments in it list the checks),caddy validate, thensystemctl reload caddy. Caddy gets the certificate the same way it does for the buildfor.life apex. - Web root: the deploy user must be able to create and rename
directories in
/var/www, as it already does for the blog. If not:sudo install -d -o <deploy user> /var/www/cnxvinyl.lol /var/www/cnxvinyl.lol-prevand make/var/wwwwritable for that user (the swap renames entries in it). - Secrets in Gitea (repo: Settings > Actions > Secrets, or user level so
every repo of the account gets them):
VPS_HOST,VPS_USER,VPS_SSH_KEY, optionallyVPS_PORT(default 22),VPS_KNOWN_HOSTS(output ofssh-keyscan -p <port> s1.buildfor.life, pins the host key),CLOUDFLARE_ZONE_IDandCLOUDFLARE_API_TOKEN(Zone > Cache Purge on cnxvinyl.lol). The names match the blog's workflow, so the blog's deploy key and values work unchanged: s1 only checks the key against the deploy user'sauthorized_keys, whichever repository sends it. Gitea secrets cannot be read back, so they are entered again here from the private key file; repo secrets set onB4L/buildfor_life_webdo not reach this repository, B4L organisation secrets only reach it if it moves into B4L. The blog key isdeploy@s1.b4l.co.th, fingerprintSHA256:o4w7HL+EsPI3MXbbcYWGn0EykN7qeLtYg0Tc9FI1a3s, and it is the only key in/home/deploy/.ssh/authorized_keyson s1 (sshd on port 2255, soVPS_PORTis 2255). The deploy log prints the fingerprint of the key inVPS_SSH_KEY; if it differs, the server answers "Permission denied (publickey)". If the private key is gone, make a new key instead:ssh-keygen -t ed25519 -N "" -C cnx_vinyl-deploy -f cnx_vinyl-deploy, public half into the deploy user's~/.ssh/authorized_keyson s1, private half intoVPS_SSH_KEY, then delete the local copy. - Runner: the job asks for
ubuntu-latest, the label the blog's runner serves. This repository is under a user account, not the B4L organisation, so a runner registered only for B4L does not pick it up; if the run stays "Waiting", register the runner for this repository or instance-wide, or move the repository into B4L. - Run the workflow once from the Actions tab and open
https://cnxvinyl.lol/.