Dockplane 0.3.0-rc.1

Dockplane 0.3.0-rc.1

The first candidate for 0.3.0. It is 0.2.0 with three changes an operator will
notice: the management interface works at the widths people actually use, the
versions running in a deployment are visible in it, and a host that has been
replaced can be taken out of the working lists without losing anything it ran.

Nothing about how Dockplane manages Docker changed. The agent, its capability
catalog and the Compose compiler are the same code as 0.2.0.

Highlights

The management tables adapt to the width they are given. In 0.2.0 every
list was one desktop table inside a horizontally scrolling box, so a container's
state, health and actions sat outside the window on anything narrower than about
1500 pixels — including a 1440-pixel laptop with the sidebar open, where the
page itself reported no overflow and nothing signalled that the rest of the row
existed. Each column now carries the priority of what it tells an operator, and
the width that decides which are shown is the table's own rather than the
window's: a full table where everything fits, a compact table that keeps what
somebody needs to act, and a stacked list below a tablet's width. What an
operator cannot act without — what the thing is, which host it belongs to, what
state it is in, and the way to act on it — is in the window at every width.

This is the lists and the settings page, not a redesign of the interface.

The settings page no longer moves under its own content. It was the one
screen whose window scrolled sideways — 292 pixels on a phone. Its sessions list
was the only table not using the shared pattern.

Controls are large enough to hit. The sort control in a table heading was
seventeen pixels tall against the twenty-four WCAG 2.2 AA asks for; in the
stacked list a row's action menu is forty-four.

Settings shows what this installation is running. The control server's
release and commit, the browser application's own release and commit, the
migration the database has reached, the agent protocol range, and what the
enrolled agents report. The server and the application are two images and are
reported as two: an operator who has upgraded one and not the other is running
two revisions, and one number called "the Dockplane version" would hide exactly
that.

Agents running different versions are visible as such. A fleet part-way
through a rollout is marked as mixed and is not treated as a fault — an agent on
an older release is supported for as long as its protocol version is one the
control server accepts. Only a protocol outside that range is reported as an
incompatibility, and an agent that has never reported a readable version is
counted as unknown rather than pushed to one end of an ordering.

Dockplane can be asked whether a newer release exists, and does not ask by
itself. The check is off. It stays off on a new installation and across every
upgrade until an administrator sets UPDATE_CHECK_ENABLED=true. Opening the
settings page, loading the dashboard, signing in and enrolling an agent do not
turn it on and cause no request.

When it is on, the control server makes one request, a few times a day at most:
a GET to the project's public release listing at a fixed address that cannot be
configured. It has no query string and no body, and carries no installation
identifier, no domain, no host names, no container or stack names, no counts and
no agent versions. The user agent is the constant string Dockplane. The
release listing learns the address the request came from, which is true of any
HTTP request and is why the check is off until you decide otherwise. Nothing is
downloaded, installed or upgraded by it: the result is a sentence, and upgrading
remains the documented manual process.

There is no auto-updater and no agent auto-upgrade.

A superseded host can be archived. Enrolling a machine again produces a
second host record, and a fleet accumulates them. Archiving takes one out of the
active host lists and stops it being offered as somewhere to run new work.
Everything it carried stays: its containers, its Compose projects, its stacks,
its actions and every audit entry that names it, all still resolving the host
they belong to. Its agent is untouched — not deleted, not revoked, its
certificate unchanged.

A host whose agent is connected cannot be archived, and the control server
decides that when the request arrives rather than from what the page was
showing. An archived host that starts answering again stays archived and is
shown as archived and connected; a heartbeat is not a decision.

Archiving is reversible, and it is not a delete, not a merge and not a
revocation. Dockplane still does not decide that two host records are the same
machine.

Security

No change from 0.2.0. The agent's capability catalog is byte-identical: the
same eighteen typed capabilities, no shell, no exec, no attach, and no way to
run a command on a managed host. Archiving is a lifecycle decision about
Dockplane's own record and changes nothing on any machine.

Archiving and restoring a host require the hosts.archive permission and are
recorded in the audit trail against the host's identifier — not its system
hostname, which every enrolment of a machine shares.

See Security Model and
Agent Security.

Installation

Ubuntu 24.04, Ubuntu 22.04 or Debian 12, with Docker Engine and the Compose
plugin:

VERSION=0.3.0-rc.1

sha256sum -c SHA256SUMS
tar xzf "dockplane-$VERSION.tar.gz"
cd "dockplane-$VERSION"
sudo ./install-control-plane.sh --domain dockplane.example.com

Then sign in and add your first host. See
Installation and
Add a Host.

Upgrading from 0.2.0

The installer is the upgrade: download the release, check it, unpack it, run
it. It takes a backup and validates it before anything changes, and stops if
either fails. Pulling images and editing .env is not an upgrade path.

One migration is applied, 0016_host_archive, which adds a nullable column to
the hosts table. Nothing is rewritten and nothing is inferred: every existing
host stays active, including the ones that are offline, whose agent was revoked,
or that share a system hostname with several others. See
Upgrading.

Upgrade the control plane first, then the agents. Nothing in this release
requires a new agent — the protocol version is unchanged at 1 — so a fleet that
is half-upgraded goes on working.

Supported platforms

Control plane	Ubuntu 24.04, Ubuntu 22.04 or Debian 12, amd64
Managed hosts	Debian 12, Ubuntu 24.04 or Ubuntu 22.04 with systemd

Ports: 80 and 443 for browsers, 9443 for agents. The API and PostgreSQL are not
published. See Supported Platforms.

ARM64

experimental — built and inspected, not runtime-tested

Packages, binaries and images are produced for arm64 and inspected, and no
arm64 machine has run them in production. Use amd64 in production.

This is a release candidate

It is the 0.3.0 feature set, verified end to end, and it has not been run in
anger. Deploy it where you can afford to restore a backup.

Known limitations

Read Known Limitations before deploying.
In short: re-enrolling a machine still creates a new host record and archiving
one is not a merge; a host is never deleted; a container cannot be prepared for
a host that is offline, though a stack can; applying a revision recreates every
service, so a stack is briefly down; deleting a stack leaves its networks and
named volumes behind; a Compose project discovered on a host still cannot be
taken over; a stack secret cannot be read back; backups are not encrypted by
Dockplane; and images are not signed.

License

GNU Affero General Public License v3 only. See
LICENSE.