Framer AI AgentsDesign and publish professional sites with AI
MCP-Billing
OAuth 2.1 + usage-based Stripe billing for MCP servers
120 followers
OAuth 2.1 + usage-based Stripe billing for MCP servers
120 followers
Self-hosted Next.js/TypeScript boilerplate: full OAuth 2.1 + PKCE, API key management with zero-downtime rotation, usage-based Stripe billing, and Redis rate limiting. 7 modules, 300+ tests. One-time €79, no revenue share, no platform lock-in. The metering core is free and open source on npm.
Hey @marc_gil1 — the webhook silent-failure story in your launch note is a great flag for exactly the kind of bug that doesn't announce itself — appreciated the honesty there.
One thing I didn't see covered in the OAuth thread: how does this handle machine-only auth, where the "user" consenting is an agent acting on someone else's behalf with no human at the keyboard to click Allow? Client-credential / device-code shaped flows with no human in the loop are the case that keeps coming up as agents start initiating their own transactions.
Also curious about the runtime — the stack leans on Postgres + Redis, is this deployable on an edge runtime (Workers, etc.), or does it assume a traditional always-on Node server?
MCP-Billing
@akbar_b to give you the direct breakdown on both points:
1. Machine-only / Agent auth no, client_credentials and device-code flows (RFC 8628) are not supported. the token endpoint strictly handles authorization_code and refresh_token.
the deeper reason here isn't just a missing grant type in a switch statement - it's the domain model. the entire token schema is built around a human userId, meaning every OAuth token has a human subject explicitly attached to it. adding machine-to-machine auth for autonomous agents means either treating the agent as a synthetic user or refactoring the schema to support subjectless tokens. it's an open architectural decision, not just a missing route. and you're spot on: autonomous agents initiating transactions on their own is the exact driver pushing for that shift.
2. Edge runtime vs Node it's actually a hybrid setup with a deliberate split:
the middleware runs on the Edge runtime by default and is built specifically for it. it validates credentials directly against Upstash Redis over HTTP/REST with zero Prisma calls, and delegates to an internal Node endpoint only on a cache miss.
the API routes, on the other hand, run on the standard Node.js runtime using the default Prisma client.
so while the Edge/Node boundary was designed intentionally, deploying the entire app to a pure edge platform like Cloudflare Workers would require swapping Prisma for an edge-compatible driver on the API routes. it's not 100% edge-ready out of the box, but the hot path in the middleware is already edge-native.
really appreciate the sharp questions!
@marc_gil1 Thanks Marc, that's really clear. The subjectless-token part is the interesting one. From doing agent auth on Workers, the thing that saved us from a schema refactor was keeping a human as the token's owner and adding a claim for the agent, so it reads as "agent X acting for user Y". Subject stays human, but you still know who's actually acting. Do you think autonomous agents genuinely need to be first-class subjects, or is delegation enough for most of it?
MCP-Billing
@akbar_b that pattern ("agent X acting for user Y") is really smart because it fits right into the current schema without breaking anything - userId stays the subject and the claim gives you the audit trail for the agent.
to answer your question: for MCP with billing specifically, i think delegation is actually enough for the vast majority of use cases. there's a structural reason for it too - if you're metering usage, you fundamentally need a billable entity. someone has to own the credit card and receive the invoice. delegation gives you "who triggered the action" without destroying "who gets billed."
the only scenario where an agent genuinely needs to be a first-class subject is an autonomous agent with its own wallet or budget, with no human in the loop at all. that's still pretty rare today, but it's definitely where things are heading long-term.
MCP-Billing
@akbar_b hey akbar, really appreciated your take on delegation vs subjectless tokens for agents the other day.
quick post-launch question for you: when it comes to stack infra like auth and billing, is building custom in-house solutions (like you did on Workers) just your default engineering approach, or was there a specific gap in this product that made you prefer building over buying?
The decision to keep the metering core open source while charging for the rest is genuinely smart, basically lets people trust the math before they trust the product. Love that there's no revenue share either, feels refreshing.
MCP-Billing
@valerian_kingston really appreciate it valerain! taking a rev-share cut on self-hosted software always felt backward to me. if you're hosting the infrastructure on your own servers, you shouldn't be paying a perpetual platform tax on top.
The decision to ship the metering core as free open source while keeping the full stack paid is a really thoughtful move, it lets developers build trust with the hardest part before committing to the boilerplate.
MCP-Billing
@monicagelle thanks monica! that was the exact goal. idempotency and ledger math are where silent money bugs hide, so letting developers inspect and run that core for free felt like the only real way to build trust before asking for a single euro.