Deploys, MCP tooling, recovery contracts, performance fixes, and the trade-offs we hit while building Percher. Subscribe via RSS.
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.)
Read post →Percher runs a hosted, OAuth-protected MCP endpoint at mcp.percher.app. Add it as a custom connector in Claude.ai, Cursor, or Windsurf, approve a Percher login, and your assistant can operate your apps. No npx, no token to paste, and a security model worth explaining.
Read post →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.
Read post →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.
Read post →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.
Read post →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.
Read post →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.
Read post →Percher errors include a typed nextAction so assistants can recover from deploy failures without parsing prose or guessing the next tool call.
Read post →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.
Read post →