Nebcon · v0.4 · macOS 14+

One window for Apple container and Docker.

Nebcon is a Mac app for running containers. It works with Apple's container runtime and with any Docker engine you have, either one at a time or all in one list. You can add a project from its compose file, pull an image and start a container from it, and see what everything is using, from a window or from the menu bar. Underneath, it runs the same docker CLI you already use.

Download for macOS

1.9 MB · Apple silicon · unsigned build

The Projects screen: four cards for containers, processor, memory and disk space, above a grid of project cards, each with a run ring, its containers, and what it is using. — The Projects screen. At the top is how much is running and what it's using, and below that is one card per project. The six projects here are each in a different state: one is half up with a crashed worker, one has lost its compose file, one has lost its folder, one is paused, one hasn't been started, and one is running.

01 Runtimes

Apple's runtime, a Docker engine, or both at once.

The picker in the toolbar decides which runtime you're looking at. Choose All runtimes and you get one list with everything in it.

Apple container

Nebcon finds Apple's runtime through the socktainer socket, so there's nothing to set up. Where Apple's runtime works differently from Docker, Nebcon goes along with it. Pause and Commit aren't offered because the runtime can't do them, and the processor and memory figures come from Apple's own container tool.

Docker engines

Every context the docker CLI knows about is in the same picker: Docker Desktop, OrbStack, Colima, or a remote engine over SSH. A context with nothing running behind it is marked offline rather than offered as if it worked.

All runtimes

Every runtime that answers goes into one list, and the usage figures are added together. Each card says which runtime it lives on, and its buttons act on that runtime.

Same project, two engines

If one compose project is up on Apple's runtime and on Docker at the same time, you get two cards, each holding its own containers. Stopping one leaves the other alone.

02 Adding things

Add a project, pull an image, start a container.

All of this happens in the app. Pick one runtime in the toolbar first, since whatever you add has to go somewhere.

Add a project

Click Add project and choose the folder your compose file is in. Nebcon asks Compose what the project is called and which services it has, then adds a card for it. Press Start and the containers are created.

Pull an image

Type a name such as postgres:16 at the top of the Images screen and press Pull.

Run one container

Choose Run from an image's menu to start a container from it. You can give it a name, publish ports, set environment variables and change the command, or leave all of that empty. It's meant for the database you want to try something against. Once there's more than one container, a compose file is the better place for it.

Log in to a registry

Registry login on the Images screen signs docker in to Docker Hub, GitHub's registry or your own, so you can pull private images and push. The password goes straight to docker login, and Nebcon doesn't keep a copy.

03 Usage

See what each project is costing you.

The Projects and Containers screens both open with four numbers: how many containers are running, and how much processor, memory and disk they're using. Every project and every container carries the same three figures, so the heavy one is easy to spot.

Open a project and each container gets a card of its own, which says in one word whether it's running, healthy, stopped or crashed. A published port shows as localhost:5432, and clicking it opens your browser. On Apple's runtime each container also has an address of its own that you can reach from your Mac on any port, published or not. Click it to copy it. If a container fails its health check or exits with an error, the card says so and the logs are one click away.

A project opened: its processor, memory and disk use, a notice that the worker stopped with an error, and one card per container with its port, its own address, and Start, Stop, Restart and Logs.

04 Projects stay put

Stopping a project doesn't make it disappear.

When you run compose down, the containers are deleted, and with them goes the only record of which project they belonged to. Most apps then drop the project from the list, and the Start button goes with it. Nebcon remembers your projects, so a stopped one stays where it was, ready to start again.

When something breaks, you get an explanation instead of a spinner. Errors are red. Warnings, where the command ran but something looked off, are amber.

The same screen with three banners at the top: a red compose error, an amber warning about missing variables, and a runtime update notice.

05 Deleting

You see exactly what gets deleted.

Deleting a project is the one thing in Nebcon that really destroys data, so it does more than ask whether you're sure. It lists every container and every volume that would go, with their sizes. If another project still uses one of those volumes, Nebcon keeps it and tells you which project that is.

The button is specific too. Instead of Delete, it says Delete 2 containers + 1 volume + files.

The delete sheet listing two containers, one volume to remove at 69.4 MB, and one volume kept at 318.8 MB because another container still uses it.

06 Setup

It can set up Apple's runtime for you.

Apple's runtime needs four command-line tools: Apple's container, socktainer (which lets Docker talk to it), the docker CLI and Docker Compose. Settings shows which versions you have and can install or update them with Homebrew. If you already run a Docker engine, you don't need any of this.

Installing does the rest of the job as well. It downloads the kernel, starts the services, and repairs the Compose plugin link, which is often still pointing at an app you uninstalled a long time ago.

The same pane shows Apple's image builder. It's a container of its own and holds on to its memory until you stop it, so you can see whether it's running, stop it, and choose how much it gets next time. And when it's the runtime itself that's misbehaving, Logs shows what its services have been saying.

