Repository navigation
Dockplane 0.1.0-rc.3
Pre-releaseDockplane 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 bashIt 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.comIt 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.