bubbles-deployment-target-adapter

Enforces per-target deployment adapters consuming an SST-generated contract for multi-target deployments.

1|Updated Mar 17, 2026
One-click install
npx skills add https://github.com/pkirsanov/bubbles --skill bubbles-deployment-target-adapter-pkirsanov
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: bubbles-deployment-target-adapter
Source: https://github.com/pkirsanov/bubbles/tree/main/skills/bubbles-deployment-target-adapter
Command: npx skills add https://github.com/pkirsanov/bubbles --skill bubbles-deployment-target-adapter-pkirsanov

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Deploying one project to multiple targets (home lab, cloud, staging VPS) usually leaks target-specific values like FQDNs, IPs, and TLS paths into shared config, and one target's bootstrap can destroy another target's state on a shared host. This Skill enforces a strict SST → generated contract → per-target adapter pattern that keeps target knowledge isolated and every operation idempotent. ## Core Features & Use Cases - Contract-Driven Adapters: Generates a target-agnostic deploy/contract.yaml from the SST and requires each target to supply its own params.yaml, bootstrap, apply, rollback, verify, and teardown scripts. - Operator Privacy via Locality Modes: Separates in-tree generic adapters from out-of-tree operator-private adapters resolved through DEPLOY_TARGETS_ROOT, with a strict no-silent-fallback CLI rule and a public-repo safety checklist. - Build-Once Deploy-Many: Pins deployments to immutable image digests with cosign signatures, SBOM and SLSA attestations, per-environment config bundles, and an assurance-gated preflight that refuses prototype-tier builds. - Use Case: When adding a home-lab target to a public repo, scaffold deploy/_example/ in-tree, keep the real host adapter in a private repo, and run deploy home-lab bootstrap twice to prove idempotency without touching peer adapters. ## Quick Start Ask the AI to scaffold a new deployment target adapter for your project following the contract and params layout, then verify bootstrap idempotency by running it twice.

Frequently Asked Questions about bubbles-deployment-target-adapter

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new deployment target to a project?▼

Create a per-target adapter directory containing params.yaml, preconditions.sh, bootstrap.sh, apply.sh, rollback.sh, verify.sh, teardown.sh, and a README. The adapter consumes the generated deploy/contract.yaml and must never duplicate values already in the SST.

How do I keep private host details out of a public repo?▼

Place operator-coupled adapters out-of-tree under ${DEPLOY_TARGETS_ROOT}/<project>/<target>/ in a private repo. The CLI resolves adapters strictly from that root when the variable is set and never silently falls back to in-tree paths.

Can two deployment targets coexist on the same host?▼

Yes, adapters coexist through namespacing and drop-in patterns: containers use ${PROJECT}-${TARGET}-${SERVICE} names, firewall rules carry project and target tags, and reverse-proxy config is added as drop-in files rather than editing the main config.

Why must deployments pin images by digest instead of tags?▼

Mutable tags like latest or staging-latest break traceability because the running container cannot be tied to a specific source SHA. Pinning by sha256 digest makes every deployed artifact auditable back to one build run and enables no-rebuild rollback.

What happens when bootstrap runs twice on the same target?▼

The second run must be a no-op exiting 0 with zero state changes. Every adapter includes an idempotency assertion step that re-runs the singleton write logic and proves no diffs, and teardown must leave host singletons and peer adapters untouched.