Faizan

Posted on Oct 26 Originally published at headsntail.com

Shared Hosting vs VPS for Laravel: When to Move

#linux #devops #tutorial

Your Laravel application works well on shared hosting until payroll day. Employees log in together, reports take longer than usual, and someone gets a "508 Resource Limit Is Reached" error.

Should you upgrade to a VPS, or is the application itself causing the problem?

The answer to shared hosting vs VPS for Laravel depends on what the application actually needs. A simple employee portal can run well on cPanel shared hosting. An application that processes large payroll batches, handles frequent background jobs or needs persistent WebSocket connections may require a different environment.

Moving to a VPS gives you more control, but it also means someone must manage server security, updates, backups and monitoring.

Quick answer: Stay on shared hosting while normal traffic fits within the provider's resource limits and scheduled background tasks complete reliably. Consider a VPS when repeated resource faults continue after optimization, background jobs need a permanent process manager, or the application requires services that your shared-hosting provider does not support.

A VPS is not automatically faster. A poorly configured server can perform worse than good shared hosting, especially when the database, PHP workers and background jobs compete for the same small amount of memory.

This guide compares both options, explains the technical limits, shows what a VPS actually costs and walks through a safer cPanel-to-VPS migration.

Shared hosting vs VPS for Laravel at a glance

Shared hosting and a VPS can both run Laravel.

The difference is how much control you have over the hosting environment and who is responsible for maintaining it.

Feature	Shared hosting with cPanel	Virtual Private Server
Starting cost	Usually lower	VPS fee, plus optional management and licenses
Root access	Normally unavailable	Usually available
Server configuration	Controlled by hosting provider	Controlled by you or managed provider
PHP versions	Limited to installed versions	Install supported versions and extensions
CPU and memory	Hosting account quotas	Allocated VPS resources
Queue workers	Cron-based processing or host-supported services	Persistent workers under a process manager
Redis	Depends on provider	Can be installed and configured
Laravel Horizon	Usually unavailable on basic shared plans	Supported with appropriate Redis and worker configuration
Laravel Reverb	Often restricted by persistent-process and port requirements	Can run with a reverse proxy and process manager
Laravel Octane	Usually impractical on basic shared plans	Can run with a supported application server
Backups	Hosting provider may supply tools	You must arrange them unless managed
Security updates	Host manages server infrastructure	Your responsibility on an unmanaged VPS
Best fit	Small sites and applications with light background processing	Applications needing more control, persistent services or predictable resource allocation

A VPS is still hosted on physical infrastructure shared with other virtual machines. It provides virtualized isolation and allocated resources, not automatically an entire dedicated physical server.

What does a small Laravel VPS cost?

As of October 2026, DigitalOcean's published Basic Droplet pricing includes these examples:

Configuration	Monthly price
1 vCPU, 1 GiB RAM	$6
1 vCPU, 2 GiB RAM	$12
2 vCPUs, 2 GiB RAM	$18
2 vCPUs, 4 GiB RAM	$24
4 vCPUs, 8 GiB RAM	$48

These are published infrastructure prices, not complete managed-hosting packages.

Taxes, backups, additional storage, monitoring, control panels and other services can increase the final bill.

A small Laravel application might start on 2 vCPUs and 2 to 4 GiB RAM, but that is a planning estimate rather than a guaranteed requirement.

A PHP application with a separate managed database has a different memory requirement from one running Nginx, PHP-FPM, MySQL, Redis and queue workers on the same server.

Check the current DigitalOcean Droplet pricing before purchasing.

Laravel PHP requirements

Laravel's PHP requirements depend on the framework version.

Laravel version	Minimum PHP version
Laravel 12	PHP 8.2
Laravel 13	PHP 8.3

Laravel 13 was released on 17 March 2026.

Before choosing hosting, check the version used by your application:

php artisan --version

Then check the PHP CLI version:

php -v

These commands show the framework version and the PHP executable used by Terminal.

On cPanel, the PHP version used by the website may differ from the command-line version.

Check both.

Also verify all required PHP extensions and Composer package requirements. PHP version compatibility alone does not guarantee the application will run.

Which shared-hosting limits actually matter for Laravel?

Shared hosting can handle normal Laravel web requests perfectly well.

Problems often start when the application begins doing more than displaying pages and saving forms.

The most common restrictions involve resource quotas, process management and access to server services.

