Puter.js is a backend platform that lets you call authentication, cloud storage, a key-value database, serverless workers, and a wide range of AI models directly from your frontend code ─ all by adding a single script tag to your HTML. Skipping the server is what you’d expect from any BaaS, but what sets Puter.js apart is the direction the billing flows. It runs on a “User Pays” model: usage is charged to each end user’s own Puter account, so no matter how many users you gain, the developer never receives a bill.
Key Features
- User Pays billing model: When a user signs in, your app runs on that user’s own Puter account. Storage, database, and AI usage are metered against the user, and the developer is never charged
- AI gateway: Direct frontend access to a large catalog of models, including OpenAI, Claude, and Gemini, with no API keys to manage. New models are added on an ongoing basis
- The full non-AI stack is included too: Authentication, a file system, a KV store, serverless workers, hosting, and peer-to-peer communication are all available from the same JavaScript library
- An API designed to be handed to an agent: No build configuration, no server setup, and short API calls. The integration is scoped so that a single instruction to an AI coding agent is enough to wire it up
- Open source and self-hostable: Released under AGPL-3.0, so running it on your own infrastructure remains an option
Pricing
The developer pays nothing. Each end user gets a free tier on their own account, and anything beyond that is paid by the user directly to Puter.
| Party | Cost | Details |
|---|---|---|
| Developer | $0 | No infrastructure costs. No charges as your user count grows |
| End user | Free tier + usage-based beyond it | Rate limits apply, such as 100 MiB of storage and 30 AI requests per 10 seconds |
Pricing information is current as of August 2026. The per-unit rates charged once the free tier is exceeded could not be confirmed from public materials. For the latest details, see the official pricing page and the rate limits documentation.
Pros and Cons
✅ Pros
- No bill arrives as your published app grows. If it goes viral and traffic spikes unexpectedly, you can leave it running without worrying about cost
- Because you never hold API keys, you carry no risk of keys leaking and being abused
- Self-hosting is available as a migration path. Keep in mind, though, that the moment you move, server operating costs become your own ─ and the zero-cost advantage this article is about goes away
⚠️ Cons
- Your end users must create a Puter account and sign in. There’s no “open it and try it instantly” path, which adds one more step where users may drop off
- Since calls are made directly from the frontend, which model you’re using and what prompts you’re sending are visible on the client side. Not a good fit when you need to keep that logic hidden
- Usage beyond the free tier is billed to the end user, but the unit rates aren’t published. That means you, the developer, can’t tell your users how much they might end up paying
Comparison with Similar Services
| Criteria | Puter.js | Supabase |
|---|---|---|
| Who pays beyond the free tier | End user | Developer |
| End user accounts | Puter account required | Fully up to your app’s design |
| AI model integration | Access to many models without API keys | Requires a separate AI SDK or vendor integration |
The reversal of who pays is the biggest difference, and the price of that reversal is having to ask your users to create an account. How you weigh it depends on whether you’re publishing an indie project or building a product where the user experience needs to be carefully crafted.
Who It’s For
- Anyone who wants to quickly add authentication, a database, and AI calls to an app they built with an AI coding tool
- Indie developers who want to publish to a large audience for free, without running servers or managing API keys
- Developers who want to avoid vendor lock-in while keeping self-hosting as an option
Summary
Puter.js flips the standard BaaS assumption that “the developer pays” and shifts the cost to the end user. It fits well for publishing indie projects and for tools you want to hand out without worrying about cost. On the other hand, it’s not the right choice for B2B deliverables where you want to design the account-creation flow yourself, or for products where you need to control the billing experience.