Which Hosting to Choose for a PHP Script

Which hosting to choose for a PHP script in 2026 depends not on ads about "SSD and 99.9%" but on the PHP version, your own database, cron, and whether you need root. A ready-made Microscript product does not live on a website builder and should not be forced into a constructor with "PHP as an option".

Short version: a simple landing page with a form can use shared hosting. A board, store, exchange, or trading account area usually needs a VDS. Below is the practical breakdown without glossy lists of "key advantages".

What the plan must include

• PHP 8.1+ with per-domain version selection.
• MySQL or MariaDB, your own database, utf8mb4.
• mysqli, mbstring, curl, gd or imagick.
• SSH access, or at least SFTP, and the ability to edit .htaccess or vhost config.
• Cron if the product needs background jobs.
• Enough inode and disk space for photo uploads.

Module checklist: PHP/MySQL requirements. If the host does not provide phpinfo and a version selector, that is a bad sign for any archive we ship.

Shared: when it is enough

Shared hosting is fine for a moderate-traffic showcase: catalog, early classified board, or small store. Panels such as Beget, Timeweb, and ISPmanager on shared hosting follow a familiar path: create a domain, create a database, upload to public_html, run the installer.

The picture breaks when:

• PHP 8 cannot be selected and only 7.4 is available "for compatibility";
• there is no cron or it runs at most once per day;
• max_execution_time and upload limits are so tight the admin area cannot breathe;
• you need long-running processes, queues, your own Redis, or a custom port.

Shared hosting is often convenient until you hit its limits. When you do, move to a VDS instead of praying for script optimization.

VPS / VDS: when it is needed

Root or sudo is needed when you install Nginx + PHP-FPM yourself, manage PHP versions, configure firewall, and control backups. Trading platforms, quotes, and busy boards with many images belong here. Hardware and OS selection: VDS for PHP; why root matters: VPS with root.

On a VDS you are responsible for updates and port security. Firewall minimum: VDS firewall. Web stack: Nginx + PHP-FPM.

Panels and "script hosting"

ISPmanager, Fastpanel, and Hestia are a normal route if you do not want to edit nginx by hand every time. The important part is that the panel does not lock you to one ancient PHP branch. "Preinstalled WordPress" does not help; you need a normal empty site and database.

Do not confuse a VDS with a panel and managed WordPress hosting. The latter usually does not fit our archive.

Rough resources

Starter VDS for a board or store: 2 CPU, 4 GB RAM, NVMe from 40 GB. Less than 2 GB for production with MySQL on the same machine is already tight, especially with admin tasks and cron. "Unlimited" shared hosting often hits CPU throttling before gigabytes.

Listing photos and repacks consume inodes. Check file count limits, not only disk space in GB.

Mail, SSL, domain

SSL is basic now: Let's Encrypt in a panel or Certbot on a VDS: SSL on a PHP site. For form mail, use the host's SMTP or an external service; plain mail() on shared hosting is a lottery.

The domain can be registered anywhere; DNS A record points to the hosting IP. After changing DNS, wait for TTL instead of reinstalling the script repeatedly because "it does not open".

Local before production

Before paying for a year of hosting, run the script locally on MicroServer: local server. You will understand the admin area and PHP requirements without production surprises. Installation: how to install a script.

Migration

The move from shared to VDS or back is the same: files + dump + new config. Script migration, dump details: MySQL migration. Backup before changing host is mandatory: backup.

If you are not sure shared hosting is enough for your product, send support the script name and expected traffic: support. This is faster than buying the wrong plan and migrating urgently on Friday evening.

What to read in plan specs

• PHP version list and per-domain selection.
• Process / CPU limits; "unlimited" is often fake.
• Inode limit, critical for photos.
• SSH availability, which saves large dump imports.
• Mail and anti-spam policy for mail().
• Automatic backups: retention and download method.

Marketing text like "for any CMS" without a module table is weak. Compare it with the requirements.

Beget, Timeweb, and similar hosts

They are a normal start for a showcase if PHP 8 exists in the selector. Create a domain, database, upload to the root, and install the script. Check the path to php82 for cron. SSL is usually a button. When CPU limits hit during preview generation, then discuss VDS.

ISPmanager on a VDS gives a similar UX with root under the hood: VPS with root.

When shared is definitely wrong

You need custom daemons, non-standard ports, high-frequency cron, separate Redis, tight php-fpm tuning, or isolation of multiple heavy projects. Trading terminals and streaming quotes should look at VDS immediately: VDS for PHP.

The cost of choosing wrong

Cheap shared hosting without SSH and with PHP 7.4 saves a small amount and costs two days of "why does it not install" correspondence. You will migrate anyway: migration. It is better to start with PHP 8 and cron.

Test before paying for a year

Many hosts provide a trial or one month. During that time: install the script, upload 50-100 photos, enable cron, and check mail. Before that, test locally on MicroServer. Installation: manual.

Database errors and 500s during the test are handled by the same manuals: MySQL, 500. SSL: SSL. Back up before the trial ends if you have already entered data: backup.

Several sites on one plan

On shared hosting, limits are shared. Two heavy stores under one account will interfere with each other. On a VDS, use separate FPM pools: Nginx + PHP-FPM. Monitoring after moving to your own server: monitoring.