CloudLinux resource limits

Many cPanel providers use CloudLinux to isolate customer accounts.

CloudLinux places resources inside Lightweight Virtual Environments, commonly called LVEs.

The hosting provider configures the limits.

Resource	What it controls	Typical result when exhausted
SPEED	CPU capacity	Requests are throttled
PMEM	Physical memory	Processes may fail or be terminated
EP	Concurrent entries into the LVE	HTTP 508 on relevant Apache configurations
NPROC	Number of processes and threads	New processes may fail
IO	Disk throughput	Disk activity slows
IOPS	Disk operations per second	Disk activity is throttled

A common mistake is treating the EP limit as the total number of PHP processes, cron jobs and SSH sessions combined.

CloudLinux distinguishes EP from NPROC.

The EP limit primarily controls concurrent entries from the web server into the LVE. Processes started inside the LVE do not automatically increment EP.

Cron, SSH and other processes can affect NPROC, memory and CPU usage without each consuming a separate EP slot.

The exact behavior also depends on the web server and PHP handler.

You can read the official explanation in CloudLinux's EP and NPROC documentation.

What happens when Laravel requests take too long?

Suppose your hosting account allows 20 concurrent entries.

An ordinary employee dashboard takes 0.2 seconds to respond.

The server may handle many requests because each one finishes quickly.

Now imagine the same dashboard waits five seconds for an expensive database query.

Requests remain active much longer.

New visitors may reach the account's concurrent entry limit even though the actual number of employees has not changed.

This is why optimizing slow database queries can help more than increasing the EP allowance.

When a 508 appears, open:

cPanel > Metrics > Resource Usage

Check the Entry Processes fault count and the time of the error.

If snapshots are available, review the active processes and URLs around that time.

For a complete troubleshooting process, see 508 Resource Limit Is Reached on cPanel: Laravel Fix.

Shared hosting and queue workers

Laravel supports background jobs through queue connections such as database, Redis and SQS.

On shared hosting, the database connection is often the easiest option because it does not require a separate Redis server.

Laravel 12's fresh application configuration commonly uses database-backed queues, sessions and caching. An upgraded application may retain different settings, so inspect its actual configuration.

The main difficulty is keeping a worker running.

Laravel recommends using a process monitor such as Supervisor to manage long-running queue workers.

Many basic shared-hosting plans do not provide root access or allow customers to install and manage their own persistent services.

Some providers offer managed workers or permit persistent processes. Those plans should be evaluated on their actual capabilities rather than assuming every shared-hosting provider has identical restrictions.

For accounts without permanent workers, a scheduled short-lived worker may be appropriate.

In Laravel 12, you can define a scheduled command in routes/console.php:

<?php

use Illuminate\Support\Facades\Schedule;

Schedule::command(
    'queue:work database --stop-when-empty --max-jobs=10 --max-time=50'
)
    ->everyMinute()
    ->withoutOverlapping(10);

This example assumes the application uses the database queue connection and the scheduler is already configured.

It starts a worker every minute, permits it to process up to ten jobs, and asks it to exit when the queue is empty or the worker's lifecycle limit is reached.

Two details matter.

First, --max-time=50 is not a hard 50-second timeout for an individual job. A job already running may continue beyond that duration.

Second, withoutOverlapping(10) prevents scheduled instances from overlapping while its cache lock remains active. The ten-minute expiration does not guarantee that a worker will be terminated when the lock expires.

Set the lock duration longer than the longest expected worker execution, and make sure the cache store supports locking correctly.

For an application already using Redis or another queue connection, change the command to match its actual queue configuration.

Also configure job timeouts, retries and idempotent processing.

For more help, see Laravel schedule:run not working on cPanel.

Why permanent Laravel workers are different

On a VPS, a process manager can keep a queue worker alive continuously.

The worker waits for jobs and processes them as they arrive.

If the process stops unexpectedly, the manager can restart it.

This is useful for applications that need to:

Generate payroll PDFs without blocking web requests.
Process large attendance imports.
Send queued notifications promptly.
Run reports that take several minutes.
Process recurring integration tasks.
Handle a growing backlog of jobs.

A permanent worker does not guarantee jobs will execute instantly. Performance still depends on queue depth, job duration, concurrency and available server resources.

Redis, Horizon, Reverb and Octane

Some Laravel features require services that ordinary shared hosting may not permit.

