Everything the Laptop Was Quietly Doing

I revived an old Ubuntu box to do the heavy lifting, so I can close the laptop and move around without stopping the work. Simple idea: put the code and the docs on the server, work from there. In practice, moving a working environment turned out to be less “copy some files” and more “discover everything the old machine was doing that I never wrote down.”

The one-way door I almost walked through

The code lives in three private git repos, so cloning them onto the server should have meant setting up a GitHub login first. My instinct was lazier: just make the repos public — there’s nothing secret in there anyway, right?

Wrong, and I’m glad I looked before flipping the switch. The API’s compose file — tracked, and sitting in the git history — carried the live database password in plain text. Making a repo public isn’t a setting you can quietly walk back; the moment it’s out, it’s cloned, cached, indexed. “Nothing sensitive in there” is exactly the sentence that comes right before a leak. Thirty seconds of grep beat an afternoon of rotating credentials. I authenticated the server the boring way and moved on.

The docs that live nowhere

The code was the easy half — git already solves that. The awkward half is everything git doesn’t track: the design notes, the bug log, the running spec, the project instructions, a little pile of memory files. On purpose, those have always been local scratch, never committed. Which is fine right up until “local” means “on the machine I’m trying to walk away from.”

So syncing them became its own small ritual, separate from a git pull — a one-way copy up to the server, and a matching command to pull them back down after I’ve edited them there. Nothing clever. But it made me say out loud which files are the actual memory of this project, and admit they have no backup but the machine they happen to sit on.

The server is not my laptop

Here’s where “same environment, new address” fell apart. The three shop-floor apps are Windows desktop apps — they literally can’t compile on Linux, so an entire category of work simply doesn’t exist on the server. There’s no screen there either, so the in-browser testing I lean on for the till isn’t possible from that box.

And the subtlest one: on our network, my laptop isn’t just a computer, it’s a trusted device. A big chunk of the security model is “this request came from a machine on the allowlist.” The server is a stranger to that list. So from it I can prove the locked doors stay locked — but not that the right keys still open them. The laptop was quietly wearing a badge I never think about.

The unglamorous last mile

The final ten percent is the part no tutorial mentions. The toolchain installed cleanly but wasn’t on the path when tools ran non-interactively. Git refused to identify me, because I’d never told that machine who I am. A hook called python where this Ubuntu only answers to python3. None of it hard; all of it exactly the kind of thing that separates “it’s set up” from “it actually works.” An environment isn’t ready when the big pieces are present — it’s ready when the small assumptions stop tripping over each other.

Where it stands

I can now shut the laptop, walk off, and keep doing the server-side work, the owner CLI, the web build, and all the writing from a box that doesn’t care where I’m sitting. What I can’t do from there is touch the Windows apps or the browser till — and that’s fine, because those are the parts I’d rather have in front of a real screen anyway.

The honest takeaway: migrating a workspace isn’t moving files, it’s excavating assumptions. Every convenience the old machine handed me for free came back as a small, specific chore on the new one. Which is the same lesson this whole project keeps teaching, in a different costume — the work is never the flashy part. It’s noticing everything the old way was quietly doing, right before you replace it.