Skip to main content

ProdPilot

Takes a web app you built with an AI coding assistant from "it works on my machine" to a live, verified deployment, without leaving your IDE.

Tests Python 3.11 to 3.14 License: MIT Version 1.1.0

AI coding assistants make it quick to build a Node.js API or a React app that runs on your laptop. Getting it to run in production is where it breaks: credentials hardcoded in the source, no security headers, no container setup, no health check, and a deploy that fails with an error you have never seen.

ProdPilot finds those gaps, has your IDE's own coding agent fix them one at a time, checks every fix itself, and deploys the project to Render with a CI/CD pipeline once it is ready. It works as a Model Context Protocol (MCP) server: a small program on your machine that the agent in VS Code with GitHub Copilot, Cursor or Devin can call as a set of tools. ProdPilot calls no AI service itself.

It is for developers building Node.js with Express APIs or React with Vite apps who want them deployed properly, not just deployed.

Features

  • A production audit of 50 rules across security, secrets, environment, build, connectivity, API, structure, observability and git hygiene, scored from 0 to 100.
  • Fixes your agent applies and ProdPilot verifies. The agent reports a fix; ProdPilot re-runs that rule's own check on your files and decides. A fix that breaks something that already worked is undone.
  • Predictable changes. 44 of the 50 rules come with an exact change for the agent to apply; only 6 ask it to write code, inside limits ProdPilot sets.
  • A gate that asks whether it will really deploy. A score of at least 90, no critical failures, and an estimate from a model trained on 684 real Render deployments.
  • Deployment in one call. Nine stages, from a local Docker build to a live, smoke tested Render service with a GitHub Actions pipeline. It stops at the first stage that fails and tells you why.
  • Your credentials stay yours. They live in a file only your account can read, never in the project, and repository secrets are encrypted before they leave your machine.
  • Works in the IDE you already use. One command connects VS Code, Cursor or Devin, formerly Windsurf.

Quick start

You need Python 3.11 to 3.14, Node.js 20 or later, Docker running, git, a GitHub token and a Render API key.

pipx install prodpilot          # 1. install
prodpilot setup                 # 2. store your GitHub token and Render API key
prodpilot connect vscode        # 3. connect your IDE: vscode, cursor, or devin --project PATH

To pin the version, ask for prodpilot==1.1.0.

Then check that everything ProdPilot needs is in place:

prodpilot doctor
ProdPilot doctor

Config file: ~/.prodpilot/config.toml
  found
  github_token: stored
  render_api_key: stored
  permissions: access is limited to the current user

Tools ProdPilot runs:
  git: git version 2.54.0.windows.1
  Node.js: v26.3.0
  Docker: daemon 29.7.2

All checks passed.

In VS Code, run MCP: List Servers and start prodpilot. Open your project and ask the agent:

Use ProdPilot to audit this project and fix what it reports, one rule at a time.

Installation

Method Command
pipx, recommended pipx install prodpilot
uv uv tool install prodpilot
pip pip install prodpilot
From source git clone https://github.com/prodpilotai/ProdPilot && cd ProdPilot && pip install .

pip install prodpilot works and is the shortest route. pipx and uv are recommended because ProdPilot is a command line tool: they keep it and its dependencies in their own environment, so it cannot clash with the packages of whatever project you are working on. That matters here because ProdPilot pins scikit-learn to the version that saved the model it ships, which only that version is guaranteed to read.

Check the install with prodpilot --help, which lists serve, setup, doctor and connect.

Requirement Why
Python 3.11, 3.12, 3.13 or 3.14 ProdPilot itself
Node.js 20 or later The audit parses your JavaScript with Node
Docker, running The gate and the deploy build your project in a container first
git, and a GitHub repository set as the project's origin Deploys push the files ProdPilot generated
A GitHub token A classic token with the repo and workflow scopes, or a fine grained one with read and write access to contents, secrets and workflows
A Render account and API key Render is where the project is deployed

ProdPilot is developed on Windows 11, and its test workflow runs the suite on Linux, macOS and Windows for Python 3.11 to 3.14. The same workflow installs the built wheel outside the repository on all three systems and loads the shipped model, which is what pip install prodpilot gives you.

Usage

Audit and fix

Use ProdPilot to audit this project and fix what it reports, one rule at a time, reporting each fix with prodpilot_fix_applied.

