Gate Every Deploy
With Automated Checks
Run SSH commands, HTTP probes, and vulnerability scanners before or after a deployment. Catch uncommitted server edits, maintenance flags, and security issues — and abort bad deploys before they cost you build minutes.
Last updated on 18th May 2026
Deployment Checks are validations that run on the deployment worker — either before the build pipeline starts (pre-build) or after every server has received its files (post-deploy). A failing pre-build check aborts the deployment cleanly before any build resources are spent. A failing post-deploy check marks the deployment failed and fires the usual failure notifications.
Two Stages, Two Questions
Every check answers one of the two questions you ask most around a deploy.
Is it safe to deploy right now?
Runs at the very start of a deployment, before the build pipeline begins. A failure aborts the deploy cleanly — no build minutes spent, no files uploaded.
- Detect uncommitted changes operators made directly on the server
- Refuse to deploy when a maintenance flag is up
- Block deploys that fail a vulnerability scan
Did the deploy actually work?
Runs after every server has received its files, before the deployment is marked complete. A failure marks the deploy failed and fires your usual failure notifications.
- Smoke-test your homepage or healthcheck endpoint
- Run a service-specific verification command
- Catch silent failures the build pipeline missed
Three Check Types
Pick the right tool for the question you're asking.
SSH Check
Run an arbitrary shell command on one or more SSH-capable servers in the project. A non-zero exit aborts (pre-build) or fails (post-deploy) the deploy. Stdout and stderr are captured into the deploy log in a console block.
git diff --quiet || exit 1
HTTP Check
Send a GET or HEAD request to any URL and assert the response status — optionally checking the body for a specific substring. Works for any project type, including FTP, ElasticBeanstalk, Heroku, and cloud-storage protocols.
GET /maintenance.json — expect 404
Vulnerability Scan
Run Trivy, Snyk, or any SARIF-emitting CLI against your source on the build server before build commands execute. Configurable severity threshold — fail on critical only, or anywhere down to low.
Jump to scanners ↓Vulnerability Scanners
Catch CVEs before your code reaches production. Trivy and Snyk are bundled into the build image — zero setup for Trivy, your existing token for Snyk.
Trivy
Open-source, zero-config
Trivy is an open-source vulnerability scanner from Aqua Security. No account, no API key, no setup. Bundled into every build image — pick a severity threshold and go.
Pick Trivy if : you want a zero-cost starting point or your team hasn't invested in a paid scanner.
Snyk
Commercial, plugs into your dashboard
Snyk is a commercial vulnerability scanner. Drop a SNYK_TOKEN environment variable on the project or account, and findings flow into your existing Snyk dashboard alongside CI results.
Pick Snyk if : your team already has a Snyk subscription and wants the findings to flow into your existing dashboard.
Custom (SARIF)
Any CLI that emits SARIF
Run any scanner that emits SARIF — Grype, OWASP Dependency-Check, or a commercial tool not directly supported. Give us the command and the path to the SARIF file, we read it and produce the findings summary in the deploy log.
Pick Custom if : you have an established scanner pipeline you want to consolidate behind the same gate.
Severity threshold
Pick the lowest severity that should fail the deploy. Critical only is the least strict; Low or higher blocks anything the scanner produces.
What People Use Them For
The same primitives, very different gates.
Detecting drift on the server
A pre-build SSH check that runs git diff --quiet against the release directory catches operators who edited config directly on the server. Aborts the deploy before it overwrites their hotfix.
Maintenance-mode gate
A pre-build HTTP check against a /maintenance.json endpoint that returns 200 during downtime. Expected 404 → deploy aborts while maintenance is up, resumes when it ends.
Post-deploy smoke test
A post-deploy HTTP check that hits your homepage with expected 200. Cheap canary that catches the deploys where the build succeeded but the app didn't actually start.
Vulnerability gate
A pre-build Trivy or Snyk scan with severity threshold of "high or higher" — refuses to deploy code with known CVEs without breaking the build for low-priority noise.
Add your first check in a couple of minutes
Enable beta features
Deployment Checks are in beta. Toggle beta features on in your account to see them in the project sidebar.
Pick a stage and type
Pre-build to gate the deploy, post-deploy to verify it. SSH, HTTP, or Vulnerability scan.
Configure the check
Pick the server (SSH), URL and expected status (HTTP), or scanner and severity threshold (Vuln). Save.
Deploy and read the log
Every deploy now runs the check. Output streams into the deploy log alongside everything else.
Frequently Asked Questions
What's the difference between pre-build and post-deploy checks?
Pre-build checks run before the build pipeline starts. A failure aborts the deploy cleanly — no build minutes spent, no files uploaded. Post-deploy checks run after every server has received its files. A failure marks the deploy failed and fires your usual failure notifications, but does not roll back — the files stay where they are and you decide how to react.
Do vulnerability scans cost extra build minutes?
Yes, but only the build-server startup cost (typically a few seconds). Trivy and Snyk are bundled into the build image, so there is no install step. A failed scan aborts the deploy before your build commands run, so you do not waste build minutes on a build whose output would be rejected.
Which scanners are supported?
Trivy (free, open source) and Snyk (commercial, requires SNYK_TOKEN) are bundled and ready to use. The Custom option lets you run any CLI that emits SARIF — Grype, OWASP Dependency-Check, or a commercial tool not directly supported.
Does a failing post-deploy check roll back the deployment?
No. Deployment Checks alert you so you can react — they do not auto-rollback. A failing post-deploy check marks the deploy failed and fires the usual failure notifications. To revert the change itself, use one-click rollback from the deployments page.
How do I enable Deployment Checks?
Deployment Checks are currently in beta. Enable beta features on your account, and a 'Deployment Checks' entry will appear in the project sidebar.
Stop shipping broken deploys
Gate every release with checks that actually run where your code goes.
10-day free trial • No setup fees • Cancel anytime
Explore More Features
Discover all the tools that make DeployHQ the easiest way to deploy your code.
Zero Downtime Deployments
→One-Click Rollback
→Turbo Deployments
→Build Pipelines
→Docker Builds
→Deployment Checks
→Deployment Targets
→Automatic Deployment
→Deployment Templates
→Deploy Behind Firewalls
→SSH Deployment
→Deployment Zones
→Team & Permissions
→Static Sites & S3
→CLI & Agents
→Powerful Integrations
→Get started today for just $9/month
That's unlimited deployments and 3 projects.