How to Migrate Strapi to Launchpad
Move an existing Strapi project to Launchpad from a self-hosted VPS, AWS, or Strapi Cloud, including environment variable and DNS cutover steps.
Moving an existing Strapi project onto Launchpad looks very different depending on where it's coming from. Because Launchpad is BYODB (Bring Your Own Database -- see Environment Variables & Your Database), migrating your database usually isn't a separate step at all. The honest exception is Strapi Cloud, covered below.
From a self-hosted setup (DigitalOcean, AWS EC2/ECS, a VPS)
If your Strapi instance already talks to an external Postgres you control (a DigitalOcean Managed Database, AWS RDS, or anything similar), this is the easy case -- there's no data export/import at all, because you're not moving the database, only where the application code runs.
Push your repo to GitHub, if it isn't already. Launchpad deploys from a GitHub repo with a working
Dockerfile.Import the repo into Launchpad and copy your environment variables over. This is the step that actually needs care:
APP_KEYS,API_TOKEN_SALT,ADMIN_JWT_SECRET, andJWT_SECRETmust be copied exactly as they are today. If these change, every existing admin session and API token breaks the moment you cut over.Point
DATABASE_URLat your existing database -- unchanged. Launchpad never takes ownership of it.If you use S3, Cloudinary, or another external provider for media, those env vars carry over the same way -- there's nothing to migrate on the media side either, since Launchpad never stores your media locally.
Deploy and verify on Launchpad's temporary
*.hosting.yaeris.comURL first, against your real data, before touching DNS.Cut your domain over once you've confirmed it works. See the cutover note below.
From Strapi Cloud
This is the one case with real friction, worth being upfront about rather than promising a copy-paste move. Strapi Cloud provisions and manages its own Postgres for you -- there's no DATABASE_URL you can just copy, because you don't get direct external access to that database.
The real path is Strapi's own first-party data-transfer tool:
strapi transfer --to <your-new-launchpad-instance-url>Run this from your Strapi Cloud project to export its content and import it into a fresh Postgres database you provision yourself (Supabase, Neon, or anywhere else) for your new Launchpad project. This is a genuine data migration step, not a config change -- budget real time for it, and test on a staging database first if your content volume is large.
From AWS specifically
If you're running Strapi on AWS against your own RDS Postgres, follow the self-hosted path above -- it's the same situation. If you're behind a managed layer you can't directly connect to or dump from (e.g. a fully managed Aurora setup with no external access), treat it like the Strapi Cloud case: export via strapi transfer or a database dump/restore into a Postgres you control, then follow the self-hosted steps from step 3 onward.
Cutting DNS over
Once your new Launchpad deployment is verified and working, add your domain under Domains and update your DNS records. Be honest with yourself about one thing: DNS propagation isn't instant. There's a real (if usually short) window -- seconds to a few minutes depending on your DNS TTL and resolver caching -- where traffic could still hit your old host. Lowering your domain's TTL a day before the cutover minimizes this. It's not the multi-hour outage people fear from an infrastructure move, but it also isn't literally zero.