Dockplane 0.3.0

Dockplane 0.3.0

The third stable release.

The interface now answers what a deployment is running, and on which
machines. Versions are reported per component and per agent, a host
that has been replaced can be taken out of the working set without losing what
it ran, and the management views stay usable at the widths people actually work
at. What Dockplane manages is unchanged from 0.2.0: the same capability
catalog, the same containers and stacks, the same trust boundary.

Highlights

The management views fit the window. Every column carries the priority of
what it tells an operator, and the width that decides which columns are shown is
the table's own rather than the browser's — so a wide window with the sidebar
open is treated as the narrower content area it is. What somebody 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 view at every width, without scrolling sideways.
Below a tablet's width a table becomes a stacked list rather than a table nobody
can read.

Settings says what this installation is. 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 every enrolled agent
reports. The server and the application are two images and are reported as two:
an operator who upgraded one and not the other is running two revisions, and one
number called "the Dockplane version" would hide exactly that.

A fleet on more than one version is shown as one, not 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, and stays off on a new installation and across every
upgrade until an administrator sets UPDATE_CHECK_ENABLED. When it is on, the
control server makes one request a few times a day to a fixed public address,
with no query string, no body and nothing about the installation in it. Nothing
is downloaded, installed or upgraded by it: the result is a sentence. 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 lists and stops it being offered as somewhere to run new work, and
everything it carried stays: its containers, Compose projects, stacks, actions
and every audit entry that names it. Its agent is untouched — not deleted, not
revoked. 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.

A stack's containers are its own, everywhere. Dockplane labels every
container it builds for a stack with the stack, the service and the revision, and
those labels now travel from the host through to what the interface shows. A
running stack reads as deployed, its operations find the containers they are
meant to act on, and the container lists say which stack a container belongs to
rather than presenting it as somebody else's.

Security and supply chain

The agent is scanned and its reports are published. Until this release the
vulnerability reports covered the two control-plane images; the agent — the
artifact that ends up on every managed host — had none. It is now scanned on
both architectures, from the binary in the release tarball rather than one built
for the occasion, with the same scanner, the same severities and the same
release policy the images are held to. Both reports are published as release
assets and covered by SHA256SUMS.

A missing report is now a failed release. Every one of the six reports is
required by name. Before, they were expected only if a matching file happened to
be present, so a scan that never ran and a scan that found nothing looked the
same.

The Go toolchain moved to 1.26.6, which resolves the standard-library
findings the 0.3.0-rc.2 build carried in the Compose compiler and in the agent.

Release inputs are pinned. Every base image is named by digest as well as by
tag, including the one the agent is compiled in, so what a build consumes is a
function of the commit rather than of the day it ran.

The assessment behind the published numbers, including findings that are carried
with a reason, is in
Vulnerability Assessment. The agent's evidence
is its checksums and those scan reports; it has no bill of materials and no
provenance attestation of its own.

Installation

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

VERSION=0.3.0

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

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. Every existing host stays active, including the ones that are
offline or whose agent was revoked.

Upgrade the control plane first, then the agents. The protocol version is
unchanged at 1, so a half-upgraded fleet goes on working: inventory, metrics,
logs, container operations and Compose discovery are served by an older agent
exactly as before.

Stack management is the exception. Attributing a stack's containers depends
on what the agent reports, so a host whose agent predates 0.3.0-rc.2 has its
stack operations refused with AGENT_UPGRADE_REQUIRED before anything is sent
to it. That host is not incompatible and nothing else it serves is affected.
Upgrading its agent is the whole repair: the package upgrade keeps the host's
identity and its private key, so nothing is enrolled again. See
Upgrading and Stacks.

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. Use amd64 in production.

Known limitations

Read Known Limitations before deploying.
In short:

• There is no remote shell, exec or attach, and no generic command execution
  on a managed host.
• A host is never deleted and two host records are never merged. Archiving takes
  a host out of the working set; nothing deduplicates by hostname or by anything
  else.
• A host whose agent is connected cannot be archived, and an archived host that
  starts answering again stays archived.
• Compose projects discovered on a host are read-only and cannot be taken over.
• build: is refused: Dockplane deploys images, it does not build them.
• There is no automatic update, no self-updater, no APT repository, and no Git
  or webhook integration.
• There is no downgrade path.
• Re-enrolling a machine creates a new host record.
• Applying a revision recreates every service, so a stack is briefly down while
  it is rebuilt.
• A rollback deploys an earlier configuration; it does not restore data. Volumes
  are never removed, and a stack's networks are not removed when it is deleted.
• A backup holds the control plane's own state. Nothing on a managed host is in
  it — not your containers, not their volumes, not their data.
