Skip to main content

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.

Deployaar is a Turborepo monorepo that splits the platform into two deployable applications and four shared packages. The Next.js 16 frontend (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 in pnpm-workspace.yaml and orchestrated by Turborepo. The layout below reflects the full directory tree sourced from the repository.
deployaar/

├── apps/
│   ├── web/                      # Next.js 16 (App Router) — frontend
│   │   ├── app/
│   │   │   ├── (auth)/
│   │   │   │   ├── sign-in/
│   │   │   │   └── sign-up/
│   │   │   ├── onboarding/
│   │   │   └── dashboard/
│   │   │       ├── feature-requests/
│   │   │       ├── prds/
│   │   │       ├── projects/
│   │   │       ├── tasks/
│   │   │       ├── reviews/
│   │   │       ├── settings/
│   │   │       ├── github/
│   │   │       └── invitations/
│   │   ├── components/
│   │   ├── hooks/                # Layer 4 — React Query + tRPC hooks
│   │   ├── lib/
│   │   │   └── auth-client.ts    # better-auth react client
│   │   ├── middleware/
│   │   ├── providers/
│   │   └── trpc/
│   │       └── create-client.ts
│   │
│   └── api/                      # Express 5 — API host
│       └── src/
│           ├── index.ts          # process entrypoint
│           ├── server.ts         # express app, route mounting
│           └── env.ts            # zod-validated env (PORT, BASE_URL, …)

└── packages/
    ├── database/
    │   ├── models/               # Drizzle schema (user, org, github, enums)
    │   ├── queries/              # Layer 1 — raw DB access
    │   └── drizzle/              # migrations + snapshots

    ├── services/                 # Layer 2 — business logic
    │   ├── ai/                   # Vercel AI SDK provider abstraction
    │   ├── auth/                 # better-auth config (google + github + email)
    │   ├── billing/              # Razorpay + plan limits
    │   ├── clarification/        # dup / "is this an edu question" gate
    │   ├── coding-agent/         # agent-kit + E2B sandbox + repo indexing
    │   ├── cron/
    │   ├── feature-request/
    │   ├── feature-task/
    │   ├── github/               # Octokit wrapper
    │   ├── health/
    │   ├── inngest/              # step-checkpointed workflow functions
    │   ├── invitation/
    │   ├── organization/
    │   ├── prd/                  # PRD generation from feature request
    │   ├── project/
    │   ├── pull-request-review/  # shallow / standard / deep AI review
    │   ├── user-settings/
    │   └── workflow-eval/        # internal eval harness for agent workflows

    ├── trpc/
    │   ├── server/               # Layer 3 — routes + models per domain
    │   │   └── routes/
    │   │       ├── feature-request/
    │   │       ├── feature-task/
    │   │       ├── prd/
    │   │       ├── agent-run/
    │   │       ├── pull-request-review/
    │   │       ├── project/
    │   │       ├── organization/
    │   │       ├── github/
    │   │       ├── billing/
    │   │       ├── invitation/
    │   │       ├── user-settings/
    │   │       ├── cron/
    │   │       └── health/
    │   └── client/

    ├── logger/
    ├── eslint-config/
    └── typescript-config/

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 endpoint
  • GET /openapi.json — auto-generated OpenAPI 3 document from trpc-to-openapi
  • GET /docs — Scalar interactive API reference
  • ALL /api/* — REST / OpenAPI mirror of all tRPC procedures
  • ALL /trpc/* — tRPC batch endpoint (used by apps/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.
PackagePurpose
packages/databaseDrizzle ORM schema (models/), raw DB query functions (queries/ — Layer 1), and migration files (drizzle/). Connects to Neon Postgres via DATABASE_URL.
packages/servicesAll 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/trpctRPC 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/loggerShared 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.
#LayerLocationRole
4Frontend Hooksapps/web/hooks/*React Query wrappers around tRPC client calls. The only code the frontend renders from.
3tRPC Routespackages/trpc/server/routes/*Thin procedures: validate input with Zod, call one service function, return output.
2Servicespackages/services/*All business logic: AI calls, GitHub API, billing, Inngest event dispatch, coding agent.
1DB Queriespackages/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 inside packages/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.
Browser

  │  HTTPS (tRPC batch or REST/OpenAPI)

apps/web  (Next.js 16, Vercel)

  │  React Query hook → tRPC client → fetch

apps/api  (Express 5, Render)

  │  tRPC adapter → createContext

packages/trpc/server/routes/*  (Zod validation → service call)


packages/services/*  (business logic, AI, GitHub, Inngest dispatch)


packages/database/queries/*  (Drizzle ORM queries)


Neon Postgres  (serverless, pooled)
Background pipeline steps (coding agent, PR review, PRD generation) are triggered by Inngest events dispatched from 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.

Build docs developers (and LLMs) love