VDS for a PHP Site and Script

A VDS for a PHP site with MySQL is your own server: you install PHP 8, raise the database, place the script in document root, and decide whether it is Apache or Nginx. For classifieds, shops, and especially trading cabinets, shared hosting with a WordPress installer is often too narrow.

Below is the practical minimum for Microscript products, without marketing about cloud scalability.

What the machine needs

• Root or sudo, otherwise you cannot install the required PHP and cron properly. See VPS with root.
• PHP 8.x plus mysqli, mbstring, curl, gd or imagick: requirements.
• MySQL 8 or MariaDB 10.3+, databases in utf8mb4.
• NVMe or SSD, not a dying HDD.
• Public IPv4, open 80/443, and SSH on a non-standard port if desired.

Rough resources

Start for classifieds or shop: 2 CPU, 4 GB RAM, and 40+ GB disk. 1 GB RAM for PHP, MySQL, and a panel is already tight; the OOM killer will become familiar. Trading platforms and quotes need separate load assessment, with CPU reserve more important than a pretty hostname.

Photos consume disk and inodes faster than expected. Monitor disk: monitoring.

Panel or bare server

ISPmanager, Fastpanel, or Hestia speed up domain and database creation. Bare Ubuntu with Nginx and PHP-FPM is more flexible and clearer if you can administer it. Web stack: Nginx + PHP-FPM.

Do not buy a managed WordPress VDS for our archive; it brings extra limitations and a different stack.

Network and security

Close unnecessary access immediately: MySQL only on localhost, SSH by keys, strong root password. Minimum firewall: VDS firewall. SSL: Certbot and SSL.

Backups should go to another disk, S3, or another VDS, not only to an unchecked monthly snapshot: backup.

Installing a script on VDS

1. Create a vhost with root pointing to the site folder.
2. Create a PHP-FPM pool under the site user.
3. Create an empty database and a user with rights to it.
4. Upload files and set upload permissions: chmod.
5. Run the browser installer: installation.
6. Configure cron: cron.

Database and 500 errors are the same everywhere: MySQL, 500.

Local testing before purchase

Test the archive on MicroServer. You understand the product without paying for a server. Then migrate: script migration, dump: MySQL migration.

Administration

OS and PHP updates are your responsibility. Do not run composer update or apt full-upgrade on production Friday without backup. Microscript product support does not replace a server administrator. Product support scope: SLA, how to contact: support.

OS and region

Ubuntu LTS or Debian Stable bring fewer package surprises. A rolling release is not needed in production. Choose a data-center region close to your audience; poor peering makes images time out even when CPU is free.

Enable IPv6 only if you can close it with the same firewall rules. Open MySQL on IPv6 while IPv4 is closed is a real ticket pattern. Rules: firewall.

Disk and photos

Classifieds and shops eat disk with previews. 20 GB may cover the system but not a year of user uploads. Check both GB and inode limits. When inodes run out, upload fails with permission or save errors even though df still shows free space.

Move backups off the system disk. Otherwise nightly dump plus archive fills the partition and MySQL falls. Backup scheme: backup.

Panel versus manual stack again

A panel speeds up domains and databases. Manual Nginx is clearer when you debug 502. If you use a panel, still learn to read its Nginx include and PHP log. Reinstalling PHP with one button does not fix a wrong password in script config.

Mail, DNS, domain

The domain may stay at a registrar while the VDS hosts the site. A record points to the server IP; lower TTL before moving. Mail does not have to live on the same VDS; often an external mail service is calmer while the server handles web and database.

Issue SSL after DNS points here: SSL. If you issue before DNS change, Let's Encrypt will not validate.

Load and upgrade

First inspect MySQL slow logs and PHP response time, then buy more CPU. Many issues come from missing indexes in custom edits or cron doing heavy recalculation every minute. Cron: tasks. Uptime and disk monitoring: monitoring.

Vertical VDS upgrade is usually simpler than horizontal complexity while one server still handles CPU and disk.

Migrating from shared hosting to VDS

1. Raise the stack and empty database on VDS.
2. Take files and dump from shared hosting.
3. Deploy and update config.
4. Check through your local hosts file without touching DNS.
5. Switch DNS and disable cron on shared hosting.

More: migration, dump. Local rehearsal is a good habit: MicroServer.

If the new VDS immediately shows 1045, you copied shared-hosting config and did not create the user: database error. Upload permissions after tar from root: chmod.

Provider snapshots are useful before major PHP upgrades or panel changes. They do not replace logical backups, but help if an OS update breaks networking. After a snapshot, still check site and cron. If you choose a managed plan without root, confirm PHP 8 and cron before paying.