Make your laptop disposable with a Mac Mini devserver

Make your laptop disposable.

Not disposable in the sense that the laptop does not matter. It is still where you prompt, edit, review, and inspect. It is the right place for the human interface to development.

It is a poor place for the state that should survive it.

A useful coding session can contain an agent that is still working, a build that is still running, a shell with useful context, logs worth keeping, and a repository that should not depend on whether a laptop has to sleep, change networks, or go into a bag. The longer that session runs, the less sensible it is to make a portable machine the only place where that state exists.

EternalMac makes a Mac Mini the durable machine and keeps the laptop as the mobile client. The goal is not to build a home data center or make local development look like a cloud workspace. It is to make a personal development environment boring enough to leave alone while the laptop comes and goes.

The real problem is durable state

The valuable part of a long-running workflow is rarely the laptop screen. It is the state behind the screen:

• processes that are still doing work;
• named shells with repository, tool, and log context;
• builds that should not stop because a lid closes;
• files that need to remain available on the machine doing the work; and
• the agent configuration that shapes how a coding tool behaves.

That distinction matters because different kinds of state fail differently. A lost terminal connection is an interface problem. A stopped agent process is an execution problem. A stale project tree is a synchronization problem. Reaching a machine only from one Wi-Fi network is a networking problem.

Treating all of those as “remote access” produces a fragile setup. A personal devserver needs to make each responsibility explicit.

What a personal devserver actually needs

Four capabilities make the laptop-and-Mac-Mini split useful.

Resilient interactive attachment. A laptop should be able to disconnect, sleep, and reconnect without turning a temporary network event into a new development session.

Named session persistence. The processes that matter need a home independent of the terminal window currently displaying them. A name such as overnight-agent should identify the work to return to, not merely the tab that happened to launch it.

Controlled file synchronization. The project files edited on a laptop and the project files used by the persistent machine need a deliberate relationship. That relationship should be visible, inspectable, and scoped to paths the user chose.

Private reachability. A Mac Mini at home should be reachable from a laptop without exposing a public SSH service just to support personal development.

None of these responsibilities requires novel infrastructure. The value is in combining mature tools around one operating model, then checking that the combination remains healthy.

How EternalMac composes the system

Laptop: edit, review, prompt
  ├─ Eternal Terminal + tmux attach ───────────────┐
  ├─ Mutagen project sync ─────────────────────────┤
  └─ Tailscale private network ────────────────────┤
                                                    ↓
Mac Mini: persistent development substrate
  ├─ named tmux sessions: agents, shells, builds, logs
  ├─ launchd daemons: health checks and reconciliation
  └─ status/doctor: explicit operational feedback

Each component has one job.

Tailscale gives the two machines a private network path and stable DNS name. The Mac Mini stays reachable through the tailnet without requiring a public SSH port.

Eternal Terminal handles the shell transport. It is designed for reconnecting a terminal after the client machine changes networks or resumes from sleep. tmux handles a different concern: it keeps named sessions and the processes inside them alive on the Mac Mini after the terminal detaches.

Mutagen synchronizes the project roots the user selects. The laptop can remain the comfortable editing surface while the Mac Mini holds the copy used by persistent shells, agents, and builds. EternalMac records those sync pairs and can report whether they are active or degraded.

launchd gives the server and client their local background work. EternalMac’s Rust CLI sets up the roles, records configuration and health state, and exposes the workflow through a small command surface instead of asking users to remember a chain of independent setup commands.

During client setup, DotSync is optional. It can discover supported AI-agent configuration locations and offer approved sync roots for tools such as Claude Code, Codex, OpenCode, Goose, Gemini CLI, Qwen Code, Pi, and Amp. It uses a curated allowlist rather than synchronizing every hidden file in a home directory, and it excludes common authentication, cache, log, telemetry, and machine-identity files.

Why not just SSH into tmux?

You can. SSH plus tmux is a reasonable foundation for a capable user who wants to assemble the rest by hand.

The remaining work is what EternalMac packages: private networking, a resilient terminal transport, client and server setup, dedicated key authorization, selected file sync, launchd agents, named-session commands, status, and diagnosis. The point is not that SSH is inadequate. The point is that a repeatable workflow should not depend on rebuilding the same personal integration every time a machine changes.

From installation to a recoverable work session

The public setup starts with one command on each machine. Install EternalMac from its Homebrew tap:

brew install eternalmac/eternalmac/eternalmac

On the Mac Mini, run server setup:

eternalMac setup server

Server setup verifies Tailscale and Remote Login, starts the Homebrew-managed Eternal Terminal service, creates a default tmux session, and installs the server daemon. Remote Login matters because Eternal Terminal and Mutagen use SSH during setup and handshaking.

Then configure the laptop with the Mac Mini’s Tailscale DNS name:

eternalMac setup client --server <tailscale-dns-name>

Client setup establishes its dedicated SSH key, discovers the server-side etterminal path, asks which project roots should synchronize, creates the corresponding Mutagen sessions, and installs the client daemon.

After that, starting a named remote session is explicit:

eternalMac attach -n overnight-agent

The agent, shell, build, and logs now run inside that named tmux session on the Mac Mini. Closing the laptop disconnects the interface; it does not by itself stop the server-side work. When the Mac Mini and its required services are healthy, reconnecting to the same session restores the working context.

Reliability is an operational feature

A setup command is not enough evidence that a workflow remains usable. Personal infrastructure becomes brittle when it reports success once and leaves the user to infer the rest.

EternalMac uses background checks to keep an explicit local health picture. On the server, the daemon observes Tailscale state and the default tmux session. If the expected default session has disappeared, it can recreate it and record that reconciliation. On the client, the daemon checks tailnet state, reaches the paired server through Eternal Terminal, and evaluates the configured Mutagen sync sessions.

Two commands make that state usable:

eternalMac status
eternalMac doctor

status is the compact snapshot: role, daemon heartbeat, Tailscale state, paired server, sessions, and sync health. doctor is for the moment something feels wrong. It turns conditions such as missing configuration, stale daemon state, a role mismatch, an unreachable server, or a degraded sync into a specific next action.

That is a small distinction with large practical consequences. A system that says it is healthy only when the relevant dependencies are healthy is easier to trust than one that only remembers that setup once succeeded.

Deliberate boundaries

EternalMac is intentionally narrow.

• It is currently a macOS, Apple Silicon, Homebrew-first workflow for one person, not shared team infrastructure.
• Both machines need to be on the same Tailscale tailnet, and the Mac Mini needs Remote Login enabled.
• Normal project synchronization is user-directed full-tree synchronization. It does not exclude secrets automatically; supply project-specific --ignore patterns when a repository needs them.
• The current Mutagen conflict-handling model is deliberately simple. A project with complex concurrent editing needs a workflow that accounts for that before relying on two-way sync.
• A Mac Mini is the intended always-on machine, not a guarantee against power loss, service failure, or degraded connectivity.
• This does not replace cloud development environments. It is for people who already want their own Mac Mini to be the machine that keeps personal development state alive.

Those limits are part of the product. A personal devserver becomes more useful when it says exactly what it owns and what it leaves to the user.

Who should try EternalMac

EternalMac is useful when a Mac Mini is already available and a laptop should remain free to move, sleep, or change networks without becoming the single point of failure for a coding session.

If the useful unit of work is becoming longer than a laptop session—an agent run, a build, a debugging shell, or simply a carefully prepared environment—try the EternalMac documentation and the open-source repository. The setup is opinionated by design: put durable work on the persistent machine, keep the laptop as the interface, and make the connection between them observable.