MACOS · DEVELOPMENT WORKSPACES

Deckhand

Knows what is running on your machine, what owns it, and what is safe to stop.

scroll

The problem

You have ten projects you haven't touched in weeks, and no quick way to tell which ones still hold something open. A busy port, a Node process left running in the background, a Docker container still up, a node_modules folder several gigabytes deep — each one is checked separately, with a different tool.

The alternative is `lsof`, `ps`, `docker ps` and a `du -sh` through every folder, one after another, project by project, every time you just want to know what is still occupying the machine.

The mechanism

One scan, four surfaces

Deckhand reads all four independently, then links what belongs together.

PortsThe TCP ports something on your Mac is currently listening on.
ProcessesThe development processes behind those ports — what they are, and how long they have been running.
Build foldersThe regenerable output each project has left behind — node_modules, .next, .build, DerivedData, target, build, dist.
ContainersDocker containers, images, volumes and build cache, correlated by their Compose working directory — shown only when Docker is installed and running.

Why correlate at all

The point of linking them

Each surface alone tells you a fact. Linked, they tell you a story your terminal cannot — that a port, a process and a container all trace back to the same project, one you may have already moved on from.

Port 3000 is held by container acme-api, started 3 days ago, from ~/work/acme — which you closed on Friday.

This is the promise `CorrelationEngine.correlate()` is built to keep — not a screenshot. No release has shipped yet, so no one has seen this app's own output.

The workflow

Close Project

Pick a project. See everything of it still on the machine. Close it in one operation — with the exact list of what gets removed and what stays because it is shared.

What gets removed
  • Live processes
    Stopped, if their PID and working directory are confirmed in the current scan.
  • Project containers
    Removed, when a container's Compose working directory matches the selected project.
  • Build folders
    Moved to the Trash — never deleted outright, and never Docker volumes.
  • Exclusive images
    Removed only if the image is built by this project and not shared with another one.
What stays, and why
  • Base and registry images
    Kept — project ownership of a pulled image is never assumed.
  • Shared images
    Kept, when the same image belongs to more than one correlated project.
  • Docker volumes
    Always kept. Volume deletion is a separate, higher-risk workflow, never part of Close Project.

Docker volumes are always shown, never removed by this workflow — deleting one is a separate, higher-risk operation with its own confirmation.

What's checkable today

Four things you can verify in the app's own source, not just take our word for.

It never phones home

There is no network call anywhere in the app's source, and its entitlements file is empty. Nothing it correlates leaves your Mac, because there is nothing in the app that could send it.

Sources/ — zero URLSession, NWConnection or socket; Resources/Deckhand/Deckhand.entitlements

Tested without touching your machine

The suite covers the probes, the correlation engine, the safety verdicts and the Close Project planner — and none of it touches a real Docker installation or a real process to do so.

docs/QUALITY_PLAN.md

A universal binary

The release build is signed for both Apple Silicon and Intel Macs — one binary, not a per-architecture download.

scripts/release.conf — ARCHS="arm64 x86_64"

Docker absence is a normal state

Deckhand does not require Docker. When it is not installed or not running, the app shows the other three surfaces and says so, instead of erroring.

docs/PRODUCT_BRIEF.md; docs/SOURCE_MAP.md

Requirements

System
macOS 14.0 or later
Architecture
Universal — Apple Silicon and Intel
Built with
Swift 6, SwiftUI

Where this stands

How the port link is made

v0.1.2

The link between a port held on the host and the container that publishes it is made **by port number, not by process identity**: on macOS the host side of a published port is held by Docker's own networking process, which belongs to no project. The app says so in the sentence it shows — "matched by port number, not by process identity" — and marks the evidence as medium confidence, not certain.

Shipped in 0.1.1. Verified by tests, on a premise measured on a real machine — a process whose working directory cannot be resolved, not one that is absent. Not verified at runtime against live containers.

Questions

No. Docker is one of four surfaces Deckhand reads, shown only when Docker is installed and running. The other three — ports, processes, build folders — work on a Mac with no Docker at all.

Yes — the download is on this page. It is signed with a Developer ID and notarised by Apple, so macOS does not warn: an ordinary double-click opens it the first time.

No. Close Project never touches volumes. They are shown so you know they exist, and removing one is a separate, deliberately higher-risk workflow.

No. There is no network call anywhere in the app's source and its entitlements file is empty — everything it scans stays on your Mac.

It is kept. Deckhand only offers to remove an image it can prove is built by this project alone and used by no other correlated project.

€65

+ VAT, calculated at checkout for your country

Activation

How to activate your licence

Download the app

Download version 0.1.2

2.6 MB

Open the app, go to Preferences → Licence and paste the key from the email.