Shared hosting, VPS or Node.js hosting: how to choose for a business website

Choosing hosting is usually decided by price and by whatever a friend used. That works until the site needs something the plan does not allow, or until something breaks and nobody is responsible for fixing it. These are the questions we ask first. Plans and prices change often, so check the current terms of any provider you consider.

Start with what the site is built on

The technology decides which kinds of hosting can run it at all:

• A WordPress or PHP site runs on ordinary shared hosting, which is built for exactly that.
• A Node.js application (for example a Next.js site with a dashboard) needs hosting that keeps a program running all the time. Ordinary shared hosting cannot do that.
• A static site with no dashboard and no forms can live almost anywhere, including very cheap storage.

If you are unsure, ask whoever built the site what it runs on. Do not guess from the price.

The four common options

Shared hosting. Many sites on one server, managed by the provider. It is inexpensive and needs little knowledge, and it is the right answer for many small PHP sites. The limits are shared resources, restricted settings and little control over the server.

Managed Node.js hosting. A shared plan that can also run a Node.js application, with a control panel to upload code, set environment variables and restart it. It suits small and medium business sites with a database. You do not manage the operating system, but there are limits to learn: memory, the number of database connections, and how the host builds your application.

A virtual private server (VPS). Your own slice of a server, with full control. It suits applications with unusual needs and teams who can maintain a server: updating the system, securing it, monitoring it and backing it up. All of that is now your job, or the job of someone you pay.

A managed platform. A service that builds and runs your code for you, often with automatic scaling. It reduces server work but changes how you deploy and how costs grow, so read the pricing carefully for a site with steady traffic.

Limits to check before you buy

• Memory and processor allowance, and what happens when you reach them.
• Database limits: how many connections at once, and any cap on new connections per hour. A pool that reopens connections too often can hit it.
• Backups: how often, how long they are kept, and whether you can restore one yourself. Do not rely on the provider's copy alone.
• Access: whether you get a terminal, or only a control panel and file upload.
• Email: sending limits, and whether messages from your domain reach inboxes.
• Support: when it is available, in which language, and whether it covers your application or only the server.
• Location and speed for the people who use the site.

Think about who looks after it

The most overlooked question is not technical. Somebody must update the software, watch for problems, restore a backup and answer when the site is down at an inconvenient time. If that person is you, choose the option you can actually maintain. If it is a supplier, get it in writing: what is covered, how fast they respond and what you receive if you leave.

A simple way to decide

1. Write down what the site runs on and what it must do.
2. List the limits that would hurt you (database, memory, email).
3. Choose the least complicated option that meets them.
4. Plan the backup and the restore test before launch.
5. Revisit the choice when traffic or needs change, not before.

If you would like a second opinion on a plan you are considering, tell us about the site and we will say plainly whether it fits. Our own notes on running applications on shared Node.js hosting are in the article on deploying Next.js on Hostinger.