• Volume deletion and image management are not implemented.
• Notifications, alerting and scheduled automation are not in this release.
• Backups are not encrypted by Dockplane, and images are not signed.
• Container output is not stored; logs are read from the host when you ask for
  them.
• arm64 is experimental, as above.

License

AGPL-3.0-only. See LICENSE.

Dockplane 0.3.0-rc.2

Dockplane 0.3.0-rc.2

The second candidate for 0.3.0. It is 0.3.0-rc.1 with one defect fixed, and
the defect is one an operator could have been bitten by without noticing: a
stack whose containers were running reported that it had never been deployed,
and deleting it reported success while leaving the containers where they were.

Everything 0.3.0 adds is unchanged — responsive management lists, version
visibility, host archival — and so is the way Dockplane manages Docker. The
agent's capability catalog is the same eighteen typed capabilities.

What was wrong

Dockplane labels every container it creates for a stack with three things: which
stack it belongs to, which of the stack's services it is, and which revision it
is running. The control server reads those labels to decide which containers on
a host are a given stack's own.

The agent never sent them. It reports containers through an allow list — labels
are free-form and routinely carry deployment detail and credentials, so only the
ones the product groups by leave the host — and the three stack labels were not
on it. They had been on the containers since stacks arrived and on the list
since before stacks existed.

What an operator saw:

• A stack deployed successfully, its containers started, and the deployment was
  reported as failed with STACK_APPLY_FAILED — "the host is as it was", which
  was not true.
• The stack stayed at not deployed while its containers ran.
• Starting, stopping and restarting it found no containers to act on.
• Deploying it again was refused because the container names were taken, by
  containers the server did not recognise as the stack's own.
• Deleting it answered 200 deleted, removed the stack from Dockplane, sent
  nothing to the host, and left the containers running.

The last of those is the one that matters most. The check that refuses to delete
a stack whose containers are still on its host was there and was correct; it
looks for containers that claim the stack, found none because none could claim
anything, and concluded there was nothing to remove.

This has been present since 0.2.0-rc.1 and is in the released 0.2.0. It is
not a regression in 0.3.0-rc.1.

What changed

The agent forwards the three stack labels. The allow list is still an allow
list — no wildcard, no prefix matching, nothing an operator wrote on a container
of their own. The three labels are identifiers Dockplane generated and a service
name it read from a revision it compiled.

Stack operations require an agent from this release. A control server is
upgraded before its fleet, so an upgraded server will be talking to agents that
still cannot report attribution. Deploying, starting, stopping, restarting and
removing a stack are refused for such a host with AGENT_UPGRADE_REQUIRED,
before anything is sent to it — a host is never given work whose result cannot
be read back.

This is not a protocol incompatibility. The protocol version is unchanged at 1,
those agents remain connected and supported, and inventory, metrics, logs,
container operations and Compose discovery on their hosts are untouched. The
version report still shows them as an older release in a mixed fleet, not as
incompatible.

A stack that was never deployed is still deletable on any host. Nothing can
have been left behind by a deployment that never happened.

Upgrading

The control plane first, then the agents, as always:

VERSION=0.3.0-rc.2

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

No migration is applied. The schema is 0016_host_archive, as in
0.3.0-rc.1; upgrading from 0.2.0 applies that one migration as it did
before.

Then upgrade the agent on every host that runs stacks. Until you do, that host's
stacks are readable and unchangeable.

Recovering a host that ran an older agent

Upgrade the agent. Nothing else is needed, and no database repair is involved:
the next inventory carries the labels, discovery attributes the containers to
their stack, and the stack's services resolve again.

Two states do not resolve themselves, because neither is Dockplane's to decide:

A stack whose deployment never completed still reads as not deployed. That
deployment genuinely never completed, and the record says so. Apply its revision
again — the containers are recognised as the stack's own and the stack is
reconciled to what you applied.

A stack that was deleted is not recreated. Its containers keep running and
still carry a label naming a stack that no longer exists. Dockplane leaves them
alone: they stay visible as managed containers on their host, belonging to no
stack, and nothing invents a stack to hold them.

They are also not removed. You can stop such a container from Dockplane, but
removing it answers CONTAINER_NOT_MANAGED: removing a container through
Dockplane needs a configuration Dockplane holds for that container, and one that
belonged to a stack has none of its own. Cleaning these up means connecting to
the Docker host, confirming which containers they are, and removing them there
with docker rm. See Stacks.

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,
and Archiving Hosts and
Stacks for what this release changes.

License

GNU Affero General Public License v3 only. See
LICENSE.

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.

Dockplane 0.2.0

Dockplane 0.2.0

The second stable release.

