The toolchain
Five tools, each doing one job well. My notes flow left to right, from where I write them to where anyone can read them.
| Tool | Role | Why this one |
|---|---|---|
| Obsidian | My notes vault, the single source of truth | Plain Markdown I already live in; everything starts here and nothing drifts from it |
| Claude | Drafting and building, under my direction | I set the vision and make the calls; it drafts from my notes, builds, and I review and correct |
| Hugo | Static site generator | Markdown-first, one fast binary, no runtime or database to maintain |
| Git and GitHub | Version control and CI | The public repo is part of the proof; Actions checks every push and deploys each release |
| Azure Static Web Apps | Hosting | Free managed TLS, a custom domain, and a deploy triggered straight from the repo |
The workflow
Everything moves one direction, from a note to a deployed page. I write in the vault, draft and build with Claude, review and correct, then Hugo generates the static site. I preview it locally, commit from my own machine, and when a set of changes is ready I publish a release, which GitHub Actions deploys to Azure. Because the repository is public, the build itself is on display.
The same repository also packages the site as a container. A multi-stage Dockerfile builds it with Hugo and serves the result from nginx, and every release publishes that image to the GitHub Container Registry, scanned for vulnerabilities first. Anyone can pull it and run this exact site with a single docker run, no build step required.
How the content is organized
The content is organized the way the site reads: by layer. Every story, document, script, and container is tagged with the part of the stack it belongs to, mapped to the OSI model plus the domains that cut across it. Hugo turns those tagged Markdown files into the real pages you can open, so growing the library is just adding a file in the right place.
The domain, external and internal
NetState Data runs as a small hybrid environment, the same shape I would run for an organization: a public cloud side and a private internal side, joined together.
External is for the web and public viewing. netstatedata.ca lives in the cloud on Azure, served over HTTPS, with email on Microsoft 365. It is what you are reading now.
Internal is a NetStateData.Local domain running on virtual machines: a domain controller and the internal services behind it. It is hybrid-joined to the cloud, so identity and policy reach across both sides, the way a real hybrid environment works.
How it is developed and released
Every change follows the same path: made and reviewed on a local copy, committed as a restore point, checked automatically, and released under a version number. Only a release goes live, every release keeps a saved copy of exactly what was published, and any earlier release can be put back live in one step.
The full process, from the local loop to versioning, releases, rollback and the guardrails around a public repository, is in its own document: The Site Development Process.
See it in action: the deploy pipeline · the commit history · releases
What I directed, what the AI built
This mirrors how I work with AI everywhere: I set the vision and make every judgment call; the AI drafts and implements; I review, change, and keep versions.
My direction: the structure and page order, which stories are told, the wording and voice, every factual claim, and what stays private.
What the AI did: drafting from my notes, building the templates and styling, generating the diagrams, and proposing options that I accepted, rejected, or redirected. Nothing reaches the site without my review.