// Migration Guide · 2026

Migrate from Render to Runsite

Q: Do I have to rewrite my render.yaml?

No. Runsite reads your existing render.yaml as-is. It maps Render's service, database and Redis definitions onto Runsite resources and auto-wires the cross-references between them. You only touch a value if you want to change something.

Q: Is there downtime during the migration?

No. Your Render deployment keeps serving traffic the entire time. You build and verify on Runsite first, then switch DNS to cut over when you're confident. Roll back by pointing DNS back at Render.

Q: What happens to my database data?

Runsite provisions an empty managed PostgreSQL of the same major version. Move your data with a standard pg_dump from Render and pg_restore into Runsite. The connection string for the new database is auto-wired into DATABASE_URL.

Q: What about my secret environment variables?

Secrets marked sync: false in render.yaml never contain a value in the file, so they're imported as blank placeholders. You paste them once in the Runsite dashboard after import, and they're encrypted at rest and never logged.

Q: What isn't imported automatically yet?

Cron jobs, background workers, private services (pserv) and pre-built Docker images aren't auto-created today, but Runsite flags them so you can recreate them manually. Everything supported is created in a single step.

Q: Why migrate from Render to Runsite at all?

Runsite is EU-native: a Frankfurt region, an EU-registered entity for real GDPR compliance, predictable EUR pricing with hard spending caps, and a permanent free tier instead of Render's removed one.

Point us at your render.yaml. Runsite reads your services, databases, Redis and env vars, then recreates the whole stack in Frankfurt. No rewrites, no lock-in, no weekend lost to YAML.

{ }

render.yaml

on Render

scan → create

live stack

Frankfurt · eu-central

Start the migration → See the 6 steps

~10 min: typical migration
Zero rewrites: no YAML rewrites
Keep Render running: until you cut over

EUR Predictable Pricing

Frankfurt EU Data Center

100% GDPR Compliant

∞ Free Tier — Forever

// the part nobody tells you about

We read your render.yaml. You don't rebuild it.

You already wrote the hard part. Runsite parses your existing render.yaml on the connected branch and shows you exactly what it will create, before anything is provisioned.

render.yaml scanning…

services:
  - type: web
    name: api
    runtime: node
    buildCommand: npm ci && npm run build
    startCommand: npm start
    healthCheckPath: /healthz
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: app-db
          property: connectionString
      - key: REDIS_URL
        fromService:
          type: redis
          name: cache
          property: connectionString
      - key: STRIPE_SECRET_KEY
        sync: false

  - type: redis
    name: cache

databases:
  - name: app-db
    postgresMajorVersion: "16"

detected on this branch

🌐

1 web service auto

api · node · build + start commands carried over
🐘

1 PostgreSQL database auto

app-db · Postgres 16 · provisioned in Frankfurt
⚡

1 Redis instance auto

cache · managed, no add-on pricing
🔗

2 env vars auto-wired auto

DATABASE_URL & REDIS_URL connected to their resources
🔑

1 secret left blank you set

STRIPE_SECRET_KEY (sync: false) — paste it once after import

Everything tagged auto is created in a single click. Nothing is provisioned until you confirm.

// step by step

From Render to live in the EU

Six steps. Most of them take seconds. Render keeps serving traffic until you flip your DNS.

1

Create a Runsite project
~30 sec

Sign in at runsite.app and create an empty project. No credit card, no sales call.
2

Connect your Git repo
GitHub · GitLab · Bitbucket

Authorize GitHub, GitLab or Bitbucket. Runsite scans the selected branch for a render.yaml automatically.
3

Review the detected blueprint
Full preview before provisioning

We list every web service, database, Redis instance and env var we found. Tweak build or start commands inline if you want. Nothing is created yet.
4

Click “Create all”
One click · everything at once

Runsite provisions the entire stack in Frankfurt in one go. Cross-resource env vars (DATABASE_URL, REDIS_URL) are wired up for you, and you get fresh DB and Redis credentials.
5

Drop in your secrets
Secrets never travel in YAML

Secret vars marked sync: false arrive blank by design. Paste your API keys and tokens once in the dashboard.
6

Push to go live
Live in < 2 min

git push and your app builds and deploys in the EU in under two minutes. Point your custom domain when you're ready. Render keeps running until you cut over.

// no surprises

What moves on its own — and what you touch

Honest about the boundaries. The supported stack is recreated in one click; a short list needs a human, and Runsite flags every item.

