Skip to content
dply/edge
deploy →

Guides

Migrate from Forge or Laravel Cloud

Move a Laravel app from a Forge server or Laravel Cloud to dply: map each piece, move the database, and switch the domain.

A Laravel app on Forge runs on a server you manage; on Laravel Cloud it runs on managed compute. On dply it runs as a container on Cloudflare's edge that sleeps when idle, with managed databases, Valkey, queues and WebSockets attached as resources. This guide maps what you have today to dply, then walks through the move.

How the pieces map

Forge Laravel Cloud dply
Server + site App cluster A container app (Deploy a Laravel app)
Deploy script Build and deploy commands Generated image; your own Dockerfile if needed
php artisan migrate in the deploy script Deploy command Run migrations when a container starts, or Migrate in the database settings
Daemons running queue:work / Horizon Queue clusters Queue workers (Queue workers)
Scheduler cron Scheduler toggle Run the Laravel scheduler every minute
MySQL / Postgres on the server Cloud databases Database resource: Postgres, MySQL or MongoDB
Redis on the server Key-value store (Valkey) dply Valkey resource
Reverb daemon Reverb / WebSockets Realtime resource (Laravel broadcasting with Realtime)
S3 bucket Object storage Object storage resource
.env file Environment variables Environment tab
Server size Compute size, hibernation Instance size, Sleep after idle, Min instances

Differences to plan for

  • No persistent disk. Containers start fresh. Files written to storage/app are lost on restart; move uploads to object storage. Sessions default to the cookie driver.
  • Shell access is through the dply agent. Run one-off commands on the app's Console tab, or open a shell with dply-edge ssh. Containers are replaced on every deploy, so don't change files by hand.
  • Release commands replace the deploy script. Put them in dply.yaml under build.release, in a Procfile release: line, or on Build → Hooks. They run in the new version before it takes traffic, and a failure stops the deploy. See Configuration files.
  • Sleep. An idle app sleeps after 5 minutes by default and the next request waits for a cold start. Set Min instances to 1 to keep one warm.
  • Horizon is detected but not run as a process. Use Queue workers, which run queue:work, against the same Redis.
  • Octane is supported: with laravel/octane installed the image runs Swoole, or RoadRunner when a spiral/roadrunner package is present.

1. Deploy the app

  1. Choose New app, connect your source control, select the repository and branch.
  2. Check that the Deploy summary shows Container, then choose Deploy.

The first deploy boots on SQLite so you can see the app answer before attaching real data.

2. Copy your environment

Open Environment and add the variables from your Forge .env or Cloud environment. Leave out values dply sets from resources (DB_*, DATABASE_URL, REDIS_*, REVERB_*, PUSHER_*): they come from the resources you attach next. Keep your own APP_KEY so encrypted data and signed cookies stay valid.

See Environment variables.

3. Attach resources

On the app's Overview, choose Add resource and add, as needed:

  • Database: Postgres, MySQL or MongoDB.
  • dply Valkey: cache, sessions and queues.
  • Queue workers: set the connection and queue names you used on Forge or Cloud.
  • Realtime: if the app broadcasts.
  • Object storage: for uploads.

Then redeploy so the app receives the new variables.

4. Move the database

  1. Put the old app into maintenance mode, or stop writes, so no data changes after the export.

  2. Export it:

    bash
    pg_dump --no-owner --no-acl -Fc "$OLD_DATABASE_URL" > app.dump

    For MySQL, use mysqldump --single-transaction.

  3. Open the database from the app's Overview. Under Export and import, choose Import your own dump, then Get upload command. Run the command where the file is (the link works for an hour), then load the uploaded file. Tables in the file are replaced; others are left alone.

For small databases you can connect with the Connection URL under Connect and restore with pg_restore or mysql directly.

See Postgres, MySQL & MongoDB.

5. Test on the dply address

Open the app on its dply address and check logins, queued jobs, scheduled tasks and uploads. Application logs are on Build & deploy logs under What your app is printing.

6. Switch the domain

  1. Add the domain under Routing, Domains.
  2. Lower the TTL on the existing DNS record, then point it at the CNAME target dply shows.
  3. Choose Verify DNS and wait for TLS to be active.
  4. Update APP_URL and ASSET_URL under Environment to the domain, and redeploy.
  5. Shut down the old server or Cloud environment once traffic has moved.

See Domains.

Next steps

View as Markdown llms.txt

dply/edge