The Operator Stack: Running a Distributed Studio From Apple Silicon

I get asked how I run everything. The honest answer is: it took a while to stop building clever setups and start building one that could survive real use.

A lot of setups look good in a screenshot. Fewer hold up under real work. Fewer still survive being stretched across multiple machines, multiple projects, multiple agents, and the fact that I am not always sitting at the same desk on the same device at the same time.

What finally worked was not a single machine, and not some magical all-in-one app. It was a small distributed operator stack built around Apple Silicon, explicit state, private networking, bounded agents, and a system where each part has a defined role.

This is the first version that actually works without me babysitting it.

The Real Shape of the Stack

The first thing worth correcting is the common assumption that this is a single-computer setup centered on one Mac mini. That was closer to the truth at one point, but it is not the full picture now.

The studio runs across multiple Apple Silicon machines with different jobs:

Mac Studio M1 64GB - primary heavy workstation and high-capacity execution node
Mac mini M1 - always-on operator node and stable utility host
MacBook Air M2 - mobile development and control client
Tailscale - private network fabric tying the whole thing together

That role separation matters more than the hardware itself. The system works because not every machine is pretending to be everything.

The laptop is not the authority. The always-on node is not the only place work happens. The workstation does not have to be awake for the studio to remain operational.

That sounds obvious. It took real iteration to get there.

The Hardware

Mac Studio M1 64GB

The Mac Studio M1 64GB is my primary high-capacity workstation and the strongest local execution node in the stack.

This is where heavier development sessions, larger local workloads, multi-tool engineering work, media-adjacent tasks, and more demanding execution tend to land. It has the headroom for the kind of real-world work that starts to feel cramped on smaller systems: larger dev environments, more concurrent processes, more room for local AI workflows, and the general class of tasks where "it technically runs" is not the same thing as "it runs well."

The important point is that the Mac Studio is not just a nicer desktop. It is part of the operator fabric. It is a machine I can rely on for serious local work without constantly designing around constraint.

In a setup like this, headroom is not luxury. It is operational slack. And operational slack is the difference between a system that feels stable and one that feels one bad day away from becoming annoying.

Mac mini M1

The Mac mini M1 is the always-on utility and operator node.

This is the machine that stays up handling the boring but important work: background services, stable processes, scheduled routines, agent activity, remote access points, and infrastructure-style tasks that should keep functioning whether or not my main workstation is awake.

This is also where the operator model makes the most sense. An always-on node is useful because it creates continuity. It becomes a reliable place for the stack to exist outside the rhythm of "I opened my laptop" and "I closed my laptop."

That continuity matters more than raw power for a lot of operational work.

The Mac mini earns its place by being predictable. It does not need to be the biggest machine in the room. It needs to be the machine that keeps showing up.

MacBook Air M2

The MacBook Air M2 is my mobile development and control client.

It is my second brain when I am not at the desk, but I am careful not to let it become the source of truth. That is a deliberate constraint, not an accident. The laptop can read and write. It can initiate work. It can control systems. It can participate fully in the workflow. But it should not quietly become the machine whose local state matters more than everything else.

That is how multi-machine setups rot.

If the laptop becomes special just because I am physically holding it, the architecture has already started to drift.

So the Air is a client. A capable client, a productive client, but still a client. It is there for mobility, not authority.

Tailscale

The connective tissue for all of this is Tailscale.

This is one of the missing pieces that matters more in practice than it sounds on paper. Tailscale gives me a private network across the Mac Studio, Mac mini, laptop, and any other nodes I need to reach without turning my life into a part-time networking job.

That means:

reliable SSH access between machines
access to internal tools and services without fragile exposure
stable node identity across changing networks
less dependence on brittle home-network assumptions
less port-forwarding nonsense
less "works at home, breaks the second I leave the house"

Without a clean private network layer, multi-machine workflows get irritating fast. Every remote interaction starts depending on location, router state, firewall quirks, or whatever mystery is happening on the current network.

With Tailscale, the studio behaves more like one private operating environment.

That is a big difference.

It means I can move between machines and treat them like nodes in a system instead of random disconnected boxes that happen to belong to me. That is a much more useful mental model, especially once agents and background services are involved.

OpenClaw and the Ace Agent

OpenClaw is the operator platform. Ace is the agent instance running on top of it.

Ace handles the operational work that used to be manual or easy to forget:

monitoring project state
surfacing anomalies
running scheduled checks
responding to events
routing work to the right handler
generating receipts for completed operations

That all sounds like standard "agent" language until you get to the important part: Ace is not treated like an autonomous decision-maker with unlimited room to improvise.

That is not a missing feature. That is the design.

Ace operates under bounded rules, explicit scope, and governance shaped by SMALL Protocol. In practice, that means there are constraints, declared execution boundaries, durable artifacts, and a record of what happened.

That is the difference between an operator and a liability.

