Go Live Please · Field Notes

When I want something changed on this site, I say it, often from my phone. A few minutes later it's live. No FTP, no zip files, no logging in to a control panel. This is how that works, and why I think it could work for someone else's site too.

There are three pieces: GitHub, where the site's code lives; my web host, an ordinary shared hosting account, where the public site lives; and two ways of changing things, Claude Code and my own Studio. Everything meets at one place: the main branch on GitHub. Whatever lands there goes live on its own.

Made with AI The heart: the Studio, pumping each day through to a Field Note. Rendered with AI for The whole machine.

Path one: I talk, Claude codes

Claude Code works on a copy of the site in the cloud, connected to my GitHub through GitHub's own app, and only to the repositories I've allowed. I describe what I want. It reads the code, makes the change, tests it, and puts it on a branch as a draft pull request, with screenshots when there's something to see. Nothing is live yet. When I'm happy, I say three words: go live, please. It merges the pull request into main.

Path two: I publish from the Studio

Real video The Studio, my private back room, where a Note is saved straight into GitHub.

The Studio is my private back room for Field Notes. When I press Save, the Studio writes the Note straight into GitHub as a commit. It uses a fine-grained token that can only touch this one repository, and only its contents. The token lives on the server in a private settings file outside the web folder, next to the Anthropic key that lets the Studio ask Claude for a draft. Neither is ever in the code.

The last mile: rsync

Made with AI An artist's impression of the works. The real machine runs on code, not clockwork.

Every push to main wakes up a GitHub Actions workflow. It builds what needs building: the share cards, the Field Notes pages, the magazines and their covers, and the Studio's parts. Then it connects to my server over SSH with a deploy key and sends the site across with rsync.

rsync is old and plain, and that's the point. It only sends files that changed, comparing them by checksum. It sets sensible permissions on the way. And it never deletes anything on the server, so files that only live there are safe. My private Field Notes folder is never uploaded. There's a dry-run switch that lists what would change without touching anything. The whole thing takes a few minutes.

That process in and of itself is going to be quite potentially powerful.

Made with AI GlazyArray at her desk after hours. She narrates this one.

What to ask for, if I were setting it up again

I keep my website's code in a GitHub repository and host it on
shared hosting that allows SSH.

Set it up so that:
- Whatever is on the main branch goes live by itself.
- Changes reach main only as pull requests I approve.
- A GitHub Actions workflow builds the site and uploads it
  with rsync over SSH, using a deploy key kept as a secret.
- The upload only adds and updates files, never deletes,
  and has a dry-run switch.
- Private folders and drafts are never uploaded.
- Every key has one job, and none is written in the code.

Tell me which secrets to create and where, step by step.

Not the exact words we used, but the shape of the ask. Give it to an AI that can work in your repository, then follow along and say yes or no at each step.

The keys

The keys begin dark, then light up one at a time from left to right, each glow easing up over about a second, the heart keyhole last and brightest; all hold lit together for a beat, then ease back down together to dark.

It took a handful of keys, each with one job and nothing more:

The three words, typed into a Claude Code session on my phone: Go live please. The draft waiting on them was pull request #400.

A deploy key: a pair, the private half stored as a GitHub secret, the public half on the server. Three more secrets say where to go: the host, the user and the folder. A fine-grained GitHub token for the Studio, limited to one repository's contents, with an expiry date. An Anthropic API key for drafting. A read-only Google Drive login, so the Studio can bring in photos and videos from my phone. And the GitHub app that lets Claude Code open pull requests. None of them is written down anywhere public, including here.

Each Key has a Purpose

It took a handful of keys, each with one job and nothing more.

An extreme close-up of one high-tech key hanging from the janitor's brass ring.

The robot janitor walks steadily forward with all keys hooked to it's belt.

A brass robot hand unclipping a second, smaller key ring from the janitor's belt and holding it out toward the camera.

Made with AI

Step by step: setting it up for a new site

Put the site in a GitHub repository
One repository, one main branch. Whatever is on main is what's live.
Make a deploy key
Generate a key pair. The public half goes on the server's list of allowed keys; the private half becomes a GitHub repository secret.
Tell GitHub where to go
Three more secrets: the server's host name, the SSH user and the folder to deploy into.
Add the workflow
A GitHub Actions file that runs on every push to main: build, then rsync over SSH, with a dry-run switch to try it safely first.
Connect Claude Code
Install GitHub's app for Claude on just that repository, so changes arrive as pull requests to review.
Optional: a back room
A private admin like the Studio, saving through a fine-grained token limited to one repository's contents, with its keys kept on the server outside the web folder.

Why it matters

It's powerful, and that's why the guard rails matter more than the speed. Only main goes live. Only I say go live. The Studio refuses a save if the Note changed since I opened it. Editors' saves wait for me. The server never loses a file.

The Studio working my answers into a draft: gather the notes and photos, Claude writes, ready to read.

Set up once, it means a site owner can change their site by describing the change. That's how I run mine now. With the same pieces, a client could run theirs the same way: talk, look at the preview, say go live. Nothing in it needs a special server; plain shared hosting with SSH is enough.

If you'd like a site that works like this, get in touch.