Migrate

Migrate from Render

Moving from Render to Stackap is straightforward for web services and static sites, and needs a plan for background workers, persistent disks and command-style cron jobs.

Who this is for

No team has migrated from Render to Stackap yet. This guide maps concepts and lays out the steps, and it is not a record of a tested run.

Render describes an app as a set of services, so the first job is to list them and sort each into one of three piles: moves directly, moves with a change, and does not move.

Take inventory first

• Every service and its type: web service, static site, background worker, cron job or Postgres.
• The environment variables on each service, and any shared environment group.
• Any persistent disk, and what the app writes to it.
• The render.yaml file if there is one, since it records the whole setup.
• The commands each cron job runs.

What does not move automatically

Background workers

A worker with no HTTP port cannot pass the health check. It can become a small web app with a health route, or stay where it is.

Persistent disks

App containers have no persistent disk. Move what the app writes to the project database or to object storage first.

Command-style cron jobs

Stackap cron calls a path on your app. The job's work has to become an endpoint, protected by a secret.

The database copy

There is no self-serve database import yet. The operator loads your dump into the project's database with you, and the row counts are compared table by table afterwards.

How to know it worked

• Row counts match table by table.
• Static pages return real 404s where they did before.
• Each converted cron endpoint runs once per schedule.
• Nothing the app wrote to a disk is missing.

Going back

Leave the Render services running until Stackap has carried real traffic, then remove them.

Steps

1. Dump the database. Use the database's external connection string with pg_dump to take a full dump.
2. Create one project per web service. Each Render web service or static site becomes a Stackap project.
3. Move the variables. Copy each variable, including the shared group, with stackap env set.
4. Replace disks and workers. Rework anything that depends on a disk or a worker before cutover.
5. Load the database. The operator restores the dump into the project database with you.
6. Convert cron jobs. Expose each job's work as an endpoint and schedule a call to it, in UTC.
7. Deploy, compare and switch. Deploy, compare with the live service, then move the DNS record and disable Render's jobs.

Early-access scope

• The database load is operator-assisted.
• No persistent disks, background workers or command-style cron jobs.
• There is no render.yaml equivalent; projects are created by command or API.
• No migration from Render has been run yet.

Questions

Last updated 2026-10-03.