Dockplane now runs workloads rather than only watching them. You write a
Compose file in Dockplane, save it, and deploy it to one of your hosts.
Dockplane owns what it created: it knows which containers belong to that stack,
which revision they are, and how to take them away again. Everything 0.1.0 did
— the inventory, the agents, the audit trail — it still does.

Highlights

Stacks. A Compose file, saved in Dockplane and deployed to a host. Every
save is an immutable revision, so what is saved and what is running stay two
separate facts and the interface never conflates them. A stack with changes
that are saved but not deployed says so; a stack whose host does not match any
complete revision says that instead, and stops.

Any revision, forwards or back. Applying revision three to a stack running
revision five is a rollback, and it is named that way. Dockplane converges the
host on whichever revision you chose.

Secrets that stay secret. A stack's environment can hold secrets. They are
encrypted at rest under the deployment's own key — not the database's — and
travel to the host inside the deployment plan. They appear in no log, no audit
entry and no API response. Dockplane shows that a secret is set; it will not
show you what it is.

Start, stop, restart. A deployed stack moves between running and stopped
without being redeployed, in dependency order, and the result is read back off
the host rather than taken from the agent's word for it.

Delete. A stack's service containers are removed and its saved
configuration and revision history are deleted. Named volumes are kept, and
no data in them is deleted. A deployed stack has to be named back before the
action is offered, and a stack whose host state is unclear cannot be deleted at
all.

Containers you create by hand. A single container can be created,
reconfigured and removed from the interface. Reconfiguring recreates it on
Docker's side, and it stays the same container in Dockplane — same identity,
same history, same audit trail. Creating one lists every host and says which of
them can be chosen: a host whose agent is offline is shown and cannot be
selected, with the reason given before the form is filled in.

Compose that says no. A file is compiled and checked before it can be
saved. Anything Dockplane will not deploy is refused with the path in the file
and a sentence saying why, rather than deployed with that part quietly missing.
See Compose Support.

A host is named by the name you gave it. A machine enrolled more than once
leaves a host resource behind for every enrolment, and every one of them reports
the same system hostname. The name you chose leads and the system hostname
follows it, everywhere a host appears. Nothing is merged and nothing is
deduplicated: they are separate hosts, and they look it.

Last known means last known. A host that stops answering marks its readings
as the last ones at once, and its containers and Compose projects do the same.
Its CPU, memory and disk are kept and labelled with when they were reported
rather than dropped, a container whose host went quiet still opens and shows the
last state seen, and opening its logs says the live stream is unavailable rather
than reporting an operation that was not carried out. A stack on an offline host
says what that does and does not prevent: configuration and new revisions can be
saved, and deploying waits for the host to come back.

Enrolment is one command. Dockplane produces it, and it works out what the
machine is, downloads the agent package matching this control plane, checks it
against the checksums published with that release, installs it, enrols the host
and starts the service. The agent holds its own certificate, obtained once with
a short-lived ticket, and connects outward over mTLS; nothing needs to reach
into the managed host.

Releases can be rebuilt. Building this release from its own commit produces
the same images and the same agent packages, on a different machine and at a
different time, so a published artifact can be checked against a build of the
source it names. What a build records about itself — its provenance attestation
— still describes that build.

Security

No remote shell. The agent has a fixed catalog of typed capabilities and no
way to run anything else. Stacks are capabilities like the rest —
stack.deploy, stack.start, stack.stop, stack.restart, stack.remove —
each carrying a resolved plan. No Compose file, YAML parser, Compose CLI or
command string reaches a managed host. Compose is read in one place, the control
server, and nowhere else.

• Dockplane touches only what it can prove is its own. Every container,
  volume and network it creates carries its identity. An operation that finds a
  container it cannot prove belongs to the stack it was asked about stops rather
  than acting, and a deployment refuses a volume or network carrying somebody
  else's.
• A half-applied stack blocks rather than guesses. If the host does not
  match one complete confirmed revision, the stack needs attention and nothing
  further is applied, operated or deleted until a person chooses a revision.
• An operation whose result never came back is not repeated. The stack stays
  blocked, and the next complete reading of that host settles what happened.
• Deleting a stack is not deleting its data. Named volumes are kept, and a
  new stack of the same name will not adopt them.
• Destructive actions carry their own permissions, need the resource named
  back, and are recorded with actor, target, result and request identifier.

Three permissions that guarded nothing — roles.manage, stacks.adopt and
stacks.secrets.reveal — were removed from the catalog. They could be granted
and conferred nothing, which is worse than not existing.

See Security Model,
Agent Security and
Authentication.

Installation

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

VERSION=0.2.0

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

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.

Upgrading from a 0.2.0 release candidate changes no schema. Upgrading from
0.1.0 migrates it.

