Deployaar is a Turborepo monorepo that splits the platform into two deployable applications and four shared packages. The Next.js 16 frontend (Documentation Index
Fetch the complete documentation index at: https://mintlify.com/paramveer-cyber/Deployaar/llms.txt
Use this file to discover all available pages before exploring further.
apps/web, deployed to Vercel at deployaar.paramveer.xyz) communicates exclusively with the Express 5 API (apps/api, deployed to Render at deployaar.onrender.com) over tRPC. The API is backed by a Neon serverless Postgres database accessed through Drizzle ORM, with Inngest driving background workflows and E2B providing the sandboxed environment for the coding agent. Every piece of business logic lives in packages/services, keeping the tRPC routes thin and the frontend entirely free of server-side concerns.
Monorepo Structure
The workspace is declared inpnpm-workspace.yaml and orchestrated by Turborepo. The layout below reflects the full directory tree sourced from the repository.
Application Layer
Deployaar has exactly two runnable applications. Everything else is a shared package that both applications depend on.apps/web — Next.js 16 (App Router)
The frontend is a Next.js 16 application using the App Router, deployed to Vercel at deployaar.paramveer.xyz. It uses React 19, Tailwind CSS, and shadcn/ui components. Routing is grouped into three segments: (auth) for sign-in and sign-up, onboarding for new-user setup, and dashboard for the main product UI. The frontend never imports from packages/services directly — all data access goes through tRPC hooks in apps/web/hooks/, which are React Query wrappers around the tRPC client.
apps/api — Express 5
The API is an Express 5 server deployed to Render at deployaar.onrender.com. The server.ts file mounts every route in the following order:
ALL /api/auth/*— better-auth handler (sign-in, sign-up, OAuth callbacks, session, sign-out)POST /api/github/webhook— GitHub App webhook receiver (signature-verified)POST /api/razorpay/webhook— Razorpay webhook receiver (signature-verified)ALL /api/inngest— Inngest function serve endpointGET /openapi.json— auto-generated OpenAPI 3 document fromtrpc-to-openapiGET /docs— Scalar interactive API referenceALL /api/*— REST / OpenAPI mirror of all tRPC proceduresALL /trpc/*— tRPC batch endpoint (used byapps/web)
The API is deployed on Render and serves both the
/trpc batch endpoint (consumed by the Next.js frontend) and a REST/OpenAPI mirror at /api/* generated automatically by trpc-to-openapi. Both surfaces expose exactly the same procedures — use whichever is more convenient for your integration. The interactive Scalar API reference at /docs documents every procedure with request/response schemas.Package Layer
The four shared packages form the backbone of the platform. They are consumed by both applications but never deployed independently.| Package | Purpose |
|---|---|
packages/database | Drizzle ORM schema (models/), raw DB query functions (queries/ — Layer 1), and migration files (drizzle/). Connects to Neon Postgres via DATABASE_URL. |
packages/services | All business logic (Layer 2): AI calls, GitHub operations, billing, workflow orchestration, the coding agent, and every domain-specific service. Never imported directly into apps/web. |
packages/trpc | tRPC route definitions (Layer 3). Each route folder contains a models.ts (Zod schemas) and a route.ts (procedures) that validates input and delegates to a service. Also exports the tRPC client factory used by apps/web. |
packages/logger | Shared structured logger consumed by all packages and the API. Log level controlled via the LOGGER_LEVEL environment variable. |
The Four-Layer Rule
Every feature in Deployaar is implemented top-to-bottom through exactly four layers. No layer is permitted to skip the one beneath it — a tRPC route cannot import a Drizzle query directly, and a frontend hook cannot import a service function.| # | Layer | Location | Role |
|---|---|---|---|
| 4 | Frontend Hooks | apps/web/hooks/* | React Query wrappers around tRPC client calls. The only code the frontend renders from. |
| 3 | tRPC Routes | packages/trpc/server/routes/* | Thin procedures: validate input with Zod, call one service function, return output. |
| 2 | Services | packages/services/* | All business logic: AI calls, GitHub API, billing, Inngest event dispatch, coding agent. |
| 1 | DB Queries | packages/database/queries/* | Raw Drizzle queries only. Zero business logic. |
This rule is the single most important architectural constraint in Deployaar. It keeps business logic testable in isolation, prevents frontend bundle bloat from server-only imports, and makes the tRPC surface a predictable contract between the two applications. See the full explanation at /concepts/four-layer-rule.
External Integrations
Deployaar’s services layer reaches out to five external systems. All integrations are encapsulated insidepackages/services — the tRPC routes and frontend never call these systems directly.
GitHub App (Octokit)
The
github service is an Octokit wrapper that handles GitHub App authentication, installation management, repository listings, branch creation, commits, pull request authoring, and incoming webhook verification. A GitHub App installation is required to link a project to a repository.E2B Sandbox
The
coding-agent service provisions an E2B cloud sandbox for every agent run. The agent executes terminal, readFiles, and createOrUpdateFiles tools inside the sandbox — fully isolated from the host environment. Controlled by E2B_API_KEY and E2B_TEMPLATE_ID.Inngest
The
inngest service exports the Inngest client and every workflow function. All long-running pipeline steps (coding agent execution, PR review, PRD generation) are implemented as Inngest functions with step.run() checkpointing. The /api/inngest endpoint on the Express server is the function serve target.Razorpay
The
billing service wraps Razorpay for payment processing and per-plan usage limit enforcement. Razorpay posts subscription events to /api/razorpay/webhook on the Express server; the handler verifies the x-razorpay-signature header before processing.AI Providers (Vercel AI SDK)
The
ai service exposes a single resolveAiModel() abstraction built on the Vercel AI SDK. It routes to Anthropic, OpenAI, Google Generative AI, or DeepSeek based on the DEFAULT_AI_PROVIDER and DEFAULT_AI_MODEL environment variables. Switching providers requires no code changes.Neon Postgres
The serverless Postgres database is accessed exclusively through Drizzle ORM in
packages/database. Neon’s connection pooling is compatible with Render’s and Vercel’s serverless/edge runtimes, and the schema is managed entirely through Drizzle migrations.Request Flow
A standard data-fetching request from the browser travels through every layer of the system in a deterministic path. Mutating requests (triggering a pipeline run, generating a PRD, etc.) follow the same path but also dispatch Inngest events from within the service layer.packages/services. Inngest calls back to the /api/inngest endpoint on the Express server to execute each workflow step, picking up from the last completed checkpoint if the server has restarted.