Redis is an in-memory data store commonly used for caching, queues and other coordination tasks.

Laravel Horizon provides a dashboard and worker management for Redis queues. It requires a compatible Redis-backed queue configuration and a supervised Horizon process.

Laravel Reverb provides a WebSocket server for real-time communication. Production operation normally involves a persistent server process and suitable proxy configuration.

Laravel Octane runs Laravel using an application server that keeps the application in memory between requests. It requires a supported server runtime and appropriate worker management.

These features can work on infrastructure that permits the necessary processes and services.

For many ordinary cPanel shared plans, that support is unavailable or limited.

A VPS gives you the freedom to configure them, although you still need enough memory, CPU capacity and operational knowledge to run them safely.

When should a Laravel application move to a VPS?

Do not migrate simply because a hosting advertisement promises more speed.

Look for a repeatable problem that the current hosting environment cannot reasonably solve.

Sign 1: Repeated resource faults under normal traffic

One 508 during an unusually aggressive bot attack is not enough evidence.

Check whether EP, memory or CPU faults continue during ordinary business activity.

If the application is already optimized and normal traffic still exceeds the account's limits, a VPS with appropriately sized resources may help.

Sign 2: Background jobs are delayed

Consider an HR application that generates payslips after monthly payroll approval.

A short-lived worker starts once per minute and processes a limited number of jobs.

As the number of employees grows, the pending queue may take longer to clear.

A VPS can run continuously supervised workers, subject to available CPU, memory and database capacity.

Before moving, check whether poorly designed jobs or unnecessary database queries are responsible for the backlog.

Sign 3: Payroll reports and imports require more resources

Large Excel imports, PDF generation and reporting can consume substantial memory and CPU.

If the host routinely terminates legitimate workloads and will not raise the relevant limits, the application may need a different environment.

A VPS gives you more control over PHP-FPM settings, worker counts, timeouts and background processing.

It does not remove the need to process records in batches.

Sign 4: The application requires persistent services

A business application may eventually need live attendance dashboards, WebSocket notifications, team chat or a Redis-backed queue dashboard.

If the host does not support those services, a VPS or managed application platform may be appropriate.

Sign 5: Hosting restrictions prevent required administration

Some Laravel applications need custom PHP extensions, operating system libraries, scheduled commands or external services.

If the shared-hosting provider will not support a legitimate requirement, moving may be simpler than trying to work around the restriction.

A practical decision table

Situation	Recommended first action
Occasional 508 during bot traffic	Filter unwanted requests and review logs
Slow employee list	Fix queries, indexing and pagination
Repeated EP faults during normal traffic	Optimize and compare higher-resource hosting
Queue backlog growing every day	Review jobs and worker capacity
Need permanent workers	Check host support, then consider VPS
Need Redis and Horizon	Choose infrastructure that supports Redis and workers
Need Reverb WebSockets	Choose suitable persistent-service hosting
Database connections exhausted	Review pooling, queries and concurrency
No one can maintain an operating system	Consider managed VPS or managed Laravel hosting
Current app is fast and reliable	Stay where it is

If MySQL is the immediate bottleneck, first read MySQL max_user_connections Error on Shared Hosting.

A VPS migration should solve a demonstrated requirement, not replace basic troubleshooting.

VPS responsibilities, queue workers and realistic costs

A VPS offers more control because you manage more of the system.

For an unmanaged Linux VPS, you generally need to configure the web server, PHP runtime, database, security, backups and process monitoring.

A common Laravel deployment uses Nginx, PHP-FPM, MySQL or MariaDB, and Supervisor.

Redis can be added when needed.

Configure Laravel queue workers with Supervisor

The following example assumes an Ubuntu-based VPS with Laravel installed at:

/var/www/hr-app

It also assumes:

PHP CLI is available at /usr/bin/php.
The application runs under www-data.
Laravel uses the database queue connection.
The application files and writable directories have correct permissions.
Required database tables and configuration are already installed.

These are example deployment paths. Confirm them before use.

Install Supervisor:

sudo apt-get update
sudo apt-get install -y supervisor

Verify it is installed:

sudo supervisorctl version

Create a configuration file:

/etc/supervisor/conf.d/laravel-worker.conf

