# Publish to the store
URL: https://lsd.tools/docs/pkg-publish
Updated: 2026-07-17

> Publishing turns a package into a store listing. A marketplace package is sealed — its code ships as an encrypted, signed .lsdpkg rather than a plain folder — and carries sealed, paid, and key_id in its manifest. Clients verify the signature against the store's published keys before trusting it.

**Publishing** takes a package you authored and lists it on the LSD store so others can find, buy,
and install it. A store package differs from a local folder in one important way: it is **sealed**.

## The publishing flow

1. **Create a publisher account** on the web store — this is the `publisher` namespace your package
 names in its manifest.
2. **Seal the package** into an `.lsdpkg` — an encrypted, signed archive of your code (rather than a
 plain code directory).
3. **Upload a version** on the publish page. The store validates the archive, records its version,
 and cross-checks the name and version against the manifest.
4. **Set its plans** if it is paid — see [Plans & licensing](/docs/pkg-plans-licensing). A free
 package needs no plan.

Each upload is a new **version**; buyers can be sent to a specific build, and clients only load a
version they are entitled to.

## Sealed packages

A sealed package's manifest carries three extra keys on top of the normal
[v1 fields](/docs/api-manifest):

```json
{
    "_schema_version": 1,
    "name": "lsd-widgets",
    "version": "1.0.0",
    "publisher": "acme",
    "sealed": true,
    "paid": true,
    "key_id": "…",
    "tool": "tool"
}
```

- **`sealed`** — the code ships as an encrypted `.lsdpkg`, not a readable folder.
- **`paid`** — the package requires a purchase to activate.
- **`key_id`** — identifies the content key. For a paid package the key is delivered per device on
 activation and is **never** stored inside the package file.

Not every store package is sealed. You can also publish with **source** delivery (the code ships
readable, on purpose) or **server** delivery (the sensitive code runs on the store's servers and
never ships at all). Delivery mode is a property of the plan — see
[Plans & licensing](/docs/pkg-plans-licensing).

## Signing & trust

Every published package is **signed**. Clients verify the signature against the store's published
signing keys before loading a package, so a tampered or forged build is rejected. Sealing is a
strong deterrent, but it is honest about its limits: any code that runs on the buyer's machine can
in principle be decompiled. When code truly must not leak, use **server** delivery, where the
crown-jewel logic executes on the server and only results cross the wire.

## Related

**Learn** — [Plans & licensing](/docs/pkg-plans-licensing) · [Buy & install](/docs/pkg-store-install) · [Collaboration & seats](/docs/pkg-collab-seats)

**API** — [lsd_package.json](/docs/api-manifest) · [PackageManager](/docs/api-package-manager)

**Examples** — [A complete package](/docs/ex-full-package)

## FAQ
### What is a sealed package?

A marketplace package whose code ships as an encrypted .lsdpkg instead of a source folder. Its manifest carries sealed=true plus paid and key_id. The content key is delivered per device on activation, never inside the package file.

### How does a client know a package is genuine?

Every published package is signed. Clients verify the signature against the store's published signing keys (a JWKS the store exposes) before loading it — a tampered or unsigned build is rejected.