Maintain the blog and recover from mistakes

Your ordinary publishing loop

Write a draft, preview its direct URL locally, review it, set draft: false, run pnpm verify, commit, push, watch the build for that commit, then verify the actual article URL. A successful local preview alone completes none of the external steps.

Use updatedDate for a substantial article revision and keep its original filename stable. If you change a published URL, create and test a redirect. A future-dated post needs a later build; use a separately configured build schedule only if you actually want scheduled publication.

When a release fails

Symptom	First useful check
Local build rejects a post	Required frontmatter and explicit date timezone
GitHub has an older commit	Commit/push completion and the remote target
Hosted build fails	Its logs, lockfile, Node/pnpm versions, and working directory
Build succeeds but content is old	Exact deployed commit, canonical domain, and article date/draft flag
Domain fails while Workers URL works	Delegation, zone activation, DNSSEC, Custom Domain, certificate status
Email stops after DNS migration	All MX/SPF/DKIM/DMARC records and actual forwarding test
Dark mode ignores the operating system	Appearance selection is System and no explicit saved override remains

Undo a source change with a new commit

Inspect the history first:

git status
git log --oneline -8

For a reviewed bad commit, restore behavior using a new reversal commit:

git revert BAD_COMMIT_SHA
pnpm verify
git push origin main

Replace the placeholder with the actual commit. If there are conflicts, resolve them deliberately and follow Git’s instructions; don’t discard unrelated local work. A revert keeps the history understandable and lets the normal pipeline deploy the correction. It does not erase sensitive data already included in history; exposed credentials require revocation/rotation.

Cloudflare also supports deployment rollback. Inspect the intended Worker before choosing a previous version and follow its rollback documentation. A platform rollback does not update your Git source, so fix or revert the source too or the next build can reintroduce the issue.

If you add comments, Worker rollback does not restore its database or schema. Code, database, secrets, and DNS are separate recovery targets.

Back up what you would need to recreate

Keep a private record of the registrar/account recovery details, zone inventory, Worker name/configuration, build settings, and password-manager recovery options. Clone the private Git repository to an independent private backup location. GitHub hosting alone is not a complete backup of DNS, credentials, or reader comments.

For the core static blog, Markdown and configuration are the valuable source. You can regenerate dist/. For comments, use a private database export and test restoration into an isolated environment; the later labs cover the separation.

An optional macOS backup container is an encrypted disk image created in Disk Utility. It is an ordinary .dmg or .sparsebundle file that mounts as a virtual disk; it does not partition or reformat a physical drive. Enter its encryption password locally and store recovery securely. Save exports inside the mounted encrypted volume, then eject it. A local-only image does not protect against losing the computer, so keep an encrypted independent copy too.

Encryption protects a stored backup; it does not make a public GitHub repository an appropriate place for it. FileVault also does not replace an independent backup.

Update dependencies deliberately

Work in a branch, read the relevant release notes, change one manageable group of versions, run verification, and inspect the built site. Commit both package metadata and the changed lockfile. Follow Astro’s upgrade guidance for breaking changes. Update the course’s pinned Node major and hosted build variables together when you change the runtime.

Check domain renewal, recovery access, build failures, usage, and the site periodically. Dynamic comments add operational work even when infrastructure is managed. Set a sustainable review habit before you add them.

Core-course graduation check

Your own domain serves the site over HTTPS; the source repository is private; system dark mode works; drafts/future posts stay out of public HTML, RSS, and sitemap; missing routes return 404; pushing a reviewed commit deploys automatically; and email still works. You know how to identify a failed release and restore source behavior.

You now have a custom blog. Continue only if you want the responsibilities that come with reader comments.