AI-powered application security and deployment readiness platform.
DeployGuard is the release gate for a registered service fleet. Teams register an application, run an inspection across health and security controls, and get a scored decision: deploy, hold for review, or block. Tony, the in-product advisor, answers from those results.
The operations dashboard is the product surface: fleet posture, health versus security, services that need a decision, and the inspection calendar. The frame below is the DeployGuard demo UI, signed in on sample data.
Interactive demo. Sign-in, inspections, and Tony stay in the browser. This copy does not call the DeployGuard API.
What it solves
Health, headers, auth, secrets, and dependency risk usually live in different tools. DeployGuard puts a registered service on one gate so an owner, a security reviewer, and a release operator see the same score and the same block reason.
What it does
Register the service and its health URL. Run an inspection. Review health and security. Score readiness. Ask the advisor whether to ship. Open the result to print a readiness report. Scheduled services stay on a daily, weekly, monthly, or yearly calendar.
An inspection walks a fixed sequence, then writes a health score, a security score, a readiness score, a written analysis, and recommendations. HTTPS is taken from the registered health URL. The other gates, dependency notes, header evidence, and method notes are produced by the inspection model and stored with the result.
Readiness
Both scores are clamped from 0 to 100. A critical finding, or a readiness score under 60, blocks the release. 60 to 79 is a warning and needs a human review. 80 or above, with no critical findings, can deploy.
Nineteen gates are implemented. Four are health. Fifteen are security. Each failed gate carries a severity and a score impact, and the report lists what to fix first.
Health and reliability
Security and compliance
File uploads fail when a registered uploader writes into a public path or skips type and size checks. Session cookies are checked for Secure, HttpOnly, and SameSite. Dependency evidence is a lockfile-style table on the report, not a live advisory feed.
Deployment advisor
From the latest inspection, the advisor answers whether the service is ready, lists the biggest risks, orders the first fixes from P0 to P2, and recommends approved, hold, or blocked.
Tony
Tony trains on the registered apps and inspections. Without an API key, answers come from that DeployGuard data. With TONY_API_KEY, training can be compiled by the configured model. The default model is gpt-4o-mini.
Voice
The app can speak a sentence through ElevenLabs when that provider is configured. The portfolio demo does not call a voice provider. Its voice button says so.
Average readiness, healthy / warning / blocked counts, health and security bars, and recent gate results.
Register name, owner, email, environment, stack, health URL, repository, description, and whether the app accepts uploads.
Daily, weekly, monthly, or yearly. The dashboard lists what is due and can run due inspections.
Open an inspection to review gates, then print or download a report with the advisor decision.
After an inspection, the owner can be emailed the score and whether the release is cleared, on hold, or blocked.
People apply for access. An admin approves or denies. Roles cover admin, developer, DevOps, platform, security, and engineering manager.
Passwords require 12 characters with upper, lower, number, and symbol. They are stored as PBKDF2-SHA-256. Sessions use an httpOnly cookie.
In-app notices for new apps, finished inspections, and held releases. Light, dark, and system appearance.
The product UI calls a Node API. Applications, inspections, users, notices, and mail logs are stored in SQL Server.
No public GitHub repository or documentation site is configured for this project.