Project Structure

Banata Auth now needs to be read in two layers:

1. Public, dashboard-first surface
2. Self-hosting implementation surface

The first is what most users should integrate with. The second exists for Banata's own dogfooding and for teams that explicitly want to self-host.

Public Surface

These are the packages that fit a dashboard-first model:

In this model, your app talks to Banata endpoints over HTTP and Banata owns the auth system of record.

Self-Hosting Surface

@banata-auth/convex is the self-hosting kit. It exists so Banata can dogfood the runtime and so advanced users can run the auth engine inside their own Convex deployment.

That path requires local backend files in the consumer app:

convex/
├── convex.config.ts
├── auth.config.ts
├── authNode.ts
├── http.ts
└── banataAuth/
    ├── convex.config.ts
    ├── schema.ts
    ├── auth.ts
    └── adapter.ts

If you are self-hosting, use:

• Quick Start
• Convex Integration
• Self-Hosting

Monorepo Layout

banata-auth/
├── apps/
│   ├── dashboard/
│   ├── example-app/
│   ├── auth-ui/
│   ├── admin-portal/
│   └── docs/
├── packages/
│   ├── sdk/
│   ├── nextjs/
│   ├── react/
│   ├── convex/
│   ├── shared/
│   └── ui/
└── tooling/

What Each App Is For

Practical Rule

• If a user only needs Banata as an auth service, point them to the dashboard and SDK.
• If a user explicitly wants to run auth inside their own Convex deployment, point them to the self-hosting docs and GitHub examples.