Hosting a small store: shared, VPS or managed?

Hosting is usually chosen against average traffic and tested by peak traffic, which is why stores fall over on the days they can least afford to. The moment that matters is a festival sale, a mention by somebody with an audience, or a broadcast message that lands with a few thousand people simultaneously. Average monthly visitors tells you almost nothing about whether the site survives that.

A store is also considerably more expensive to serve per visitor than a brochure site, and for a structural reason. A static page can be cached and served identically to everybody. A cart, a checkout and a logged-in account page are unique per visitor and have to be generated on request, hitting the application and the database every time. So the pages that matter most commercially are precisely the ones that caching cannot rescue.

The practical consequence is that a plan comfortably serving your homepage can still collapse at checkout under load, and the homepage is what everybody tests. When assessing a plan, ask what happens to concurrent dynamic requests, not what the bandwidth allowance is.

Shared hosting puts many sites on one server and divides its resources between them. At a few hundred rupees a month it is genuinely the right answer for a brochure site and a defensible starting point for a store in its first months, when order volume is low and the alternative is spending money you have not yet earned.

The limitation is that you share processor time, memory and disk throughput with neighbours whose traffic you do not control. Somebody else's busy morning becomes your slow checkout, and there is nothing you can do about it from your side.

The marketing language deserves translation. 'Unlimited bandwidth' is bounded by a fair-use clause, and in practice you are throttled by processor and memory limits long before any bandwidth figure becomes relevant — the resource that actually runs out is the one not advertised as unlimited. 'Unlimited websites' has the same character.

The failure mode is not choosing shared hosting. It is staying on it through a planned sale, having never tested what happens when the concurrency arrives.

A virtual private server gives you a defined allocation of resources that neighbours cannot consume, and root access to configure whatever stack you want. For a store that has outgrown shared hosting and has specific requirements, it is the natural next step.

It also transfers a list of responsibilities that were previously somebody else's: operating system updates, security patching, firewall configuration, certificate renewal, database tuning, backups, monitoring, and being the person who gets woken up when it stops responding.

The expensive version of this mistake is an unmanaged VPS bought by a business with nobody who is comfortable on a command line. The saving over managed hosting is real and modest; the cost of an emergency contractor at 11pm during a sale is neither. If nobody in the business wants to own that work, the honest position is that a VPS is more expensive rather than cheaper, because the labour is real whether or not it is invoiced.

Managed VPS plans exist precisely for this gap: dedicated resources with the operating system, patching and backups handled by the provider, at a price between the two.

Managed hosting for a specific platform — most commonly WordPress with WooCommerce — is worth understanding in terms of what is and is not included, because the word 'managed' is doing a lot of work.

Typically included: platform and core updates, caching already tuned for that software, a staging environment, automated backups with a restore path, platform-specific security rules, and support staff who know the stack rather than reading a generic script.

Typically not included: the consequences of your own choices. A theme doing something expensive on every page load, a dozen plugins each adding queries, and unoptimised product images are all still your problem, and no amount of server management compensates for them.

Two commercial details to check before signing. Many plans are priced by monthly visits or orders, so read what happens when you exceed the allowance — whether it is an overage charge, a forced upgrade, or throttling. And check whether the caching layer handles your cart and checkout correctly, since aggressive caching applied to dynamic pages produces the memorable bug where one customer sees another's basket.

Physical distance is latency that no amount of optimisation removes. A request travelling to a server on another continent and back pays that round trip on every uncacheable interaction, and a checkout involves several.

For a business whose customers are predominantly in India, an origin server in India is a real and measurable advantage, and the benefit lands specifically on the dynamic pages that matter most — cart, checkout, account, search. This is the part people get backwards: they add a content delivery network and expect it to solve everything.

A CDN serves cached copies of static assets from locations near the visitor, which genuinely helps images, stylesheets and scripts. It does not serve a personalised cart, because that response has to be generated by your origin. So the two are complementary rather than substitutes: put the origin near your customers, and use a CDN for the assets.

When comparing providers, ask which city the server is actually in rather than accepting 'we have Indian infrastructure', and test it — a simple timing check from a connection in your main market is more informative than any claim on a features page.

Uptime commitments are easier to read once converted into time. A 99.9% commitment permits roughly 43 minutes of downtime a month. A 99.99% commitment permits roughly 4.3 minutes. The difference between those two numbers looks cosmetic written as percentages and is an order of magnitude in practice.

What the commitment is worth is a separate question. The remedy is almost always a service credit proportional to the outage — a refund of a fraction of your monthly fee. If the outage falls on your busiest sale day, that credit does not begin to cover the lost orders. So treat the figure as a statement of the provider's engineering expectations rather than as insurance, and ask two follow-up questions: how is uptime measured, and is planned maintenance excluded from it? Frequently it is.

Backups deserve more attention than uptime and get less. Ask about frequency, retention period, whether backups are stored somewhere separate from the server, and whether you can restore yourself without raising a ticket.

Then actually restore one, to a staging site, and time it. An untested backup is a hypothesis, and the day you discover it does not work is the day you needed it.