Filebase Alternative: Simpler IPFS Pinning Without S3 Complexity

Quick Comparison: Filebase vs IPFS Ninja#

The bottom line: if you’re already wiring up AWS SDK clients anyway, Filebase slots in naturally. If you want to ship a file to IPFS in one curl command, IPFS Ninja wins on simplicity.

Upload a File to IPFS in 30 Seconds#

This is the IPFS Ninja upload path. No SDK, no XML, no bucket creation step:

curl -X POST https://api.ipfs.ninja/upload/new \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Hello from IPFS Ninja!",
    "description": "My first file"
  }'

Response:

{
  "cid": "bafkreib4mrow...",
  "sizeMB": 0.00002,
  "uris": {
    "ipfs": "ipfs://bafkreib4mrow...",
    "url": "https://ipfs.ninja/ipfs/bafkreib4mrow..."
  }
}

Done. That CID is pinned, accessible over IPFS, and reachable via the public gateway immediately.

Now here is the equivalent Filebase flow:

1. Create an account and a bucket in the Filebase console.
2. Generate an access key + secret key pair.
3. Configure an S3 client with endpoint https://s3.filebase.com, region us-east-1, and your credentials.
4. Call putObject with your file body.
5. Poll the object’s metadata to retrieve the IPFS CID (it appears as an x-amz-meta-cid header after Filebase pins it).

That’s not wrong — it’s just more moving parts than most REST-native projects need.

Why Developers Hit S3 Friction on Filebase#

Filebase’s S3 compatibility is genuinely useful when:

• You have existing infrastructure that talks S3 (Lambda functions, Terraform modules, backup agents).
• You store large blobs and want multipart upload semantics you already know.
• Your team is AWS-fluent and the S3 SDK is already a dependency.

But many developers building IPFS into a web app, a dApp, or a CI pipeline aren’t coming from that world. They run into:

XML error responses. S3 returns XML. Your JavaScript fetch call gets back <?xml version="1.0" ...><Error><Code>InvalidAccessKeyId</Code> and you have to add an XML parser to debug it.

Credential management. S3-style auth (access key + secret + HMAC-SHA256 request signing) is not trivial to implement from scratch in a browser or edge function. Pre-signed URLs help, but generating them server-side adds a round trip.

CID retrieval as an afterthought. The CID is metadata on the S3 object, not the primary response. You either parse response headers or call a separate metadata endpoint.

No native signed upload tokens. If you want users to upload directly from a browser without exposing server credentials, Filebase requires you to build a pre-signed URL generation endpoint yourself.

IPFS Ninja’s signed upload tokens handle this pattern natively: generate a time-limited token server-side once, embed it in your frontend, and let users POST directly to api.ipfs.ninja until the token expires or you revoke it.

Pricing Side by Side#

For small-to-medium projects, the jump from free to the first paid tier is $5/mo on IPFS Ninja vs roughly $20/mo on Filebase. If you’re building a side project or a startup MVP, that difference matters.

Gateway Features Compared#

Both services offer dedicated IPFS gateways (subdomains that serve your pinned content over HTTPS). Where they differ:

Filebase gives you a dedicated gateway on paid plans. It serves your bucket’s content and integrates with their S3 namespace.

IPFS Ninja gateways at https://{slug}.gw.ipfs.ninja support:

• Access modes: restricted (token required), open (public), or folder (directory listing).
• IP whitelisting: lock a gateway to known server IPs.
• Origin restrictions: restrict to specific HTTP origins, useful for browser-only CORS scenarios.
• Image optimization: the /image/{cid} endpoint lets you resize, crop, and convert format on the fly — no separate image CDN needed.

If your use case is serving assets to a web frontend, the CORS origin restriction and built-in image optimization endpoints save you a separate service integration.

Pinning an Existing CID#

Already have a CID from another node or service? Both platforms let you pin it without re-uploading. On IPFS Ninja:

curl -X POST https://api.ipfs.ninja/pin \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{
    "cid": "bafkreib4mrow...",
    "description": "Pinned from external source"
  }'

On Filebase, you pin via a PUT to your bucket with the CID as a custom metadata header, then Filebase fetches and pins it. The CID-first workflow on IPFS Ninja is more direct if you’re coming from an IPFS-native mindset rather than an S3-native one.

See what is IPFS pinning for a deeper explanation of why pinning matters and what happens when content isn’t pinned.

Client-Side Uploads Without Leaking Credentials#

This is a common architecture question: how do you let a browser upload to IPFS without shipping your API key to the client?

Filebase approach: generate a pre-signed S3 PUT URL on your server, return it to the client, client PUTs directly. Standard S3 pre-sign pattern, works fine, but you need to implement the server-side signing endpoint.

IPFS Ninja approach: call /token/upload/new (or generate via dashboard) to create a signed upload token. Embed that token in your frontend. The client posts to api.ipfs.ninja using Authorization: Signed {token}. The token can be scoped to expire after a set time or revoked instantly from the dashboard.

// Frontend code — token was fetched from your server
const token = 'your-signed-upload-token';

const response = await fetch('https://api.ipfs.ninja/upload/new', {
  method: 'POST',
  headers: {
    'Authorization': `Signed ${token}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    content: btoa(fileContentAsArrayBuffer), // base64 for binary
    description: 'User uploaded file',
  }),
});

const { cid, uris } = await response.json();
console.log('Pinned at:', uris.url);

For a deeper walkthrough of upload patterns, see how to upload files to IPFS.

When to Still Choose Filebase#

This article is meant to be honest, not a one-sided pitch.

Choose Filebase if:

• Your codebase already uses AWS SDK v3 or Boto3 and you want zero additional dependencies.
• You’re migrating from S3 to IPFS and want to swap endpoints rather than rewrite upload logic.
• You’re storing very large files and need reliable multipart upload with S3 semantics (though IPFS Ninja also has a large upload API).
• Your team has deep AWS expertise and finds S3 auth more familiar than REST headers.

Choose IPFS Ninja if:

• You want a single POST /upload/new to get a CID back with no intermediate steps.
• You’re building a frontend-first app and need client-safe upload tokens without building pre-sign infrastructure.
• You want image optimization and access-controlled gateways without adding another service.
• You’re price-sensitive and the $5/mo entry point matters for your project stage.

Summary#

Filebase is a solid product for teams already living in the AWS ecosystem. Its S3 compatibility is a real advantage when that’s your context. But for developers who just want to pin files to IPFS through a clean REST API — and get a CID back immediately — the S3 layer adds ceremony without benefit.

IPFS Ninja keeps the API surface minimal: upload, pin, fetch. The gateway, image optimization, and upload token features are available when you need them, not required upfront.

For a broader look at how IPFS Ninja compares to other services, see best IPFS pinning services.

Ready to start pinning? Create a free account — 500 files, 1 GB storage, no credit card required.