Banata

Deployment

Self-Hosting

Run the full Banata platform on your own infrastructure.

Self-hosting means hosting the Banata platform yourself, not embedding a different auth model into your product. The goal is the same product shape as the hosted Banata service:

  • dashboard-first project setup
  • project-scoped API keys
  • Banata-managed emails, templates, organizations, and auth configuration
  • the same SDKs and frontend packages pointed at your self-hosted Banata instance

If you just want to integrate with Banata as a customer, use the hosted dashboard flow instead.

Product Shape

The hosted and self-hosted models are intended to match:

  1. An operator deploys Banata
  2. Developers sign in to the Banata dashboard
  3. They create a project
  4. They create a project-scoped API key
  5. Their apps use Banata's SDKs and auth surfaces against that Banata instance

The Convex package exists to power that platform deployment. It is not the primary customer integration surface.

Convex Wiring

The self-hosted platform keeps a small amount of local Convex wiring:

text
convex/
|-- convex.config.ts
|-- auth.config.ts
|-- authNode.ts
|-- http.ts
`-- banataAuth/
    |-- auth.ts
    |-- adapter.ts
    `-- schema.ts

Why these remain:

  • auth.ts binds project runtime config, env, and local auth config
  • adapter.ts closes over the local auth factory
  • schema.ts remains as a local schema anchor for Convex component codegen

What comes from @banata-auth/convex:

  • packaged component registration
  • packaged component schema
  • packaged component migrations
  • auth factory helpers, plugins, triggers, and HTTP route helpers

Infrastructure

To self-host Banata, you still need:

  • Convex for backend functions and data
  • a Next.js host for dashboard, auth UI, and proxy routes
  • an email provider for delivery
  • your own domains and DNS

Follow Quick Start for the reference wiring and Deploy for production deployment.