Why we built MCP-first hosting
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.
The first version of this problem was mundane: code in one place, deploys in another, logs in a third.
When a build failed, the loop looked like this: open the hosting dashboard, copy a log chunk, paste it into Claude Code, apply a fix, redeploy, repeat. The assistant never saw the platform state directly. It saw scraps we carried back to it.
What MCP-first means here
MCP, the Model Context Protocol, lets an assistant call external tools. For hosting, that means deploys, logs, env vars, domains, rollbacks, and account state can be exposed as structured tool calls instead of dashboard screens.
Plenty of hosts now have MCP servers. That is good, but it makes "has MCP" a weak signal. The useful questions are:
- Can the assistant publish without leaving the coding loop?
- Can it inspect the actual failure?
- Can it recover without scraping prose?
- Does the tool surface cover operations, or only deployment lookup?
For Percher, MCP is not an add-on to a dashboard. It is the main interface. The dashboard exists, but the platform is designed so an assistant can run the day-to-day loop: publish, wait, inspect, set env vars, read logs, roll back, connect GitHub, add domains, run doctor, and handle backups. That surface is 42 tools today.
The important part is not the tool count. It is that each tool returns a structured result, including recovery.nextAction when the operation needs a follow-up.
The loop we wanted
A deploy fails. The assistant calls percher_doctor. Doctor reads the build log or runtime signal, classifies the failure, and returns the next step. Missing env var? Return the exact keys. Bad config? Return the config problem. Health check timeout? Point at the web port or health path. Crash loop? Pull the runtime log tail.
The user should not need to translate a platform error into a prompt. The platform already knows enough to say what should happen next.
This changes the product shape in a few concrete ways.
Fewer platform chores
With a dashboard-first host, the user has to know where everything lives: env vars, rollback, logs, cache controls, custom domains. With an MCP-first host, the user can say "set the Stripe key", "roll back the last deploy", or "redeploy without cache" and let the assistant choose the tool call.
That does not remove the need for a dashboard. It removes the dashboard from the hot path.
Smaller platform model
We also kept the infrastructure deliberately small. Percher runs in one region, behind Caddy, with one route table and one place to look for logs. Multi-region routing, edge functions, and serverless fan-out are useful, but they make the recovery model harder. For this product, a small operational model is a feature.
The assistant can reason about one app, one container, one deploy, one health check, one rollback chain.
Typed failures instead of prose
Every API error carries a code such as REQUIRED_ENV_MISSING, DEPLOY_RATE_LIMITED, DAILY_QUOTA_EXCEEDED, or BUILD_FAILED. Those codes map to a small set of recovery actions: set_env_vars, wait_deploy, run_doctor, retry, fix_config, fix_problems, ask_user, and a few others.
That means the assistant does not need to parse "please set OPENAI_API_KEY and try again" out of a sentence. It gets:
``json { "nextAction": "set_env_vars", "args": { "keys": ["OPENAI_API_KEY"] } } ``
That is the core design choice. Error messages are for humans. Recovery payloads are for tools.
What we are not trying to be
Percher does not have multi-region deploys, edge functions, built-in cron jobs, serverless scale-to-zero, SOC 2, or an uptime SLA. Those are valid requirements. If you are building paid SaaS or a workload with contractual uptime needs, use a platform built for that.
Percher is for personal apps: tools, side projects, internal utilities, and small things you build for yourself or people close to you. The trade is simple infrastructure, flat pricing, and an operations loop your assistant can actually drive.
That is the reason for MCP-first hosting. Not because MCP is fashionable, but because it lets the platform return the next move instead of making the user carry screenshots between tabs.