Decision guide

Percher or Render?

Render and Percher are architecturally close cousins: both run long-lived containers behind a managed proxy, both ship from Git, both auto-issue TLS, and both expose an MCP server today. The real differences are who they're built for and how deep the agent integration goes. Render is a polished, multi-region PaaS aimed at small-to-mid teams who want managed Postgres + Redis and per-service pricing they can scale up. Percher is a solo-builder platform with MCP as the primary deploy surface — 42 tools covering the full operational loop and a typed `recovery.nextAction` contract — opt-in PocketBase batteries (`[data] mode = "pocketbase"`), and flat per-account pricing.

Who Percher is for

Percher is built for personal apps — projects you build for yourself or your close circle. It is notpositioned as production-grade or enterprise hosting today: there is no uptime SLA, no formal compliance attestation, and a single region in Germany. If you're shipping a monetised SaaS, an app for paying customers, or anything that needs an SLA, Render or a higher-tier provider is the safer choice. Percher may grow into that space; it is not there now.

At a glance

Feature	Percher	Render
Free tier	Free plan (2 apps, sleep after 10 min idle)	Free web service tier (sleep after idle, monthly hour cap)
Paid entry price	€3/mo (Starter) — flat, per account	Per-service pricing (Starter web service ~$7/mo) — as of 2026-05
Pricing model	Flat monthly subscription per account	Per-service + bandwidth + database add-ons
Region	Single region (Falkenstein, DE)	Multi-region (US, EU, Asia, Australia)
Compute model	Long-running containers per app	Long-running containers per service
Built-in database	Opt-in managed PocketBase per app (SQLite, auth, file storage) via `[data] mode = "pocketbase"`	Managed Postgres + Redis (separate billed services)
Built-in auth	Yes (when PocketBase is enabled) — auth out of the box with PocketBase	No — bring your own
MCP server	MCP-first: 42 tools covering publish, logs, env, rollback, doctor, backups, domains and GitHub connect, plus a typed `recovery.nextAction` for chaining failures into fixes	Has an MCP server for service management (deploy lookup, log retrieval, service ops)
Framework support	Node, Bun, Python, static, any Dockerfile	Node, Python, Ruby, Go, Elixir, Rust, any Dockerfile
Background workers / cron	Not first-class (use a single long-running app)	First-class service types: workers, cron jobs
Custom domains	Yes (paid plans)	Yes
Automatic SSL	Yes — Let's Encrypt via Caddy	Yes — Let's Encrypt
Compliance	EU data residency; no formal certifications yet	SOC 2 Type 2, HIPAA available on paid plans
Rollback	Instant per-deploy rollback	Instant per-deploy rollback

When Percher is the better choice

You want the assistant doing more than `publish` — full operational tools (logs, env, rollback, doctor, backups, domain add) and a typed `recovery.nextAction` that chains a failed deploy into the next fix without leaving the chat.
You want flat per-account pricing so two or three small apps don't multiply your bill — Render charges per service.
You want an opt-in managed PocketBase per app for SQLite + auth + file storage (one config line: `[data] mode = "pocketbase"`) rather than standing up a separate Postgres service and bolting on auth.
Your project needs EU data residency. Percher runs in Germany only.
You're a solo builder where the per-service cost and per-database add-on cost on Render add up faster than the value they bring.

When Percher is the wrong choice (and Render fits better)

You need managed Postgres or Redis as a first-class product, not an external service connected over `DATABASE_URL`. Render's databases are tightly integrated with the platform.
You need multi-region deployment — US, Europe, Asia, Australia. Percher is single-region in Germany.
You need explicit background workers or cron jobs as first-class service types. Render models those distinctly; Percher doesn't.
You need SOC 2 Type 2, HIPAA, or other formal compliance certifications. Percher is a young single-team project without those yet.
You're scaling beyond a handful of apps and want fine-grained per-service control — instance types, autoscaling per service, private services.

Migrating from Render

If your Render service is a Docker container, the migration is mostly mechanical: ship the same Dockerfile, set the same env vars, and you're live. `bunx percher init` generates a `percher.toml` from your project that points at the existing Dockerfile (set `runtime = "docker"`), and `bunx percher publish` builds and deploys it. Custom domains move with a one-time DNS update.

What doesn't carry over directly: Render's managed Postgres and Redis are separate services on Render but have no direct equivalent on Percher — the Percher pattern is the opt-in PocketBase sidecar (`[data] mode = "pocketbase"`) for SQLite + auth + file storage, or `DATABASE_URL` pointed at any external Postgres provider (Neon, Supabase, your own). Background workers and cron jobs on Render need to be folded into your main app for now (a long-running queue consumer thread, or an external cron-as-a-service hitting a webhook); Percher doesn't expose those as distinct service types yet.

# In your project root (with your existing Dockerfile):
bunx percher init            # generates percher.toml (runtime=docker)
bunx percher env set DATABASE_URL=...  # for each env var on Render
bunx percher publish         # build + deploy
bunx percher domains add yourdomain.com

FAQ

Can I run my Render Docker service on Percher?

Yes. If your Render service uses a `Dockerfile` (the common case), Percher builds and runs the exact same image with `runtime = "docker"` in `percher.toml`. No code changes are needed — only your `DATABASE_URL` and other env vars have to be re-set with `bunx percher env set`. The build pipeline picks up your Dockerfile automatically when `bunx percher init` detects it in the project root.

Is Percher cheaper than Render?

For a single small app, the two are roughly comparable at the entry level. Where Percher wins on cost is multi-app usage: Render charges per service (each web service, each Postgres, each Redis is billed separately), while Percher's flat-rate plans cover everything on one account. For one heavy app with a beefy Postgres, Render can be cheaper because you only pay for what you use; for three or four small apps, Percher's flat plans are typically less.

Does Percher support multi-region like Render?

No. Percher runs in a single region (Falkenstein, Germany). Render offers US, EU, Asia, and Australia regions. If your audience needs sub-100 ms latency outside Europe, Render (or fronting Percher with a global CDN) is the right call. For European audiences, Percher's single region is fine.

What replaces Render's managed Postgres?

Percher doesn't ship a managed Postgres of its own today. Every app can opt into a managed PocketBase sidecar (SQLite + auth + S3-compatible file storage) by setting `[data] mode = "pocketbase"` — the sidecar is provisioned automatically and reachable via the `POCKETBASE_URL` env var. For raw Postgres specifically, point `DATABASE_URL` at any external provider (Neon, Supabase, your own server) and Percher's outbound proxy handles the connection transparently.

How do I run a background worker on Percher?

Render models workers as a distinct service type; Percher doesn't, yet. The current pattern is to fold the worker into your main app — start a background task (queue consumer, scheduler, etc.) at app boot, in the same process or as a child process inside the same container. For periodic jobs, external cron-as-a-service (GitHub Actions on a schedule, EasyCron, etc.) hitting a webhook endpoint is the common workaround.

Try Percher in under a minute

Free plan, no credit card. Bring any Node, Bun, Python, or Docker app.

Bringing an existing app? See recommended setup or the migration walkthrough above.