Detection Engine

When you connect a repository to Jetpacked, the detection engine runs before any build starts. Its job is to answer the questions that would otherwise take a developer 30–60 minutes to figure out manually: what framework is this, what runtime does it need, what services does it require, and how should it start in production.

What it reads

The detection engine reads structured signals from your repository — it does not send your source code to an AI model.

Manifest files

package.json — dependencies, scripts, engines field
bun.lockb, pnpm-lock.yaml, yarn.lock, package-lock.json — package manager detection
.nvmrc, .node-version — Node.js version pinning

Config files

next.config.*, vite.config.*, astro.config.*, nuxt.config.* — framework-specific config
prisma/schema.prisma, drizzle.config.* — ORM and database detection
.env.example — expected environment variable hints

Directory structure

src/, app/, pages/, routes/ — output and entry point inference
public/, dist/, .next/, .svelte-kit/ — build output location hints

Detection order

Each framework has a ranked set of signals. Jetpacked checks them in order and stops at the first confident match:

Primary signal — a framework-specific config file or unique directory (e.g. next.config.js for Next.js)
Dependency signal — a framework package in dependencies or devDependencies
Script signal — a framework CLI in the scripts block (e.g. "build": "next build")

If multiple frameworks match (e.g. a repo that has both Next.js and Storybook), the highest-confidence match wins.

What it produces

After detection, Jetpacked produces a deployment plan with the following fields:

framework:     next.js
version:       14
runtime:       node
nodeVersion:   20
packageMgr:    pnpm
buildCmd:      pnpm run build
startCmd:      node .next/standalone/server.js
outputDir:     .next
services:
  - postgres
migrations:
  - prisma migrate deploy

This plan is shown to you before the first deploy and can be overridden field by field.

Overriding detection

If the engine gets something wrong, you can override any field from the Configure tab in your project settings. Overrides are persisted and applied to every subsequent deploy — the detection result is only used as the default.

Structured inference

For ambiguous situations — for example, a repo that uses Prisma but hasn't specified which database provider — Jetpacked uses structured inference rules rather than guessing. In the Prisma example, it reads the provider field in schema.prisma to determine whether to provision PostgreSQL, MySQL, or SQLite.

Your source code is never sent to a language model during this process.

Failure transparency

When detection is confident but the build or start fails, Jetpacked produces a diagnostic report with:

The stage where the failure occurred
The specific error from the build log
Evidence used to reach the conclusion (files found, patterns matched)
A suggested fix in plain language

This means you never get a generic "deployment failed" message — you get the reason and a starting point for fixing it.