Add:

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
directory=/var/www/hr-app
command=/usr/bin/php artisan queue:work database --sleep=3 --tries=3 --timeout=60 --max-time=3600
autostart=true
autorestart=true
user=www-data
numprocs=2
redirect_stderr=true
stdout_logfile=/var/log/supervisor/laravel-worker.log
stopasgroup=true
killasgroup=true
stopwaitsecs=120

This configuration starts two database queue workers and asks Supervisor to restart them when they exit.

Two processes are a starting example, not a recommended worker count for every application.

Each worker consumes resources. Running too many workers can overload a small database or VPS.

The example uses a 60-second job timeout.

For the database queue connection, check retry_after in config/queue.php. It must exceed the worker timeout by a safe margin.

A common configuration uses a 90-second retry interval with a 60-second worker timeout, but the right values depend on the longest expected job.

If jobs legitimately run longer, adjust job timeout, retry interval and Supervisor's stopwaitsecs together.

Laravel's documentation warns that stopwaitsecs must exceed the longest job execution time to avoid premature termination.

Load the configuration:

sudo supervisorctl reread
sudo supervisorctl update

Check the workers:

sudo supervisorctl status

Each expected worker should report RUNNING.

After deploying new Laravel code, run from the application directory:

php artisan queue:restart

Laravel uses its configured cache to signal workers to restart after finishing their current jobs.

Make sure the cache store is correctly configured for that behavior.

Supervisor should then start replacement workers.

Configure the Laravel scheduler

The scheduler still needs a cron entry.

For example:

* * * * * cd /var/www/hr-app && /usr/bin/php artisan schedule:run >> /dev/null 2>&1

Install this in the application user's crontab, not blindly under root.

Verify the correct path and user first.

If the application previously scheduled queue:work --stop-when-empty every minute, remove that worker schedule once Supervisor takes responsibility for the queue.

Do not run both methods without deliberately designing the concurrency.

A duplicate worker configuration can cause unexpected load and complicate troubleshooting.

What about Redis?

Redis is optional for many Laravel applications.

For a small application already using database queues successfully, you can keep the database connection after moving to a VPS.

Do not switch queue backends merely because Redis is available.

Changing the queue connection requires a plan for pending jobs.

Jobs waiting in a database queue do not automatically appear in Redis after an environment variable is changed.

If Redis is needed, install and secure it using the operating system's supported packages and Laravel's documented client configuration.

Laravel supports PhpRedis and Predis, with different installation requirements.

Do not expose the Redis service directly to the public internet.

The hidden work of an unmanaged VPS

These responsibilities become yours unless the provider explicitly manages them.

Security updates: Apply supported operating system and software updates, review advisories, and plan any required reboots.

Firewall: Restrict inbound traffic to the services the application actually needs.

SSH access: Use appropriate authentication, restrict administrative access and keep a recovery method available.

SSL certificates: Configure HTTPS and test renewal.

Database backups: Create consistent backups and store them away from the VPS.

Application files: Back up uploaded documents, private storage and application-specific files.

Monitoring: Detect service failures, high memory usage, low disk space, failed jobs and unusual resource consumption.

Recovery: Maintain a procedure for restoring the application to a working state.

For payroll or HR applications, backups should be tested periodically rather than assumed to work.

Firewall precautions

Ubuntu commonly uses UFW as a convenient firewall interface.

Before enabling it, verify the actual SSH port and confirm you have another recovery method such as the VPS provider's console.

Do not assume SSH always runs on port 22.

For a server using port 22 and serving HTTP and HTTPS, the basic commands are:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Check the rules:

sudo ufw status verbose

Only enable the firewall after confirming that your remote access is permitted and that any other required services have been accounted for.

A mistake here can lock you out of the server.

Managed VPS versus unmanaged VPS

With an unmanaged VPS, the provider usually maintains the virtualization platform and underlying hardware, while you handle the operating system and application stack.

A managed VPS includes some administration services, but the exact scope varies widely.

Do not assume the word "managed" means the provider will maintain your Laravel code, recover application data or troubleshoot a queue failure.

Ask for a written list of responsibilities.

VPS control panels in 2026

You do not need cPanel to run Laravel on a VPS.

There are free and paid options.

Option	Pricing model	Best use
Plain Nginx and PHP-FPM	No hosting-panel license	Developers comfortable managing Linux
HestiaCP	Free, open source	General website and hosting administration
CloudPanel	Free	PHP application and server management
cPanel & WHM	Paid license	Teams wanting familiar cPanel hosting administration
Laravel Forge	Paid service	Laravel deployments and server provisioning

