Publish a solution demo

TL;DR

Publishing turns one of your backends — a solution you built — into a public, shareable demo anyone can open at its own URL, no account required. A solution entry binds that backend to a public alias, a target node flavor for visitor-spawned runs, taxonomy tags (industry, business goal, modality), and an optional sponsored-runs budget the template workspace pays.
Publishing makes the demo public on its own. The curated Solutions catalog — the browse-and-discover showcase — features a platform-selected subset of published demos; appearing there is a platform decision, not a flag you set. Your demo is reachable at its public URL whether or not it is featured.
An entry is published from an existing backend. The backend's components, graph, parameters, and file bindings are what visitors interact with; the entry is the publishing layer that binds them to a public URL.
Two CLI verbs cover the surface: ppl solution create registers an entry, and ppl solution update patches existing fields. A backend carries at most one entry; once it exists, create returns a conflict and update is the way to change it.
On plans that include sponsored runs, the template workspace can cover visitor compute up to a configurable budget. When the budget reaches zero, visitor runs stop until it is topped up.
The flavor is the runtime contract for visitors: it pins the node class their on-demand runs land on, which fixes cold-start time, GPU class, and capacity for the visitor experience.

What a solution entry is

A solution entry is a published binding between a workspace-owned backend and a public URL. The entry holds the public-facing configuration — alias, flavor, taxonomy tags, sponsored-runs budget — and references the backend by ID; it does not copy the backend's graph. Changing the backend changes what visitors interact with, with no separate artifact to keep in sync.

The taxonomy tags (industry, business goal, modality) drive discovery on the Solutions catalog. The flavor pins visitor runs to a known node class, so cold-start time and capacity are predictable. The sponsored-runs budget caps team-funded visitor compute. The team manages one object — the entry — and the platform handles routing, throttling, and visitor session lifecycle.

The taxonomy set, the visitor session model, and the flavor catalog are platform-defined rather than arbitrary. Those constraints are what make publishing a one-line operation. Whether a published demo is then featured in the curated Solutions catalog is a platform-side decision; publishing gives you the public URL either way.

Mental model

your workspace                                    public-facing
──────────────                                    ─────────────
  backend (vertices, params, files, endpoints)
        │
        │ ppl solution create --backend <id>
        ▼
  solution entry  ───▶  public solution URL (resolved by alias)
   - alias                                                 │
   - flavor (visitor runtime class)                        ▼
   - industry / business-goal / modality            visitor session
   - sponsored-runs budget                          (on-demand deploy,
                                                     billed to template
                                                     workspace until
                                                     budget is empty)

The entry sits between the workspace-owned backend and the public URL. Changing the backend updates what visitors see; changing the entry updates how visitors find it and what their runs look like.

See Backends and Runtimes and nodes for the underlying primitives.

Creating an entry

Use this step to publish a backend for the first time.

ppl solution create registers the entry. The only required flags are --backend (the workspace backend you are publishing) and --flavor (the node class visitor runs will land on); everything else is optional metadata.

ppl solution create \
  --backend <backend_id> \
  --flavor n1-gpu-micro \
  --industry healthcare --industry retail \
  --modality vision \
  --alias vision-demo

A backend carries at most one entry. The first create registers it; a second create for the same backend returns a conflict rather than overwriting, so changes to an existing entry go through ppl solution update.

--flavor determines the visitor runtime. Visitor runs land on the named flavor's node class, which sets cold-start time, GPU or CPU class, and available RAM: a GPU class for inference-heavy demos, a CPU class for lighter work, a class with more RAM for memory-bound models. The CLI lists the available flavors when needed; pick one that matches what a representative visitor run requires.

--alias is the public slug visitors will see in the URL (lowercase, max 64 characters; a custom alias is available on plans that include custom demo URLs). Omit it and the entry is reachable by the backend's identifier; pass it and the URL becomes a shareable slug. The taxonomy tags (--industry, --business-goal, --modality) drive discovery on the Solutions catalog; repeat them as needed.

Patching an existing entry

Use this step to change one field without re-stating the whole entry.

ppl solution update patches the fields you pass and leaves everything else alone. The most common reasons to patch are adjusting the sponsored-runs budget, adding or removing a taxonomy tag, or clearing the public slug (pass --alias "").

ppl solution update --backend <backend_id> \
  --industry healthcare --modality vision --sponsored 500

The patch is incremental: only the fields the call names change. That shape fits the common edits — adjusting the sponsored budget, fixing a tag — without re-stating the full entry configuration.

Visitor experience

When a visitor opens the entry's public URL, the platform starts a visitor session against the bound backend on the configured flavor. The session lifecycle is platform-managed: the visitor does not need an account, does not interact with backends or runtimes directly, and does not see internal workspace state. Replays attached to the entry — deterministic playbacks of a single run recorded by the team — are the lightweight viewing path; visitors watch them without spinning up real compute. Live-trial runs are the heavier path, and they consume the sponsored budget when one is configured.

A common configuration is a few attached replays for visitors who want to see what the entry does, plus a sponsored live-trial budget for visitors who want to feed in their own input. Replays display without consuming compute; the live trial is bounded by the budget.

When something goes wrong

invalid_value on --flavor — the flavor name is not in the current catalog. List the available flavors and pick one that exists.
conflict on solution create — an entry already exists for that backend (or the chosen alias is already taken by another entry). Use ppl solution update to patch the existing entry, or pick a different alias.
permission_denied — the workspace identity used to publish does not have write access on the target backend or on the solution surface. The fix is workspace-side, not CLI-side.
Visitor runs stopped — the sponsored budget reached zero, or the bound backend was deleted. Top up the budget or republish against a current backend.

Where this fits

Solutions is the publishing surface for putting a solution demo in front of users — collaborators, customers, or the public — in one operation. The entry references the backend by ID, so it stays in sync with the backend as the backend changes, and the sponsored-runs budget bounds team-funded visitor compute. The visitor session model is platform-managed rather than team-defined.

Backends — the object an entry binds to.
Runtimes and nodes — the runtime fabric the flavor selects from.
Deploy and monitor — the non-public counterpart of this surface.
Applications — when a publishing surface needs more than an entry.
Solutions — backend endpoints and the consumers they serve.