VPS, Shared Hosting or a Managed Platform?
9 min read
"I need a company website. Which kind of hosting should I buy?" has no standard answer, because the three mainstream options are selling different things. Shared hosting sells cheapness, a VPS sells control, and a managed platform sells not having to think about it. The monthly figure on the price list is only part of the total, and the real differences hide in who does the maintenance, who is responsible when something breaks, and how painful it will be in three years when you want out. What follows takes the view of a small company or an independent contractor and lays out the differences, the cost structure, the security responsibilities and the cost of moving. By the end you should at least know which category you are in, rather than being steered by a sales pitch.
1. What each option actually is
Shared hosting splits one physical server between anything from dozens to hundreds of accounts, all drawing on the same processing capacity and the same disk throughput. You normally work through a control panel such as cPanel, and what you get is a directory and a database. The operating system is out of reach.
A VPS is a machine of its own carved out of a larger one, with the highest level of access in your hands. The operating system is yours to decide from top to bottom: which software gets installed, which PHP version runs, how scheduled jobs and firewall rules are set.
Managed platform covers a wide spread of services, from wordpress.com and the one-click install plans hosts offer, through to static hosting like Cloudflare Pages and Netlify. What they share is that the platform absorbs everything underneath, leaving you the content and the publishing.
| Option | What you actually get | Who does the maintenance | Who it suits |
|---|---|---|---|
| Shared hosting | A directory and a database, worked through a control panel | The host looks after the operating system, you look after the site | Low-traffic brochure sites and blogs where budget comes first |
| VPS | Full access to a whole machine, with resources allotted to you | Everything above the hardware is yours | Stores, membership sites, anything needing custom work or specific software |
| Managed WordPress | One admin interface; updates, caching and backups handled by the platform | The platform runs the lower layers, and plugins and settings are often restricted to an allowlist | People who do not want to touch the technical side and will pay monthly to avoid it |
| Static hosting | Upload files and they are live; no PHP, no database | The platform handles all of it | Pure content sites, or static pages generated by a front-end framework |
Ask yourself one question before choosing: does your website need to run code, or only to serve files? A site that only serves files can be hosted statically for close to nothing. Sites that run code and need a database are the ones the rest of this applies to.
2. The differences that matter: control, resources, maintenance, lock-in
Set the three side by side and the differences concentrate in four places. First, control: shared hosting gives you a directory, a VPS gives you a machine, a managed platform gives you an interface. Second, resources: on shared hosting compute is contended, so when the site next door gets a traffic spike you slow down with it. A VPS has a defined allocation, while managed platforms usually price on requests or bandwidth.
Third is whether you can install your own software, which is where people get caught out. If you want to run something other than WordPress, or stand up your own caching or background service, nothing except a VPS will usually allow it, and this tends to be discovered after signing. The reverse holds too: an ordinary WordPress content site with no custom back end is well served by shared hosting or a managed platform.
Fourth is who does the maintenance, and it runs inversely to control. The more you are allowed to change, the more you have to look after. There is no exception to that and no middle path. Choosing a VPS means taking on the system administration job.
3. Price bands and hidden costs
The headline gap looks enormous and the real total narrows it considerably. The figures below are in New Taiwan dollars (NT$), which is what these services are billed in locally. Shared hosting commonly sits between a few hundred and a few thousand NT$ a year, led by a discounted first year. Entry-level VPS plans usually start from a few hundred NT$ a month and climb with the specification. Managed WordPress platforms commonly run from several hundred to several thousand NT$ a month, tiered by site count and traffic.
What really needs counting is everything after that. Renewal price rises are routine, and plans that cost NT$1,000 for the first year and NT$3,000 for the second are everywhere. Backups and SSL are sometimes billed separately. Going over a traffic or request allowance costs extra. And when the host recommends an upgrade, find out what the difference in price will be before you need it.
The hidden cost on a VPS is people. Somebody has to understand system updates, restores and basic hardening, and if that time is not yours it is somebody you are paying. Either way it is a cost. Compare on total spend across a year rather than the monthly fee, and the ranking of the three options often comes out differently from what you assumed.
4. Estimating traffic and performance: look at caching first
Most people estimate traffic by guessing at monthly page views, and that number helps very little with the choice. The more useful question is what proportion of your pages can be served from a full-page cache.
A content site with no logins and no shopping basket, behind a caching plugin or a CDN, leaves the server handling only a small share of requests, and shared hosting copes fine. Member areas, baskets, checkout and admin searches all bypass the cache. Every one of those requests runs code and hits the database, and that is the part that genuinely consumes resources.
So sort your pages first: fully cacheable (home page, articles, product listings) against must-be-live (logged in, basket, checkout). Then estimate peak concurrent visitors rather than monthly totals. Two hours of traffic from a live shopping stream is far harder to carry than the same volume spread evenly across a month.
If you have a lot of images or video, look at a CDN or object storage before trying to push that bandwidth through the server. Once you are live, measured data beats guesswork: the compute usage, memory usage and slow query log on the hosting panel will tell you whether what you bought is enough. Membership sites, stores, and anything that needs scheduled jobs and outbound mail should be assessed starting from a VPS or a higher managed tier.
5. Where the security responsibility divides
The three options carry different shapes of risk. On shared hosting your neighbours affect you: if somebody on the same machine is compromised or sends bulk spam, the shared IP can end up on a blocklist and your mail stops arriving. The machine's resources can be consumed as well. How well accounts are isolated depends on the host, and you can neither see it nor control it.
A VPS hands you the operating system, which means remote login hardening, the firewall, system updates, backups and restore rehearsals all become your work. A VPS with nobody doing those things can be less secure than a well-kept shared account. A managed platform handles the lower layers and the core updates for you, and the price is a narrow range of movement: if you need a custom firewall rule or a particular security plugin, you get stuck.
Each option therefore has its own homework. On shared hosting, ask whether accounts are permission-isolated, whether a dedicated IP can be added, and whether outbound mail goes through a separate channel. On a VPS, at minimum: key-based login instead of passwords, a firewall open only on the ports you need, automatic security updates, and regular off-site backups. On a managed platform, ask which plugins are blocked, whether there is an application firewall, and what the process and recovery time commitment are after a compromise.
| This layer | Shared hosting | VPS | Managed platform |
|---|---|---|---|
| OS and service updates | The host | You | The platform |
| Firewall and login hardening | The host, with no visibility for you | You, and it needs checking regularly | The platform, usually not customisable |
| Backup and restore | Depends on the plan, often billed separately | You, including verifying the restore works | The platform, but ask how many copies are kept |
| WordPress core and plugin updates | You | You | The platform, though plugins may be restricted |
| Admin credentials and two-factor | You | You | You |
The last two rows are the point: whichever hosting you buy, the application layer is always yours. Plugin updates, weak passwords and two-factor authentication on the admin panel are not something any host finishes for you. Remember too that a backup only counts once it has been restored successfully, so put a restore rehearsal in the calendar at least once a year.
6. Migrating later: today's decision reaches three years out
How hard a move is depends on how much of your site is tied to the platform. For a standard WordPress site, the database plus the site files is the whole estate, and changing host is usually half a day to a couple of days, with most of the effort going into the domain settings and the checks afterwards.
The hard cases are sites built on platform-specific features: a proprietary page builder, proprietary image URLs, the platform domain written into the article text, or content in a format with no export at all. Moving between shared hosts is comparatively simple. Going from shared hosting up to a VPS means rebuilding the whole environment, meaning web server, PHP, database, certificates and scheduled jobs, and that step usually needs somebody who knows how. Getting out of a managed platform is the luck of the draw: some export everything cleanly, others hand you a partial archive.
Four things to do before you sign
- Run an exit test. Try exporting the full database and files, and see whether what you get will run somewhere else. A platform that exports incompletely is the one that will hold you later.
- Keep the domain settings under your own control. Hold them somewhere you manage, rather than locked inside a host's control panel.
- Use different companies for the registrar and the hosting. Then changing host does not mean moving the domain as well.
- Plan the downtime in advance. Stores and membership sites need a maintenance window and a freeze on orders; a pure content site can be switched straight over. Shorten the propagation time on the domain settings before the move so the old and new sites do not both stay live for long.
7. How to choose: match yourself to a situation
The sections above reduce to a handful of concrete situations. For most small companies in Taiwan, the first website falls into one of the first two lines. Growing into the next tier once the business demands it is cheaper than buying a big machine on day one. If you already know you need a custom back end, or the limits of your current host are actively blocking you, go straight to a VPS. The options in between are just a detour.
Find the line that describes you
- Brochure site or blog, budget first. At a few thousand to a few tens of thousands of views a month, shared hosting or an entry managed plan is enough.
- Pure content site generated by a front-end framework, no back-end forms. Static hosting plus a form service is the cheapest thing available.
- A WordPress content site and no wish to touch the technical side. Pay monthly for managed WordPress and buy the quiet life.
- A store, a membership system, custom features or integration with outside systems. Choose a VPS, and confirm somebody is responsible for maintaining it.
- Software your host does not offer, or a firm performance requirement. Only a VPS does that. There is no other option.
- Already blocked by your current host. Plugins that will not install, a sluggish admin panel, overage charges arriving repeatedly: work out the cost of moving, because it is almost always cheaper the sooner you do it.
- A VPS with nobody who understands maintenance. Outsource the maintenance, or step back to a managed plan. Do not leave the machine running unattended.
There is no universal answer to hosting. There is only the answer that matches your current size, technical capacity and budget. Shared hosting is cheap and restricted, a VPS is flexible and needs an owner, a managed platform is easy and narrow, and each fits a different stage. Before you decide, settle two things: whether you can take your content out intact, and who handles it when something goes wrong.
Common questions
- Is a VPS overkill for a small company's first website?
- For a brochure site or a blog, shared hosting or a managed plan is usually plenty, with a low monthly cost and no system updates to worry about. The value of a VPS is control and room to grow, and it assumes somebody will spend time on maintenance, meaning updates, backups and hardening. Without that person, a VPS can end up less secure and less stable than a managed plan. Upgrade when you have custom requirements, or when the current plan starts getting in the way.
- Do other sites on the same shared server really affect mine?
- Yes, in two ways. On resources, a neighbour suddenly consuming a lot of compute or disk throughput slows your site down, which is more common on the cheapest plans. On reputation, if the shared IP gets blocklisted because somebody else sent spam, your notification and order emails can be blocked. Most hosts isolate accounts well enough that direct cross-site compromise is rare, but the knock-on effects on resources and IP reputation are real.
- How much work is moving from a managed platform to a VPS?
- It depends on the complexity of the site and how well the platform exports. For a standard WordPress content site, building the environment plus moving the data and switching DNS is typically one to two working days. A store or a site with custom features adds testing and downtime planning on top. What actually eats the time is replacing platform-specific features, for example rebuilding layouts produced by a proprietary editor. Run a full export test first and confirm you can get your data out before agreeing a schedule.