Docker Client MX

News

What we shipped, and what comes next.

Docker Client MX moves in small releases — a handful of features, a real check against a real daemon, and out the door. This is the short version of the last few. The app updates itself, so you are on the newest one already.

Current release 1.53.0 ·

1.53.0

Images that update themselves — and roll back when they do not come up

Pick a moment, pick a project or a container, and the app pulls the newer image, recreates what runs on it, and watches it for five minutes. If it does not stay up, the old image goes back exactly as it was. You read about it afterwards instead of babysitting it.

  • A fixed time per project or container, and a list of what is behind right now.
  • A five-minute settle window; a container that exits or turns unhealthy is rolled back to the image it had.
  • Anything a compose file owns is skipped, because the file is the truth there.
  • One notice in the morning and a round on the dashboard: what was updated, what stayed, what was put back.
Update by itself →
1.52.0

Choose the machine the app starts on

The app used to open on whatever the Docker CLI pointed at. Now you decide: the machine you were last on, one you name yourself, or the CLI context after all. The setting sits on the settings page, and the status bar says which of the three you got.

  • Three options: last used, a fixed machine, or follow the CLI.
  • DOCKER_HOST still wins, because the environment is a deliberate choice too.
  • The machine you switch to is remembered, so "last used" needs no maintenance.
Machines and connections →
1.51.0

A machine that does not answer no longer holds up the window

A startup machine is only useful if the app survives it being off. It now probes before it commits, falls back to one that does answer, and says on the dashboard what it fell back from. Nothing hangs while a laptop waits for a server that is asleep.

  • A four-second probe per machine, then a fallback with the reason in plain words.
  • Volumes finally show up in the engine events: Docker puts a volume name in a field nobody expects.
  • A divider in the sidebar between the pages you work on and the app itself.
Events and history →
1.50.0

A day of CPU and memory, the notices you missed, and every engine event

Three pieces of the same idea: a problem that starts while you are not looking should still be there when you get back. The app keeps a day of usage per container, holds on to the notifications you did not see, and lists what the engine reported.

  • A rolling day of CPU and memory, so a leak has a shape instead of a number.
  • Notices you missed stay readable; a Windows toast that nobody saw is not a report.
  • One page with everything the daemon announced: created, started, died, pulled, removed.
Events and history →
1.49.0

A checkup that says what could be better before it breaks

Not a scanner and not a grade — a short list of things worth fixing on this machine, each with the reason and the way out. It also produces a written report of what runs where, for the moment you need to hand that to somebody.

  • Containers without limits, without a healthcheck, restarting in a loop, publishing on every interface.
  • Passwords stay off the screen, and the checkup points out where they should not be sitting.
  • A report of a machine, yours or another, that you can keep.
Checkup →
1.48.0

Every Docker machine on one page

Every context you have, with what runs on it and whether it answers at all. Switching is one click, copying an image or a volume to another machine is another, and notifications from the machines you are not on now reach you where you are.

  • Each context with its version, its containers and its reason for staying quiet.
  • Copy an image or a volume from one machine to another, without a registry in between.
  • Notifications from machines you are not currently on.
Machines and connections →
1.47.0

Volumes you can actually restore

Backing up is the easy half. This release does the other half: restore from the backups the app made itself, stop whatever is using the volume first, and start it again when the restore is done.

  • Restore from the backups the app made, or back up right now.
  • Users of a volume are stopped during a restore and started again afterwards.
  • Volumes, folders and the healthcheck of a standalone container are editable.
  • A notice when a container sits at its memory limit.
Volumes →
1.45.0

Where the disk went, and a backup schedule per volume

Docker is quietly expensive on disk, and the answer is usually one image or one volume you forgot about. The dashboard now says which. Volumes got a schedule of their own, so the backup does not depend on you remembering.

  • The biggest images, volumes and containers, with what is safe to remove.
  • A backup schedule per volume, and a weekly cleanup of untagged images and build cache.
  • Edit and upload a file inside a volume without starting a container for it.
Dashboard →

In the works

The other machine, without switching to it.

Written down before it exists, so read it as a plan rather than a promise. The order is deliberate: reading first, buttons afterwards.

See another machine without switching to it

The machines page already counts the containers on your server. Soon you can unfold that count and read the rows themselves — name, image, status, compose project — without the app tearing down every stream to move house.

And act on them, carefully

Start, stop, restart and read the logs of a container on another machine, over a connection that closes again afterwards. Every row and every panel carries the machine name, because this is exactly where a mistake is the kind you do not notice.

The difference between two machines

Two machines side by side: which images run on both, and at which version. What differs goes on top; what matches needs no attention. Copying an image across is the button that is already there.

Every release, in full.
The changelog and the downloads live on Codeberg. Free and open source.
Releases on Codeberg
$ npx docker-client-mx