Choosing a path
You have an extension that builds and runs. This page decides where it goes.
Choose by what your users need to run. A branded Desktop product uses the
extension artifact; a backend integration uses the HTTP API and does not need
an extension. wamp ext install installs a build into your own Desktop, but it
is a local authoring step rather than a distribution channel.
What your users download
Section titled “What your users download”| Branded desktop product | Your own product | |
|---|---|---|
| They download | your app, as its own installer, with its own name, icon and window | whatever you already ship; nothing of WAMP is visible |
| They need a WAMP install | no — your binary is the install | no |
| You maintain | one extension plus a product file and a release feed | your product; WAMP is a dependency of your backend |
| Execution and identity | Agent runtime in your binary; users sign in with WAMP | Your backend or client calls the model proxy, or starts managed Cloud sessions |
| Distribution | your own download page and update feed | your existing release channel |
The questions that decide
Section titled “The questions that decide”Are you only installing the extension for yourself? Keep using wamp ext dev and wamp ext install; there is nothing to ship. The public catalog is
published through the WAMP operator’s maintained workflow.
Is your extension the whole product? A product wants its own window, its own
name in the dock, and no WAMP chrome around it. Build a branded product and set
rootPageId to one of your pages so it boots straight into it.
Do you already have a server and a user directory? If yes, use your own product. You are not looking for an app shell — you have one. You want metered model access with per-end-user attribution, which is exactly what an app principal gives you, and none of it requires shipping a desktop binary.
Identity follows the distribution path
Section titled “Identity follows the distribution path”A branded Desktop product is a WAMP client: its users sign in with WAMP, and
the product receives the same account-backed platform services as the default
Desktop. Identity is not configurable in product.json.
If your product already owns its users, keep that identity in your own backend and mint app-signed end-user tokens for model access. That is the backend path, not a second Desktop account mode. See Your own backend.
What remains identical
Section titled “What remains identical”Local installation and a branded Desktop product share the extension: same
manifest, same permissions, same
plugin API, same build. A branded product bundles the same
staged artifact that wamp ext install validates, so there is no second version
of the extension to maintain.
Where each path stands today
Section titled “Where each path stands today”Read this before you commit to a path — the two are not equally finished.
Branded desktop product. The product file, the build pipeline, and the release upload script all live inside the WAMP monorepo, so producing a branded binary requires access to that repository today. Signing, notarization, release-build update gating, and artifact architecture are covered in Branded desktop product.
Your own product. The HTTP integration is available, but @wamp/app-sdk is not published to npm, so today you either vendor
the package or call the endpoints directly. The token you have to mint is a
signed JWT with four claims, which is a short function in any language — see
Your own backend for the contract and a worked example.
Not on this page
Section titled “Not on this page”Running agents on WAMP’s own infrastructure rather than on a user’s machine — a durable session driven from a CRM, a bot, or a scheduler — is a separate product with its own documentation at docs.cloud.vampikez.fun. It is orthogonal to the two paths here: a branded product and your own backend can each drive Cloud sessions.