The checklist your agent reads before you ship.
AI can write an entire application in an afternoon — including the mistakes that used to take years of production incidents to learn. These checklists make sure what should be true before your code goes live actually is. One list per stack, published as plain files at fixed URLs. It reports. It never changes your project.
Or just say it: check this project against https://deploy-list.com/llms.txt
Why this exists
Software is being shipped faster than it has ever been shipped — by more people who have never shipped before.
Coding agents write whole applications in hours. Hobbyists push weekend projects to the open internet. Startups take internal tools to production with two people and no senior review. Companies hand their repos to AI and let it run.
Speed like that skips the scar tissue. The lessons that used to cost a decade of production incidents — .env files with real database credentials, debug mode left on, default secrets, internal dashboards with no authentication — are now being learned in public, on public GitHub, reachable from anywhere on Earth.
The old answer was get a senior engineer to review it. But AI multiplied the volume of code being shipped, not the number of senior engineers. The bottleneck stopped being writing code. It is now judgment.
deploylist is what should be true before software goes to production, written for the agents that write so much of it now. Give your agent one link, it reads the checks for your stack, runs the read-only verification, and hands you a report with a severity on every finding. It never applies a fix, and it never touches your project. Its only job is to make sure you know — before the internet does — what you are about to ship.
How it works
- 1. It reads the index One link. Your agent finds the catalog and works out which stack this project is built on.
- 2. It runs the checks Read-only verification steps, checked against an allowlist before they are ever published.
- 3. It hands you a report Findings, with a severity on each. What to fix, and whether to fix it, is yours to decide.
What it checks
Secrets that should not be in git. Debug flags left on. Caching, build and toolchain settings. Meta tags, error pages, logging, accessibility. Not only security, and not only the basics.
Every check carries a category and a severity, so you can take the whole list or only the ship-blockers.
Limits, on purpose
-
It never changes your project
There is no apply mode and there will not be one. The agent's job ends at a report handed to you.
-
Not even unattended
Every published file tells the agent that running on autopilot is not the approval it is missing. If something needs changing, it says so and stops.
-
It does not run your toolchain
Where only your framework's own CLI can answer a question, deploylist suggests the command and leaves the decision to you.
-
It does not see your code
These are static files. Your agent fetches them. Nothing about your project is sent anywhere.
Covered today
Every stack inherits the universal layer — the handful of things that are true of any software project. Checks that follow from what a project is rather than what it is written in live in their own layer: anything served over HTTP. A command-line tool has no favicon and should not be told it needs one.
Each list is complete on its own, so a framework list already contains its language and universal checks. The live catalog, with the current count for every stack, is index.json.
Wanted, not yet written
- Rust
- Java
- Zig
- Flutter
Nobody knows every stack. If you know one of these well — or one that is not listed — the repository takes contributions.
Before you act on a report
Verify anything before you change it. A check can be wrong, out of date, or wrong for your project specifically. You know your codebase, your deadline and your risk. deploylist does not.
These lists are provided as-is, with no warranty. deploylist and its authors are not responsible for anything that breaks in your project, whether you acted on a finding or missed one.