What makes the gate BLOCKED versus READY_WITH_WARNINGS?

Blocked findings are deploy-stoppers: a malformed package.json, a missing lockfile, a Dockerfile without FROM, a pull_request_target workflow that checks out untrusted PR code, or a hardcoded credential. Warnings are reproducibility and least-privilege gaps such as an unpinned base image, no USER directive, no build script or no test step in CI. Any blocked finding forces BLOCKED regardless of warnings; the verdict is derived from the findings, not entered by hand.

Does this replace Trivy, Checkov, actionlint or Hadolint?

No. The browser cannot run those scanners, so the static rules are a fast preflight. For deep coverage, run the full scanners in CI and paste their output into the Scanner results field — Trivy, Checkov, Hadolint or SARIF JSON, or actionlint text. The gate aggregates those real findings alongside the static checks; CRITICAL/HIGH vulnerabilities or detected secrets force BLOCKED, while SARIF levels and actionlint findings are advisory warnings because their severity semantics vary by tool.

Is my source code uploaded anywhere?

No. All analysis runs locally in your browser; nothing is sent to a server. The exported JSON and Markdown reports are generated on your machine, and you decide where to store them.

Prepare Deployment — Guide

Pre-deployment readiness gate for your project. Paste package.json, lockfile, Dockerfile and CI workflow, or import Trivy/Checkov/Hadolint/SARIF JSON or actionlint text; get a READY / READY_WITH_WARNINGS / BLOCKED / NOT_ASSESSED verdict with evidence-backed findings (reproducible builds, pinned images, non-root containers, CI injection risks, hardcoded secrets, real scanner results) and an exportable release report. Inspired by Vercel/Netlify preflight checks; runs fully in your browser.

What it is and when to use it

Deploy failures rarely come from the code itself — they come from the gaps around it: an unpinned base image that rebuilds differently every week, a missing lockfile that makes installs unreproducible, a CI workflow that checks out untrusted pull-request code with write permissions, a container running as root. Managed platforms like Vercel and Netlify run preflight checks before they accept a deploy, but those checks are locked inside their hosting. This tool brings the same idea to any project and any host: paste the four files that describe how your project is built and shipped, and it derives a release gate — READY, READY_WITH_WARNINGS, BLOCKED or NOT_ASSESSED — from a fixed rule set covering reproducible builds, pinned and non-root containers, CI injection risks and hardcoded credentials. Every finding carries a stable ID, the offending evidence and a concrete fix, and the whole report exports as JSON or Markdown so it can travel with the release record. It is a pre-deployment quality workbench, not a hosting service: it tells you what to fix before you ship, wherever you ship.

Checks whether a project is ready to deploy: paste package.json, a lockfile, a Dockerfile and a CI workflow, and get a four-state release gate with evidence-backed findings.

How to use it

Paste each project file into its field (everything stays in your browser)
Click Assess deployment readiness
Read the gate verdict and the findings, then export the JSON or Markdown report for your release record

A worked example

Fill in a sample package.json

{
  "name": "demo-service",
  "version": "1.0.0",
  "engines": { "node": ">=20" },
  "scripts": { "build": "vite build", "test": "vitest run" }
}

Copy this into the tool, or open Prepare Deployment

Things that trip people up

The gate is derived from the findings, never self-reported: any blocked finding forces BLOCKED, warnings give READY_WITH_WARNINGS, a clean pass gives READY, and no input gives NOT_ASSESSED
Checks are static heuristics on the pasted text; they complement, not replace, running Trivy, Checkov, actionlint or Hadolint in CI
Paste Trivy, Checkov, Hadolint or SARIF JSON (or actionlint text) into the Scanner results field to aggregate real scanner findings into the same gate; CRITICAL/HIGH vulnerabilities and detected secrets force BLOCKED, while SARIF and actionlint findings are advisory warnings

Questions people ask

What makes the gate BLOCKED versus READY_WITH_WARNINGS?: Blocked findings are deploy-stoppers: a malformed package.json, a missing lockfile, a Dockerfile without FROM, a pull_request_target workflow that checks out untrusted PR code, or a hardcoded credential. Warnings are reproducibility and least-privilege gaps such as an unpinned base image, no USER directive, no build script or no test step in CI. Any blocked finding forces BLOCKED regardless of warnings; the verdict is derived from the findings, not entered by hand.
Does this replace Trivy, Checkov, actionlint or Hadolint?: No. The browser cannot run those scanners, so the static rules are a fast preflight. For deep coverage, run the full scanners in CI and paste their output into the Scanner results field — Trivy, Checkov, Hadolint or SARIF JSON, or actionlint text. The gate aggregates those real findings alongside the static checks; CRITICAL/HIGH vulnerabilities or detected secrets force BLOCKED, while SARIF levels and actionlint findings are advisory warnings because their severity semantics vary by tool.
Is my source code uploaded anywhere?: No. All analysis runs locally in your browser; nothing is sent to a server. The exported JSON and Markdown reports are generated on your machine, and you decide where to store them.

Next steps

Open the Prepare Deployment tool

Spotted something wrong on this page? Tell us via Contact Us