When the AI says your deploy failed
What missing keys, build failures, health checks and deploy limits mean, and what you or your assistant can do next.
Deploys, MCP tooling, recovery contracts, performance fixes, and the trade-offs we hit while building Percher.
What missing keys, build failures, health checks and deploy limits mean, and what you or your assistant can do next.
A one-command starter with a provisioned database, sign-in and realtime already wired, so your assistant builds on a working app instead of an empty folder. (Managed AI was part of this at the time and is currently switched off — see the note at the top.)
Connect your assistant, choose what it can access, and start working on your Percher apps without installing a local package.
Hosting for vibe coders. Deploy as a tool call from Claude Code, Cursor, or Windsurf, with everything an app needs already wired up. Honest about what it isn't.
Percher's new Topology view is a live map of everything that makes your app run, including the parts Percher manages for you. It is also an MCP tool, so your assistant reads the same map you do.
Percher stopped using Nixpacks as the default for Node and Bun and wrote its own multi-stage Dockerfile generator. Cold builds went from a minute or two down to about twenty seconds. Here is the design and the trade-off.
What "publish my app" actually does when you say it to an assistant with hosting tools. Walkthrough of the loop, the failure case, and the parts of the old workflow that disappeared.
Deploys, logs, env vars, and rollback should be callable from the same place the code is being changed. That is the practical reason Percher is built around MCP.
Percher errors include a typed nextAction so assistants can recover from deploy failures without parsing prose or guessing the next tool call.
A Percher app had fast server responses but a blank page for seven seconds. The culprit was a blocked Google Fonts request, not the app server.