Getting started
Dashboard
The dashboard shows the same data as the CLI, through the same API. It is also the only place where changes that matter are approved (see Approvals).
| Page | What's there |
|---|---|
| Organizations | Your organizations; create one |
| Projects | Projects in an organization |
| Integrations | Providers Ahena supports, their capabilities and docs |
| Recipes | Recommended stacks, reasons, alternatives, costs |
| Team | Members and roles (owner, admin, developer, viewer); invite by email, pending invitations |
Invitation (/invite/<token>) |
An emailed invitation: the organization, role and who invited; join it |
| Sign in, Forgot password, Reset password | /login, /forgot-password, /reset-password (from the emailed link) |
| Activity | The organization's audit log |
| Project → Overview | Production health, environments and their connections |
| Project → Stack | The Stack Graph: capabilities → providers → resources → health, with next actions |
| Project → Environment | Connections (connect, Doctor, disconnect) and secrets |
| Project → Doctor | Latest checks per environment, with fixes |
| Project → Drift | What changed at the providers since the approved state (ahena.lock), per environment, with "Check now"; scheduled checks and email alerts are set per environment under Settings → Monitoring |
| Project → Plans | Stored plans, their operations and outcomes (including partial failure); approve, apply and cancel them |
| Project → Activity | The project's audit log, including agent (MCP) and CI actions |
| Project → MCP | Agent setup, approval policy, recent agent activity |
Approvals (/approvals/<id>) |
A change the CLI or an agent asked to make: approve or decline it |
| Project → Settings | CI tokens for ahena deploy-check |
Sign-in uses an httpOnly cookie on the dashboard's own origin; the dashboard calls the API server-side with a bearer token.
Team invitations
Owners and admins see Invite by email on the Team page: an address and a role (only owners can offer Owner). The invitee gets an email with a link that works once, for 7 days. Pending invitations lists who was invited, the role, by whom and when the link expires; owners and admins can revoke (an owner invitation only by an owner). Inviting the same address again sends a new link and the old one stops working. A plan without room for another member says so when you invite, with a link to the plans. Add an existing account adds someone whose Ahena account already has a verified email, without an email round trip.
The invitation page (/invite/<token>) shows the organization, the role and who invited. Signed
out, it offers sign-in or a new account and returns afterwards. Signed in with a different address,
it says the invitation is for someone else and offers to switch accounts; with an unverified email,
it asks to confirm the address first (and can resend the link). Join adds you and opens the
organization. The page sends no Referer, so the link isn't passed on.
Approvals
Changes that matter are approved only from a signed-in browser: anything that isn't SAFE in production, and anything billable or destructive in any environment. The CLI and AI agents (MCP) can ask for approval but never give it, even with an admin's token.
When ahena apply (or an agent) reaches such a change, Ahena records an approval request and
prints its link, https://app.ahena.io/approvals/<id>. The page shows:
- the organization, project and environment (production is called out);
- what will change: each operation with its classification (safe, needs confirmation, billable, destructive) and the provider's cost notice;
- who asked: "your terminal" (the CLI) or "an AI agent via MCP", when, and when the request expires;
- Approve and Decline.
After approving, return to your terminal; Ahena continues automatically. A request is decided once. Its states: waiting, approved, declined, used (a direct apply consumed it) and expired. Signed out, the link goes to sign-in and back; people outside the organization get the normal not-found page. Deciding needs the same permissions as approving directly: an owner or admin for production and for billable or destructive changes; a developer for other changes outside production.
On a plan's page (Project → Plans → a plan), people who may change that environment can:
- Approve the pending operations. "Include billable and destructive changes" appears only when such operations are pending; without it they stay pending.
- Apply the approved operations. The page then shows the outcome (verified, not verified yet, failed, unknown, skipped) and the plan's status.
- Cancel the plan.
Each operation shows whether it needs dashboard approval and how it was approved (in the dashboard, from the CLI, or by an agent). Changes that matter run only on a recent approval from the dashboard; an older approval, or one given elsewhere, has to be renewed here.