# Migrate from Render

> Move your app and managed Postgres from Render to Ownkube. Connect your repo, re-create the database, copy env group variables, and cut over with no rewrite.

Moving from [Render](https://render.com/) to Ownkube is mostly re-pointing your repo, re-creating your database, and copying the variables from your env groups. There's no rewrite: if it deploys on Render, it deploys on Ownkube. This guide walks the cutover, including the database dump and restore.

For a side-by-side of the two platforms, see [Ownkube vs Render](/docs/compare/render).

## What moves

| On Render | On Ownkube |
|---|---|
| Web Service from a GitHub repo | A **Web** deployment from the same repo |
| Background Worker | A **Worker** deployment |
| Cron Job | A **Job** deployment with a schedule |
| Render Postgres | A managed **PostgreSQL** database |
| Env group variables | Environment variables on the deployment |
| Public URL | A public hostname with automatic TLS, plus your [custom domain](/docs/guides/custom-domain) |

## Migrate your app

1. **Connect your repo**

   Connect your GitHub or GitLab account so Ownkube can build from the same repo. See [Registries](/docs/features/registries).

2. **Create a Web deployment**

   From your [dashboard](https://app.ownkube.io/dashboard), create a **Web** deployment, point it at your repo and branch, and set the port your app listens on. Ownkube builds from source, or uses your `Dockerfile` if you have one. A Render Background Worker maps to an Ownkube **Worker** deployment the same way.

3. **Copy your environment variables**

   Bring over the variables from your Render env groups. Add them as `KEY=value` pairs and flip **Secret** on the sensitive ones. See [Environment variables](/docs/guides/environment-variables).

## Migrate your database

1. **Create a managed Postgres database**

   Add a **Database** (PostgreSQL) in the same [environment](/docs/features/environments) as your app. Ownkube generates credentials and injects `DATABASE_URL` into your app. See [Databases](/docs/features/databases).

2. **Dump from Render**

   Using your Render database's external connection string, dump the data:

   ```bash
   pg_dump "$RENDER_EXTERNAL_DATABASE_URL" --no-owner --no-privileges -Fc -f dump.pgc
   ```

3. **Restore into Ownkube**

   Turn on [public access](/docs/features/databases#public-access) for the new database (temporarily), then restore into it with TLS verification on:

   ```bash
   pg_restore --no-owner --no-privileges \
     -d "postgresql://user:pass@db-yourname.ownkube.app:5432/app?sslmode=verify-full&sslnegotiation=direct" \
     dump.pgc
   ```

   Turn public access back off when the restore finishes. For production traffic, connect from inside the network.

Do a trial run into a development environment first, verify row counts and a few queries, then repeat the dump/restore during a short maintenance window for the real cutover so you don't lose writes.

## Cut over

1. **Verify on Ownkube.** Open the generated hostname, exercise the app, and confirm it reads and writes the migrated database.
2. **Move your domain.** Point your [custom domain](/docs/guides/custom-domain) at the Ownkube deployment. TLS is provisioned and renewed automatically.
3. **Decommission Render** once traffic is served from Ownkube and you've confirmed a clean window.

## Want your own cloud later?

You can start on Ownkube Compute and, if you ever want your own data boundary or your own bill, [connect an AWS account](/docs/guides/connect-aws) and run the same app in your own VPC with no second migration. See [Clusters](/docs/features/clusters).

- [Ownkube vs Render](/docs/compare/render)
- [Deploy a Next.js app](/docs/deploy/nextjs)
- [Pricing](/docs/configuration/pricing)
- [On the blog: Render vs running in your own AWS account](/blog/render-vs-aws-own-account)

---

**Don't see a feature you need?** Email [support@ownkube.io](mailto:support@ownkube.io?subject=Feature%20request). Ownkube is shaped by the teams using it and we ship what our users ask for.