Migrate from Laravel Vapor to fortrabbit

# Migrate from Laravel Vapor with a coding agent

Claude Code, Codex, Cursor and other coding agents can run this migration. Paste this prompt into the agent, in the project folder:

Read https://www.fortrabbit.com/agents.md and set up fortrabbit. Then move this site from Laravel Vapor to fortrabbit, following https://www.fortrabbit.com/raw/migrate/from-laravel-vapor.md

Sign-in happens in the browser, see agent setup. The agent uses the Vapor CLI to pull the environment and needs a way into the database, see step 5. The steps below are what the agent follows, and what to do by hand without one. The agent changes nothing on the old host: a person deletes the old setup once the site runs on fortrabbit.

# Vapor settings and where they go

# 1. Create the app

Create an app in the dashboard with the Laravel software template. Its default domain works with HTTPS right away, so the whole move can be tested before DNS changes. Lower the TTL of the domain's DNS records now, see migrate to fortrabbit.

# 2. Export the settings

Pull the environment with the Vapor CLI:

vapor env:pull production

It writes .env.production. Copy every value except the ones Vapor injects for the database, queue, cache and storage into the environment variables of the fortrabbit environment.

In vapor.yml, the build hooks, such as composer install --no-dev, go into the build commands, the deploy hooks, such as php artisan migrate --force, into the post-deploy commands.

# 3. Replace the AWS services

• Scheduler: add one cron job running php artisan schedule:run every minute.
• Queues: set QUEUE_CONNECTION=database and add a worker running php artisan queue:work. fortrabbit has no SQS and no Redis, see Laravel queues and scheduler.
• Cache and sessions: switch from DynamoDB to database or file.
• Assets: Vapor serves them from CloudFront with ASSET_URL. On fortrabbit they come from the app: remove ASSET_URL, or keep a CDN in front.

# 4. Deploy the code

Connect the same GitHub repository to the environment and push. The first deployment runs the build commands.

# 5. Move the database

A public RDS database can be dumped directly. A private one needs a Vapor jumpbox in the same network, then a dump over an SSH tunnel through it:

ssh -N -L 3307:<rds-host>:3306 ec2-user@<jumpbox-ip>
mysqldump -h 127.0.0.1 -P 3307 -u <user> -p <database> > dump.sql

Run the tunnel in one terminal and the dump in a second one.

Import the dump into the MySQL component as described under MySQL export and import. A PostgreSQL database needs converting to MySQL first, since fortrabbit runs MySQL only.

# 6. Move the files

Uploads on Vapor live in S3, since the Lambda filesystem is temporary. Keep the bucket and its credentials in the environment variables, or download it with an S3 client and push the files to the storage component with rsync.

# 7. Switch the DNS

Test the app on its default domain, add the custom domain to the environment and point the records at the domain provider to fortrabbit, see external domain setup. Domains whose nameservers were delegated to Vapor have their records in AWS: change them there, or move DNS to the registrar first.

Once the app runs on fortrabbit, delete the Vapor environment, then the database, the cache and the network in AWS, so the AWS bill stops.