# Autumn: a billing layer that sits between Stripe and your application

> An Apache-2.0 TypeScript platform for subscriptions, credits, usage limits and enterprise plans, where the integration surface is three functions. What it takes on, and what it still asks you to run.

**useautumn/autumn** — Autumn is an open-source pricing & billing platform

- Repository: https://github.com/useautumn/autumn
- Website: https://useautumn.com
- Stars: 2,813 · Forks: 274
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/useautumn-autumn

## A layer between Stripe and the code you already have

Autumn describes itself as an open-source layer between Stripe and your application, and that framing explains most of the design. It is not a competing payment processor. Stripe still moves the money, and Autumn sits on top of it holding the pricing model, the entitlements and the state machine that connects a customer to a plan.

The README lists what you can build on it: subscriptions, credit systems and top ups, usage-based models and overages, and custom plans for large customers. Each of those is a configuration job on the dashboard rather than a set of database migrations. Products and plans are created on the dashboard first, and the README is emphatic that any pricing model is supported, giving four that are common in practice: usage with overage, credits, seat-based with per-seat limits, and pay-upfront for a fixed quantity of a feature consumed over time.

The project is a Y Combinator F24 company, the licence is Apache-2.0, and the hosted version lives at useautumn.com with documentation at docs.useautumn.com. The repository is not archived and the last push was on 2026-09-24, so the code is moving, though there are no tagged releases to point at, which is a real gap for anyone who wants to pin a version.

## Three functions carry the whole integration

The design decision that makes Autumn worth reading about is how small the client surface is. All billing logic is implemented through three calls, and the README shows each one with a snippet you could paste into a React component.

The first is attach, which handles every purchase flow in one place. It returns a Stripe Checkout URL or performs an upgrade or downgrade, so a single button covers both the first subscription and a plan change:

```tsx
const { attach } = useAutumn();
<button
  onClick={async () => {
    await attach({ productId: "pro" });
  }}
>
  Upgrade to Pro
</button>
```

The second is check, which answers whether a customer has access to a product or feature, or how much usage remains:

```ts
const { check } = useAutumn();

const { data } = await check({ featureId: "ai_tokens" })

!data.allowed && alert("AI limit reached")
```

The third is track, which records a usage event when a customer consumes something metered:

```ts
const { track } = useAutumn();

await track({
  featureId: "ai_tokens",
  value: 1312
})
```

What disappears from your codebase is the unglamorous half. The README is specific that Autumn handles webhooks, upgrades and downgrades, cancellations and payment failures, so the Stripe webhook endpoint and the reconciliation logic that usually accumulates around it are not yours to maintain.

## Why billing gets hard faster than payments

The README's argument for the project is not about Stripe being difficult. Its first numbered point is that billing infrastructure gets complex fast, and the list it gives is more specific than marketing usually manages: permission management, metering, usage limits enforced with cron jobs, and connecting all of it to upgrade, downgrade, cancellation and failed payment states. Race conditions and edge cases follow from that list rather than being incidental.

The second point is about coupling. Growing companies iterate on pricing, the README says, by raising prices, experimenting with credits or charging for a new feature. Each of those changes, done inside your own application, means a database migration, a rebuild of the in-app purchase flows, an internal dashboard for custom pricing, and a migration plan for grandfathering users who are still on old pricing.

That last item is the one that tends to hurt most. Grandfathering is not a bug in a pricing model, it is a permanent feature of a business with paying customers, and it is exactly the kind of thing that is cheap to add in month one and painful in month eighteen. Moving pricing state into a separate system makes it queryable and auditable rather than smeared across your product tables, which is the real argument the three-function API is making.

The trade is that you now have two systems that must agree about who is entitled to what. Autumn holds the authoritative pricing state; your application has to ask it before granting access, and a stale local copy is a support ticket waiting to happen.

## Self-hosting works, with a caveat the README does not soften

The self-hosting instructions are three steps, and they assume bun rather than npm or pnpm:

```bash
bun install
```

```bash
bun dev
```

After that the dashboard should be at `http://localhost:3000`. Two configuration details come next, both in a `server/.env` file. To log in you enter an email at the sign in page and a one-time password appears in your console, because normally the flow uses Resend to send that email or Google OAuth, and those credentials can be supplied in `server/.env`. If you want your own Postgres instance, the connection string goes into `DATABASE_URL` in the same file.

The caveat is the line right after the instructions: Autumn depends on a bunch of services, and if you want help with self-hosting or running a local instance you should contact the team on Discord. That is an honest admission that the three steps get you a running process rather than a complete production install, and it is the main thing to weigh when choosing self-hosting over the cloud service at app.useautumn.com.

The repository layout explains the dependency surface. The tree carries a docker directory, an emulate.config.yaml, firelens.conf, a server directory, shared, packages, scripts and vite, alongside apps for checkout, docs, website, leaf, sdk-test, sso-test-idp and testbench. It is a large monorepo, not a small service you can read in an afternoon.

