BunshipArchitecture
Runtime topology, route boundaries, and integration boundaries.
Positioning
Bunship is deployed as a single site: one web deployment serves marketing, app workspace, admin console, and docs.
Stack Overview
| Domain | Stack | Purpose |
|---|---|---|
| Web runtime | Next.js 16 + App Router | Unified route hosting and rendering |
| Business API | Elysia | Domain logic and external service orchestration |
| Auth | Better Auth / Clerk | Identity, sessions, OAuth, and account lifecycle |
| Data | PostgreSQL + Drizzle | Persistent business state and typed access |
| Queue/cache | Redis | Async jobs, queue control, and rate limiting |
| Billing | Stripe | Subscription billing and payment lifecycle |
| Storage | S3-compatible storage | Asset upload and delivery |
| AI | Multi-provider integration | Model execution and generation workflow |
Runtime Topology
Rendering diagram...
Request Flows
Business requests
- Browser loads page or triggers API action.
- Web layer forwards business calls to API layer.
- API layer applies domain rules and calls dependencies.
- Response updates user/admin UI.
Docs search requests
- Browser sends docs search query.
- Docs search service resolves indexed content.
- Result set is returned to docs UI with highlighted matches.
Boundary Rules
- Marketing routes focus on growth and conversion.
- App routes focus on end-user workflows.
- Admin routes focus on operations and governance.
- Docs routes focus on onboarding, integration guidance, and operations playbooks.
Docs uses an isolated layout/theme so docs styling does not affect marketing/app/admin interfaces.