Marketplace & Templates

Marketplace entries are curated ways to create workloads. They should not become a second species of workload after creation.

Current implementation

MarketplaceApp template
   ↓
marketplace deploy endpoint
   ↓
MarketplaceDeploymentService
   ↓
Deployment / Service / route records
   ↓
Kubernetes resources

The backend already records resulting workloads as deployments and marks their source as marketplace. Some templates have richer app-specific orchestration, such as CNPG Postgres and NATS, which means a template can be more than “one image plus one Service.”

Durable product boundary

marketplace = catalog / discovery / install intent
deploy       = runtime lifecycle

Question	Best home
What can I install?	marketplace
What defaults and inputs does it need?	marketplace
What is running?	deploy
How do I restart, roll back, observe, place, or destroy it?	deploy

Target architecture

template resolution
   ↓
shared workload spec
   ↓
shared deployment pipeline
   ↓
normal deployment lifecycle

1ctl marketplace deploy can remain as friendly sugar. A future 1ctl deploy --template ... would make the shared model more explicit, but the deeper requirement is internal convergence.

When to introduce a higher-order primitive

If future templates become truly multi-service products with coupled lifecycle — for example a web app, worker, cache, database, and jobs that must be operated as one object — the next durable noun may be app or stack. Even then, marketplace should remain the catalog that instantiates the object, not the runtime home forever.

Current gaps and target direction

Gap	Target
Separate marketplace orchestration path can drift from ordinary deploy behavior.	Template resolution feeds the same pipeline.
Marketplace flags and deploy flags are not fully aligned.	One placement, domains, scaling, and observability language.
Rich templates blur whether they are “just deployments.”	Document them as template-backed workloads unless/until a true stack primitive exists.