Architecture Overview

deplo.ai is a small number of clearly separated pieces: a dashboard, a REST API, a job queue with a worker, a stack-detection engine, and provider adapters that talk to Vercel and Render using your credentials. Here is the whole system on one diagram:

The dashboard#

The dashboard at www.deplo.in is a Next.js application deployed on Vercel. It handles sign-in, repository browsing, the deploy flow, live logs, and per-project monitoring. It contains no API logic of its own — every action is a call to the REST API. The deplo CLI is a second client for exactly the same API, so anything the dashboard can do, the terminal can too.

The API and the rewrite proxy#

The API is an Express application (TypeScript, clean architecture) running on Render. The browser never talks to it directly: it always calls same-origin /api/v1/… on www.deplo.in, and a Vercel rewrite forwards the request to the Render backend. One domain, no CORS preflights, and the backend host stays an implementation detail.

Requests authenticate with a Bearer token — a 7-day JWT from GitHub OAuth, or a long-lived dpl_ CLI token. Details in Authentication & Security and the API reference.

The queue and the worker#

Deployments are long-running, so the API never does the work in the request cycle. POST /deployments validates, creates a deployment record, enqueues a job on a BullMQ queue backed by Redis, and returns immediately. A worker picks the job up and drives the deployment through its phases while the dashboard polls for status and logs. Jobs retry transient failures with exponential backoff; provider errors that can never succeed (bad requests, missing configuration) fail fast instead of retrying.

The detection engine#

The first phase of every deployment is analysis. The engine takes one snapshot of the repository tree and runs it through a layered, evidence-scored pipeline: structure analysis (single app, frontend + backend, or monorepo), weighted framework signatures, language detection, and resolvers for runtime, build commands, and deployment strategy. Detection is deterministic first; only when confidence is low does it escalate to a strictly bounded AI fallback (at most two model calls per deployment).

The provider adapters#

The final phase talks to the hosting providers through dedicated adapters — one for Vercel, one for Render. Both act with credentials you connected (a Vercel OAuth token, a Render API key), stored AES-256-GCM encrypted per user and decrypted only at deploy time. There are no platform-level hosting credentials anywhere in the system:

• The backend deploys first, as a Render web service in your workspace (named like deplo-my-app-api).
• Its live URL is injected into the frontend build, which then deploys to your Vercel account (named like deplo-my-app-web).
• The backend receives FRONTEND_URL so your CORS configuration points at the real frontend origin.

The exact order of operations, every status, and what happens on failure are covered in Deployment Lifecycle.

Data stores#

• PostgreSQL (via Prisma) — users, repositories, deployments and their logs, encrypted provider connections, CLI token hashes, uptime samples.
• Redis — the BullMQ job queues plus caching (repository lists, deployment status, user profiles).

Going deeper#

This page is deliberately shallow. When you want the internals — clean architecture layers and their dependency rules, the full detection pipeline with confidence scoring, queue retry semantics, and how credentials are encrypted — go to the deep dive: