Repository Scan

Before you deploy an app, Devpilot scans your repository to figure out what it is and how it should be deployed. The scan detects your framework and language, identifies build and start commands, extracts required and suggested environment variables, infers database and service dependencies, and then produces an AI-generated deployment pipeline you can review and tweak in the deploy wizard.

You do not have to run a scan manually — it kicks off automatically when you connect a new repository or start a new deployment from the Deploy wizard. But you can also trigger it directly if you want to see what Devpilot detects before creating an app.

When a scan runs

• On repository connect. When you select a repository in the deploy wizard, Devpilot scans it immediately so the wizard can pre-fill framework, build commands, env vars, and pipeline hooks.
• On demand. You can trigger a fresh scan for any repository URL your workspace can access — useful when you want to preview what Devpilot would detect before committing to a deployment.
• Force rescan. If you have pushed changes that affect detection (for example, you added a Dockerfile or changed your package manager), you can force a rescan to bypass the cache.

What Devpilot detects

The scan produces a structured result with everything the wizard needs to build a deployment:

• Framework — The framework name, version, and an icon (for example, Laravel 12.0, Next.js 14, Django 5.0).
• Language — The primary language and version (PHP 8.2, Node 20, Python 3.12, and so on).
• Package manager — composer, npm, yarn, pnpm, pip, or similar.
• Build configuration — The suggested install, build, and start commands, plus the output directory.
• Environment variables — Two lists:
  • Required vars — Variables your app cannot run without, each with a description and whether it is sensitive (for example, APP_KEY).
  • Suggested vars — Variables that are commonly configured for your stack, with sensible defaults and sensitivity flags (for example, APP_ENV, DB_CONNECTION, OAuth client IDs).
• Databases — Detected database dependencies (mysql, postgres, sqlite, redis, and so on), with versions when available.
• Services — Additional services your app uses (queue workers like Horizon, object storage like S3, caches, and so on).
• Port — The port the app expects to run on, if it can be inferred.
• Monorepo detection — Whether the repository is a monorepo, and if so, the packages inside it.
• Server requirements — Minimum RAM and CPU, recommended OS, required runtimes (for example php:>=8.2, node:>=18), and any required PHP extensions or system packages.
• Confidence score — How confident Devpilot is in the detection (0–1).
• Notes — Human-readable notes about the stack (for example, "Horizon is configured for queue management", "Redis is required for caching and queueing").

Alongside the detection, Devpilot also generates a deployment pipeline — a full list of hooks with their stage, action type, command, and priority — tailored to the detected stack.

Running a scan

How scan results flow into the deploy wizard

The scan is not just informational — every field it produces drives a specific step of the wizard:

• Framework and language preselect the platform and show the matching icon.
• Build configuration pre-fills the install, build, and start commands on the build step.
• Required env vars are listed at the top of the environment step and must be provided. Suggested env vars appear underneath with default values filled in; you can toggle them on or off.
• Detected databases and services let the wizard warn you if the chosen server is missing a required runtime.
• Server requirements feed into the runtime preflight check, which verifies your target server has the right runtimes and extensions before deployment starts.
• Generated pipeline is the initial set of deployment hooks, including install, migrate, cache, and restart steps appropriate to the stack.

You are never locked into the scan's suggestions — edit any value before deploying, and refine the pipeline using natural language if you want to add or change hooks.

Refining the generated pipeline

After the scan, you can describe changes to the pipeline in plain language — for example, "add a step to seed the database after migrate" or "run tests before deploying". Devpilot's pipeline generator takes your prompt and the current pipeline and returns an updated version. This is rate-limited to 20 pipeline generations per minute per workspace.

Runtime preflight

Right before you deploy, Devpilot can run a runtime preflight check against your target server using the scan's server requirements. The preflight verifies that the server has the required runtimes (PHP, Node, Python, etc.), required versions, and required PHP extensions. If anything is missing, the wizard surfaces a clear warning so you can install the missing pieces before triggering the deployment.

Scan statuses

Each scan record moves through a handful of statuses:

Completed scans expire after a short window so that stale results do not drive new deployments; once expired, the next scan runs fresh against your repository.

Limits and privacy

• Rate limit. You can run up to 10 scans per minute per workspace.
• Provider authentication. Scans run against connected GitHub, GitLab, or Bitbucket integrations. If your provider token has expired, Devpilot returns a clear error asking you to reconnect in workspace settings.
• Branch support. You can scan any branch you have read access to. If you leave the branch blank, Devpilot uses the default branch.
• What Devpilot sees. The scan reads your repository's files to detect the stack. Detection metadata, suggested env vars, and the generated pipeline are stored; source file contents are not retained beyond the scan itself.

Tips for accurate detection

• Commit your manifest files. Framework detection relies on composer.json, package.json, requirements.txt, go.mod, and similar manifests. Keep them up to date.
• Lock versions where possible. A pinned PHP, Node, or Python version makes the server requirements more precise.
• Scan the branch you will deploy. Detection is branch-specific, so scan the same branch you intend to ship from.
• Force a rescan after stack changes. If you add a new dependency, a Dockerfile, or change package manager, a force rescan gives you an up-to-date pipeline.

Next steps