AHENA
Documentation menu

Guides

Recipes

Uses the Ahena CLI (beta). Install it with npm install -g @ahena/cli, or prefix commands with npx @ahena/cli. See Installation. The dashboard covers projects, connections, Doctor, the Stack Graph, plans and approvals without it.

Recipes answer "what stack should I use?" Each one is a recommendation for a common kind of app. Every choice can be changed: Ahena never locks you into a recipe's providers.

Recipe Default stack Optional
saas Supabase (database, auth), Stripe (subscriptions), Resend (email), Cloudflare R2 (storage) Cloudflare DNS, AI
marketplace As SaaS, with Stripe Connect for seller payouts Cloudflare DNS, AI
mobile Supabase, Firebase (push), Cloudflare R2 Resend, Stripe, AI
web-app Supabase, Resend, Cloudflare R2 Cloudflare DNS, Stripe, AI
ecommerce Supabase, Stripe (Checkout, products from ahena.config.ts), Resend, Cloudflare R2 Cloudflare DNS
ai-app Ollama in development + OpenAI in production, Supabase, Cloudflare R2 Resend, Stripe

CLI

ahena recipe                       # list recipes
ahena recipe saas                  # the stack, why each choice, alternatives and known costs
ahena init --recipe saas --domain leo.app --app-name Leo
ahena recipe marketplace --apply --domain leo.app   # add to an existing project

Change the recommendation with flags (on --apply and init --recipe):

Flag Effect
--use <capability>=<provider> Use a different provider, e.g. ai=anthropic or ai=development:ollama,production:anthropic. Refused if that provider can't fill the capability.
--with <capability> Include an optional choice (e.g. --with dns).
--without <capability> Leave a default choice out.
--domain, --app-name, --bundle-id, --package-name Fill in settings: auth redirect URLs, email domain and sender, webhook endpoints, CORS origins, mobile app ids.

Recipes only fill in what they can derive from these inputs. Anything else is listed under "Still to fill in" instead of being guessed.

What --apply does

  • Adds the capabilities ahena.config.ts doesn't have yet. Sections you already have are never changed; they're reported as "kept".
  • Shows known provider costs and manual steps before asking for approval.
  • Writes nothing without confirmation (--yes to skip; --json requires --yes).
  • Warns when rewriting the file would drop comments or custom code, and refuses to write if the file changed while you were deciding.
  • Only ahena.config.ts can be updated. For .js/.mjs configs, copy the sections from ahena recipe <id> --json.

Applying a recipe changes only your config file. Providers are connected and configured afterwards with the usual reviewed flow: ahena connect, ahena doctor, ahena configure, ahena generate.

Registry checks

Every recommended and alternative provider is checked against the provider capability registry: a provider must declare what the capability needs (for example transactional-email for email, text-generation for AI). Tests fail if a recipe recommends a provider that this Ahena build doesn't ship. GET /v1/recipes reports any mismatch in unsupported.

API and dashboard

  • GET /v1/recipes and GET /v1/recipes/:id (public, no organization data).
  • Dashboard: Recipes in the organization navigation, with each recipe's stack, reasons, alternatives, costs, manual steps and the CLI commands to use it.