HestiaCP's current documentation lists support for Debian 12/13 and Ubuntu 22.04, 24.04 and 26.04 LTS.

CloudPanel's current documentation lists Debian 12/13 and Ubuntu 22.04, 24.04 and 26.04, with a minimum of one CPU core and 2 GB RAM.

Both should be installed according to their official instructions, preferably on a fresh supported operating system.

Do not install multiple competing server-control panels on an existing production server without verifying compatibility.

cPanel license costs

As of October 2026, cPanel's published direct-store Cloud license prices include:

License	Account allowance	Monthly price
Solo Cloud	1 account	$29.99
Admin Cloud	Up to 5 accounts	$35.99
Pro Cloud	Up to 30 accounts	$53.99
Premier Cloud	Up to 100 accounts	$69.99

Additional charges apply for accounts beyond the included Premier allowance.

Prices exclude applicable taxes, and hosting providers may offer different bundled or reseller pricing.

A $24 VPS with a separately purchased $29.99 cPanel Solo license is therefore not a $24 complete hosting setup.

Other operating expenses may still apply.

Check cPanel's official 2026 license pricing before purchasing.

Does a Laravel HR application need 4 GB RAM?

Not necessarily.

Memory depends on the PHP worker count, database size, queue workers, application workload and installed services.

A small application might operate with 2 GB RAM if its database and background-processing needs are limited.

A server running Nginx, PHP-FPM, MySQL, Redis, Supervisor and a control panel may need more room, especially during PDF generation or large exports.

Start with measured requirements.

Check peak memory and CPU consumption during the busiest application workflows before selecting a plan.

The number of employee records alone is not enough to predict server requirements.

A safe cPanel-to-VPS Laravel migration checklist

Moving a Laravel application is not just copying public_html.

The database, private files, encryption keys, jobs, scheduled tasks and external integrations all need attention.

For an HR or payroll application, plan a controlled migration with a verified rollback option.

Step 1: Prepare a migration inventory

Before touching production, record:

Current Laravel and PHP versions.
Required PHP extensions.
Database engine and version.
Environment configuration.
Cron jobs.
Queue connection and pending job counts.
Uploaded files and private storage.
Email sending configuration.
Third-party API connections.
Current DNS records and TTL values.
SSL certificate configuration.
Current backup and restore procedures.

Verify what actually runs on the existing host.

The Laravel deployment guide for cPanel can help identify the current shared-hosting setup.

Step 2: Create verified backups

Before migration, back up the source database and application files.

For a MySQL database, a basic command is:

mysqldump --single-transaction --quick --default-character-set=utf8mb4 -u DB_USER -p DB_NAME > backup.sql

Replace DB_USER and DB_NAME with the real values.

The command prompts for the database password.

--single-transaction provides a consistent snapshot for supported transactional tables, provided concurrent schema changes are avoided.

It does not automatically guarantee a consistent snapshot for every nontransactional table or external file.

Include stored routines, events and other database objects when your application uses them, subject to the required database privileges.

A backup is not verified simply because the command completed.

Confirm the archive exists, has plausible contents and can be restored into a test database.

Also back up application storage and records not held in Git.

This may include uploaded employee documents, salary exports, images, signed files and other private data.

Keep the backup outside both the old and new production servers.

Step 3: Build the destination server

Install a supported operating system and the required application stack.

At minimum, check:

PHP CLI and PHP-FPM versions.
Required PHP extensions.
Composer.
Web-server configuration.
Database connectivity.
Writable storage and cache directories.
Timezone settings.
File ownership and permissions.

Laravel's document root must point to its public directory.

Do not expose .env, vendor, private storage or the application source directory through the web server.

Set up a non-root deployment account and protect administrative access.

Before opening the site publicly, apply baseline security configuration.

Step 4: Deploy code from a trusted source

Use a verified Git commit or deployment package.

Do not copy an unknown mixture of old application files, temporary patches and generated caches into the new server.

From a trusted project directory, install production dependencies:

composer install --no-dev --prefer-dist --optimize-autoloader --no-interaction

This installs the versions defined in composer.lock, subject to the target environment's compatibility.

Composer can run installation scripts and plugins, so use a trusted project and review its dependency configuration.

If the application uses Vite or another frontend build system, deploy the built assets or perform the appropriate production build.

Step 5: Preserve the Laravel APP_KEY

This is one of the most important migration details.

Do not run php artisan key:generate on an existing production application merely because it has moved to another server.

Laravel uses APP_KEY for encryption.

Changing it can invalidate sessions and make previously encrypted values unreadable unless an appropriate key-rotation strategy is in place.

Preserve the existing key securely during a normal migration.

If the application uses APP_PREVIOUS_KEYS, preserve and review those settings as well.

Update database credentials, cache settings and other environment values only as needed for the new server.

Do not publish .env in a web-accessible directory or commit secrets to Git.

Step 6: Migrate database and private files

Import the verified database backup into the destination database.

Check that the expected tables, data and indexes are present.

Compare representative row counts and application records.

Restore uploaded files into their correct storage paths.

Verify private documents remain private.

For Laravel, confirm any required storage link points to the intended directory:

php artisan storage:link

Use this command only if the application needs Laravel's standard public storage symlink and the link is not already correctly configured.

Some shared-hosting deployments use custom storage arrangements.

Review those before changing them.

If storage links are failing, see Laravel Storage Link Not Working on Shared Hosting.

Step 7: Prepare queues and scheduled tasks without running duplicates

Review all pending and failed jobs before cutover.

If the application uses database queues, its queued jobs may be included in the database backup.

However, jobs created after the backup will not automatically appear on the destination server.

Also check whether any job was in progress during the export.

Do not start new workers and the old workers against separate copies of the database without a plan.

This can produce duplicate emails, reports, notifications or business transactions.

Prepare the VPS workers and scheduler, but activate them only at the appropriate point in the migration.

If you intend to switch from database queues to Redis, explicitly plan how outstanding database jobs will be completed or transferred.

Changing QUEUE_CONNECTION alone does not migrate pending jobs.

Long-running jobs should use idempotent processing where practical so retries do not create duplicate records.

Step 8: Test the destination before changing public DNS

Use a temporary domain, private test route or local hosts-file override to test the new server.

On Windows, the hosts file is normally located at:

C:\Windows\System32\drivers\etc\hosts

An administrator can temporarily map the application domain to the new VPS IP.

For example:

VPS_IP hr.example.com

Replace VPS_IP with the actual address.

Do not use an example IP as a real destination.

A hosts-file override changes local name resolution only on the test computer. It does not issue or repair a TLS certificate.

If the existing domain certificate is not yet valid on the VPS, prepare a valid certificate using an appropriate staging or domain-validation method before HTTPS testing.

Check:

Login and logout.
Employee lists and search.
Forms and file uploads.
Permissions and user roles.
Payroll calculation.
Report and PDF generation.
Email delivery.
Scheduled tasks.
Queue processing.
Application logs.
HTTPS and redirects.
Database writes.
Private document access.

Do not send real customer emails or trigger financial actions during testing unless the environment is deliberately configured for that purpose.

Step 9: Perform a controlled final data cutover

This is where a migration can go wrong even when both servers work.

The destination database copied during initial testing will become outdated as employees continue using the old site.

Choose an appropriate maintenance period.

A safe sequence is:

Announce the maintenance window.
Stop or restrict new writes on the source application.
Allow in-progress operations to finish safely.
Pause queue producers and workers as appropriate.
Disable scheduled tasks that would modify data.
Take a final consistent database backup.
Synchronize final uploads and changed private files.
Import or apply the final data to the destination.
Verify the final records.
Activate the destination workers and scheduler.
Direct production traffic to the VPS.

Use a documented approach for any integrations that continue writing data during maintenance.

DNS cutover alone does not guarantee that all users immediately reach the new server. Resolvers may cache previous answers.

Do not let the old and new servers independently accept production writes during this period.

For applications using webhooks or other external integrations, update and test those endpoints as part of the cutover.

Step 10: Switch DNS and verify HTTPS

Lower the relevant DNS TTL in advance, allowing the previous TTL to expire before cutover where practical.

Update the authoritative DNS records to point to the new server.

Verify that the public domain resolves correctly.

Test the TLS certificate and HTTPS configuration.

Do not wait until after public DNS cutover to discover that the new server cannot obtain or use an appropriate certificate.

Where possible, prepare the certificate in advance using a suitable validation method.

Also review email DNS records.

If the old cPanel account hosts email, moving the website does not automatically mean email should move.