A lot of current AI tooling still wants to present freedom as a virtue. Give an agent broad access, let it roam, let it "handle things." That might make for a flashy demo. It is not how I want real systems to behave.

An always-on agent without real boundaries is just a new way to create damage.

The point is not to build a machine that can do anything. The point is to build one that can do the right things reliably, explainably, and inside a known contract.

Without that, "AI operations" is just a nicer phrase for "hope nothing weird happened at 3am."

The Vault

The Vault is the source of truth for the durable parts of the system.

That includes structured files, project state, receipts, logs, and operational artifacts that need to outlive any one machine session or any one agent invocation.

It is not a database in the normal sense. It is a disciplined file-system authority.

That distinction matters.

In a multi-machine, multi-agent workflow, the easiest way to create confusion is to let truth drift into the wrong places:

the last machine you touched
the current shell session
a tool's internal state
a chat transcript
whatever an agent "remembers"

That is all garbage as a source of truth.

The file system, when treated with enough discipline, is better. It is concrete. It is inspectable. It is durable. It can be versioned, audited, and reasoned about without pretending memory is infrastructure.

That is the real purpose of the Vault. It gives the system somewhere stable to stand.

It came out of the usual frustration that shows up once work spans machines and agents:

something changes on the laptop
something else runs on the always-on node
an agent executes overnight
now three places all act like they are current

That is how projects become ambiguous.

The Vault solves that by making state on disk the authority. Not a machine's RAM. Not a UI session. Not chat memory. Not whichever device happened to touch the project last.

State that matters should exist in a place the system can actually inspect.

Receipts for Everything

The receipt model is one of the parts I care about most.

Every meaningful operation that changes state should produce a receipt:

what was requested
what happened
when it happened
what outputs were created
which actor or machine performed it

Receipts are append-only. They accumulate into history. That history becomes reconstructable instead of anecdotal.

This is not some grand invention. It is basically an audit trail. But most development workflows are still disturbingly casual about this. People automate more and more work while keeping terrible visibility into what actually changed.

Then something breaks, and suddenly everyone is staring at the same question:

What changed?

That should not be a mystery.

If a system can execute but cannot explain itself afterward, it is incomplete. If multiple machines and agents can write state but there is no durable history of those writes, you are not running a robust workflow. You are gambling with a nicer dashboard.

The point of receipts is not bureaucracy. The point is reconstructability.

I want the ability to walk back through project history and see what happened in order, across machines, across operators, across time, without depending on fuzzy human recall. Because human recall is unreliable, and "I think this changed sometime yesterday" is not an operational standard.

Why This Works

The reason this setup works is not because the individual tools are magical. It works because the responsibilities are explicit.

Each major part has one job:

Mac Studio M1 64GB - high-capacity workstation and heavier execution node
Mac mini M1 - always-on operator and utility node
MacBook Air M2 - mobile client for development and control
Tailscale - private network fabric across the studio
Ace / OpenClaw - bounded operator layer
Vault - durable file-system source of truth
Receipts - append-only execution history

That role clarity removes a surprising amount of friction.

There is no machine that becomes special just because I am holding it. There is no serious state that should live only in memory. There is no agent with unbounded authority. There is no meaningful operation that should happen without leaving a record.

That is the architecture.

It is not flashy. It is not trying to be cute. It is just built to keep working.

What I Actually Like About It

The part I like most is that the system feels calmer than the setups that came before it.

That is a real metric, even if people do not talk about it enough.

A lot of modern workflows create hidden stress because they are full of implied state and invisible dependency chains. You are never fully sure which machine matters most, which process is current, which service is exposed, which agent ran last, or whether some important piece of work exists only in a place you are not looking.

This stack reduces that uncertainty.

The always-on node stays on. The workstation handles the heavier local work. The laptop stays mobile without pretending to be the center of the universe. The network layer makes the nodes reachable. The Vault anchors durable state. The receipts make history inspectable. The agent operates inside a contract instead of cosplay autonomy.

That combination turns a pile of machines and tools into an actual operating model.

The Point of the Whole Thing

The real goal here is not "homelab coolness" or trying to make a small studio sound bigger than it is.

The goal is to build a working environment where:

tools can be trusted
state can be found
actions can be explained
work can continue across machines
agents can help without becoming a risk surface

That is the whole design philosophy.

Small studio. Real infrastructure mindset.

Not because I am pretending to run a hyperscaler out of my office. Because once your work spans code, media, multiple repos, multiple machines, and multiple AI systems, casual setups stop being charming and start becoming expensive.

So this is the operator stack: a Mac Studio M1 64GB, a Mac mini M1, a MacBook Air M2, Tailscale as the private network layer, OpenClaw and Ace as the bounded operator layer, a Vault as the durable file-system authority, and receipts for every meaningful state change.

It is a distributed studio, but it runs more like infrastructure than a pile of apps.

That is why it works.