Getting containers to start is only half of a self-hosted deployment. The other half is making sure the hostname works from the public internet, the TLS certificate is valid, and GitHub can deliver events back to your installation.

A dashboard that loads on your own machine does not prove any of those things.

This walkthrough covers the main installation path on one Linux VM. Settle the package versions and public entry point first, then connect a repository. Troubleshooting every failure by trying a different image tag is a good way to lose track of what actually changed.

This is a third-party deployment note, not official SuperPlane documentation. The version baseline comes from the full guide's November 5, 2026 review; it is not a fresh check of upstream releases or a claim about the latest version.

Check the host before downloading anything

Start with a Linux VM you administer, using either amd64 or arm64. You need Docker Engine, Compose v2, Bash, cURL, tar, and OpenSSL. The host must also reach GitHub Releases, ghcr.io, and Docker Hub over HTTPS; otherwise, installation can stall at the download stage.

For the public entry point, use a domain you control and make sure TCP ports 80 and 443 reach the installation host. Every published A or AAAA record must point to the correct machine and remain reachable. Testing only whichever address your laptop prefers can miss a broken route.

If another reverse proxy already owns those ports, resolve that conflict before installing. Do not stack another entry point on top and hope for the best.

Size the machine for execution, not just for displaying the dashboard. The official sizing guidance carried into the full guide reserves approximately 2 vCPU, 8 GB RAM, and 30 GB disk per concurrent runner, excluding the core services. Set capacity around the resources actually available; copying defaults is not a performance guarantee.

There is also an important trust boundary: Fleet Manager mounts docker.sock, giving it control over the host's Docker environment. Install it only on a machine you manage, with that level of access in mind.

1. Choose the application package, not just a release tag

This note uses the v1.0.0 application package, specifically the superplane-single-host.tar.gz asset attached to that application release. Its accompanying components are Fleet Manager v0.1.6 and Runner v0.2.1. Keep those together rather than independently upgrading the components.

After extracting the archive, enter the superplane directory and check that it contains:

  • install.sh
  • docker-compose.yml
  • Caddyfile

Before installing, compare these details with the upstream application release. The versions here are a documented baseline, not a statement that they are today's newest releases.

2. Run the installer and establish HTTPS

From the installation directory, run:

./install.sh

When prompted, enter a hostname such as superplane.example.com, without an https:// prefix. The installer handles configuration and secrets, pulls images, starts services, and uses Caddy to request a certificate.

Restrict access to the generated environment file and secrets directory, and back them up appropriately. They are not suitable attachments for a public troubleshooting issue or repository.

Keep public exposure limited to the required ports, 80 and 443. Do not additionally expose the database or message-queue administration interfaces just to make debugging easier.

3. Verify the public endpoint before creating the owner account

Check the containers first:

docker compose ps

Then check /health through your own HTTPS domain. The expected response is HTTP 200. A running container is one useful signal, but it does not replace checking the externally reachable service.

Once that works, open /setup and create the owner account. For the community edition, choose Continue with Community.

This ordering gives you a working foundation before you start repository authorization. Repeatedly trying the GitHub connection while the public endpoint is still broken only adds another moving part.

4. Connect GitHub through the interface

Enter the workspace and follow Connect GitHub to complete authorization or installation. Choose a repository for which you have sufficient permissions, then import work. Keep the connection scope small and start with a simple task.

When configuring GitHub triggers, let the product create and manage the webhook. Do not bypass its authorization flow by guessing a callback URL from another article and pasting it into GitHub. Exact interface details depend on the installed version and official instructions.

Treat service reachability and task execution as separate checks. If the interface works but no runner container appears, investigate the local fleet settings in the interface before reinstalling everything. Save the current configuration and logs first, then consult the relevant documentation section. Troubleshooting should not undo the parts that already work.

Two traps worth checking early

GitHub's “Latest” is not necessarily the single-host package

The release marked Latest may be a component tag rather than the application release containing the single-host archive. If the download looks wrong, check the tag and asset name first. Mixing Fleet Manager and Runner versions is not a fix for downloading the wrong package.

A certificate stays pending

Check the domain's A and AAAA records, then confirm that ports 80 and 443 actually reach Caddy. Next, inspect its logs:

docker compose logs caddy --tail=50

Successful access from inside the host does not establish public reachability. Until HTTPS works, avoid treating the failure as a GitHub authorization problem.

When you need the longer checklist

This outline helps establish the installation order and prerequisites. For installation, capacity planning, acceptance checks, GitHub integration, and upgrade/uninstall boundaries in one place, the full Chinese SuperPlane guide is a $9, docs-only guide written in Chinese—not a software license, with no deployment service, ongoing operations, or availability guarantee included.