1. 1. Write the files directly

   A static site has nothing to compile. The folder holds an index.html, a style.css, a Procfile containing the single line static: ., and an ENV file pinning the port and the server name. No package manager, no build step, no renderer ever runs.

2. 2. Check the instance before trusting it

   The piku instance must run a patched fork with the PIKU_NGINX_NO_TLS switch turned on, and its nginx must read the vhost directory piku writes into. A short preflight over SSH proves all three; if any check fails, the deploy stops there, because a push would report success while the site served nothing.

3. 3. Push with git

   The folder is a git repository with one remote: piku@piku:<name>. Pushing main ships the committed files as they are. Piku stores the publication in a folder named after the site, so every site needs a unique name to never collide.

4. 4. Serve plain HTTP on the pinned port

   Piku writes an nginx vhost that listens on the port from ENV, here 8007, and serves the files straight from disk. Nothing inside the container terminates TLS; that is deliberate, because no container owns port 443 in this architecture.

5. 5. Verify with a loud gate

   curl -sf against http://piku:8007/ exits non-zero on a refused connection or any HTTP error, so a dead site can never be reported as live. Only a clean 200 passes the gate.

6. 6. Put a name in front of the port

   Exposure is a separate lane. A command like ivps expose-service maps a tailnet name to the port and handles TLS, tags, approval and verification. The same port can also carry a public domain. Both commands run from the laptop, not from the container, and never by hand-wiring a web server inside it.