I wanted to publish the site in its current, unfinished form and write about each change as I make it. That means the infrastructure itself becomes part of the story. This is a short log of the move from local-only to a live Oracle Cloud server. It was simple in theory and a little stubborn in practice.

The plan (simple version)

  • Point the domain to an Oracle VM.
  • Get HTTPS running.
  • Deploy the site as static files.
  • Keep updating it while documenting the updates.

The Oracle Always Free VM is already running. Nginx is already there. The site builds with Astro. All that sounded like a clean one-hour task.

The DNS traps

The biggest time sink was not the server. It was DNS.

GoDaddy still had the domain forwarding rule active, plus a “Parked” A record. Even after adding the correct A record, external resolvers kept returning the old parked IPs. The fix was to remove forwarding and keep exactly one A record for the root:

  • @ -> YOUR_IP
  • www -> zinchuk.online (CNAME)
  • keep mogrt on Google Cloud (separate CNAME)

Once the authoritative DNS finally returned only the Oracle IP, everything else clicked into place.

HTTPS went smoothly (after DNS)

As soon as the DNS was clean, Certbot worked on the first try. The Nginx config already had both zinchuk.online and www.zinchuk.online in server_name, so the certificate issued cleanly and HTTP->HTTPS redirect was automatic.

Deploying: CI was stubborn, rsync won

I tried to set up GitHub Actions to build and rsync on every push. The workflow kept failing with Permission denied (publickey) even when the deploy key looked correct. After too much time on it, I switched to the most reliable path:

  • build locally
  • rsync to the web root on the server

That surfaced another small fix: the target directory needed to be owned by the deploy user. Once permissions were correct, deploys were instant.

A small quality-of-life win

Typing the SSH key passphrase on every deploy gets old fast. The local ssh-agent solves that. Load the key once per session and rsync becomes a single, predictable step.

What this unlocked

The site is live, even if it is still rough. That is the point. From now on, each visual or functional change can be published and documented immediately. The infrastructure work is no longer a blocker; it is part of the narrative.

Next steps

  • Automate deploy again when I have more patience.
  • Ship the next post about the mogrt service (separate host, same domain).
  • Keep the ouroboros alive: publish the work, then write about the publishing.