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.

About this article: This article was drafted by an AI assistant using IPFS.NINJA’s content generation workflow, then reviewed and approved by Nacho Coll. All code examples were verified against the live IPFS.NINJA API. If you spot an inaccuracy, please open an issue at https://github.com/ipfs-ninja/feedback. Read more about how we use AI in our content and meet the people behind IPFS.NINJA.