Pyplines System Manager

pyplines-system-manager installs, upgrades, verifies, and diagnoses a Pyplines appliance through the Docker or SSH infrastructure driver and the Kubernetes, PostgreSQL, and OCI APIs managed behind that boundary.

pipx install pyplines-system-manager
pyplines-system-manager

Running without a subcommand in an interactive terminal opens the Textual management interface. Explicit commands support Rich terminal output and authoritative JSON for automation. The manager is a capability-based thin client: it resolves the selected immutable published Platform Release OCI artifact and uses that release's inventory, Kubernetes resources, migrations, and image digests. Local Docker and production SSH appliances consume this same release; a source checkout and locally built platform images are not installation inputs. The manager never shells out to kubectl. A newer platform release does not require reinstalling the manager when it uses contracts and capabilities the installed client already supports.

For a local installation, Docker is the only host prerequisite. System Manager creates real k3s, PostgreSQL, and OCI registry services and never requires the operator to supply a kubeconfig or run k3d or kubectl. The local registry stores prepared Function images only; platform workloads are pulled by immutable digest from the published release repository.

The interactive interface is a state-aware wizard. It reconstructs its current position from the installation, release lock, credentials, Kubernetes state, and any unfinished release transaction. Restarting the manager therefore resumes at the first unresolved phase instead of repeating successful work.

The installation journey is:

Target → Infrastructure → Credentials → Platform → Finish

Every change follows the same interaction:

Configure → Review → Apply → Result → Next

Infrastructure precedes credential checkpointing because a new local appliance must provide the Kubernetes authority in which installation credentials are stored. Existing production infrastructure is detected and skipped.

After installation, the wizard becomes a focused operations home for opening, reviewing, verifying or repairing the installation, managing credentials, collecting diagnostics, and entering advanced recovery operations. Upgrade and repair journeys reuse the same review, apply, verification, and result screens.

Plans show the release transition, pending migrations, affected components, and changed resources. Unchanged Kubernetes resources remain hidden until explicitly requested. If installation state changes after review, the wizard requires the operator to review a refreshed plan before applying it.

Installation and upgrade work uses a dedicated progress screen with durable lifecycle stages. Raw activity is collapsed by default and remains selectable and copyable when needed. Credential and Root changes receive their own review screen; secret values are never rendered in that review.

Drag to select text and press Ctrl+C to copy it, press c to copy the current screen, press a to copy activity, or use the visible copy buttons. Escape returns to the previous reviewable step, r refreshes authoritative state, and q exits when no operation is being applied. Automation commands and their JSON contracts remain stable.

pyplines-system-manager --config pyplines-installation.yaml configure
pyplines-system-manager --config pyplines-installation.yaml doctor
pyplines-system-manager --output json --config pyplines-installation.yaml plan
pyplines-system-manager --config pyplines-installation.yaml apply --auto-approve
pyplines-system-manager --config pyplines-installation.yaml verify
pyplines-system-manager --config pyplines-installation.yaml stop
pyplines-system-manager --config pyplines-installation.yaml start