The agent asks ProdPilot for the exact change each failing rule needs, applies it, and reports back. ProdPilot re-runs the rule's check and answers resolved, unresolved or blocked, whatever the agent claimed. On one of the deliberately broken sample projects in this repository, the first audit scores 13 out of 100 with 6 critical failures; after the fix loop it scores 96 with none.

Deploy

Commit your changes, then:

Deploy this project with prodpilot_deploy.

The deploy creates a real Render service on the free plan and pushes to your GitHub repository, so the agent is told to confirm with you first. You get a live URL and a GitHub Actions workflow that redeploys on every push and checks the service afterwards. A small Express API that the fix loop took from 69 to 100 went live on Render this way, all nine stages passing, in 82 seconds.

Deploying again goes to the same service. If the new deploy then fails its smoke test, ProdPilot rolls the service back to the previous version and says so; --no-rollback turns that off. See docs/rollback.md.

When something is refused

ProdPilot always says which condition failed. These are real messages:

score 89 but 1 critical rule(s) still fail: SEC-003
score 99 meets the threshold, but the model estimates a 5% chance of deploying, below its operating point of 37%
build failed, missing dependency: npm error The `npm ci` command can only install with an existing package-lock.json or

In CI

The ProdPilot GitHub Action audits the project on every push and pull request, uploads the findings to code scanning, writes a report to the job summary, and fails the job when the project is not ready:

permissions:
  contents: read
  security-events: write

jobs:
  prodpilot:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          fetch-depth: 0
      - uses: prodpilotai/ProdPilot@v1
        with:
          fail-on: p0
          min-score: "70"

Outside GitHub, prodpilot audit --ci exits 0 when the project passes, 1 when it does not and 2 for a tool or usage error. See docs/github-action.md for every input, flag and exit code.

Tools and commands

The five tools your IDE's agent sees:

Tool What it does
prodpilot_ping Confirms the server is running
prodpilot_detect_stack Identifies the project's stack and returns what a production-ready version must contain
prodpilot_fix_instruction Returns the exact change, or the limits for the change, that fixes one failing rule
prodpilot_fix_applied Takes the agent's report of a fix and answers from the rule's own check
prodpilot_deploy Runs the nine deploy stages; creates a real Render service and pushes to GitHub

The commands you run:

Command What it does
prodpilot setup Stores the GitHub token and Render API key in ~/.prodpilot/config.toml, readable only by you
prodpilot doctor [--project PATH] Checks the credentials, git, Node.js and Docker; with --project, that the project's state file is kept out of git
prodpilot connect vscode|cursor|devin [--project PATH] Adds ProdPilot to that IDE's configuration; --project is for Devin, which is set up per project
prodpilot serve Starts the MCP server over stdio; your IDE runs this for you
prodpilot audit [PROJECT] [--ci] [--min-score N] [--fail-on p0|p1|none] [--baseline REF] Audits read-only and exits 0, 1 or 2 for CI
prodpilot report --format sarif|md|html --out PATH [PROJECT] Writes a SARIF, Markdown or HTML report of the audit
prodpilot fix --dry-run [PROJECT] [--rule ID] Shows the fix loop's changes as diffs, in loop order, and writes nothing
prodpilot deploy [PROJECT] [--no-rollback] Runs the nine deploy stages, as prodpilot_deploy does

How it works

flowchart LR
    A[Your project] --> B[Audit: 50 rules, score 0 to 100]
    B --> C[Fix loop: your agent applies, ProdPilot verifies]
    C --> B
    C --> D{Gate: score 90 or more, no critical failure, model estimate}
    D -- refused --> C
    D -- cleared --> E[Deploy: 9 stages]
    E --> F[Live on Render, with CI/CD]

Each rule has its own check, and a fix only counts when that check passes on the files on disk. Each rule gets three attempts, and the loop runs up to five times while the gate stays shut. The deploy stages are pre-flight checks, environment sealing, a local Docker build and run, a push of the generated files, the Render deployment, deploy monitoring, a smoke test of the live service, and CI/CD wiring. The design, the model and the data behind it are in docs/architecture.md.

