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

推荐订阅源

P
Proofpoint News Feed
WordPress大学
WordPress大学
Help Net Security
Help Net Security
Jina AI
Jina AI
Security Latest
Security Latest
Y
Y Combinator Blog
Project Zero
Project Zero
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
GbyAI
GbyAI
Know Your Adversary
Know Your Adversary
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
NISL@THU
NISL@THU
Cisco Talos Blog
Cisco Talos Blog
博客园 - 司徒正美
MyScale Blog
MyScale Blog
Cyberwarzone
Cyberwarzone
D
Docker
T
The Blog of Author Tim Ferriss
G
Google Developers Blog
C
CERT Recently Published Vulnerability Notes
B
Blog
L
LangChain Blog
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
SecWiki News
SecWiki News
The Hacker News
The Hacker News
C
Check Point Blog
L
Lohrmann on Cybersecurity
V2EX - 技术
V2EX - 技术
S
Securelist
T
Threat Research - Cisco Blogs
Stack Overflow Blog
Stack Overflow Blog
TaoSecurity Blog
TaoSecurity Blog
云风的 BLOG
云风的 BLOG
Latest news
Latest news
人人都是产品经理
人人都是产品经理
L
LINUX DO - 最新话题
Application and Cybersecurity Blog
Application and Cybersecurity Blog
The Register - Security
The Register - Security
Webroot Blog
Webroot Blog
Simon Willison's Weblog
Simon Willison's Weblog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Microsoft Security Blog
Microsoft Security Blog
AWS News Blog
AWS News Blog
C
Cybersecurity and Infrastructure Security Agency CISA
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
小众软件
小众软件
T
Tailwind CSS Blog
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
宝玉的分享
宝玉的分享
O
OpenAI News

Jim Nielsen’s Blog

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 Full Page Paralysis Being “Good” at Things Coding Is Designing An Ode to the Exacting Pedantry of Computers Book Notes: “Poor Charlie’s Almanack” Something’s Rotten in the State of macOS Icon Design Building Software Requires Digestion Out With the JS, In With the HTML Reminder: You Can Stitch Together Lots of Little HTML Pages With Navigations For Interactions Collective Speed Is Not the Summation of Individual Speed Hook It Up to the Machine Speed is Not Conducive to Wisdom That’s a Skill Issue
Fewer Computers, Fewer Problems: Going Local With Builds & Deployments
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.