## A monorepo that shows its working

The package manifest describes a bun workspace with a long list of packages, and reading it tells you more about Autumn's priorities than the README does. Alongside the obvious ones, server, shared, sdk, autumn-js, auth and ui, there are packages named stripe-sync, gateway, mcp, openapi, render, ksuid and ducklake. There is also an atmn-generator, an ax-evals directory, atmn-tests and an agent-docs package.

Two of those deserve comment. A stripe-sync package implies Autumn keeps local state reconciled against Stripe rather than treating Stripe as a black box queried per request, which is what makes entitlement checks fast enough to sit in a request path. An mcp package, alongside an agent-docs package and the modelcontextprotocol SDK in the overrides list, means Autumn is set up to be driven by coding agents as well as by HTTP clients.

The rest of the tree makes that last point concrete. Alongside the application code sit .claude, .cursor, .conductor, .plans, .superset and .zed directories, a CURSOR.md, skills-lock.json, agent-envs and trigger.config.ts. Editor and agent configuration is checked in alongside the code, which is unusual to see and says the team builds with those tools rather than merely tolerating them.

The dependency versions place the project in a specific moment. React is pinned at 19.2.7, vite at 7.3.2, Stripe at a 19.3.0-beta.1, drizzle-orm at 0.43.1 and better-auth at 1.6.25. decimal.js is in the catalog alongside postgres 3.4.7, which is a sensible pair for money handling, since binary floating point is the wrong tool for currency.

## What is settled and what is not

Some things the repository settles. The client API is three functions with examples attached. The pricing models it targets are named specifically rather than described vaguely. The self-hosting path exists, the licence is Apache-2.0 rather than a custom one, and the codebase is legible enough that the package layout tells you the architecture.

Other things it does not. There are no tagged releases, so there is no version to pin and no changelog to read, and the default branch is dev, which means the branch you see is not necessarily what a hosted customer runs. The dashboard configuration model is only described at the level of four examples, so the actual constraint system behind a plan, how limits reset, and how grandfathered pricing is expressed are all questions the documentation has to answer rather than the README.

The dependency list also hints at the operational weight. Stripe at a beta version, a gateway package, ClickHouse in the catalog, and MCP support together suggest a system with real moving parts. None of that is disqualifying for a billing platform, where moving parts are the nature of the work, but it does mean the choice between the hosted service and self-hosting is closer to a real decision than it looks from the three-line install guide.

## Conclusion

Autumn is most convincing for teams whose pricing changes faster than their database schema does, which is the case the README argues at length and the reason the attach, check and track split exists. Credits and usage overages are the models it handles with the least ceremony, and the separation between pricing configuration and application code is the real product. Two things to weigh before committing: self-hosting is supported but the README says plainly that Autumn depends on a bunch of services and points you to their Discord for help, and the default branch is dev with no tagged releases, so pinning is on you. Start on the cloud service at app.useautumn.com, wire up check and track behind your existing entitlement logic, and only then decide whether the self-hosted path is worth the dependency list.

## FAQ

### Is Autumn a payment processor or a library?

Neither exactly. It is a layer between Stripe and your application: Stripe still processes payments, while Autumn holds pricing configuration, entitlements and the state around upgrades, downgrades, cancellations and failed payments. Your code talks to it through three functions rather than by managing webhook state itself.

### How do I run Autumn locally?

Install bun, then run bun install followed by bun dev, and the dashboard appears at http://localhost:3000. Login uses a one-time password printed to your console unless you supply Resend or Google OAuth credentials in server/.env, and you can point DATABASE_URL at your own Postgres. The README notes Autumn depends on a number of services and suggests contacting the team on Discord for self-hosting help.

### Which pricing models does Autumn support?

The README says any pricing model, and gives four common ones: usage with overage where limits reset on a schedule you choose, credits that many features draw from, seat-based billing with per-seat limits, and pay-upfront for a fixed quantity consumed over time. Plans are configured on the dashboard rather than encoded in your application.

### Can I pin a specific version of Autumn?

Not from releases, because the repository has no tagged releases. The default branch is dev, and the licence is Apache-2.0 with the package manifest marked private, which is the usual arrangement for an application whose packages are consumed through the hosted service or an SDK rather than from npm. The README points at the cloud service as the quickest starting point.

## Sources

- [Issues](https://github.com/useautumn/autumn/issues)
- [License: Apache-2.0](https://github.com/useautumn/autumn/blob/dev/LICENSE)
- [Project website](https://useautumn.com)
- [README](https://github.com/useautumn/autumn/blob/dev/README.md)
- [useautumn/autumn on GitHub](https://github.com/useautumn/autumn)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/useautumn-autumn