Upgrade the control plane first, then the agents. While a fleet is
half-upgraded, everything 0.1.0 could already do goes on working on every host,
and an operation this release added is refused on a host whose agent has not
been upgraded yet — with This host does not support that operation. Nothing is
changed on that host and nothing is recorded as if it had been. See
Upgrading.

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. Use amd64 in production.

Known limitations

Read Known Limitations before deploying.
In short:

• There is no remote shell, exec or attach, and no generic command
  execution on a managed host.
• Compose projects discovered on a host are read-only and cannot be taken over.
• build: is refused: Dockplane deploys images, it does not build them.
• There is no automatic update, no self-updater, no APT repository, and no Git
  or webhook integration.
• There is no downgrade path.
• Re-enrolling a machine creates a new host record; the old one stays behind and
  nothing is merged automatically.
• An agent must reach the control plane at the hostname it was enrolled with.
• Applying a revision recreates every service, so a stack is briefly down while
  it is rebuilt.
• A stack's networks are not removed when it is deleted, volumes are never
  removed, and a volume left behind by a deleted stack is not reused by a new
  one.
• A rollback deploys an earlier configuration; it does not restore data.
• A stack secret cannot be read back.
• Volume deletion and image management are not implemented.
• Notifications, alerting and scheduled automation are not in this release.
• Backups are not encrypted by Dockplane, and images are not signed.
• Container output is not stored; logs are read from the host when you ask for
  them.
• arm64 is experimental, as above.

License

AGPL-3.0-only. See LICENSE.

Dockplane 0.2.0-rc.4

Dockplane 0.2.0-rc.4

The fourth candidate for 0.2.0, and a release-correctness candidate: nothing
about managing Docker changed since 0.2.0-rc.3. The control server, the
application, the agent and the Compose compiler are the same code, and this
release exists because of how that code is built and packaged rather than
because of anything it does.

0.2.0-rc.4 corrects release-build reproducibility discovered during the
verification of 0.2.0-rc.3.

Highlights

A release can be rebuilt from its own commit. Building 0.2.0-rc.3 twice
produced two different sets of images, which meant the published artefacts could
not be checked against a build of the source they name. They can be now: the
same commit produces the same images and the same agent packages, on a different
machine and at a different time. What a build records about itself — its
provenance attestation — still describes the build that made it, and the release
manifest records the digest that was actually published.

Images carry the release, and nothing about the machine that built it.
Timestamps inside the layers were left at the minute each build ran. A
checkout's own file times and permissions reached the image through the files
the compilers copy rather than generate — the database migrations, the icons and
fonts — and those are properties of a working copy, not of a commit. An image
built for an architecture other than the building machine's also carried the
emulator's translation cache: an amd64 image built on Apple silicon contained
it.

An agent package declares a size it derives from its own contents. It was
read from the block allocation of the filesystem the package was staged on, so
two builds of byte-identical payloads declared different sizes and were
different files.

A check that cannot run says so. A release gate written against a newer
shell than the one running it printed an error, reported nothing, and exited
successfully. Gates now refuse before reporting anything.

Security

No change from 0.2.0-rc.1. Stacks remain typed capabilities, no Compose file
or command string reaches a managed host, and a stack whose host state is
unclear is still blocked rather than guessed at. See
Security Model,
Agent Security and
Authentication.

Installation

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

VERSION=0.2.0-rc.4

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

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.

Upgrading from 0.2.0-rc.1 or 0.2.0-rc.3 changes no schema. Upgrading from
0.1.0 migrates it, as that release's notes describe. Either way, upgrade the
control plane first and the agents afterwards. See
Upgrading.

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. Use amd64 in production.

This is a release candidate

It is the 0.2.0 feature set as 0.2.0-rc.3 shipped it, built so that the
result can be verified. Deploy it where you can afford to restore a backup.

Known limitations

Unchanged from 0.2.0-rc.1. Read
Known Limitations before deploying. In
short: applying a revision recreates every service, so a stack is briefly down
while it is rebuilt; deleting a stack leaves its networks and its 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

AGPL-3.0-only. See LICENSE.

Dockplane 0.2.0-rc.3

Dockplane 0.2.0-rc.3

The third candidate for 0.2.0, and a bugfix candidate: no new features since
0.2.0-rc.1.

Everything here is one subject seen from several pages — which host a record
belongs to, and whether what is on the screen is happening now or is the last
thing anybody saw. Running the first candidate against a real deployment made
both questions hard to answer, and this release answers them.

0.2.0-rc.2 was not published as a release: publication stopped before any
artifact was built. This candidate carries the same product fixes.

Highlights

