Skip to main content
The atmn CLI keeps your pricing in code. You write your features and plans in an autumn.config.ts file, preview what would change, and push it to Autumn with one command.
This page covers atmn 2. If you have a config from atmn 1.x, see upgrading from 1.x.

​
Set up a project

Run atmn init in the root folder of your project:
init does the whole setup in one go:
  1. Connects you to Autumn. If you don’t have a key yet, it asks how you want to connect: sign in (opens your browser), or go keyless (creates a sandbox for you right away, no account needed).
  2. Creates your config folder. By default that’s autumn/, holding autumn.config.ts next to features.ts, plans.ts and rewards.ts. In a monorepo it asks where the folder should go (default packages/autumn) and what to call the package.
  3. Adds atmn to your package.json and installs it, because the config imports from it. It also adds an atmn script and a small "atmn" field to your root package.json, so every command can find the config from anywhere in your repo.
  4. Pulls what’s already in Autumn into the config files.
  5. Installs the Autumn skills next to the config, so your coding agent knows how to work with the CLI.
Your keys end up in a .env file at the root of your repo:
.env
Went keyless? Your sandbox has no owner yet. Link it to an account within a few days with bunx atmn login --claim you@example.com. The key you already have keeps working.
You can check your setup at any time with bunx atmn env. It shows which organization, environment and key your commands will use.

​
Log in on its own

You don’t need init to connect. atmn login opens your browser, lets you pick an organization, and writes both keys to your .env:
Add --keyless to create a sandbox without an account instead.

​
Push and pull

Once you have a config, sync it with Autumn:
push reads your config, compares it with what’s in Autumn, and shows what would be created, updated or deleted. Nothing changes until you add --yes. If a change affects a plan that already has customers, Autumn drafts a migration for you and push prints the link to run it. After a push, the CLI writes an internalId into each feature and plan in your config. Leave it there. It’s how the CLI knows to rename something instead of deleting and recreating it. pull fetches your features, plans and rewards from Autumn and writes them into features.ts, plans.ts and rewards.ts, keeping your formatting where it can. If you don’t have a config yet, it asks where to create one.
Already made plans in the dashboard? Run bunx atmn pull to turn them into a config.

​
Environments

All commands use your sandbox by default. Add -p to target production:
push -p only previews the changes. Add --yes to apply them to production.
You can also create extra sandboxes for testing, each with its own plans and customers:
See the command reference for the full list.

​
Upgrading from 1.x

atmn 2 uses a new config format. If you run a 1.x config, the CLI stops and tells you so instead of guessing. To move over:
  1. Note any changes you made to your config that aren’t in Autumn yet.
  2. Rebuild the config from your organization. This rewrites autumn.config.ts and the features.ts, plans.ts and rewards.ts beside it. Other files are left alone.
  3. Re-apply your pending changes in the new format, then bunx atmn push.
What changed: Next: Configuration reference Learn how to define features, plans and pricing in your autumn.config.ts.

Configuration reference

Every builder and field available in autumn.config.ts