patrickz
Before you start
A static practice site, version control and hosting you already control. Do not change domain records during this exercise.
Why this lesson exists
This site’s move to GoDaddy uses a GitHub workflow to publish reviewed files. The general lesson is a repeatable release process, not a requirement to use a particular host.
The idea this guide practices: I gave three AIs my LinkedIn archive. They built this website.
Do the exercise
Identify the actual source
Choose one repository and one output directory. Document the command that creates or validates the site. Keep credentials out of the files that will be served.
Preview the complete journey
Open the home page, one guide, a contact route and a missing URL. Test on a phone-sized screen. Verify local links and image paths before upload.
Separate validation from publishing
Have the workflow validate first, then upload only the intended output directory. Use an encrypted upload such as SFTP or FTPS with certificate checks, and repository secrets for credentials. Start with a non-production destination when available.
Verify the live release
Check the public URL, images and nested pages after deployment. Compare a visible changed detail with the preview. Keep the prior commit and hosting configuration so a failed release can be reversed.
A prompt to adapt
Replace the bracketed parts with your own details.
Review this static-site release plan: [plan]. Identify the source repository, build/output directory, validation checks, encrypted upload method, secret storage, live verification and rollback. Flag any step that could affect unrelated sites. Do not change DNS or publish until the concrete destination and files are clear.
What this looks like
This site’s own release is a worked example. (1) Every pull request and every push to main runs a validate job: link and file checks, unit tests and a JavaScript syntax check. (2) The publish job declares needs: validate, so nothing uploads unless those checks pass. (3) Publishing runs only on main, never for a pull request, and only while a DEPLOY_ENABLED repository variable is true. That gives you an off switch that needs no code change. (4) The FTPS login comes from repository secrets and never appears in the served files. (5) Each file goes up under a temporary name, is downloaded again and compared by SHA-256, then renamed into place. Nothing on the server is deleted automatically. (6) The files it replaced are kept as a 30-day workflow artifact, so a bad release can be undone. A green build with a skipped upload job is still not a live deployment: check the public URL and a nested page.
Check your result
Use evidence from your output. A confident explanation from the AI is not enough.
If it isn’t working
If the home page works but guides fail, check nested paths, document root and server routing. Avoid changing DNS as a first response to a file-path problem.
Optional. Progress stays in this browser.
Where this came from
An original foundation lesson based on this site’s own release workflow. Read how patrickz.ai is built and published ↗. Sources and approach.
Prepared September 2026. Tools and interfaces change; use current official setup instructions. Session lengths are estimates.