Publish a solution demo

TL;DR

Publishing turns a release of 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 a tagged release of the project to the application its page launches, an ordered list of places visitor runs land, an optional public alias, 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 a fixed release. You commit the backend's graph, tag the commit, and the entry serves that tag; later edits to the backend reach visitors only when you move the entry to a newer tag.
Two CLI verbs cover the entry: ppl solution create registers it, and ppl solution update patches existing fields.
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.
Every deployment has a lifetime and stops on its own when it ends, without notice.

What a solution entry is

A solution entry is a published binding between a tagged release of a workspace-owned project and a public URL. The entry holds the public-facing configuration — release tag, application, placement preference, alias, taxonomy tags, sponsored-runs budget — and references the release by its tag; it does not copy the graph. Because a tag never moves, what visitors run stays exactly what you released until you point the entry at another tag.

The taxonomy tags (industry, business goal, modality) drive discovery on the Solutions catalog. The placement preference pins visitor runs to known node classes, most preferred first, 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 backend commit / ppl backend tag
        ▼
  release tag (a fixed commit)
        │
        │ ppl solution create --project <id> --release-tag <tag>
        ▼
  solution entry  ───▶  public solution URL (resolved by alias)
   - release tag + application                             │
   - placement preference (visitor runtime)                ▼
   - industry / business-goal / modality            visitor session
   - sponsored-runs budget                          (on-demand deploy,
                                                     billed to template
                                                     workspace until
                                                     budget is empty)

The entry sits between a fixed release and the public URL. Moving the entry to a newer tag updates what visitors see; changing the entry's other fields updates how visitors find it and where their runs land.

See Backends and Runtimes and nodes for the underlying primitives.

Releasing a version

Use this step before publishing, and again for every new release.

ppl backend commit <backend_id> -m "<message>" records the backend's working graph as an immutable commit; it refuses when nothing changed since the last commit. ppl backend tag <backend_id> <tag> names that commit as a release. A tag never moves, so each release gets a tag of its own.

Creating an entry

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

ppl solution create registers the entry. Four flags are required: --project (the project the release belongs to), --release-tag (an existing tag of it), --application (the application the solution's page launches) and --prefer (where visitor runs land); everything else is optional.

ppl solution create \  --project <project_id> \  --release-tag v1.0.0 \  --application <application_id> \  --prefer n1-gpu-micro \  --industry healthcare --industry retail \  --modality vision \  --alias vision-demo

--prefer determines the visitor runtime. Repeat it for an ordered list, most preferred first; each value is a public flavor name or a node ID. A run lands on the first target that can take it, 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.

--alias is the public slug visitors will see in the URL. Omit it and the entry is reachable by the project's identifier; pass it and the URL becomes a shareable slug. --visibility decides who may open the page (public, unlisted or private), --requires-login makes a live run need a signed-in visitor while replays stay open, and --expiration-minutes sets how long a visitor's live session lasts. 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 --solution <project_id or namespace/alias> patches the fields you pass and leaves everything else alone. The most common reasons to patch are moving the page to a new release (--release-tag), adjusting the sponsored-runs budget, adding or removing a taxonomy tag, or clearing the public slug (pass --alias "").

ppl solution update --solution acme/vision-demo \  --industry healthcare --modality vision --sponsored 500

The patch is incremental: only the fields the call names change.

Deployment lifetime

Every deployment stops on its own — the one you record a replay on and each one a visitor starts. A deployment reports expires_at. One that auto-extends keeps running while the workspace pays for it, until it is torn down or the credit runs out; one with a fixed lifetime (ppl backend deploy --fixed-duration <duration>) is torn down at expires_at. Nothing announces the stop: a page running against the deployment keeps loading and shows no more data. A visitor's live session lasts the entry's --expiration-minutes.

Visitor experience

When a visitor opens the entry's public URL, the platform starts a visitor session against the release on the first usable placement target. 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.

Checking what you published

A preview of the application shows it in deployment mode only. The solution page is where solution mode and replay mode first run, so open the page and try both before sharing it. The application itself answers at /application/<qualified name>/ once it is published, deployed and released; open that address and check that the page and everything it loads answer. An application that names itself by its ID in its session config keeps resolving after a rename; one that names itself by its qualified name stops resolving the moment it is renamed.

When someone reports an address that fails, check that exact address, path and query included, before and after a change: another address working says nothing about theirs.

When something goes wrong

invalid_value on --prefer — the flavor name is not in the current catalog. List the available flavors and pick one that exists.
nothing to commit — the backend's graph is the same as its last commit. Tag that commit as it is.
conflict on solution create — the chosen alias is already taken by another entry. Pick a different alias, or patch the existing entry with ppl solution update.
permission_denied — the workspace identity used to publish does not have write access on the project or on the solution surface. The fix is workspace-side, not CLI-side.
Visitor runs stopped — the sponsored budget reached zero, or the release's project was deleted. Top up the budget or republish a current release.
The page stopped showing data — the deployment behind it reached the end of its lifetime.

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 serves a fixed release, so visitors see exactly what you released, and the sponsored-runs budget bounds team-funded visitor compute. The visitor session model is platform-managed rather than team-defined.

Backends — the object a release is cut from.
Runtimes and nodes — the runtime fabric the placement preference 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.