VPS Hosting for Indian Websites: A Configuration Guide

Most Indian businesses that outgrow shared hosting make the same sequence of mistakes on their first VPS: under-provisioning RAM, skipping the swap file, using the default firewall rules, and wondering why the MySQL pod keeps getting killed.

This guide skips the theory and walks through the decisions that actually matter.

When to move off shared hosting

Shared hosting stops working when you hit one of these:

• PHP-FPM or Node processes are being OOM-killed under traffic spikes
• Cron jobs run longer than the 30-second gate allows
• You cannot install a system package because there is no shell access
• The database query planner is making bad decisions because tmp_table_size is capped at 16 MB

If any of those are familiar, a VPS is the right next step.

Sizing the machine

The la-carte model at WebHost24 lets you compose a plan. Here is how to think about each dimension.

vCPU

One vCPU is one physical core thread. For a typical WordPress or Node.js workload:

• 1 vCPU: fine for a blog or brochure site with under 500 daily visitors
• 2 vCPU: handles a business site with 1,000-5,000 daily visitors and some dynamic routes
• 4+ vCPU: only needed when you have concurrent background workers or compute-heavy pipelines

More vCPU does not make MySQL queries run faster. It makes concurrent requests not queue behind each other.

RAM

RAM is where the failure mode is most abrupt. Rule of thumb for a standalone (no container orchestration) setup:

• 2 GB: WordPress with caching plugin, MySQL running, some headroom
• 4 GB: Node.js API server, PostgreSQL, still safe under moderate traffic
• 8 GB: any of the above plus an email server or a second application process

Always add a swap file equal to at least half your RAM. Linux will use swap for buffered filesystem reads before it OOMs. Without swap, a single request that touches more physical memory than exists triggers the OOM killer directly.

Storage

SSD only. NVMe preferred if available on the plan. Spinning disks do not belong in a 2026 web server.

Size for growth. If your database is 2 GB today and you expect to be at 10 GB in a year, provision for 20 GB. Expanding storage on a live VPS usually requires a restart.

Bandwidth

WebHost24 plans are unmetered on the standard tier. For most Indian SMB sites, the plan bandwidth far exceeds what the site will use.

Operating system and initial setup

Use Ubuntu 24.04 LTS or Debian 12. Both have long support windows and large package repositories. Do not use non-LTS Ubuntu releases for a server that is meant to run for more than six months.

Run all OS updates before you install anything else:

apt update && apt upgrade -y

Set up unattended upgrades if the machine is not monitored by a person who will remember to patch it manually every week.

Firewall

Every VPS should be running a firewall. UFW (Uncomplicated Firewall) ships on Ubuntu by default.

Default deny incoming, allow outgoing:

ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow http
ufw allow https
ufw enable

If you are running a mail server, add SMTP ports explicitly. If you are using a custom SSH port, open that port before enabling UFW or you will lock yourself out.

Web server

For most Indian SMB workloads, Nginx is the right choice. It consumes less RAM than Apache and handles static assets efficiently.

If you are serving PHP (WordPress, Laravel), use PHP-FPM with Nginx. Do not use mod_php. PHP-FPM pools can be tuned per-site with different pm settings (static, dynamic, ondemand) and memory ceilings.

If you are serving a Node.js application, run it behind Nginx as a reverse proxy. This lets Nginx terminate TLS, serve static files directly, and load-balance across multiple Node processes.

Database

Use the managed database option if your plan includes it. If you are running the database on the same VPS:

• Set max_connections to something your RAM can support. The default of 151 is fine for a small site.
• Enable the slow query log. Any query taking over 1 second should be examined.
• Do not use MyISAM. Use InnoDB with innodb_buffer_pool_size set to roughly 70% of your available RAM if the VPS is database-only.

For WordPress specifically, install a persistent object cache (Redis or Memcached) before you worry about database tuning. The cache solves more performance problems than any MySQL configuration change.

TLS

Use Let’s Encrypt. It is free, automated, and works for every Indian domain. The certbot package handles Nginx and Apache configs automatically.

apt install certbot python3-certbot-nginx
certbot --nginx -d yourdomain.in

Set up a cron job or systemd timer to renew automatically. Let’s Encrypt certificates expire in 90 days. Certbot installs a renew timer by default; verify it is active:

systemctl status certbot-renew.timer

Backup strategy

A VPS is not a backup. If the hypervisor has a fault or you corrupt data with a bad DROP TABLE, the server itself is gone.

WebHost24 offers an optional per-GB backup addon. Enable it. Additionally, set up a nightly database dump to a separate location:

mysqldump -u root -p --all-databases > /backups/db-$(date +%Y%m%d).sql

Rotate backups older than 7 days with a simple find command in cron.

What not to do

• Do not install a GUI on the VPS. Every package you add is an attack surface.
• Do not open port 22 to the world. Use a specific IP whitelist, a VPN, or a jump host for SSH access.
• Do not run services as root unless there is no other option.
• Do not skip the swap file because “RAM is enough.” It is a safety net, not a performance feature.

Migrating from shared hosting

The migration path depends on what you are moving. For a WordPress site:

1. Export the database from the shared host using phpMyAdmin or mysqldump.
2. Copy files over SFTP or rsync.
3. Import the database on the new VPS.
4. Update wp-config.php with the new database credentials.
5. Change DNS to point to the new server IP.
6. Test with curl -H "Host: yourdomain.in" http://<new-server-ip> before the DNS TTL expires.

Keep the old hosting active until DNS has fully propagated and you have verified the site works on the new server. Most DNS changes in India propagate within 2-4 hours.

For a Node.js application, containerize it first. A Dockerfile in the project root and a docker-compose.yml file make the migration repeatable and eliminate the “it worked on my machine” class of failures.

Getting help

If the configuration feels complex, WebHost24 offers managed hosting plans where the server maintenance is handled for you. The WhatsApp CTA on any plan page connects you to the team directly.