Office-Native: Deploy Where It's Used

"Every machine you deploy to is a machine you have to babysit. A one-artist tool belongs on one artist's machine."

One Place, Because That's Where It's Used

Loomis runs on a single machine — the office Mac, where Dad actually draws. It is deliberately not fanned out across the fleet, not a mom-mode surface, and not a heavy-GPU load. The deployment is right-sized to the real use: one artist, one workstation, a CPU-light engine that lives exactly where the drawing happens. This isn't a limitation the project hasn't gotten around to fixing — it's a deliberate boundary, the same scope discipline the architecture keeps everywhere else.

Scope Discipline for Ops

Here's the reasoning, and it generalizes far past this engine. Every machine you deploy a service to is a machine you now have to monitor, update, secure, and eventually debug. That operational surface is real and it compounds. Deploying a single-user drawing tool onto a fleet of machines that will never open it doesn't add capability — it adds a dozen copies to keep patched and a dozen places for something to silently break, all for zero benefit. Scope discipline in operations means the same thing it means in code: build and deploy for the concrete need in front of you, not for an imagined future that may never arrive.

launchd Owns the Lifecycle

The live service is launchd-owned: the operating system keeps it running, restarts it if it dies, and brings it back after a reboot. Critically, source work does not authorize a restart — editing the code is a separate act from bouncing the live process. That separation protects Dad's actual drawing tool from being yanked out from under him every time development touches a file. The lifecycle belongs to the OS, not to whoever is currently editing, and that boundary is what lets the tool be both actively developed and reliably up.

Build-as-Default

One more honest ops choice. The engine serves the built UI as its real surface, not the development server, because a dev server's flurry of per-module requests falls apart over a high-latency link — and a tool you might reach remotely has to survive a slow connection. So the robust path (the built bundle) is the default, and the dev server stays what it should be: a local workbench for fast iteration, never the thing a remote user depends on. Making the resilient option the default, and keeping the convenient-but-fragile one clearly labeled as a workbench, is a small decision that saves a real headache.

Code

Right-sized deployment: one machine, by design·text

# ONE machine, because one artist draws on one machine.
office Mac
  launchd: com.cwk.loomis-serve      # keeps `loomis serve` alive: RunAtLoad + KeepAlive
    -> engine on :8300               # serves the BUILT UI -- the real, robust surface
       (dev server on :5176 is the local HMR workbench, NOT the remote surface)

# NOT deployed: the fleet (no need), mom's Mac (not a surface), any GPU box (CPU-light).
#
# Scope discipline: every extra deploy target is monitoring + updating + debugging
# surface for ZERO benefit. Deploy where it's used; nowhere else.
# And: source edits do NOT authorize a restart -- the OS owns the live lifecycle.

Exercise

Find something you've deployed or installed in more places than it's actually used — an agent on every server, an app on every device, a service running where nobody calls it. Tally the ongoing cost each extra location adds: updates to apply, monitoring to watch, configuration to keep in sync, surfaces to secure. Then decide whether consolidating to just where it's used would lose you anything real.

Hint

Extra deployment locations rarely add capability but always add carrying cost — every one is another thing to patch, another place to drift out of config, another attack surface. If you can't name a concrete use for a given location, that's usually a place to remove, not maintain. Loomis stays on one machine for exactly this reason: the one machine is the only one that draws.