✓

Imported automatically

✓ Web services — runtime, build & start commands
✓ PostgreSQL databases, including major version
✓ Redis instances as managed databases
✓ Env vars referencing other services or DBs (auto-wired)
✓ Health check paths & auto-deploy settings

⚑

You handle once

→ Secret env vars (sync: false) — blank by design, paste once
→ Cron jobs, background workers & private services — recreate manually for now
→ Pre-built Docker images — point Runsite at your repo instead
→ Persistent disks — confirm size & mount path after import

// render problems → runsite solutions

Common Render frustrations — sound familiar?

Every Render frustration, solved.

Render problem

"Render removed their free tier"

Render eliminated free web services. Hobby projects and prototypes now require a paid plan.

Runsite solution

Permanent free tier, no credit card

Run side projects and prototypes forever. Free means free — not a trial with an expiry date.

Render problem

"Only one EU region — Frankfurt"

Render offers a single EU data center. Limited redundancy and no choice for GDPR-sensitive workloads.

Runsite solution

EU-only Frankfurt region

Deploy to Frankfurt (eu-central) with EU data residency. Full EU coverage, lower latency for European users.

Render problem

"Render is a US company"

Your data is subject to US jurisdiction. CLOUD Act means US authorities can request access to EU user data.

Runsite solution

EU entity, full GDPR compliance

Runsite is registered in the EU. Your data stays in Europe, governed by European law. No transatlantic data transfers.

// comparison

Runsite vs Render

Side-by-side. No marketing fluff — just facts.

Feature	Runsite	Render
EU Data Centers	✓ Frankfurt (eu-central)	✓ Frankfurt only
GDPR Compliance	✓ Full compliance, EU entity	✗ US company, data transfers
Free Tier	✓ Permanent, no expiry	✗ Removed free tier
Web Starter (0.5 vCPU, 512MB)	€5/mo	$7.00/mo
Managed PostgreSQL	€5/mo	$10.00/mo
Object Storage	✓ €0.025/GB	✗ Not available
Deploy from Git	✓	✓
CLI Tool	✓ Rust-based	✗

// migration questions

Migrating from Render, answered

Do I have to rewrite my render.yaml?

No. Runsite reads your existing render.yaml as-is. It maps Render's service, database and Redis definitions onto Runsite resources and auto-wires the cross-references between them. You only touch a value if you want to change something.

Is there downtime during the migration?

No. Your Render deployment keeps serving traffic the entire time. You build and verify on Runsite first, then switch DNS to cut over when you're confident. Roll back by pointing DNS back at Render.

What happens to my database data?

Runsite provisions an empty managed PostgreSQL of the same major version. Move your data with a standard pg_dump from Render and pg_restore into Runsite. The connection string for the new database is auto-wired into DATABASE_URL.

What about my secret environment variables?

Secrets marked sync: false in render.yaml never contain a value in the file, so they're imported as blank placeholders. You paste them once in the Runsite dashboard after import, and they're encrypted at rest and never logged.

What isn't imported automatically yet?

Cron jobs, background workers, private services (pserv) and pre-built Docker images aren't auto-created today, but Runsite flags them so you can recreate them manually. Everything supported is created in a single step.

Why migrate from Render to Runsite at all?

Runsite is EU-native: a Frankfurt region, an EU-registered entity for real GDPR compliance, predictable EUR pricing with hard spending caps, and a permanent free tier instead of Render's removed one.

Leave Render behind

Bring your render.yaml. We'll handle the rest — in Frankfurt.

Start your migration →

✓ No rewrites ✓ Zero downtime ✓ Deploy in 2 min ✓ EU servers

Migrate from Render to Runsite

We read your render.yaml. You don't rebuild it.

From Render to live in the EU

Create a Runsite project

Connect your Git repo

Review the detected blueprint

Click “Create all”

Drop in your secrets

Push to go live

What moves on its own — and what you touch

Imported automatically

You handle once

Common Render frustrations — sound familiar?

"Render removed their free tier"

Permanent free tier, no credit card

"Only one EU region — Frankfurt"

EU-only Frankfurt region

"Render is a US company"

EU entity, full GDPR compliance

Runsite vs Render

Migrating from Render, answered

Do I have to rewrite my render.yaml?

Is there downtime during the migration?

What happens to my database data?

What about my secret environment variables?

What isn't imported automatically yet?

Why migrate from Render to Runsite at all?

Leave Render behind