There comes a moment in every Laravel developer's journey when shared hosting stops being enough. Maybe your application is outgrowing the resource limits. Maybe you need SSH access, queue workers, or a proper deployment pipeline. Maybe you are tired of fighting with cPanel to get your Laravel application to work in a public_html directory structure that was designed for WordPress.
Whatever the reason, migrating from shared hosting to a proper server management platform is one of the biggest quality-of-life upgrades you can make as a developer. This guide is written specifically for developers making this transition — from cPanel and shared hosting to Deploynix. We will cover everything: exporting your data, provisioning your new server, configuring your application, migrating your database, updating DNS, and going live.
Understanding What Changes
Before we start, let us clarify what is fundamentally different about moving to Deploynix.
On shared hosting, your application lives alongside dozens or hundreds of other applications on the same server. You share CPU, memory, and disk I/O with strangers. You have limited control over PHP versions, extensions, and server configuration. You access your server through cPanel, FTP, or a limited file manager.
On Deploynix, your application runs on a dedicated virtual private server (VPS) that you control entirely. You get dedicated CPU and memory, root-level access, the ability to install any PHP extension, run background processes, configure Nginx however you want, and deploy code through Git instead of FTP.
The biggest mindset shift is this: you are no longer renting a room in someone else's house. You have your own house. Deploynix is the property management company that handles the infrastructure setup and maintenance so you can focus on your application.
Phase 1: Prepare Your Application
Ensure Git-Based Source Control
If your application is not already in a Git repository, this is the first thing to fix. Deploynix deploys code from Git (GitHub, GitLab, Bitbucket, or a custom Git provider), not from FTP uploads.
If your code only exists on the shared hosting server, download it and initialize a Git repository:
git init
git add .
git commit -m "Initial commit — migrating from shared hosting"
Push it to GitHub, GitLab, or Bitbucket. This becomes your deployment source.
Review Your composer.json
Make sure your composer.json and composer.lock files are complete and up to date. On shared hosting, you might have manually installed packages or edited files directly on the server. Run composer install locally to verify everything resolves correctly.
Check PHP Version Compatibility
Deploynix provisions PHP 8.3 by default (with 8.4 also available). If your shared hosting was running PHP 8.1 or 8.2, review the PHP migration guides for any breaking changes. Common issues include:
- Deprecated functions that have been removed
- Stricter type checking
- Changed default values for some PHP settings
Run your test suite (you do have tests, right?) against your target PHP version locally to catch compatibility issues before migrating.
Review Environment Variables
On shared hosting, your .env file might reference localhost for database connections, use file-based sessions, and have file-based cache. On Deploynix, you will want to take advantage of the full stack:
- Database connection to the locally provisioned MySQL/PostgreSQL
- Valkey (Redis-compatible) for cache, sessions, and queues
- Proper mail configuration (shared hosting often uses the local
sendmail, which is unreliable)
Make a copy of your current .env file. You will reference it when configuring the environment on Deploynix.
Phase 2: Export Your Data
Export Your Database
This is the most critical step. Your database contains all your application's data.
If you have phpMyAdmin access (most shared hosts provide this through cPanel):
- Log into phpMyAdmin
- Select your database
- Click "Export"
- Choose "Custom" export method
- Select SQL format
- Check "Add DROP TABLE / DROP VIEW" in the Object creation options
- Click "Go" to download the SQL file
If you have SSH access (some shared hosts allow this):
mysqldump -u your_username -p your_database > database_backup.sql
If you have neither, check if your hosting provider has a backup tool in cPanel under "Backup" or "Backup Wizard." You can often generate and download a database backup from there.
For PostgreSQL databases, use pg_dump similarly.
Save this file somewhere safe. You will import it into your new server later.
Export Uploaded Files
If your application stores user uploads or other files in the storage/app directory, you need to move these files to your new server.
Download the entire storage/app/public directory (and any other storage directories your application uses) from your shared hosting via FTP, SFTP, or the cPanel file manager.
Important: Do not download the storage/framework or storage/logs directories. These contain temporary cache files and logs that are specific to the shared hosting environment and should be regenerated fresh on the new server.
Document Your Cron Jobs
If you have cron jobs configured on your shared hosting (usually through cPanel's "Cron Jobs" section), document them. Note the commands and their schedules. On Deploynix, you will recreate these through the Cron Jobs interface or, more likely, simply configure Laravel's task scheduler which handles scheduling within your application code.
Phase 3: Set Up Deploynix
Create Your Account
Sign up at deploynix.io. The free tier includes one server and up to three sites, which is perfect for getting started.
Connect Your Cloud Provider
You will need an account with a cloud provider. If you do not already have one, DigitalOcean, Vultr, and Hetzner are popular choices for Laravel developers. DigitalOcean and Vultr offer starting plans at around $5-6/month, and Hetzner's European servers are even more affordable.
Create an API token with your cloud provider and add it to Deploynix through the organization settings.
Connect Your Git Provider
Connect GitHub, GitLab, or Bitbucket so Deploynix can access your repository.
Provision Your Server
Create an App Server on Deploynix. For a typical Laravel application migrating from shared hosting, a 1-2GB RAM server is a good starting point. This gives you significantly more resources than shared hosting typically allocates to a single account.
Select your database (MySQL if you were using MySQL on shared hosting, PostgreSQL if PostgreSQL) and your preferred PHP version.
Wait for provisioning to complete. This takes about 3-5 minutes.
Create Your Site
Once the server is ready, create a site. Enter your domain name, select your repository, choose the deployment branch, and leave the web directory as /public.
Phase 4: Configure Your Application
Set Up Environment Variables
Open the environment editor in your Deploynix site dashboard. Start with the default template and update these key values:
APP_NAME="Your Application Name"
APP_ENV=production
APP_KEY=base64:your-existing-app-key-here
APP_DEBUG=false
APP_URL=https://yourdomain.com
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=your_database
DB_USERNAME=your_db_user
DB_PASSWORD=your_db_password
CACHE_STORE=redis
SESSION_DRIVER=redis
QUEUE_CONNECTION=redis
MAIL_MAILER=smtp
MAIL_HOST=your-mail-host
MAIL_PORT=587
MAIL_USERNAME=your-mail-username
MAIL_PASSWORD=your-mail-password
MAIL_ENCRYPTION=tls
Critical: Copy your existing APP_KEY from your shared hosting .env file. If you generate a new key, any data encrypted with the old key (passwords are hashed and not affected, but encrypted fields, signed URLs, and cookies will break) becomes unreadable.
Deploynix creates database credentials during site setup. Use those credentials for the DB_* variables.
Import Your Database
You need to get your database dump onto the new server and import it. There are several ways to do this.
Using the web terminal: Upload your SQL file to a file-sharing service or your server directly via SCP, then import it through the Deploynix web terminal:
mysql -u your_db_user -p your_database < /tmp/database_backup.sql
Using SCP from your local machine:
scp database_backup.sql deploynix@your-server-ip:/tmp/
Then SSH in (or use the web terminal) and import:
mysql -u your_db_user -p your_database < /tmp/database_backup.sql
After importing, verify the data is intact by checking a few tables.
Upload Storage Files
If you have user uploads or other storage files, transfer them to your new server:
scp -r storage/app/public/* deploynix@your-server-ip:/home/deploynix/your-site/storage/app/public/
Make sure the symbolic link from public/storage to storage/app/public is in place:
php artisan storage:link
Phase 5: Deploy and Test
Run Your First Deployment
Click "Deploy" in the Deploynix dashboard. Watch the deployment log. A successful deployment will:
- Clone your repository
- Install Composer dependencies
- Install npm dependencies and build assets (if applicable)
- Run any pending migrations (there should not be any if you imported a production database)
- Cache configuration, routes, and views
- Symlink the new release
Test Before Switching DNS
Edit your local /etc/hosts file to test the new server:
your-server-ip yourdomain.com
On Windows, this file is at C:\Windows\System32\drivers\etc\hosts.
Now visit your domain in a browser. Everything should work exactly as it did on shared hosting, but faster. Test all critical functionality:
- User login and registration
- Forms and data submission
- File uploads and downloads
- Payment processing (if applicable)
- Email sending
- Any API endpoints
Remove the hosts file entry when you are done testing.
Set Up Queue Workers
If your application uses queued jobs (and it should for any email sending, notification, or background processing), create a queue worker in the Deploynix dashboard:
Command: php artisan queue:work redis --sleep=3 --tries=3 --max-time=3600
Processes: 1 (increase if needed)
On shared hosting, you may have been running queue jobs synchronously (the sync driver) because there was no way to run a persistent worker process. Now that you have Supervisor managing your workers, switch to the redis queue driver for proper async processing.
Set Up Scheduled Tasks
Add the Laravel scheduler to your cron jobs through the Deploynix dashboard. The command is:
php artisan schedule:run
Set it to run every minute. This replaces any cron jobs you had configured on shared hosting. Laravel's scheduler handles all the timing logic within your application code, which is far more maintainable than managing individual cron entries.
Phase 6: DNS Cutover
Update Your Domain's DNS Records
Log into your domain registrar (GoDaddy, Namecheap, Cloudflare, or wherever you manage DNS) and update your A record to point to your Deploynix server's IP address.
If you have subdomains, update those A records or CNAME records as well.
Do not delete your old DNS records until the new ones are working. Simply update them.
DNS Propagation
DNS changes can take anywhere from a few minutes to 48 hours to propagate globally, though most changes take effect within 1-2 hours. During this time, some users will hit your old shared hosting server and some will hit your new Deploynix server.
To minimize issues during propagation:
- Keep your shared hosting active during this period
- If possible, put the shared hosting version in maintenance mode a few hours after updating DNS, once most traffic has shifted
- Monitor both servers for errors
Provision SSL
Once DNS points to your new server, provision an SSL certificate through the Deploynix dashboard. Deploynix supports free Let's Encrypt certificates that auto-renew.
If you are using Cloudflare as your DNS provider, Deploynix can also provision certificates using DNS validation, which does not require waiting for DNS propagation.
If you do not have a domain yet, use a Deploynix vanity domain (like your-app.deploynix.cloud) which comes with automatic SSL.
Phase 7: Post-Migration Cleanup
Verify Everything Works
After DNS has fully propagated:
- Test all application functionality again
- Verify that SSL is working (padlock icon in browser)
- Check that emails are being sent
- Verify queue workers are processing jobs
- Confirm scheduled tasks are running
Configure Backups
Set up automated database backups through Deploynix. Choose a backup storage provider (AWS S3, DigitalOcean Spaces, Wasabi, or any S3-compatible service) and configure daily backups. On shared hosting, your hosting provider may have handled backups. Now it is your responsibility.
Set Up Monitoring
Enable health checks and alerts in Deploynix. Configure notifications for server downtime, high CPU usage, high memory usage, and disk space warnings. This proactive monitoring is something shared hosting never offered.
Cancel Shared Hosting
Once you are fully confident everything works on Deploynix — give it at least a week — cancel your shared hosting account. Download a final backup of everything on the shared host before cancellation, just in case.
What You Gain
The difference between shared hosting and a Deploynix-managed server is significant:
- Performance: Dedicated resources mean consistent, fast response times
- Control: Install any PHP extension, adjust any server setting, run any process
- Deployments: Push to Git instead of uploading via FTP. Zero-downtime deploys with instant rollback
- Background processing: Real queue workers, scheduled tasks, and daemons
- Security: Dedicated firewall, automatic security updates, SSL certificates
- Monitoring: Real-time server health dashboards and alerting
- Scale: When you outgrow one server, add more. Load balancing, dedicated databases, and worker servers are all available
Conclusion
Migrating from shared hosting to Deploynix is a one-time investment that pays dividends every day. Your application runs faster, your deployments are safer, and you gain tools and capabilities that shared hosting simply cannot provide.
The process is straightforward: export your data, provision a server, import everything, test, switch DNS, and go live. Most developers complete the entire migration in an afternoon.
Start your migration at deploynix.io. Your free tier includes one server and three sites — everything you need to make the move.
Top comments (0)