VPS with root for a PHP script

A VPS with root is what you need when shared hosting says "not allowed": a specific PHP branch, your own cron every minute, a separate Nginx setup, Redis, closed ports, and snapshots on your own schedule. The PHP script is still the same archive; what changes is your level of control over the machine.

Clients often use VPS and VDS as synonyms. What matters to us is root/sudo and a proper PHP 8 environment, not the plan name in the provider cart. General hardware choice: VDS for PHP.

When root is actually needed

• Shared hosting has no PHP 8.1+ or cannot enable mysqli/gd.
• Cron frequency is limited or CLI execution is forbidden.
• You need your own web server and PHP-FPM tuning for load.
• You want to install a panel, monitoring, and your own backups to S3.
• Long-running processes or queues are killed by shared hosting.

If the site is a small brochure with ten visits a day, root for its own sake is not mandatory. See hosting for a script.

What you do as root after purchase

1. Update the OS, create a sudo user, add SSH keys, and disable password root login if possible.
2. Set up the firewall: firewall for 22/80/443, with MySQL kept internal.
3. Install Nginx/Apache + PHP-FPM 8.x + MariaDB.
4. Issue SSL: SSL.
5. Upload the script: installation.

Web server stack: Nginx + PHP-FPM. File permissions: chmod. Cron: cron.

Root vs a hosting panel

Shared hosting protects you and limits you. With root, one mistake in iptables can cut off SSH. Before experimenting with firewall rules, keep the provider console handy (VNC/KVM). A disk snapshot before major updates is cheap insurance.

A control panel on a VPS (ISPmanager and similar) does not replace root; it uses it. But the root password for the panel and SSH should not remain the same "123456" from the provider email after the first login.

Minimum security

• Do not expose phpMyAdmin to the world without a password or VPN.
• Do not listen with MySQL on 0.0.0.0.
• Test backups by restoring them: backup.
• Use fail2ban or an equivalent for SSH.

Moving to a VPS

From local development or shared hosting: files + dump + config. Migration, MySQL migration. After the move, disable cron on the old host.

Local testing before buying a server: MicroServer.

Script support and server administration

A ticket saying "configure the whole VPS for me from scratch" is server administration and not always part of the product SLA. What script maintenance usually includes: SLA. How to report an installation error: support.

The PHP requirements on your node are still the same: requirements. Deployment errors: 500, database.

Root does not mean "break anything"

As root, one mistake in rm -rf or ufw can cause downtime more expensive than any shared hosting plan. A sane workflow is a regular user with sudo for daily work, and root for recovery and initial bootstrap. Back up before an apt upgrade of PHP, not during a Friday production release.

Many VPS images ship with a root password from an email. Change it on the first login. Add an SSH key immediately. If the provider gives only a password, add the key and disable PasswordAuthentication after confirming the key works.

Packages to install

Minimum set for a Microscript script:

• nginx or apache2;
• php-fpm for the required 8.x branch and the mysqli, mbstring, gd, curl, xml, zip extensions;
• mariadb-server or mysql-server;
• certbot;
• fail2ban if needed;
• unzip, git as needed.

Do not install "everything from a 2017 guide" with php5 and mysql-server 5.5. Script archives are not built for that. After installing packages, check php -v and php -m under the same binary that CLI cron will use.

Site user

Create a system user for the project, a home directory with www, and an FPM pool running as that user. Site files should belong to that uid. Then you do not live in a world where everything is 777 and owned by root. Uploads are written by the same user, so there are fewer permission denied surprises.

Deployment by SFTP as this user is cleaner than root login followed by chown. On shared hosting you do not see this model because the panel hides the uid. On a VPS it is your responsibility.

Mail from a VPS

Plain mail() from a dynamic IP often goes to spam. For registration forms and notifications, use SMTP (mail host, SendGrid-class service, or a corporate mailbox). In VPS tickets about "mail not arriving", the cause is almost always IP reputation and missing SPF/DKIM, not a script bug. The script only sends through the configured transport.

When shared hosting is still better

If nobody can answer an alert at three in the morning, shared hosting with provider hardware support is calmer. If you cannot fix a broken apt after a failed update, the same applies. Root makes sense when shared hosting limits already hurt or you need an architecture where you manage Nginx and cron every minute yourself.

Compare again: which hosting. Test the product locally before paying for a year of VPS: MicroServer, installation is here.

First-day checklist on a new VPS

1. Change passwords, add SSH keys, update the OS.
2. Firewall: ports.
3. Nginx + PHP-FPM + database.
4. Create a utf8mb4 database and a user limited to it.
5. Upload the script, set permissions, run the installer.
6. SSL, cron, test file upload, test email.
7. Back up the clean state after installation.

About SSL: manual. About a dump when moving from an old host: MySQL migration. If you get a white screen after the first day, do not reinstall the OS; read the log: 500.

Another root habit: do not keep editing site templates in an interactive root session. Log in, adjust the system, log out. Deploy product code as the site user. This reduces the chance that a new file remains root:root and the admin panel stops writing cache. Permission alignment: chmod. Web stack: Nginx + PHP-FPM. Once the server is live, add external uptime checks: monitoring. A firewall can be "successfully" changed while the site is dead from outside, and otherwise clients will tell you first. Back up after the first successful deploy: backup. Script installation: installation.