Every app needs
somewhere to land.

No — that's the point. You tell your AI assistant things like "publish my app", "put a password on it", or "why did it crash?", and it operates Percher for you. Every docs page starts with a ready-to-copy message for your assistant, so you never have to learn the commands underneath.

See how publishing works →

Any assistant that supports connectors: Claude.ai, Claude Code, Claude Desktop, Cursor, Windsurf, and VS Code all connect in a few clicks — chat clients through the hosted connector, local coding agents through the Percher MCP server. And if your assistant can't connect at all, the CLI works from any terminal.

Connect your assistant →

A flat monthly price, never a usage invoice. Free is €0 (three apps, each sleeps after 20 minutes idle and wakes on the next request). For Swedish consumers, paid plans are €3.75, €15, and €36.25 per month including 25% VAT (net prices €3, €12, and €29); Polar shows your exact localized tax and final total before payment. There is no per-GB bandwidth bill, so a busy weekend doesn't turn into a surprise invoice.

You ask "why did it crash?" and your assistant finds out. Percher's percher_doctor tool reads the deploy and runtime logs, works out what went wrong (a build error, a missing setting, out of memory, a crash loop) and hands back the exact next step: set the missing variable, fix the offending line, retry, or roll back to the last working version. The crash-to-fix loop stays inside the conversation.

No. bunx percher publish works straight from your terminal with nothing else installed, and the dashboard covers logs, rollbacks, domains, and settings. Connecting your assistant is the upgrade: once it can publish, read logs, and roll back as tools, you stop switching tabs.

Yes, if it needs one — ask your assistant to "add a database", or opt in with one line: [data] mode = "pocketbase". That runs SQLite, sign-in, and S3-compatible file storage in a managed sidecar, reachable through POCKETBASE_URL. Prefer your own backend? Point DATABASE_URL at any external Postgres.

Yes, on any paid plan. Ask your assistant to "point my domain at it", or run bunx percher domains add yourdomain.com to get the DNS records to set; the HTTPS certificate is issued automatically through Let's Encrypt. Free apps live at name.percher.run.

The simplest route needs no store at all: your app can become an installable PWA that opens full-screen from the home screen and works offline — for many apps that's enough. To go into the actual App Store or Google Play, you wrap your Percher app in a thin native shell (a TWA for Play, or Capacitor for both) while Percher keeps serving the web app and its backend. You bring the developer account and submit it; Percher doesn't publish to the stores for you.

Read the guide →

In the EU. Percher runs in Germany, and nightly encrypted backups are stored in a different EU datacenter. Visitor analytics are cookie-free by design, and your code and data can be exported at any time.

Yes. Set runtime = "docker" in percher.toml and Percher builds your Dockerfile untouched. Otherwise bunx percher init detects the framework (Next.js, Vite, FastAPI, Django, and more) and writes the config for you, so most apps never need a Dockerfile at all.

For the apps most people build here, yes: every app gets a real HTTPS link, daily backups, logs, and one-click rollback. What it doesn't have is the heavy guarantees a paid product needs. It runs in one region, so a rare outage there means downtime with no automatic backup region. There's no uptime guarantee (an SLA), and it isn't audited for formal standards like SOC 2 or HIPAA. So it's a great home for personal projects, an app for your family or club, internal tools, or a small-business site, but not for a paid SaaS that customers depend on.

You're not locked in. Every deploy is git-backed and your data exports as a tarball at any time, so the same app and its database move elsewhere without a rewrite. We also publish a shutdown commitment on the "If Percher shuts down" page.