Deciding

How to choose a PaaS and move between them

Start from what your team can't compromise on, shortlist two or three options, and test the one thing most likely to go wrong. When it is time to move, go service by service with a way back.

Updated

The five questions that narrow the field

  1. Must the apps and data run in your own cloud account? If yes, the shortlist is the own-cloud options. See the two hosting models compared.
  2. Do you need a BAA or a SOC 2 report this year? Check which plan provides it and whether its price is published.
  3. Will you run your own models on GPUs? Most vendor-hosted platforms don't offer them.
  4. What will it cost at ten times today's usage? Price your app on each shortlisted platform's published rates at today's size and at ten times it.
  5. How would you leave? Prefer standard containers, standard databases, and platforms that say what happens if you stop paying.

Checklist by team type

Shortlists come from the ranking's ratings on the criteria that matter most for each team, not from the overall score.

Solo developer or side project

Prioritise

  • Low entry price
  • Fast setup
  • A database next to the app

Shortlist

Railway, Fly.io, Render, DigitalOcean App Platform

Watch out: Free and entry tiers change often, and some sleep when idle. Check the pricing page on the day you sign up.

Early-stage startup, no DevOps hire

Prioritise

  • Push-to-deploy with previews
  • Room to grow without re-platforming
  • Cloud credits if you have them

Shortlist

Render, Railway, Porter, Northflank

Watch out: If you hold AWS, Google Cloud or Azure credits, an own-cloud platform lets them pay for compute; a vendor-hosted one can't use them.

Growth-stage team selling to larger companies

Prioritise

  • SOC 2 report
  • Data in your own cloud account
  • Private networking to your databases

Shortlist

Porter, Northflank, Qovery

Watch out: Ask each platform which permissions it needs in your account, and what keeps running if you stop paying.

Healthcare or other regulated data

Prioritise

  • A signed BAA
  • Published price for the compliant tier
  • Audit logs and access control

Shortlist

Porter, Google Cloud Run, Render, Heroku, Fly.io

Watch out: A BAA covers the platform, not your app. You still have to configure encryption, access and logging correctly.

AI team running its own models

Prioritise

  • Self-serve GPUs
  • Scale to zero for bursty inference
  • GPUs and app on one platform

Shortlist

Northflank, Porter, Google Cloud Run

Watch out: GPU quotas in your own cloud account can take time to raise. Request them before launch day.

Team already running Kubernetes

Prioritise

  • Works on your existing cluster
  • Self-service for developers
  • No re-platforming

Shortlist

Qovery, Northflank, Porter

Watch out: Check the Kubernetes versions each one supports against yours.

Frontend-heavy or Next.js team

Prioritise

  • Framework-aware builds
  • Global CDN
  • Preview per pull request

Shortlist

Vercel, Render

Watch out: Long-running workers and background jobs usually need a second platform next to a frontend cloud.

Before you commit: a one-week trial

  • Deploy your real app, not a sample, with its database and one background worker.
  • Open a pull request and check the preview environment works end to end.
  • Roll back a deploy, and restore a database backup into a new instance.
  • Read the first month's projected bill, and set a spend alert.
  • Ask support one real question and note how long the answer takes.

Migrating an app from one PaaS to another

Most moves follow the same seven steps, whatever the platforms. The data move is where the risk is; everything else can be rehearsed.

  1. Take inventory.
    • List every service (web, workers, cron jobs), every database and cache, every add-on, every environment variable, every domain and every scheduled task.
    • Note what is platform-specific: add-ons, platform cron syntax, routing rules, build settings, edge or function features.
  2. Package the app portably.
    • If the app builds from a buildpack or a platform-specific runtime, add a Dockerfile (or confirm the target supports the same buildpack) and check it builds and runs locally.
    • Read configuration from environment variables only, and make the app listen on the port it is given.
  3. Stand up the target, empty.
    • Create the services on the new platform with the same sizes and environment variables, pointing at a copy of your data rather than production.
    • For an own-cloud platform, connect the cloud account and request any quotas (including GPUs) now.
  4. Move the data.
    • For a small Postgres database, a pg_dump and pg_restore during a short maintenance window is simplest. Time a dry run first.
    • For a large one or a no-downtime move, use logical replication (or your target's migration tooling) to keep the new database in sync until cutover.
    • Move file storage and caches; caches can usually start cold.
  5. Replace platform-only pieces.
    • Swap each add-on for its equivalent (managed database, Redis, email, logging) and move cron schedules and background workers.
    • Recreate secrets on the new platform; never copy them through chat or tickets.
  6. Run both, then cut over.
    • Lower your DNS records' TTL a day ahead. Run the new deployment against production data in read-only or shadow mode if you can.
    • Cut over: put the old app in maintenance, do the final data sync, switch DNS, and watch errors and latency.
  7. Keep the way back open.
    • Keep the old platform running, stopped from writing, until you are confident; know the exact steps to switch DNS back.
    • Once stable, export what you need for records, remove the old services, and cancel the old plan.
Many platforms publish their own migration guides (for example from Heroku). They are useful for the mechanics, but they are written by the destination, so check the steps against this list.
Back to the ranked listReweigh the criteria