A host is named by the name you gave it. A machine enrolled more than once
leaves a host resource behind for every enrolment, and every one of them
reports the same system hostname. Hosts, agents, containers and stacks all
showed that one word, so six different machines read as one. The name you chose
now leads and the system hostname follows it, everywhere a host appears —
including the deployment dialog and the stack list. Nothing is merged and
nothing is deduplicated: they are separate hosts, and they look it.

Last known means last known, immediately. A host that stops answering marks
its readings as the last ones at once, because nothing is going to refresh
them. Its containers and its Compose projects now do the same. For the length
of the staleness window, one page used to show workloads as running beside a
host that already said it was offline.

A host's readings stay on its page. CPU, memory and disk are kept while a
host is offline, labelled with when they were reported, rather than dropped.

A container whose host went quiet still opens. It was reported as though
the container no longer existed, which sent people looking for a workload that
had not gone anywhere. Its page opens, its state is shown as the last one seen
rather than in the colour of a running workload, and it says when it was
observed.

Logs say what is missing. Opening the logs of a container on an offline
host says the live stream is unavailable, instead of reporting it as an
operation that was not carried out.

A stack on an offline host says what it can still do. Configuration and new
revisions can be saved; deploying waits for the host to come back. Only the
deployment controls mentioned this before, each in a tooltip.

Fields look like fields. Form controls are easier to make out before they
are focused, in both themes. Several were drawn without a border at all in the
dark theme, and the sign-in fields were drawn as a box around their label
rather than around the input.

Creating a container says which host it can use. Every host is listed, a
host whose agent is offline cannot be selected, and the reason is given before
the form is filled in rather than after it is submitted.

Security

No change from 0.2.0-rc.1. Stacks remain typed capabilities, no Compose file
or command string reaches a managed host, and a stack whose host state is
unclear is still blocked rather than guessed at. See
Security Model,
Agent Security and
Authentication.

Installation

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

VERSION=0.2.0-rc.3

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

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.

Upgrading from 0.2.0-rc.1 changes no schema. Upgrading from 0.1.0 migrates
it, as that release's notes describe. Either way, upgrade the control plane
first and the agents afterwards. See Upgrading.

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. Use amd64 in production.

This is a release candidate

It is the 0.2.0 feature set with the first candidate's reporting corrected.
Deploy it where you can afford to restore a backup.

Known limitations

Unchanged from 0.2.0-rc.1. Read
Known Limitations before deploying. In
short: applying a revision recreates every service, so a stack is briefly down
while it is rebuilt; deleting a stack leaves its networks and its 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

AGPL-3.0-only. See LICENSE.

Dockplane 0.2.0-rc.1

Dockplane 0.2.0-rc.1

The first candidate for 0.2.0.

Dockplane now runs workloads rather than only watching them. You write a
Compose file in Dockplane, save it, and deploy it to one of your hosts.
Dockplane owns what it created: it knows which containers are that stack's,
which revision they are, and how to take them away again.

Highlights

Stacks. A Compose file, saved in Dockplane and deployed to a host. Every
save is an immutable revision, so what is saved and what is running are two
separate facts and the interface never conflates them. A stack that has
unsaved-but-undeployed changes says so; a stack whose host does not agree with
any complete revision says that instead, and stops.

Any revision, forwards or back. Applying revision three to a stack running
revision five is a rollback, and it is named that way. Dockplane converges the
host on whichever revision you chose.

Secrets that stay secret. A stack's environment can hold secrets. They are
encrypted at rest under the deployment's own key — not the database's — and
travel to the host inside the deployment plan. They appear in no log, no audit
entry and no API response. Dockplane shows that a secret is set; it will not
show you what it is.

Start, stop, restart. A deployed stack can be moved between running and
stopped without being redeployed, in dependency order, and the result is read
back off the host rather than taken from the agent's word for it.

Delete. A stack's service containers are removed and its saved
configuration and revision history are deleted. Named volumes are kept, and
no data in them is deleted. A deployed stack has to be named back before the
action is offered, and a stack whose host state is unclear cannot be deleted at
all.

Containers you create by hand. A single container can be created,
reconfigured and removed from the interface. Reconfiguring recreates it on
Docker's side, and it stays the same container in Dockplane — same identity,
same history, same audit trail.

Compose that says no. A file is compiled and checked before it can be
saved. Anything Dockplane will not deploy is refused with the path in the file
and a sentence saying why, rather than deployed with that part quietly missing.
See Compose Support.

Security

Still no remote shell. Stacks are typed capabilities like everything else —
stack.deploy, stack.start, stack.stop, stack.restart, stack.remove —
carrying a resolved plan. No Compose file, YAML parser, Compose CLI or command
string reaches a managed host. Compose is read in one place, the control server,
and nowhere else.

