Sal’s

And switched again, now deploying with wrangler

My original description for this post was “don’t need no stinkin’ git cloud.” As in, after moving from GitLab to GitHub, I decided to eschew cloud git providers altogether and use my home server as my source of truth.

So I set that up, and instead of deploying this blog via a git push to one of the cloud providers, I’m deploying it locally on the command line with wrangler using Cloudflare Page’s direct-upload option.

I was chuffed. And then I lost power. I’m writing this on my laptop while my power is still out. My home server and networking gear are all down.

Less chuffed.

So now I’m leaning toward Claude’s suggestion: use both. I can deploy with wrangler and still use GitHub, at least as a secondary remote, though I’m going to use it as my origin and source of truth once again.

Why wrangler?

I like deploying from my machine and getting immediate feedback on the progress and completion. When I deploy via a git push, on the other hand, there’s a lot more complexity. Cloudflare has to receive the webhook event (at least I assume that’s what they use), then spin up a build, and run a full npm install before it gets to the actual 11ty build. That doesn’t really matter in the scheme of things, but if I have the choice — and I do — I prefer the first approach.

Here’s what my last deploy looked like:

> npm run deploy
# ...
# site builds, etc.
# ...

✨ Success! Uploaded 440 files (122 already uploaded) (1.81 sec)

✨ Uploading _redirects
🌎 Deploying...
✨ Deployment complete! Take a peek over at <staging url>

Bam, done.

Better yet, I can deploy branches on the fly for a staging preview of things I’m trying out. With Cloudflare’s Workers, dev-branch builds are either on or off, meaning they’ll either build and deploy every push on every branch, or only on my main branch. With wrangler, I can deploy any branch as often as I want.

Another benefit is that I can do less git branching. When pushing to my main branch triggers a deployment, I do most of my work in other branches and then merge into main when I’m ready to deploy. This is a totally fine and good approach to deploying things that are actually important. But for this scrappy blog, it’ll be nice to just hang out in main and only switch branches when I’m doing something risky. My draft posts are hidden regardless thanks to the draft frontmatter key.

One more: when I deploy with wrangler, I don’t think there’s a limit to the number of deployments I can do. When I deploy via Cloudflare builds, I believe I’m limited to 300 per month. I don’t know that I’d ever get close to hitting that cap, but it’s nice to be able to deploy lots of little typo fixes and whatnot without worrying about consuming my quota.

Why GitHub?

If I’m not using it for deployments anymore, why bother?

First, for backups. I haven’t had to set up any backup software on my home server because anything important is stored in GitHub and sync’d to at least two other computers on a quasi-daily basis. If I don’t use GitHub, even though I’ll still have my repos sync’d, I really should figure out backups. And that sounds like a boring project right now.

Plus, GitHub is a more reliable source of truth. Since my home server is my source of truth right now, and it’s currently down, I don’t know if this laptop’s git repo is up to date. That means I shouldn’t deploy this post until the power is back online and I can sync back up with my home server. No huge deal, but a point in favor of GitHub.

Power is back on

I have rejoiced. And, tail between my legs, returned to GitHub.

#git #github #cloudflare