Publish per-provider Nebi starter workspaces to quay.io/nebari

[dcmcand]

Part of #552.

Goal

Ship the config template as a versioned artifact rather than a wizard. A starter workspace is a Nebi/Pixi workspace bundle containing the pinned toolchain, a placeholder config.yaml, and the deploy tasks, so getting from nothing to a deployable config is:

nebi import quay.io/nebari/starter-aws:v0.11.0 -o ./my-nebari
cd my-nebari && $EDITOR config.yaml
nebi run validate && nebi run deploy

One per provider: starter-{aws,gcp,azure,hetzner,local,existing}, tagged with the nic version they pin.

Shape

[workspace]
name = "nebari-aws"
channels = ["conda-forge"]
platforms = ["linux-64", "linux-aarch64", "osx-arm64", "osx-64"]
version = "0.1.0"

[dependencies]
nic = "0.11.*"                 # bootstrap task until the conda package exists
kubernetes-client = ">=1.34"
k9s = ">=0.51"

[tasks]
validate   = "nic validate"
deploy     = { cmd = "nic deploy", depends-on = ["validate"] }
status     = "nic status"
destroy    = "nic destroy"
kubeconfig = "nic kubeconfig -o kubeconfig.yaml"

[tool.nebi.bundle]
include = ["config.yaml", "README.md"]
exclude = [".env", "kubeconfig.yaml", "*.tfstate*"]

Gating deploy on validate via depends-on answers ADR-0005's open question 5 at the workspace level: validation stays mechanical and separate from config creation, but cannot be skipped.

Two properties that make this work without extra plumbing: Pixi runs tasks from the workspace root, so nic's auto-discovery of ./config.yaml (cmd/nic/config_discovery.go:34) resolves correctly even when invoked as nebi run nebari-aws deploy from another directory; and nebi import refuses to write into a non-empty directory when the bundle carries asset layers, so the import-then-edit cycle cannot clobber existing work.

Open decisions for this issue

• Where the starters live: a directory in this repo (keeps them next to examples/, versioned with nic) or a separate repo (keeps deployment templates out of the tool's release cycle)
• How they are generated: the config.yaml in each starter should be derived from examples/<provider>-config.yaml in CI so it cannot drift. The examples are already mostly teaching comments (aws-config.yaml is 217 lines, 51 of them non-comment), so a starter is closer to the effective content plus placeholders.
• Quay push credentials in CI, following the existing oci://quay.io/nebari/charts channel as precedent

Definition of Done

• nebi import quay.io/nebari/starter-local:vX && pixi install && nebi run deploy brings up a kind cluster in CI, end to end
• Every starter's config.yaml is generated from examples/ in CI, with a drift gate
• Every starter bundles [tool.nebi.bundle] exclude for .env, kubeconfig.yaml and *.tfstate*
• Each starter has a README covering: fill the placeholders, where secrets go (env vars, never the config), and that filled configs belong in a private registry or nebi server, not a public one
• Publishing runs on tag, producing tags that match the pinned nic version
• Docs site page walking through the import-edit-deploy flow

Related

• Epic: Local Development Environment #165 Epic: Local Development Environment (the starter-local workspace)
• ADR-0005: this is the "generated starters" answer to the config-bootstrap question