• Dockplane touches only what it can prove is its own. Every container,
  volume and network it creates carries its identity. An operation that finds a
  container it cannot prove belongs to the stack it was asked about stops
  rather than acting, and a deployment refuses a volume or network that carries
  somebody else's.
• A half-applied stack blocks rather than guesses. If the host does not
  match one complete confirmed revision, the stack needs attention and nothing
  further is applied, operated or deleted until a person chooses a revision.
• An operation whose result never came back is not repeated. The stack stays
  blocked, and the next complete reading of that host settles what happened.
• Deleting a stack is not deleting its data. Named volumes are kept, and a
  new stack of the same name will not adopt them.

Three permissions that guarded nothing — roles.manage, stacks.adopt and
stacks.secrets.reveal — have been removed from the catalog. They could be
granted and conferred nothing, which is worse than not existing.

See Security Model,
Agent Security and
Authentication.

Installation

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

VERSION=0.2.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.1.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.

Upgrade the control plane first, then the agents. While a fleet is
half-upgraded, everything 0.1.0 could already do goes on working on every host,
and an operation this release added is refused on a host whose agent has not
been upgraded yet — with This host does not support that operation. Nothing
is changed on that host and nothing is recorded as if it had been. See
Upgrading.

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. Use amd64 in production.

This is a release candidate

It is the 0.2.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: applying a revision recreates every service, so a stack is briefly
down while it is rebuilt; deleting a stack leaves its networks and its 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

AGPL-3.0-only. See LICENSE.

Dockplane 0.1.0

Dockplane 0.1.0

The first stable release.

A self-hosted control plane for managing Docker across multiple hosts. You
run it yourself, on your own machine, and it reaches your Docker hosts through
an agent that connects outward. Nothing about your infrastructure leaves your
network, and there is no account to create anywhere.

Highlights

Multi-host inventory. Every connected Docker host in one place, with its
operating system, Docker version, metrics and connectivity — and with what is
stale marked as stale rather than presented as current.

One-command host onboarding. Hosts → Add host produces a single command.
Run it on the new machine and it works out what the machine is, downloads the
agent matching this control plane, verifies it against the checksums published
with that release, installs it, enrolls the host and starts the service. Docker
Engine has to be there already; nothing else is installed.

Container lifecycle. Start, stop and restart, each behind its own
permission, confirmed before it runs, recorded as an action and in the audit
trail, and answered with the state actually observed on the host afterwards.

Historical and live logs. What a container has printed, and a stream that
follows it, with stdout and stderr kept apart. Closing the view stops the read
on the host rather than leaving it running.

Compose visibility. Projects discovered on each host, with their membership
and aggregated state, and inspected on request.

Operators and access. Local accounts, TOTP second factors with single-use
recovery codes, server-side sessions you can list and revoke, and roles whose
permissions are enforced by the control server rather than by what the
interface chooses to show.

Audit history. Who did what, to what, with what result, and the request it
belongs to.

Backup and restore. The database, the application encryption key, the agent
certificate authority and Caddy's certificates, with a manifest and checksums.
A restore validates the whole backup before touching anything.

Upgrades that migrate. The installer recognises what is installed, takes a
backup and reads it back before it changes anything, replaces the deployment's
files, migrates the schema before the containers change, and records the new
version only once the result is serving.

Security

Remote control without a remote shell. The agent exposes a fixed catalog of
typed capabilities decided when it was built. A request names a container and
an operation from that list; nothing carries a command, a script or input for a
container. There is no exec, no attach and no shell — not disabled, absent.

That is a limit on Dockplane as much as on an attacker: Dockplane cannot do
things to your hosts that are not on that list, and neither can anyone who
takes over the control plane.

• Agent identity is a certificate. Each host generates its own key pair,
  which never leaves it, and connects outward over mutual TLS. Identity comes
  from the client certificate, not from anything the agent claims.
• Enrollment is one-time and short-lived. The token is stored only as a
  digest, spent once, and never appears in the visible command, in an argument
  list or on disk. The command's ticket travels in the request body, not the
  address, so no proxy log records it.
• Credentials are revoked individually. A revoked agent is refused, its
  connection dropped and its streams ended, without touching any other host.
• Sessions are server-side. The database holds only a digest, so a database
  copy contains nothing replayable, and revocation takes effect on the next
  request.
• State-changing requests are protected by both an origin check and a
  per-session token.
• Secrets stay out of the record. No password, token, second-factor secret
  or recovery code reaches a log or the audit trail. Container output is never
  stored, and never audited — that somebody read a container's logs is
  recorded; what those logs said is not.

