惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Jina AI
Jina AI
大猫的无限游戏
大猫的无限游戏
T
Tailwind CSS Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
WordPress大学
WordPress大学
Last Week in AI
Last Week in AI
Hugging Face - Blog
Hugging Face - Blog
阮一峰的网络日志
阮一峰的网络日志
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
人人都是产品经理
人人都是产品经理
V
V2EX
博客园 - 叶小钗
雷峰网
雷峰网
小众软件
小众软件
量子位
V
Visual Studio Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
The GitHub Blog
The GitHub Blog
Martin Fowler
Martin Fowler
G
Google Developers Blog
博客园_首页
博客园 - Franky
有赞技术团队
有赞技术团队
宝玉的分享
宝玉的分享

Jim Nielsen’s Blog

Do You Prefer Artificial? Bottlenecks Get a Bad Rap Preserving Netlify Analytics Data Beyond 30 Days An Ode to Links Don’t Let Anyone Take Away Your Big Box of Cables The Bulldozing of an Interface Can We Stop With the Uptime Percentages? Nobody Believes It, Everybody Does It My Experience Has Nuance, Yours Is a Data Point A Calendar View For My Blog Have You Heard the Good News About Microlighter? Getting an LLM to Make Me a Tool for Enriching the Color Metadata in My Icon Collection A Sloppy Interface Is a Security Liability  Oops, Should’ve Thought of That Oh Hey, It’s Not Just Me The Fruits of AI A License to Act The AI Aesthetic Can the Tide of AI Investment Life All Boats on the Web? Podcast Notes: Ed Catmull on David Senra Make It Work vs. Make It Good Podcast Notes: Iain McGilchrist on “The Great Simplification” What’s an Icon in 2026? Family Feud: Mac-assed Mac App Edition Making a Shuffle Button This Page Left Intentionally Blank Notes from Bryan Cantrill’s “Intelligence is not Enough” My Om Malik Story Blogging Can Just Be Stating The Obvious Consistency, But in Excellence Not Appearance
Fewer Computers, Fewer Problems: Going Local With Builds ...
Jim Nielsen · 2026-04-10 · via Jim Nielsen’s Blog

Me, in 2025, on Mastodon:

I love tools like Netlify and deploying my small personal sites with git push

But i'm not gonna lie, 2025 might be the year I go back to just doing builds locally and pushing the deploys from my computer.

I'm sick of devops'ing stupid stuff because builds work on my machine and I have to spend that extra bit of time to ensure they also work on remote linux computers.

Not sure I need the infrastructure of giant teams working together for making a small personal website.

It’s 2026 now, but I finally took my first steps towards this.

The Why

One of the ideas I really love around the “local-first” movement is this notion that everything canonical is done locally, then remote “sync” is an enhancement.

For my personal website, I want builds and deployments to work that way.

All data, build tooling, deployment, etc., happens first and foremost on my machine.

From there, having another server somewhere else do it is purely a “progressive enhancement”. If it were to fail, fine. I can resort back to doing it locally very easily because all the tooling is optimized for local build and deployment first (rather than being dependent on fixing some remote server to get builds and deployments working).

It’s amazing how many of my problems come from the struggle to get one thing to work identically across multiple computers.

I want to explore a solution that removes the cause of my problem, rather than trying to stabilize it with more time and code.

“The first rule of distributed computing is don’t distribute your computing unless you absolutely have to” — especially if you’re just building personal websites.

The What

So I un-did stuff I previously did (that’r right, my current predicament is self-inflicted — imagine that).

My notes site used to work like this:

  • Content lives in Dropbox
  • Code is on GitHub
  • Netlify’s servers pull both, then run a build and deploy the site

It worked, but sporadically. Sometimes it would fail, then start working again, all without me changing anything. And when it did work, it often would take a long time — like five, six minutes to run a build/deployment.

I never could figure out the issue. Some combination of Netlify’s servers (which I don’t control and don’t have full visibility into) talking to Dropbox’s servers (which I also don’t control and don’t have full visibility into).

I got sick of trying to make a simple (but distributed) build process work across multiple computers when 99% of the time, I really only need it to work on one computer.

So I turned off builds in Netlify, and made it so my primary, local computer does all the work. Here are the trade-offs:

  • What I lose: I can no longer make edits to notes, then build/deploy the site from my phone or tablet.
  • What I gain: I don’t have to troubleshoot build issues on machines I don’t own or control. Now, if it “works on my machine”, it works period.

The How

The change was pretty simple.

First, I turned off builds in Netlify. Now when I git push Netlify does nothing.

Next, I changed my build process to stop pulling markdown notes from the Dropbox API and instead pull them from a local folder on my computer. Simple, fast.

And lastly, as a measure to protect myself from myself, I cloned the codebase for my notes to a second location on my computer. This way I have a “working copy” version of my site where I do local development, and I have a clean “production copy” of my site which is where I build/deploy from. This helps ensure I don’t accidentally build and deploy my “working copy” which I often leave in a weird, half-finished state.

In my package.json I have a deploy command that looks like this:

git pull && npm ci && netlify deploy --build --prod

That’s what I run from my “clean” copy. It pulls down any new changes, makes sure I have the latest deps, builds the site, then lets Netlify’s CLI deploy it.

As extra credit, I created a macOS shortcut

# So it knows where to get the right $PATH to node
source ~/.zshrc

# Then switch to my dir and run the command
cd ~/Sites/com.jim-nielsen.notes/
npm run deploy

So I can do CMD + Space, type “Deploy notes.jim-nielsen.com” to trigger a build, then watch the little shortcut run to completion in my Mac’s menubar.

I’ve been living with this setup for a few weeks now and it has worked beautifully. Best part is: I’ve never had to open up Netlify’s website to check the status of a build or troubleshoot a deployment.

That’s an enhancement I can have later — if I want to.