Why Migrate?

Phase 1: Document Your Forge Configuration

Server Inventory

Site Configuration

Background Services

Database Details

DNS Configuration

Phase 2: Set Up Deploynix

Create Your Account and Organization

Connect Your Cloud Provider

Connect Your Git Provider

Phase 3: Provision Servers on Deploynix

Phase 4: Create Sites and Configure

Create Sites

Configure Environment Variables

Configure Custom Nginx Rules

Set Up Queue Workers

Set Up Cron Jobs

Set Up Firewall Rules

Phase 5: Migrate Your Database

Export from Forge Server

Transfer to Deploynix Server

Import on Deploynix Server

Verify the Import

Phase 6: Deploy and Test

Initial Deployment

Test Without DNS

Verify Background Services

Phase 7: DNS Cutover

Reduce TTL (Optional but Recommended)

Update DNS Records

Provision SSL Certificates

Monitor

Phase 8: Cleanup

Keep Forge Running Temporarily

Final Database Sync (If Needed)

Verify Backups

Decommission Old Servers

Common Gotchas

Conclusion Switching server management platforms is one of those tasks that sounds risky but, with proper planning, is remarkably straightforward. If you are currently using Laravel Forge and considering a move to Deploynix, this guide will walk you through the entire migration process. We will cover how to document your existing configuration, provision equivalent infrastructure on Deploynix, migrate your data, and cut over DNS with minimal downtime. The key principle throughout this migration is simple: run both platforms in parallel until you are confident the new setup works perfectly, then switch. Before diving into the how, let us briefly address the why. Developers move between server management platforms for various reasons: pricing, features, support, or simply wanting a fresh approach. While Forge has added features like zero-downtime deployments and server monitoring in its recent overhaul, Deploynix offers a different set of strengths: built-in load balancing with multiple balancing methods (Round Robin, Least Connections, IP Hash), seven specialized server types for granular architecture control, scheduled deployments via API, Valkey as a truly open-source Redis alternative, support for modern frontend frameworks (Next.js, Nuxt, SvelteKit) alongside Laravel, and a free tier with vanity domains on deploynix.cloud to get started without a credit card. But ultimately, the decision to migrate is yours. This guide assumes you have already made that decision and need a clear path from A to B. The first step is to create a complete inventory of everything running on your Forge-managed servers. This is your migration blueprint. For each server on Forge, document: For each site, document: Document your current DNS records: Take your time with this inventory. Missing a cron job or environment variable can cause subtle issues that are hard to debug after migration. Sign up at deploynix.io and create your organization. If you have team members, you can invite them with appropriate roles: Owner, Admin, Manager, Developer, or Viewer. Each role has different permissions, so assign them according to your team's needs. Navigate to your organization's settings and connect the same cloud provider you are using with Forge. Deploynix supports DigitalOcean, Vultr, Hetzner, Linode, AWS, and custom servers. Using the same cloud provider means your new servers will be in the same network, which makes database migration faster and simplifies the transition. Connect GitHub, GitLab, Bitbucket, or your custom Git provider. Deploynix needs access to the same repositories that Forge is currently deploying from. Now, provision servers on Deploynix that mirror your Forge infrastructure. For each Forge server, create an equivalent Deploynix server. Choose the same region as your existing server. This keeps latency consistent for your users and allows for easy data migration between old and new servers. Match the server size. If your Forge server is a 2GB/2vCPU instance, provision the same on Deploynix. You can always resize later. Select the right server type. Deploynix offers specialized server types: App, Web, Database, Cache, Worker, Meilisearch, and Load Balancer. For a standard Forge server that runs everything, an App Server is the equivalent. Match the database. If your Forge server runs MySQL 8, select MySQL during Deploynix server provisioning. Match the PHP version. Deploynix supports PHP 8.0 through 8.4, so you can match your current Forge PHP version exactly. If your Forge server runs an older version, this is also a good opportunity to upgrade, but only if your application supports it. Wait for provisioning to complete. Deploynix will configure Nginx, PHP-FPM, your database, Valkey, and Supervisor automatically. For each site on your Forge server, create a corresponding site on your Deploynix server. Enter the domain name, select the repository, choose the branch, and set the web directory. Important: Do not change your DNS yet. The new sites will not be receiving traffic at this point. You are building the new environment in parallel. Copy your .env from Forge and paste it into the environment editor on Deploynix. Update the following values: If you have external service credentials (mail, payment, etc.), those stay the same. If you had custom Nginx configuration on Forge, apply the same rules in Deploynix. Navigate to the Nginx configuration for your site and add your custom directives. Deploynix validates the configuration before applying, so you will catch syntax errors immediately. Recreate your queue workers as Daemons in Deploynix. For each queue worker on Forge, create a corresponding daemon with the same command, number of processes, and configuration. Add your scheduled tasks through the Deploynix Cron Jobs interface. At minimum, ensure the Laravel scheduler cron entry is configured: php artisan schedule:run running every minute. Review your Forge firewall rules and recreate any custom rules in Deploynix. The default rules (SSH, HTTP, HTTPS) are created automatically. This is the most critical step. You need to move your data from the old server to the new one. SSH into your Forge server and create a database dump: Copy the dump file to your new Deploynix server: SSH into your Deploynix server (or use the web terminal) and import: Run a few quick checks: count records in key tables, verify that recent data is present, and test a few queries. Make sure the import is complete before proceeding. Trigger a deployment for each site on Deploynix. Watch the deployment log to ensure everything completes successfully: code cloned, dependencies installed, migrations run (they should report nothing to migrate since you imported an existing database), assets built. You can test your new sites without changing DNS by modifying your local /etc/hosts file: This makes your browser connect to the new server when visiting your domain, while everyone else still hits the old server. Browse through your application, test critical flows (login, signup, payments, API endpoints), and verify that everything works correctly. Check that your queue workers are processing jobs, scheduled tasks are running, and any daemons are functioning correctly. The Deploynix dashboard shows the status of all managed processes. Once you are confident the new setup works perfectly, it is time to switch DNS. If your DNS records have a high TTL (Time to Live), consider reducing it to 300 seconds (5 minutes) a few hours before the cutover. This ensures that after you update DNS records, the change propagates quickly. Update your A records to point to the IP address of your Deploynix server. If you use CNAME records for subdomains, update those as well. Once DNS points to your new server, provision SSL certificates through Deploynix. If you are using Let's Encrypt, Deploynix handles the entire ACME challenge process. If you are using a DNS provider supported by Deploynix (Cloudflare, DigitalOcean, AWS Route 53, Vultr), you can provision wildcard certificates using DNS validation. After the DNS switch, monitor your application closely for the first few hours. Check error logs, response times, and user reports. The Deploynix dashboard provides real-time monitoring and health alerts to help you catch issues quickly. Do not cancel your Forge subscription or destroy your old servers immediately. Keep them running for at least a week after the migration. This gives you a safety net: if something goes wrong, you can revert DNS back to the old servers instantly. If your application continued receiving writes on the old server during DNS propagation, you may need to do a final data sync. This depends on your application's tolerance for brief data gaps and whether you can put the old site in maintenance mode during the cutover. Configure automated database backups on Deploynix before decommissioning your old servers. Deploynix supports backups to AWS S3, DigitalOcean Spaces, Wasabi, and any S3-compatible storage. Verify that at least one backup completes successfully. Once you are satisfied that everything is working on Deploynix and you have verified backups, you can safely destroy your Forge servers and cancel your Forge subscription. SSH keys: If your application needs to pull from private repositories or connect to other servers via SSH, make sure the necessary SSH keys are configured on your Deploynix server. File storage: If your application stores user uploads on the local filesystem (not S3), you need to copy the storage directory from the old server to the new one. Consider migrating to S3-compatible storage during this transition. Environment-specific settings: Double-check any settings that reference the old server's IP address, such as trusted proxies, CORS origins, or webhook URLs. Email configuration: If your old server ran a local mail server, you will need to configure an external mail service on the new setup or ensure the same mail configuration works. Cron timing: After migration, verify that your scheduled tasks are running at the expected times. Check the timezone configuration in both your server and your Laravel application. Migrating from Forge to Deploynix is a methodical process, not a risky one. By running both platforms in parallel, testing thoroughly before DNS cutover, and keeping the old infrastructure as a fallback, you eliminate virtually all risk. The entire migration can typically be completed in an afternoon for simple setups, or over a weekend for more complex multi-server environments. Once complete, you gain access to Deploynix's full feature set: real-time monitoring, health alerts, web terminal, scheduled deployments, load balancing, and more. Start your migration today at deploynix.io. Your first server is free. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse