How to Set Up a VPS for a Site in India

Most firms in India leave shared hosting the same way. Their first VPS has too little RAM. It has no swap file. It has the stock firewall rules. Then the MySQL pod keeps dying.

This guide skips the theory. It walks through the picks that matter.

When to leave shared hosting.

Shared hosting stops working when you hit one of these.

• PHP-FPM or Node tasks die under traffic spikes.
• Cron jobs run past the 30-second gate.
• You cannot add a package. There is no shell access.
• The data store makes bad calls. tmp_table_size stops at 16 MB.

Do any of those ring a bell? Then a VPS is the right next step.

Sizing the machine.

The plan list at WebHost24 lets you pick a tier. Here is how to think about each part.

vCPU.

One vCPU is one core thread. Here is how it maps to a real site.

• 1 vCPU: fine for a blog or brochure site. It takes under 500 hits a day.
• 2 vCPU: runs a shop site. It takes 1,000-5,000 hits a day. It can have some live pages.
• 4+ vCPU: only for lots of background workers or heavy compute jobs.

More vCPU does not make MySQL queries run faster. It lets requests run at once.

RAM.

RAM is where the failure hits hardest. Here is the rule of thumb. It is for a plain setup with no container control layer.

• 2 GB: WordPress with a cache plugin. MySQL runs too. You get some spare room.
• 4 GB: Node.js API host, PostgreSQL. It is still safe under normal loads.
• 8 GB: any of the above. Add a mail host or a second app.

Always add a swap file. Make it worth half your RAM or more. Linux uses swap for file reads. It does this before it runs out of RAM. With no swap, one big request can kill the OOM killer. It happens at once.

Storage.

Fast local storage only. Spinning disks do not belong in a 2026 web host.

Size for growth. Your data is 2 GB today. You expect 10 GB in a year. Plan for 20 GB. Growing storage on a live VPS often needs a restart.

Bandwidth.

WebHost24 plans come with no traffic cap. This is on the standard tier. For most small firm sites, the plan bandwidth is far more. The site will use much less.

OS and first setup.

Use Ubuntu 24.04 LTS or Debian 12. Both have long support terms. Both have big package lists. Do not use a non-LTS Ubuntu release. Your host must run for over six months.

Run all OS patches first. Add nothing else until they finish.

apt update && apt upgrade -y

Turn on auto patches. Do this if no one watches the machine. We mean by hand, each week.

Firewall.

Each VPS should run a firewall. UFW (Uncomplicated Firewall) ships on Ubuntu.

Deny all traffic that comes in. Let all traffic go out.

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

If you run a mail host, add the SMTP ports. Add them by hand. If you use a custom SSH port, open it first. Do this before you turn on UFW. Or you lock yourself out.

Web host.

For most small firm loads, Nginx is the right choice. It needs less RAM than Apache. It serves static files well.

If you serve PHP (WordPress, Laravel), use PHP-FPM with Nginx. Do not use mod_php. You can tune each PHP-FPM pool on its own. You can set its pm settings (static, dynamic, ondemand). You can set memory caps too.

If you serve a Node.js app, run it behind Nginx. Nginx works as a reverse proxy. This lets Nginx end TLS. Nginx serves static files on its own. It spreads the load across lots of Node processes.

Data store.

Use the managed data plan. Use it if your plan has one. If you run it on the same VPS:

• Set max_connections to a number your RAM can hold. The default of 151 is fine for a small site.
• Turn on the slow query log. Check any query that takes over 1 second.
• Do not use MyISAM. Use InnoDB with innodb_buffer_pool_size. Set it at roughly 70% of your free RAM. This is if the VPS runs it only.

For WordPress, install an object cache (Redis or Memcached) first. Do this before you tune it. The cache fixes more speed problems. It beats any MySQL setting change.

TLS.

Use Let's Encrypt. It is free. It renews on its own. It works for any Indian domain. The certbot package sets up Nginx and Apache files. It does that for you.

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

Set up a cron job. Or use a systemd timer. It renews on time. Let's Encrypt certs expire in 90 days. Certbot installs a renew timer for you. Check that it runs.

systemctl status certbot-renew.timer

Backup plan.

A VPS is not a backup. If the host has a fault, the server itself is gone. You can also ruin it with a bad DROP TABLE.

WebHost24 offers a per-GB backup add-on. Turn it on. Set up a dump each night. Keep it in a separate place.

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

Cut backups older than 7 days. Use a find command in cron.

What not to do.

• Do not add a GUI on the VPS. Each package you add is an attack surface.
• Do not open port 22 to the world. Use an allow list, a VPN, or a jump host for SSH.
• Do not run apps as root. Do this only if you have no other choice.
• Do not skip the swap file because "RAM is enough." It is a safety net, not a speed feature.

Moving from shared hosting.

The path rests on what you are moving. Here are the steps for a WordPress site.

1. Export from the old host using phpMyAdmin or mysqldump.
2. Copy files over SFTP or rsync.
3. Load it on the new VPS.
4. Update wp-config.php with the new login details.
5. Change DNS to point to the new server IP.
6. Test with curl -H "Host: yourdomain.in" http://<new-server-ip>. Do this before the DNS TTL runs out.

Keep the old host active until DNS has spread. Then check the site. Most DNS changes in India spread within 2-4 hours.

For a Node.js app, put it in a container first. Put a Dockerfile in the project root. Add a docker-compose.yml file. They make the move easy to repeat. They also kill the "it worked on my machine" errors.

Getting help.

If the setup feels hard, WebHost24 offers managed plans. We do the upkeep for you. Order now on any plan page. The team is on WhatsApp for questions.