Skip to content
dply/edge

Guides

Migrate from Vercel or Netlify

Move a site from Vercel, Netlify or Cloudflare Pages to dply with the import wizard, then move redirects, environment variables and custom domains without downtime.

dply's import wizard reads a project's build settings and environment variables from Vercel, Netlify or Cloudflare Pages and hands them to the create page. You deploy once on a dply address, check the site, then move your domain. Nothing changes on the old host until you switch DNS.

What carries over

From the old host On dply
Repository and production branch Pre-filled on the create page
Build command and output directory Pre-filled; editable later under Build
Framework Sets the delivery mode (see below)
Environment variables Saved as production variables on the new app
_redirects rules Paste them under Routing (not read from the build output)
Custom domains Listed in the wizard with a DNS runbook; you add them yourself
Serverless and edge functions Not converted. See Functions and server code

Import the project

  1. On the dashboard, choose Import a site.
  2. Pick the provider and paste an access token:
    • Vercel: a personal access token (Account → Tokens). Team accounts also need the Team id.
    • Netlify: a personal access token (User settings → Applications → Personal access tokens).
    • Pages: an API token with Pages:Read plus the Account id.
  3. Choose Verify + list projects, then pick the project.
  4. Review Preview import: repository, branch, framework, Runtime mode, Build command, Output dir and the environment variable keys.
  5. Choose Continue to Create →, then Deploy.

The token stays in memory for the session only; dply does not store it. Nothing is created until you choose Deploy.

Note

Environment variables whose values the provider will not return, such as Vercel's sensitive variables or secrets Cloudflare Pages redacts, are skipped. Add them under Environment before the first deploy that needs them.

Check the delivery mode

The wizard picks the mode from the framework:

  • Static site generators and plain builds become Static.
  • On Vercel, Next.js, Remix, SvelteKit and Nuxt projects are marked for Worker SSR.

Worker SSR on dply supports Next.js (through OpenNext), Astro, SvelteKit (with @sveltejs/adapter-cloudflare) and Remix (with @remix-run/cloudflare). A Nuxt project marked for SSR will not build; deploy it as a static site with nuxt generate instead. See Deploy a Next.js app for the Next.js options.

Move redirects and headers

  • Netlify _redirects: open Routing, choose Import in bulk, paste the file's lines under Redirects to import, and choose Import. Each line is /from /to 301. A _redirects file left in your build output is not read.

  • Cloudflare Bulk Redirects CSV pastes into the same box.

  • vercel.json and netlify.toml redirects, rewrites and headers are read for you when the repo has no dply.yaml: the app's first deploy saves them under Routing (the build log lists what it imported). dply matches exact paths and a trailing *, so /(.*) and /:path* become /* with :splat in the target; a rule with named parameters (/blog/:slug) or has / conditions is skipped and named in the build log. After that first deploy the rules are yours to edit; the file is not read again.

  • To keep them in the repo instead, write them in dply.yaml:

    yaml
    redirects:
      - from: /docs/*
        to: /guide/:splat
        status: 301
    
    rewrites:
      - from: /api/*
        to: https://api.example.com/:splat
    
    headers:
      - for: /assets/*
        values:
          Cache-Control: "public, max-age=31536000, immutable"
    

See Routing, redirects & headers and Configuration files.

Render and Railway

A repo with render.yaml, railway.json or railway.toml (and no dply.yaml) gets its build and start commands from it on the create page, ahead of what dply would guess. From render.yaml dply takes the web service (its routes and headers too; set Repo root to a rootDir yourself) and lists its envVars names to set under Environment; other services, databases and Railway cron schedules are listed as notes to set up as their own apps, resources or crons.

Functions and server code

dply does not convert Vercel or Netlify Functions. Your options:

  • Next.js API routes and middleware run in Worker SSR mode.
  • Middleware for static sites: see Edge middleware.
  • A separate API server (Express, Fastify, Nest, Koa, Laravel, Rails) runs as its own container app. See Container apps.
  • An API you keep elsewhere: proxy it with a rewrites rule, or use Hybrid mode with its URL as the origin.

Netlify Forms map to dply Forms.

Move the domain

Deploy first and check the site on its dply address. Then follow the runbook the wizard shows:

  1. Add each domain under Routing, Domains. dply shows the CNAME target for it.
  2. Lower the TTL on the existing DNS record to 60 seconds and wait one full TTL.
  3. Change the record that points at the old host (for example cname.vercel-dns.com or apex-loadbalancer.netlify.com) to the dply CNAME target. Apex domains need an ALIAS, ANAME or flattened CNAME at most DNS providers.
  4. Choose Verify DNS and wait for the domain to show ready with TLS active.
  5. Remove the domain from the old host.

See Domains and Domain verification.

Next steps

View as Markdown llms.txt

dply/edge