See Security Model,
Agent Security and
Authentication. Findings from the release
scans, and the assessment of each one, are in the
Vulnerability Assessment.

Installation

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

VERSION=0.1.0

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

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.

Upgrading from any 0.1.0 release candidate works the same way. See
Upgrading.

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. Use amd64 in production.

Known limitations

Read Known Limitations before deploying.
In short: re-enrolling a machine creates a new host record and the old one
remains, backups are not encrypted by Dockplane, images are not signed, Compose
projects are read-only, container removal and volume and image management are
not implemented, and there is no automatic updater and no APT repository.

License

AGPL-3.0-only. See LICENSE.

Running a modified Dockplane as a network service means offering its users the
corresponding source.

Dockplane 0.1.0-rc.4

Dockplane 0.1.0-rc.4

The fourth release candidate. No new features: this one is about the
documentation being true, the checks being real, and the parts of the release
machinery that could pass without doing anything.

Documentation

The documentation is now organised into getting started, operations, security
and reference, and it is written once — in the repository, beside the code it
describes. The website builds its index from those files rather than keeping a
second copy, so a page that is added or rewritten shows up on the site and
nothing on the site can quietly fall out of step.

New pages cover adding a host,
upgrading,
supported platforms,
known limitations and the
vulnerability assessment.

One correction matters if you followed the old pages. They told you to
install dockplane-agent_0.1.0~rc.2_amd64.deb. Nothing was ever published
under that name — the tilde belongs in the package's version field, not in a
file name — and the download would have failed. Every documented file name is
now checked against what the project actually publishes.

Which agent version a new host gets

Adding a host installs the agent matching your control plane, and follows it
across every upgrade. That was already true; what was missing is that an
explicit pin was invisible.

If AGENT_RELEASE_VERSION is set in your .env, new hosts keep receiving the
version named there. An upgrade now says so, and dockplane-control doctor
reports it at any time:

! AGENT_RELEASE_VERSION is pinned to 0.1.0-rc.3, not 0.1.0-rc.4
  Add host will keep installing the 0.1.0-rc.3 agent on new machines.

Neither changes it. A pin is your setting, and only you can decide it has
served its purpose.

Security

The web image applies its distribution's security updates. Caddy publishes
an image per release and does not rebuild it when Alpine patches a library
inside it, so an image on the newest Caddy still carried what its base held the
day it was built. This removes five of the ten high findings against it — curl,
libcurl and c-ares.

Five remain, all compiled into the Caddy binary, and only Caddy can fix them by
publishing a build against a newer Go toolchain.

The control server's findings are unchanged: twenty-two, every one a Debian 12
package with no published fix, none from Dockplane's own dependencies. Each of
the five critical ones is now assessed by name rather than reported as a count.
See the vulnerability assessment.

Release verification

Three ways a release check could pass without doing its job, all closed:

• The asset verification compared checksums without requiring the tool that
  computes them. On a machine without it, both sides of the comparison were
  the empty string, they matched, and a release verified having read nothing.
  This is why 0.1.0-rc.3 was reported green from a machine that never read a
  single package.
• The build wrote a placeholder into the release manifest when it could not
  determine an image digest — as present as a real digest to anything that only
  asked whether one was there, and pinning nothing.
• Several scripts reached for dpkg-deb, sha256sum, tar and git without
  naming them as requirements.

A required tool that is missing now fails the gate and says which one.

Continuous integration

The website, the workflow files, the documentation and the browser flows are
now gates rather than things somebody remembered to run. The search palette and
Add host suites run against an instance created for the run and destroyed with
it — its own database, its own certificate authority, and an administrator
whose password is generated in the process. No credential is configured for
CI, and nothing there can reach a real deployment.

Fixed

• The features page advertised images, networks, volumes, container metrics,
  host groups and resource scopes. None exist in this release. All six are now
  listed as planned.

Supported platforms

Control plane	Ubuntu 24.04, Ubuntu 22.04 or Debian 12, with Docker Engine and the Compose plugin
Managed hosts	Debian 12, Ubuntu 24.04 or Ubuntu 22.04 with systemd. amd64 is supported; arm64 is experimental

arm64 is experimental — built and inspected, not runtime-tested. Use amd64
in production.

Upgrading

VERSION=0.1.0-rc.4

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

The installer takes a backup before it changes anything, reads it back the way
a restore would, and stops if any of that fails. See
Upgrading.

Known limitations

Unchanged from 0.1.0-rc.3, and set out in full under
Known Limitations: re-enrolling a machine
creates a new host record, backups are not encrypted by Dockplane, images are
not signed, there is no shell or exec, Compose projects are read-only, and
there is no automatic update or APT repository.

License

