Add an idempotent Bash installer for deployment hosts

[Nickfost]

Goal

Provide a repository-owned Bash installer for the separate deployment control plane so test/staging and production deployment hosts can be installed, upgraded, repaired, verified, or removed without repeating a manual checklist.

This must remain separate from ordinary shared CI runners. CI workers must never receive deployment credentials or production network access.

Required interface

Provide a command such as:

sudo ./scripts/install-deployer.sh --config /etc/ci-fleet/deployer.env

The exact name may change, but deployment must reduce to one documented, noninteractive command after host-local configuration and credentials are present.

Responsibilities

• verify supported Linux, root privileges, Docker Engine, Compose v2, required generic tools, disk capacity, network prerequisites, and host isolation;
• validate host-local deployment configuration without printing secrets;
• create root-owned configuration and secret directories with enforced permissions;
• require credentials to exist in approved host-local files or an external secret manager;
• install a pinned deployer image/service and record its source commit and image digest;
• install healthcheck, scoped cleanup, monitoring, drain, upgrade, and rollback systemd units/timers;
• verify that no ordinary CI runner or unrelated workload is present on the deployment host;
• support explicit --check, --install, --upgrade, --rollback, and --uninstall modes or equivalent;
• produce a concise final report suitable for an operator or automation agent.

Security rules

• Never place deployment credentials in ci-fleet, an application repository, Git history, images, logs, command arguments, or job artifacts.
• Never expose production credentials to pull-request or ordinary validation jobs.
• Staging and production must use distinct identities and secret scopes.
• Production deployment must require the repository/environment approval policy defined by the delivery standard.
• The installer must not modify application repositories or GitHub environment approvals.
• The deployer must accept only explicitly authorized immutable artifacts or image digests.
• Never use global Docker prune or remove unrelated resources.
• Do not install application runtimes directly on the host.
• Do not combine the deployer with the shared CI runner controller.

Operational requirements

• Idempotent: rerunning the installer converges safely without duplicate services, identities, timers, or residue.
• Transactional: validate the candidate deployer before replacing the healthy version.
• Rollback-capable: preserve or identify the last known-good deployer and configuration.
• Drain-aware: upgrades and reboots must not interrupt an active deployment.
• Fail closed: missing approval, identity, artifact provenance, target policy, or credentials must stop deployment.
• Environment-aware: staging/test and production targets must be explicit and impossible to confuse through defaults.
• Backup-aware: require or verify a recoverable host checkpoint before first activation and risky upgrades.
• Document one-command fresh install, upgrade, repair, validation, rollback, and removal.

Acceptance

On a prepared isolated deployment host, an operator should only need to:

1. checkout a reviewed ci-fleet/delivery commit;
2. place the host-local configuration and approved credentials;
3. run one Bash command;
4. receive a verified deployer service and an actionable final report.

A second run must make no unnecessary changes. A production deployer must remain incapable of accepting ordinary CI jobs, and ordinary CI workers must remain incapable of deploying.

[Nickfost]

[lane-a:phase2:issue-22-outcome]

Repository implementation is clean at draft PR #69 head 515b071461911ad395734792aeb6e82da92da394: exact-head CI passed, Codex reported no major issues, all 263 findings have evidence replies and +1, and no useful thread remains unresolved.

The issue remains open for separately authorized isolated-host/operator evidence, including application-owned adapter, credential, health, failure, and rollback proof. No deployment host or production system was changed.