Providers on Bitsy Wiki

Pinata

Mon, 01 Jan 0001 00:00:00 +0000

Pinata is the longest-running service built for nothing but IPFS pinning, and the one most likely to be assumed when a project says “we pin to a service”. It runs its own infrastructure rather than fronting somebody else’s network, which makes the arrangement an ordinary hosting relationship: retention while the invoice is paid, no proof mechanism, no second tier behind it.

Two APIs, and only one of them is portable#

The native API does uploads in one call — post a file, get a content identifier (CID) back — plus metadata, key scoping, and grouping that the standard specification has no vocabulary for. Everything written against it is written against Pinata.

Filebase

Mon, 01 Jan 0001 00:00:00 +0000

Filebase is object storage with an S3-compatible interface whose buckets are backed by decentralized networks, IPFS among them. The consequence is unusual in this market: no client library is required, because every tool that already speaks bucket semantics — the AWS command line, backup software, Terraform, anything with an S3 driver — works against it unmodified.

The bucket is the pinset#

Files written to an IPFS bucket are pinned automatically, and Filebase has long described the pinning as geo-redundant across separate locations. The current pinning documentation does not state a replication factor, which puts it in the same position as most of this market — the quiet variable is how many copies “pinned” means, and the answer is usually not written down.

Lighthouse

Mon, 01 Jan 0001 00:00:00 +0000

Lighthouse serves content over IPFS and persists it to one of two networks behind the scenes — Filecoin or Walrus — with the choice made per plan rather than per file. What distinguishes it from the rest of this section is not the storage but the access control layered on top.

Encryption with programmable access conditions#

Kavach is Lighthouse’s threshold-encryption layer. A file is encrypted before upload, the key is split across nodes, and reassembly is conditioned on a rule evaluated at request time: holding a particular token or NFT, presenting a passkey, or satisfying an arbitrary contract call.

QuickNode

Mon, 01 Jan 0001 00:00:00 +0000

QuickNode sells blockchain node infrastructure, and IPFS pinning is one product in that catalogue rather than the business. The case for using it is that the account, the billing, and the dashboard already exist for whatever RPC endpoints the project is running on.

Its own REST API#

There are three groups of endpoints under one base — gateway management, pinning, and account usage — authenticated with an x-api-key header:

curl -X POST "https://api.quicknode.com/ipfs/rest/v1/pinning" \
  -H "x-api-key: $QN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "cid": "bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi",
        "name": "site-v4",
        "origins": ["/ip4/203.0.113.7/tcp/4001/p2p/12D3KooWExampleOriginPeerID"]
      }'

This is not the vendor-agnostic Pinning Service API, and the way it is not is instructive. The request body is the specification’s body — cid, name, origins, meta, with name required here rather than optional. origins carries the multiaddresses of nodes that already have the blocks and does the same work here as it does everywhere else. What differs is the envelope: a proprietary path, an x-api-key header where the specification says Authorization: Bearer, and no /pins root. So ipfs pin remote service add cannot point at it, no standard client library works, and porting to a provider that does implement the specification is mostly a matter of moving the same JSON to a different URL.

4EVERLAND

Mon, 01 Jan 0001 00:00:00 +0000

4EVERLAND is a Web3 infrastructure platform — storage, static hosting, and node access — whose storage arm includes 4EVER Pin, an IPFS pinning service that implements the vendor-agnostic Pinning Service API.

Standard API, bulk-oriented tooling#

The endpoint takes a bearer token generated on the 4EVER Pin page, and Kubo talks to it with no adapter:

1
2

ipfs pin remote service add 4everland https://api.4everland.dev "$TOKEN"
ipfs pin remote add --service=4everland --name=archive-2026 <cid>

The tooling around it leans toward bulk work that the specification does not describe: importing many content identifiers (CIDs) at once, uploading whole folders, and parsing content addressable archive (CAR) files rather than requiring individual objects. Bringing an existing pinset in from somewhere else is the operation that is usually painful and is specifically catered for here.

Crust

Mon, 01 Jan 0001 00:00:00 +0000

Crust is a decentralized storage network with a chain of its own, and its pinning product is the only one in this section with no account and no invoice. Storage is ordered on chain and served by staked nodes, so the thing that normally ends a pinning relationship — a company deciding to stop — has no obvious counterpart.

A wallet signature in place of a token#

Crust’s W3Auth pinning service implements the standard Pinning Service API surface and then replaces the one part that assumes a vendor. The specification says the Authorization header carries a bearer token; Crust carries a signature instead:

web3.storage and Storacha

Mon, 01 Jan 0001 00:00:00 +0000

This entry is a lineage rather than a live option. One service was renamed twice and re-architected each time, dropping a little more of its IPFS surface at every step, and the names are still all over old code and documentation.

1
2
3

web3.storage      →   Storacha        →   Fil One
Pinning Service       own client,         S3-compatible object
API, then not         capability auth     storage for AI workloads

What each generation was#

web3.storage was Protocol Labs’ free-tier upload service: post a file, get a content identifier (CID), with Filecoin deals behind it. It implemented the vendor-agnostic Pinning Service API, and then withdrew that interface — the first step away from portability.