depbot

Production proof for apps built with AI.

Check, fix, deploy, and keep proving production readiness without uploading your source or findings.

Download depbotSee how proof works

Choose your platform on the download list; detection was not certain.

Step 1 Critical findingRow-level security is off on bookings; an anonymous request read 3 rows.
Step 2 Applied locallyYou reviewed the exact migration and depbot changed only your local files.
Step 3 Proven on productionA read 3 expected rows; B and anonymous received none.

depbot runs on your machine and proves results against your server. Your source, findings, and evidence never leave it. What stays local

What stays local, what the cloud holds

On your machine and your server

  • Your source, the findings, the patches you review, and the evidence of every check.
  • Deployment credentials, in your operating-system keyring.
  • Job history and rollback targets, in a local ledger.

In the depbot cloud

  • Your account, workspaces, members and approved devices.
  • Plan, allowance and the permits that count a scan against it.
  • Opaque project identity for ownership and transfer. No paths, no code, no findings.

How proof works

Every step reports what it observed. Unknown is a word, never a pass.

  1. Check. depbot runs production-readiness detectors against your code and your live server and returns a verdict: critical findings first, then warnings, then unknown, then passing.
  2. Fix. You review the exact patch, hunk by hunk. Approved hunks are applied to your local files; blocked hunks are struck through and left out.
  3. Deploy. The release goes to your server with a rollback target recorded before anything changes. Code and config restore; database changes from the release remain.
  4. Keep proving. After deploy, depbot re-runs the probes on production: role A read 3 expected rows; roles B and anonymous received none. A regression is reported from your server, not inferred.

Platform availability

Choose your platform. Packaged installers, code signing and update channels are published by the distribution task (T20); nothing here is a placeholder binary.

PlatformStatusRequirements
macOS Pending installer publication (T20)macOS 13 or later, Apple silicon or Intel
Windows Pending installer publication (T20)Windows 10 or later, x64
Linux Pending installer publication (T20)x64 or arm64; systemd for the background service

Plans

Plans are versioned; a published version never changes for the workspaces on it. The current sellable versions are listed on the pricing page once the plan catalog is published.

Security and privacy questions

Does depbot upload my code?
No. Checks, fixes and evidence run on your machine and against your server. The cloud receives account, workspace, device and permit records only.
How does a device get access?
The desktop shows a short code; you approve that device for a workspace on this website, signed in with a single-use email link. Approval can be denied or revoked at any time.
What does the cloud learn about a check?
That a permit was issued for a workspace and project identity. Not the findings, not the paths, not the evidence.
What about offline use?
A device can hold a bounded number of offline permits; they are counted as held, neither spent nor available to another device, until they are used or expire.