Privacy and security

  • ProdPilot talks only to GitHub, Render, and, while building your project, Docker Hub and the npm registry. It sends no telemetry.
  • Your GitHub token and Render API key are stored outside every project, in a file restricted to your account.
  • Secrets go to the test container at run time, never into the image, and to GitHub encrypted with your repository's public key.

Report a vulnerability privately as described in SECURITY.md.

Limitations

  • Two stacks only: Node.js with Express, and React with Vite.
  • One deployment target: Render, on its free plan.
  • For the 6 rules where the agent writes the change, how often a live agent's change passes on the first try has not been measured yet.
  • A project whose code requires a file it does not contain can pass the audit; the Docker build during the deploy catches it and names the missing module.
  • Render's own automatic deploy stays on, so a push can start a second deploy beside the workflow's; the workflow waits for the newer one.
  • Rolling back needs Render to still hold the earlier build, which it keeps for a limited number of recent deploys.
  • Generated files pin Node 24 unless the project declares a supported LTS line, while rule BLD-005 still asks for a Node 20 pin; see docs/node-versions.md.
  • Not yet observed on real services: a deploy started by an IDE agent, and prodpilot connect inside Cursor and Devin. The generated workflow has run on GitHub Actions against a live service; see docs/releases/1.1.0-verification.md.

What's new in 1.1

  • A GitHub Action and prodpilot audit --ci for checking readiness in CI, with a baseline comparison for pull requests.
  • prodpilot report writes SARIF for GitHub code scanning, Markdown and HTML.
  • prodpilot fix --dry-run previews every change as a diff before your agent makes it.
  • A deploy that fails its smoke test is rolled back to the previous version.
  • Generated Dockerfiles and workflows follow the project's declared Node LTS line, Node 24 by default, and end-of-life Node versions are flagged.
  • The ruleset, scoring, model and gate are unchanged from 1.0.0.

The full list is in CHANGELOG.md.

Documentation

Contributing

git clone https://github.com/prodpilotai/ProdPilot
cd ProdPilot
python -m venv .venv
.venv/bin/pip install -e . --group dev     # on Windows: .venv\Scripts\pip; needs pip 25.1 or later
.venv/bin/python -m pytest

The tests reach no live service: Render and GitHub are scripted. Tests that build real Docker images are skipped when no Docker daemon is running. Please open an issue before a large change, and run the suite before sending a pull request.

Questions and bug reports go to GitHub issues.

License

MIT, see LICENSE. Bundled third-party code is listed in THIRD_PARTY_NOTICES.md.

Credits

Built by Muhammad Sudais Khalid, Muhammad Farooq Khan and Muhammad Talha Khan as the Final Year Project BSAI-FYP-2026 of the Department of Artificial Intelligence, Shifa Tameer-e-Millat University, at the Artificial Intelligence Technology Centre, National Centre for Physics, Islamabad. Supervised by Mr. Rehan Naveed Abbasi, Muhammad Tahir with industrial supervision by Dr. Rana Fayyaz Ahmad and Muhammad Junaid Asif.

Metadata

Release files for prodpilot 1.1.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for prodpilot 1.1.0
File Size Uploaded
prodpilot-1.1.0.tar.gz 854.7 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for prodpilot 1.1.0
File Interpreter ABI Platform
prodpilot-1.1.0-py3-none-any.whl Python 3 none any Details

Total release size: 1.4 MB

Release files / prodpilot-1.1.0.tar.gz

Download URL prodpilot-1.1.0.tar.gz
Size 854.7 kB
Tags Source
SHA-256 checksum
How to use checksums
137917d895a88303d3b4e15645787a40538221a58536130e13cfac9e6d988c85
BLAKE2b-256 checksum
How to use checksums
4734b5a2a8f770553adf6e9adfc52e96c9c914c976dbd8c1ae9cebde5b224fa8
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 10, 2026.

Transparency log

Release files / prodpilot-1.1.0-py3-none-any.whl

Download URL prodpilot-1.1.0-py3-none-any.whl
Size 512.2 kB
Tags Python 3
SHA-256 checksum
How to use checksums
a72a25d2dc836aeb3945051011dcc7d49791fcf456cff2fc46c49ef6d4c5e95f
BLAKE2b-256 checksum
How to use checksums
8487d064a19c9e494f9560940655b9aa5acf6a5830199c89dcc2da8a472c3d27
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 10, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

1.1.0 This release

2 release files

1.0.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page