Opinionated CLI, not a control plane

Staging deploys that feel deliberate, not duct-taped.

Deploy Wizard is for homelabbers running Docker Compose apps behind Traefik who want one local CLI to detect or scaffold, configure staging, build the exact image, verify it before traffic flips, publish it cleanly, and destroy it when the branch is done.

Bootstrap from an app repo Read the practical guide

curl -fsSL https://raw.githubusercontent.com/stephenjoly/deploy-wizard/main/bootstrap.sh | bash

# then, from your app repo later
deploy-wizard
deploy-wizard destroy

Detect or scaffold Build and smoke-test Publish through Traefik or TRM Destroy preview branches cleanly

Why this exists

Most homelab deploy flows start as a handful of shell commands and slowly become a maze of copied Compose files, env files that only live on one box, proxy edits, and half-working preview naming. Deploy Wizard turns that sprawl into one repeatable branch-aware lifecycle.

What it manages

Repo files, remote updates, and proxy state

It owns the manifest, rendered Compose output, proxy artifacts, staging env capture, app-host deployment, traffic publication, and teardown path.

What it avoids

No fake platform layer

You keep Docker Compose and Traefik. The CLI is there to make the lifecycle coherent, not to replace your stack with a hosted abstraction.

Who it helps

Homelabbers who want something tighter than scripts

This is aimed at people who want staging to feel intentional without adopting a full platform or multiplying one-off operational scripts.

The lifecycle

The value is not just deployment. It is the full path from repo discovery to clean teardown, with branch-aware preview naming and verification before traffic is published.

Detect

Reuse existing Docker and Compose inputs, or scaffold a sensible starting point if the repo is bare.

Build

Build and push the exact image that staging will run instead of hand-waving around tags.

Verify

Smoke-check locally and on the remote host before anything public points at the deployment.

Publish

Update routing through SSH-managed Traefik config or the Traefik Rules Manager API.

Destroy

Tear down the current branch’s staging deployment and remove the proxy state when you are done.

Built-in preset

Keep the zero-config Stephen flow, but make the product legible

The current default run uses the built-in stephen-home-lab preset. That means Stephen’s setup still works out of the box, but the product story is no longer “Stephen’s deploy script.” The CLI is the product. The preset is one opinionated infrastructure default.

No preset chooser is added right now.
No extra configuration sprawl is introduced.
The same manifest, profile, and lifecycle model still underpins everything.

Practical guide

Getting started

Start here if you want the operator path: what to run, what the wizard will touch, and what the built-in preset expects.

Validation

Testing guide

Use this when you want to exercise the flow deliberately, verify generated artifacts, or test deploy and destroy behavior with less risk.

Examples

Starter repo files

Generic examples for a new app repo, including a simple Compose starting point and a GHCR publishing workflow.

Reference

Manifest schema

The source of truth for project-level configuration if you want to inspect or validate the manifest shape directly.

Core commands

Keep the main command for the guided operator path. Use the others when you want tighter manual control over part of the lifecycle.

Command	Purpose
`deploy-wizard`	Run the full guided flow: detect or scaffold, configure, build, verify, publish, and summarize.
`deploy-wizard validate`	Validate manifest, profile, Compose inputs, and route compatibility without deploying.
`deploy-wizard render`	Regenerate deployment artifacts without changing remote state.
`deploy-wizard apply --image-tag <tag>`	Use a known image tag for an advanced non-interactive deployment.
`deploy-wizard destroy`	Remove the current branch’s staging deployment and its published routing state.
`deploy-wizard sync-proxy`	Publish only the proxy side through SSH-managed YAML or the TRM API.

Call to action

Bootstrap it from the app repo you actually want to stage.

That path is the cleanest one right now. It caches Deploy Wizard outside your repo, refreshes it on rerun, builds it locally, and launches the CLI against your current directory.

curl -fsSL https://raw.githubusercontent.com/stephenjoly/deploy-wizard/main/bootstrap.sh | bash

Open the GitHub repo Read the practical setup guide