List Your App

Introduction

Deploying makes your Product reachable at its dotNS address. Listing makes it discoverable: it puts your Product in a directory that users browse inside their Host, so people who have never heard your .dot name can still find and open it.

There are two discovery surfaces:

• The Playground directory (playground.dot): The directory the playground CLI publishes to on the TestNet it targets. This is the path you use when you deploy with playground deploy.
• Browse: Polkadot's native discovery catalogue, surfaced in the App and Desktop dashboards. It is the broader destination for a Product that is ready for end users.

Both are catalogues of published Products surfaced inside the Hosts, and both store a minimal on-chain record while pulling display details from your name's dotNS metadata. They differ in the tooling that publishes to them, covered below.

TestNet names end in .paseo, not .dot

dotNS top-level domains are per network. On Paseo Next v2, the TestNet the Apps tooling targets by default, names are minted under .paseo: publish myproject57 and you get myproject57.paseo, served at https://myproject57.paseo.li. Whether you supply the bare label or the full name depends on the tool; see Choose a Name.

Products Devnet

Building on the PCF Products Devnet (devnet preset)? See App discovery: Browse.

The Playground Directory

The Playground directory lives at playground.dot, which you open in the Polkadot Desktop browser. It is scoped to the TestNet the playground CLI targets, so treat a listing there as a way to share work in progress rather than as a launch surface; Browse is where a Product goes when it is ready for end users. Listed Products appear under their dotNS name, and your Product's README.md becomes its detail page in the directory, so make sure it is up to date before you publish.

List During Deploy

Listing is a choice you make during playground deploy. At the publish to the playground? prompt, choose yes:

  publish to the playground?
    › yes  ·  list it in the public playground
      no  ·  deploy to my .paseo address only

Choosing no still deploys your Product to its dotNS address; it stays unlisted. To skip the prompt, pass the --playground flag:

playground deploy --domain my-product --playground

With the phone signer, publishing adds one more approval in the Polkadot App, for writing the listing to the Playground registry.

Categorize the Listing

Pass --tag to file your Product under a category, which drives the tag filter in the playground app. Omit the flag and the CLI prompts you:

playground deploy --domain my-product --playground --tag gaming

An app carries at most one tag, and the accepted values are a fixed list: site, social, chat, utility, gaming, marketplace, and irl. There is no free-form tag, because a value outside this list still renders on your app's card but has no filter pill, making it effectively unfilterable.

Keep a Listing Private

Pass --private (alongside --playground) to publish with owner-only visibility. The listing exists but only you see it, which is useful for staging a Product in the directory before you announce it. Unlike the other listing choices, this one is never prompted for — you have to pass the flag:

playground deploy --domain my-product --playground --private

Let Others Fork Your Product

Pass --moddable (alongside --playground) to mark your Product as one others can clone, customize, and redeploy as their own. A moddable listing records your public repository as its source:

playground deploy --domain my-product --playground --moddable

The CLI reads your existing origin remote and records its URL in the Bulletin metadata. It never creates a repo or pushes for you, so set that up first. The deploy fails with an actionable message if origin is unset, points at a private repo, or points anywhere other than GitHub, because pg mod fetches source only from codeload.github.com:

git remote add origin https://github.com/<user>/<repo>
git push -u origin main

Anyone can then clone a moddable Product with pg mod:

pg mod my-product

pg mod copies a moddable Product from the Playground registry into a local project you can edit and redeploy under your own name. Omit the domain to open a picker showing every moddable Product. See the Quick Start for the full pg mod reference.

Change or Remove a Listing

The listing choice is made at deploy time through the publish to the playground? prompt (or --playground). Redeploying re-runs that choice, so deploy again with your preferred option to update the listing state. The playground CLI does not currently expose a separate unlist command.

Browse

Browse is Polkadot's native discovery catalogue: a curated directory surfaced inside the Host dashboards, and the destination for a Product once it is ready for end users. You saw its Browse section on the Polkadot Desktop dashboard after pairing.

How a Browse Listing Works

Browse enforces who can list, on chain, so the directory stays tied to real ownership and real people:

• Ownership: You must own the dotNS name you are listing.
• Proof of Personhood: The listing account needs Proof of Personhood, Lite or Full. Personhood is obtained in the Polkadot App on your device.
• Rate limits: Listings are rate-limited per personhood tier over a rolling 24 hours — Lite accounts can publish one per day, Full accounts five per day.

A listing itself stores only a minimal on-chain record: a hash of the label, the publisher's address, and a timestamp. The display name, description, and icon are not stored in the listing; they are read from your name's dotNS manifest when the directory renders, so keeping your manifest current keeps your Browse card current.

Publishing to Browse

Publishing into the on-chain Browse catalogue is separate from the playground CLI, which publishes to the Playground directory described above, not to Browse. Browse is run by the Polkadot Community Foundation (PCF), so report problems with it to PCF; see Choose the Right Channel. PCF's pad deploy CLI no longer lists apps in Browse: its --publish and --unpublish flags were removed in October 2026. For the publish permission model, the personhood requirements, and the Browse contract details, see App discovery: Browse.

Two toolchains, two directories

These docs standardize on the playground CLI, whose listing path is the Playground directory. Browse is the Community Foundation's directory, with its own on-chain registry. The two are separate publish mechanisms that share the same idea: a discovery directory of published Products surfaced inside the Hosts.

Where to Go Next

• Deploy Your App

  ---

  The full deploy flow, where the publish to the playground? choice is made.

  → Deploy Your App

• Register a .dot Domain

  ---

  A listing points at your .dot name, so register one first.

  → Register a .dot Domain

• Proof of Personhood

  ---

  The personhood tiers a Browse listing checks, and how they gate names and features.

  → Reference