QM abstracts deployment across Fly.io and AWS through a provider registry, with provider choice locked at qm init time and organization-specific deployment logic isolated in deploy/layers/<org>/. Operators must implement their own deployment CI; QM provides provider templates and a sandbox build command (flyctl deploy --remote-only --build-only --push), not a complete workflow.
The installed @yc-software/qm package carries both Fly.io and AWS provider templates and dispatches their common lifecycle through a hosting-provider registry.[1] Provider choice (Fly.io or AWS) is fixed at qm init time because it determines the config, secret rules, generated files, and teardown contract; changing providers requires initializing a new empty directory.[1] The hosting-provider registry is an internal lookup table mapping provider names (e.g., fly, aws) to lifecycle hooks (init, deploy, teardown), allowing QM to dispatch provider-specific logic without callers needing to know which provider is active. FlyDeployProvider (src/deploy/fly-deploy-provider.ts) implements the hosting-provider interface, enabling qm publish to target Fly.io-hosted deployments as a first-class provider option. Fly provider selection is driven by config declared in src/config.ts; src/deploy-service.ts integrates the provider into the deploy-service lifecycle. src/wiring.ts conditionally instantiates FlyDeployProvider based on the active config, registering it as a deploy backend alongside any other configured providers. Commit ba457a2 is the primary integration point for tracking upstream changes to CLI backends, provider scaffolding, sandbox provisioning, or deployment configuration between the internal fork and the public branch.
Organization-specific deployment customizations live in deploy/layers/<org>/, containing config, sandbox customizations, provider coordinates, and generated Slack manifests; the rest of the tree stays identical to upstream.[1] The QM source repository carries no production deployment workflow, and qm init does not create deployment CI — operators must wire their own.[1]
Fly.io sandbox images are built and published with flyctl deploy --remote-only --build-only --push --image-label latest; the target app name is controlled by the FLY_SANDBOX_APP_NAME environment variable.[2]
Sources