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.”

Package trust and availability

The catalog exposes deployable and, when it is false, a stable deployability_code. The CLI displays unavailable entries and refuses to send a deployment request for them.

The built-in WordPress package is currently quarantined with PACKAGE_TRUST_INVALID: its checked-in release is not trusted by the shipped package roots and declares mutable image references. It is not a supported deployment path. An authorized operator must produce a digest-pinned package with the required health contract, certify it, and sign it with an authorized release key before registering a new immutable release.

Private release deletion and retention

An active-organization owner can logically remove an eligible private marketplace release with 1ctl package delete <release-id>. The CLI asks for confirmation; --yes skips that prompt for automation. This operation is deliberately not a byte purge.

The publisher API is:

DELETE /v1/marketplace-publisher/organizations/{organizationId}/releases/{releaseId}

On success, its data is a tombstone with release_id, deleted_at, and deleted_by. A normal 404 intentionally conceals both unknown releases and releases outside the caller’s tenant. A typed 409 means the release is not eligible yet: make it private and remove deployment, catalog, and publication references before retrying. Public or pending-publication releases are also blocked. The operation is owner-scoped; it is not a general catalog or deployment deletion mechanism.

In v1, logical deletion hides the release from ordinary publisher and user-facing paths: package list and status, archive download, catalog lookup, deployment, and public-request flows no longer expose it. The immutable release identity, archive bytes, and audit tombstone remain retained. Authorized internal or administrative audit access is separate from ordinary publisher endpoints.

Future physical purge

v1 provides no operator command and no physical archive purge. Before any operator-only purge can destroy bytes, its policy must define a retention schedule, legal and audit holds, a fresh reference check, explicit approval, and independent archival and purge audit records. It must also define the recovery and rollback stance before destruction; physical deletion must not be presented as reversible without a defined recovery path.

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.

Current consumer contract

The marketplace command also has a market alias. List defaults to a limit of 25 and an offset of 0; sort is optional. Get resolves one app name or ID. Deploy takes an app plus an optional deployment name, repeated hostname flags, and optional CPU, memory, and storage-size overrides.

Marketplace deployment acceptance is not readiness. The command has no wait flag, so follow it with application status and normal workload verification. Package metadata is the source for required secrets, retention, replica limits, health endpoints, and architecture declarations.

Architecture declarations are not image-manifest inspection. Package authors must verify that an immutable image supports every architecture they declare. See Publish a Private Marketplace Package.

Current consumer gaps

Gap	Safe behavior
Package releases have no package-delete command.	Treat a private publish as a durable organization record, not a disposable smoke test.
Package architecture declarations are author supplied.	Verify the pinned image manifest before declaring amd64 and arm64 support.