Keep the relevant MX, SPF, DKIM and DMARC records correct.

For a comparison of external email hosting, read cPanel Email vs Google Workspace vs Zoho Mail.

Step 11: Verify production and keep a rollback plan

After cutover, inspect the production application.

Test the login process, database writes, document uploads, queues, scheduled jobs and emails.

Monitor PHP-FPM, database and worker health.

Review application and server error logs.

Keep the old hosting account and verified backups available until the migration is accepted.

However, leaving the old site active as a second writable production system is not a safe rollback strategy.

A rollback must account for data written to the VPS after cutover.

For a stateful payroll or HR application, simply pointing DNS back to the old server may lose newer employee changes or cause duplicate processing.

Document how those records will be reconciled before reverting.

Only decommission the old system after confirming that production is stable and the recovery plan is complete.

When to stay on shared hosting instead

A VPS is not always the right move.

If the application has modest traffic, no demanding background services and no repeated resource faults, shared hosting may be the simpler and cheaper choice.

There are also situations where fixing the application is a better investment than migrating it.

Fix slow queries before buying more RAM

An application that loads thousands of records on every request may remain slow after moving.

Look for missing indexes, unnecessary joins, N+1 queries and expensive repeated calculations.

Use pagination and appropriate caching.

Measure the improvement before changing infrastructure.

Split long jobs into smaller operations

A single payroll export that takes several minutes may be better handled in smaller queued jobs.

Laravel supports batching and chaining for workflows that need to process tasks in a controlled order.

For a practical example, see Laravel Queue Batches: How to Chain Multiple Batches.

Splitting work also makes retries easier because a failed operation does not necessarily require restarting the entire export.

Do not choose an unmanaged VPS without an administrator

An unmanaged VPS needs ongoing attention.

Someone must know how to update the operating system, recover from disk failure, secure SSH, investigate database problems and restore backups.

For an HR application containing employee documents and salary records, that responsibility is substantial.

If there is no one available to maintain it, consider a managed hosting service instead.

The cheapest monthly server is not necessarily the cheapest way to run a business application reliably.

Make the decision using actual measurements

Before migrating, compare the current workload with what the new server will provide.

Useful measurements include:

Peak concurrent requests.
Average and slowest response times.
CPU and memory consumption.
Database query duration.
Queue backlog and job completion times.
Storage usage and growth.
Error rates.
Backup size and restore duration.

If the existing host meets those requirements, there is no technical reason to migrate just because a VPS is available.

If the current provider cannot support legitimate application requirements, choose the destination based on those requirements rather than marketing claims.

FAQ

Can Laravel run on cPanel shared hosting?

Yes.

Laravel 12 can run on compatible shared hosting with PHP 8.2 or newer, the required PHP extensions and a suitable application directory structure.

Laravel 13 requires PHP 8.3 or newer.

The web-server document root should point to Laravel's public directory.

Background jobs and scheduled tasks are possible when the hosting provider supports the required execution methods.

Persistent services such as Horizon, Reverb and Octane depend on the provider's process and service restrictions.

How much RAM does a Laravel VPS need?

There is no fixed amount.

A small application may work with 2 GB RAM, while an application running PHP-FPM, a database, Redis, queue workers and a control panel on the same server may benefit from 4 GB or more.

Heavy exports, large databases and multiple concurrent workers can increase memory requirements.

Measure the actual workload before selecting a plan.

Is managed VPS hosting better than unmanaged VPS hosting?

Managed VPS hosting is usually a better fit when the organization needs more server control but does not have the staff to handle ongoing system administration.

Unmanaged VPS hosting can cost less in monthly infrastructure fees, but operating system updates, server security, monitoring and backups remain your responsibility.

Always verify what services are included in the management agreement.

Do I need cPanel after moving Laravel to a VPS?

No.

Laravel can run with Nginx, PHP-FPM, a supported database and a process manager without cPanel.

Free panels such as HestiaCP and CloudPanel may also be suitable, depending on the deployment requirements.

cPanel remains useful for teams that want its familiar interface and hosting-management features, but its VPS license adds cost.

Choose the management approach that your team can operate and maintain reliably.

Official sources and further reading

Laravel documentation:

Hosting and infrastructure:

Originally published at headsntail.com. Free tools for PHP, Laravel and cPanel work: headsntail.com/tools.