AGPL-3.0-only. See LICENSE.

Dockplane 0.1.0-rc.3

Dockplane 0.1.0-rc.3

The third release candidate. It carries what 0.1.0-rc.2 was meant to deliver,
and fixes the packaging mistake that stopped anyone from using it.

Adding a host

Hosts → Add host produces a single command to run on the new machine:

printf '{"ticket":"%s"}' '<ticket>' | curl -fsS --data-binary @- \
  -H 'content-type: application/json' \
  https://dockplane.example.com/api/v1/host-setups/bootstrap | sudo bash

It checks what the machine is, downloads the agent package that matches this
control plane, verifies it against the checksums published with that release,
installs it, enrolls the host and starts the service. The interface then shows
what the control plane has observed — the command was run, a certificate was
issued, the agent connected, the inventory arrived — and nothing else.

Docker Engine has to be there already. Nothing else is installed.

The command carries a bootstrap ticket: 256 bits of random material, stored
only as a digest, claimed atomically so two machines racing with the same
command cannot both be served, and dead after ten minutes, a cancellation or a
regeneration. It travels in the request body rather than the address, so no
proxy or access log on the way records it. What the agent enrolls with is the
existing one-time enrollment token, which never appears in the visible command,
in an argument list or on disk.

The bootstrap ticket can survive in your shell history. It has to reach the
machine somehow. Until it is used, treat it as a password.

Upgrading

The installer is the upgrade. Download the release, check it, unpack it,
run it:

sha256sum -c SHA256SUMS
tar xzf dockplane-0.1.0-rc.3.tar.gz
cd dockplane-0.1.0-rc.3
sudo ./install-control-plane.sh --domain dockplane.example.com

It recognises what is installed and says what it is about to do. Before it
changes anything it takes a backup, reads it back with the validation a restore
performs, and stops if any of that fails. Then this release's Compose file and
Caddyfile, the schema migration, and only then the containers. The version on
disk is written last.

Secrets, the certificate authority, the database and settings you added are
kept. Backups are written to /var/backups/dockplane.

Upgrading by pulling images and editing .env does not work and is no
longer documented. A release can change more than an image tag, and a new
setting has to reach the container that reads it.

Fixed since 0.1.0-rc.2

The agent package could not be downloaded from the release. GitHub rewrites
a tilde in an asset name, so the package was published as
dockplane-agent_0.1.0.rc.2_amd64.deb while the installer asked for
dockplane-agent_0.1.0~rc.2_amd64.deb, and adding a host failed on a 404. The
tilde belongs in the package's Version field — it is what dpkg reads as
"earlier than" — and not in a file name. The file is now named for the product
version and the field still carries the tilde:

dockplane-agent_0.1.0-rc.3_amd64.deb        Version: 0.1.0~rc.3

A release is now checked before it becomes public. It is created as a draft,
its assets are fetched back from GitHub and compared with what was built, the
published checksum file is run against the published files, and the packages are
read for the version they declare. Only then does it become a release candidate.

Multi-architecture image builds are reliable. The JavaScript and TypeScript
build now runs on the machine doing the building rather than under emulation,
where the toolchain wrote binaries and executed them immediately and one release
build failed on it. The control server's production dependencies are still
installed for the architecture being built, because the password hashing library
is a native module with a package per platform.

Fixed since 0.1.0-rc.1

The search overlay was laid out on every page, even closed, which put it
below the page content instead of over it.

The installer named the release it was written for rather than the one it
shipped in, so an upgrade went looking for the version it was replacing.

The pre-upgrade backup was reported without being taken.

An install command that had stopped working still counted down.

Supported platforms

Control plane	Ubuntu 24.04, Ubuntu 22.04 or Debian 12, with Docker Engine and the Compose plugin
Managed hosts	Debian 12 or Ubuntu 24.04 with systemd. amd64 is supported; arm64 is experimental

arm64 is built for and inspected, and no arm64 machine has run it. Nothing
about arm64 in this candidate is a runtime claim. Use amd64 in production.

Known limitations

• Backups are not encrypted. They contain the agent certificate authority's
  private key and the application encryption key. Keep them on encrypted storage.
• Re-enrolling the same machine creates a new host record.
• No automatic updates and no APT repository. Upgrades are explicit.
• No shell, exec or arbitrary command execution, and Compose projects are
  read-only. Both are product decisions, not gaps.
• Container removal, volume deletion and image management are not
  implemented.
• The agent must reach the control plane at the hostname it was enrolled
  with.
• Images are not signed. A bill of materials and build provenance are
  attached as attestations, which is not the same thing.

License

AGPL-3.0-only. See LICENSE.

Related

• Installation
• Backup and Recovery
• Interface Versions