The runtime tools pane: four tools with their versions and status, a note saying the update is installed but the old version is still running, and the image builder running with 4 CPUs and 8 GB. — The amber note appears when an update has installed but the old version is still running. Press Restart to finish.

07 Cards

Everything is a card, at any window size.

Each container is a card with its name, its state, where to reach it and what it's using. Start, Stop, Restart and Logs are buttons with words on them, so you don't have to hover over icons to find them. The cards reflow as you resize the window, down to a single column when it's narrow.

The Containers screen: four cards for containers, processor, memory and disk space, above a grid of container cards. Running, stopped, paused and crashed containers, each with its addresses, its processor, memory and disk figures, and Stop, Restart and Logs buttons.

08 Logs and images

Fewer trips to the terminal.

The commands you'd otherwise type are in the menu on each card and each image.

Logs that go back further

A log window starts with the last 300 lines. You can ask for 1,000, 10,000 or the whole thing, and on a Docker engine you can also start from five minutes, an hour or a day ago. Save writes what's on screen to a file.

The boot log

On Apple's runtime each container is a small VM. When one won't start, its log is empty, because it never got far enough to write anything. Tick Boot to see what the kernel and init said instead.

Inspect

Shows the full JSON for a container or an image, which you can read, copy or save.

Rebuild

Start reuses an image it has already built, even after the Dockerfile has changed. A project that builds its own images gets Rebuild and start, and you can watch the build as it runs.

Tag and push

Tag gives an image a second name, which is how you point it at a registry and an account. Push uploads it and shows docker's own progress and errors as they come.

09 Why use it

The small stuff that saves you time.

Nobody asks for features like these. I added each one after it caught me out.

It checks your compose file first

If a variable from your .env is missing, Compose quietly fills in a blank and starts anyway. You end up with a database that won't start and no idea why. Nebcon checks the file first and tells you which variable is missing.

It hides buttons that won't work

Apple's runtime can't pause containers or save them as images, so Nebcon doesn't show those buttons there. You'd only click one and get an error. On a Docker engine they're in the menu.

It switches when a runtime goes away

If the runtime you're using stops answering, maybe because you restarted it or uninstalled something, Nebcon moves to one that works and tells you it did.

Red means something is wrong

A container you stopped isn't a problem, and Nebcon doesn't color it like one. Red is saved for a container that exited with an error or is failing its health check.

It handles socktainer's quirks

socktainer renames some Compose labels, turning working_dir into working-dir, and never answers docker stats. Nebcon reads both spellings and gets the numbers another way, so your projects still group correctly and the usage figures still show up.

It shows real volume sizes

socktainer reports every volume as -1B. Nebcon measures the volume's disk image instead, so you see how much space it really takes.

It won't start the wrong project

If a folder has no compose file, Compose looks in the parent folder and can start a completely different project. Nebcon won't run Compose there. It tells you why, and Start and Stop still work on the containers that exist.

It frees space by name

Free up space lists every stopped container, unused image and unused volume with its size, and says which ones can't be brought back. Nothing is selected until you select it.

10 Limits

What it doesn't do.

Nebcon is the app that sits on top of a runtime. If you want the engine, a VM and everything else in one package, other tools are built for that.

No engine: Nebcon doesn't include a runtime, VM or kernel. It works through the docker CLI, so you need a runtime installed and running.
No Kubernetes or Linux VMs: It handles containers, images, volumes and Compose projects.
Adding needs one runtime: Under All runtimes you can start, stop and delete anything, but adding a project, pulling an image and logging in to a registry are turned off. Each of those has to go to one runtime, so pick it first.
Exec isn't a full terminal: The built-in exec runs one command at a time. For anything interactive, use Open in Terminal from the same menu.
Updates on a timer: Apple's runtime doesn't send live updates, so Nebcon checks every two seconds while its window is open and every ten when it isn't. Processor and memory are sampled every five seconds.
Not signed: The app isn't signed or notarized by Apple, so macOS warns you the first time you open it.

11 Get it

Up and running in a minute.

Download Nebcon 0.4

1.9 MB · macOS 14+ · Apple silicon

Open the disk image and drag Nebcon into Applications.
Open Nebcon. macOS blocks it the first time because it isn't signed.
Go to System Settings › Privacy & Security, scroll down to the message about Nebcon, and click Open Anyway.

Or use Terminal

xattr -dr com.apple.quarantine /Applications/Nebcon.app

This removes the flag macOS puts on apps you download. That flag is what the warning is for, so only do this if you trust where the app came from.

What you need

A Mac with Apple silicon running macOS 14 or later, and a container runtime: Apple's container with socktainer, a Docker engine you already have, or both. Homebrew is optional, but with it Nebcon can install and update Apple's runtime for you.