Pinner.xyz

Status: community product notes — not a paid placement. Primary docs: docs.pinner.xyz · LLM full dump: llms-full.txt · Product: pinner.xyz (a Lume Web service).

If you live in Handshake (HNS), IPFS, and “own your stack” culture: Pinner is the practical pinning + static hosting layer that showed up after Fleek-style all-in-ones got messy. One subscription covers pinning, website hosting, and DNS — without locking your CIDs into a proprietary silo.

One sentence

Pinner pins your content on IPFS, hosts static sites / SPAs / dapps on decentralized storage with real domains (DNS or onchain names), and stays out of the “public anonymous gateway” tax.

What Pinner is (and is not)

Tagline from their side: Store anything. Decentralized, private, no lock-in.

Why this matters for Handshake people

HNS is the naming / root layer story. Sites still need content that stays online. IPFS is the usual answer; pinning is the boring operational part most of us do not want to run ourselves forever.

• CIDs travel with you. Content-addressed storage means switching pin providers is a pin list, not a data migration.
• Two name paths. Traditional DNS domains get DNSLink + SSL via Pinner. Onchain names (docs lead with .eth / contenthash; same IPNS pattern applies to other onchain systems you control) use pinner point without DNS gymnastics.
• Fleek-shaped hole. Fleek Hosting shut down (docs: 31 Jan 2026). Pinner explicitly documents migration for sites, DNS, ENS pointing, and GitHub Actions.
• Privacy culture fit. No identity required for crypto billing; Monero is first-class; no anonymous public gateway subsidy baked into pin pricing.
• Same ecosystem as LumeWeb / agent-ready static dumps. Useful next to Headless Domains, HRP/IPFS backups, and agent-facing static manifests.

Products

Five-minute quickstart

1. Account

Sign up at pinner.xyz (email verification required) or register from the CLI. Pick a plan in the dashboard — cards (Stripe) or crypto (ATLOS). Crypto path does not require ID.

2. Install CLI + auth

# macOS / Linux
curl -fsSL https://get.pinner.xyz | sh

# Windows (PowerShell)
# irm https://get.pinner.xyz/install.ps1 | iex

# Guided first-time setup (auth + API key)
pinner setup

# Or login and auto-create a machine key
pinner auth --email you@example.com

API keys are long-lived JWTs (docs: ~30-day expiry) for PINNER_AUTH_TOKEN / Bearer auth. Manage with pinner account api-keys. Enable 2FA via pinner account otp enable.

3. Pin something

# Upload a file → prints CID
pinner upload ./my-file.txt

# Pin an existing CID
pinner pin QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco

# Upload a build directory
pinner upload ./dist

SDK path (TypeScript)

npm install @lumeweb/pinner

import { Pinner } from "@lumeweb/pinner";

const pinner = new Pinner({ jwt: process.env.PINNER_AUTH_TOKEN! });
const result = await pinner.uploadAndWait(file);
console.log("CID:", result.cid);

Two paths for names

Pinner splits website access by how the name resolves:

Onchain: point

pinner point vitalik.eth --cid bafybeig...your-cid

# Output includes IPNS name + contenthash (ipns://...)
# Paste contenthash into your name manager / ENS controller

# Later: update content without changing on-chain contenthash
pinner point vitalik.eth --cid bafybeig...new-cid

# Tear down IPNS key on Pinner side
pinner unpoint vitalik.eth

Why IPNS instead of a raw CID in contenthash: one on-chain set, then every redeploy is an off-chain IPNS republish. Direct CIDs force a chain tx on every update.

DNS: websites wizard

npm run build
pinner websites wizard
# content source → IPFS/IPNS → domain → DNS mode → validate

# Or manual
pinner websites create mysite.example.com --cid <CID>
pinner websites validate mysite.example.com
pinner websites ssl status mysite.example.com

DNS modes: Pinner-managed (delegate nameservers; DNSLink / ALIAS / validation automatic) vs self-managed (you keep Cloudflare etc.; add TXT validation + _dnslink + CNAME/ALIAS yourself).

CI/CD: GitHub Actions

Drop-in deploy after build (Fleek-shaped replacement):

- name: Deploy to Pinner
  uses: lumeweb/pinner-deploy-action@v0
  with:
    api-key: ${{ secrets.PINNER_API_KEY }}
    path: ./dist
    domain: mysite.example.com

Also supports pin-by-CID mode, IPNS publishing, and cleanup flags — see Deploy with GitHub Actions.

Migrations people actually need

import { Pinner, pinataAdapter } from "@lumeweb/pinner";
const pinner = new Pinner({ jwt: process.env.PINNER_AUTH_TOKEN! });
const adapter = pinataAdapter(pinner);

Why no public anonymous gateway

Deliberate product choice, not a missing feature. Public anonymous gateways are expensive, abuse-prone, and force pin customers to subsidize bandwidth they may never use.

• Pinning = keep your content available on the IPFS network.
• HTTP for the web = website hosting on your domain via ipfs.pub (DNSLink gateway for domains you configure — not open CID browsing).
• Availability checks = check.ipfs.pub.
• Other retrieval = public gateways, local IPFS, or your own gateway.

If Pinner disappears tomorrow: CIDs are still yours. Export the pin list, re-pin on another provider or your own node. Caveat shared by every pin service: if they were the only holder, content goes dark until something else pins it. Dual-pin production assets.

Ops details worth knowing

• Quotas: upload / download / storage monthly limits per plan. Hitting a limit returns explicit quota errors with usage headroom.
• Operations: long-running work (upload, pin, deploy) is trackable — pinner operations list --watch, pinner operations get <id> --watch.
• CIDs: Pinner normalizes toward CIDv1; content is content-addressed either way.
• Cancel plan: pins remain through the billing period end, then stop. No proprietary export format — pin list + re-pin.
• Scoped API keys: currently full account access; scoped keys on the roadmap.
• Roadmap callouts: private zero-knowledge storage; S3-compatible object storage on a decentralized network.

CLI / SDK map (cheat sheet)

How this fits the stack on this site

External resources

• pinner.xyz — product / signup / billing
• docs.pinner.xyz — human docs
• llms-full.txt — full docs dump for agents
• LumeWeb/pinner-cli — CLI source / releases
• pinner-deploy-action — GitHub Action
• ipfs.pub — DNSLink gateway for hosted domains
• Lume Web — parent ecosystem
• Support: support@pinner.xyz

Related on this site

• Handshake decentralized SLDs — HIP-0015 / HIP-0016 path for on-chain SLDs
• Custom nameservers for Handshake TLDs
• DNSid.ai vs Headless Domains — agent identity + Handshake/IPFS moat
• DNS-AID vs Headless Domains
• Sky Include — early Handshake web experiments
• Cloudflare DNS control handover
• CLI for agents — why CLI-shaped tools compound for agent ops