The Droplet Nobody Owned: A Hong Kong Consumer Brand's Storefront Hosting Problem

Short answer: The meaningful split in cloud hosting is not cloud versus on-premises — it is managed versus unmanaged. A US$11-per-month server bill is not the cost of hosting. The cost is who does provisioning, migration, patching, monitoring, backup and restore testing, and whether that person answers a ticket at 9pm.

The web agency that built the storefront closed in 2023. Nobody at the company noticed at the time, because the site kept working.

This is a composite scenario, not a named client, but the shape of it will be familiar to a lot of Hong Kong consumer brands. Call it a housewares and personal-care label with somewhere between forty and eighty staff, a main Magento 2 storefront, and a WooCommerce microsite for a sub-brand that was launched as an experiment and then quietly became ten per cent of revenue. Both run on a single virtual machine bought years ago on someone's corporate card.

The e-commerce manager inherited the relationship and has never met anyone who worked at the agency. The hosting account is in the name of a marketing coordinator who left in 2024. The last time anyone logged into the server directly was to change a banner image before Chinese New Year, and it took two days to find someone who knew how.

Nothing is on fire. That is the problem — it makes this very easy to keep postponing.

The industry: when the storefront is real revenue and nobody owns the infrastructure

Mid-size Hong Kong consumer brands sit in a specific and fairly common gap. The storefront is genuinely commercial — it takes orders, it holds customer data, it carries the brand — but the company is not big enough to justify an in-house web infrastructure person, and never has been. The result is that the hosting decision was made once, by somebody else, a long time ago, and has never been revisited because revisiting it has never been anyone's job.

What makes it distinctive rather than just small is the mix of stacks. A Magento 2 install and a WooCommerce install are different animals with different upgrade rhythms, different plugin ecosystems and different failure modes, and a company this size usually ends up with both because the second one was added by a different agency in a different year for a different reason. Neither was ever consolidated, because consolidating them was never urgent.

Meanwhile the operational reality is retail: traffic is seasonal, promotions are calendar-driven, and the periods when the site matters most are precisely the periods when nobody wants to touch it.

The scenario: an unmanaged VPS with an unknown patch state

Here is what an audit of this arrangement actually turns up, and none of it is unusual.

Nobody knows the patch state. The PHP version is whatever it was when the agency set it up, plus whatever automatic updates the operating system applied without anyone reading the log. Nobody can say with confidence when the last security update was applied, or whether it was applied to the operating system, the web server, the PHP runtime, the database, or any of them.

The "backup" is a snapshot nobody has ever restored. The hosting provider offers snapshots and the box is ticked. Whether a snapshot from this configuration can actually be restored into a working storefront, with the database consistent and the media library intact, has never been tested. A backup that has never been restored is a belief, not a backup.

The support path ends at the hardware layer. The hosting provider is contractually responsible for the virtual machine being powered on and reachable. They are explicitly not responsible for Magento throwing a 500, for a plugin conflict after an update, for the checkout failing on a specific payment method, or for the site being slow. For everything above the hypervisor, the support path ends at a status page.

The credentials are archaeological. Root access exists somewhere. There is an SSH key on a laptop that was reimaged. There is a control-panel login that goes to a departed employee's mailbox. Recovering access is a project in itself, and it is the project that always happens under pressure, on the day something breaks.

Nobody owns the gap. This is the underlying point. There is a gap between "the server is up" and "the store takes orders," and in this arrangement no party has agreed to stand in it. The hosting provider owns the first. The brand assumes the agency owned the second. The agency no longer exists.

What this costs, in the ways that do not appear on an invoice

Version drift turns maintenance into a project. PHP and plugin versions do not stay still; support for them expires whether or not anyone is watching. Deferred long enough, what would have been a routine minor upgrade becomes a migration with a compatibility matrix, a test plan and a budget — and it arrives on a schedule set by an end-of-life date rather than by the business.

Cost looks cheap on the invoice and expensive in incident hours. The monthly platform bill is small and visible. The hours spent by a marketing manager, an operations lead and an external freelancer trying to work out why the checkout is failing on a Saturday are large and invisible, because they are never booked against hosting.

There is no audit trail. Who changed what, when, and why is not recorded anywhere, because there is no change process — there is only access. For a consumer brand holding customer data, that is not merely untidy. When someone eventually asks how personal data on that server is protected and who can reach it, "we are not sure" is a genuinely bad answer.

Risk is concentrated where it is least visible. Two revenue-carrying storefronts on one unmanaged machine is a single point of failure that has been quietly load-bearing for years.

The bus factor is one, and that one person is external and gone. Every arrangement like this has a keystone — a person who knows how the cron jobs are wired, which plugin handles the shipping-rate lookup, why the staging subdomain still resolves. When that person was an agency employee and the agency has closed, the keystone is not merely unavailable, it is unidentifiable. There is nobody to call and no successor to call instead. This is the difference between a risk you can mitigate by picking up the phone and a risk you can only mitigate by rediscovery.

It is worth being precise about why this persists rather than treating it as negligence. None of the four problems above produce a visible symptom until the day they produce a severe one. Version drift is invisible until an upgrade fails. An untested backup is indistinguishable from a good backup until you need it. Missing ownership of the gap is invisible on every day the site happens to work. The arrangement is stable in exactly the way that makes it hard to justify spending money on — right up until it isn't.

How we think about it: managed versus unmanaged is the real decision

There is a long-running argument in this space about cloud versus on-premises, and for a company like this it is largely beside the point. Both storefronts are already on a cloud virtual machine. The question was settled years ago by an agency and nobody has proposed moving them into a cupboard.

The decision that actually matters is managed versus unmanaged — and it is a decision about labour and accountability, not about infrastructure.

Consider the numbers, which are public and checkable. On the Cloudways platform, a 1 GB / 1 vCPU DigitalOcean Standard server with 25 GB of storage and 1 TB of bandwidth lists at US$11 per month. Step up and it is US$26 for 2 GB, US$50 for 4 GB with 2 vCPU and 80 GB of storage, and US$88 for 8 GB with 4 vCPU and 160 GB. Those are real figures, observed as public Cloudways list prices on 19 August 2026.

Now notice what that number is and is not. It is the cost of the machine. It is not the cost of provisioning it correctly, migrating two live storefronts onto it without losing orders, keeping PHP and the stack patched, watching it when nobody is looking, backing it up, and — the part that is almost always skipped — periodically proving that the backup restores.

That work is the actual hosting cost. In the arrangement described above it is not priced anywhere, which is not the same as it being free. It is being paid for in deferred upgrades, in incident hours, and in risk.

Our second view is about where hosting belongs organisationally. A storefront server is not a special category of thing. It needs patching on a cadence, monitoring with somewhere for the alert to go, a tested restore, and a record of who changed what — which is exactly what every endpoint and every server in a managed IT plan already gets. Buying hosting as a separately-managed island means maintaining a second, weaker version of disciplines the company is already paying for elsewhere. It is usually simpler and cheaper to put it inside the same plan, with the same audit trail and the same escalation path, than to run it as its own little world with its own little vendor relationship.

What the numbers actually look like

If you are comparing options, three things are worth understanding about the pricing.

Entry price is not comparable across providers. On the same managed platform you can run DigitalOcean Standard from US$11, DigitalOcean Premium on NVMe from US$14, Linode from US$12, Vultr from US$14, Google Compute Engine from about US$33.30 and AWS from about US$36.51. Those last two look much more expensive, and in an important respect the comparison is unfair in the other direction: their bandwidth is metered on demand rather than bundled into the plan. A cheap plan with 1 TB included and an expensive plan with metered transfer are not the same product, and a promotional traffic spike is exactly when that difference shows up on a bill.

The stack matters more than the badge. The managed platform supports WordPress and WooCommerce, Magento 2, Laravel, Joomla, Drupal, and custom PHP applications on PHP 7.4 through 8.4. For the company in this scenario that is the relevant fact: both storefronts, on different stacks, can sit on one managed platform with one operational model rather than two.

Platform price and management price are separate lines. The figures above are the platform's public list prices. Brocent's provisioning, migration, patching, monitoring, backup and support are quoted separately on top of them. We are deliberate about presenting it that way — a bundled "from US$X per month, fully managed" number sounds cleaner and tells you less, because it hides which half of the cost is the machine and which half is the work.

One more honest note. We do not claim the hosting is Hong Kong-hosted, and we do not name a region, because the underlying provider region is your choice rather than a property of the service. If data residency matters to you — and for some consumer brands with mainland customers it genuinely does — that is a design conversation, not a plan tier.

Three ways to run a storefront server

Unmanaged VPS bought direct

• The cheapest line item and by far the most expensive total, because the labour is unpriced rather than absent.
• Support scope ends at the virtual machine. Anything above the operating system is yours.
• Patching happens when someone remembers; version drift accumulates silently until an end-of-life date forces a project.
• Backups exist as snapshots; restore capability is assumed rather than demonstrated.
• Works well for a genuinely technical team who have chosen this deliberately. Works badly as an inheritance.

Agency-managed hosting

• Usually a real improvement on unmanaged, and often a perfectly good arrangement while it lasts.
• The agency owns the relationship, which is convenient right up until the agency's priorities change, its team turns over, or it closes. Then the knowledge and often the credentials go with it.
• Hosting is typically bundled into a retainer alongside design and campaign work, which makes it hard to see what you are paying for infrastructure and easy for maintenance to be quietly deprioritised against creative deadlines.
• Cadence depends on the agency's discipline rather than on a defined standard — and the same agency that is excellent at build quality may have no patch schedule at all.

Managed hosting inside the IT plan (the Brocent model)

• Provisioning, migration, patching, monitoring, backup and support are a defined scope with an owner, not a favour.
• The platform bill and the management fee are separate, visible lines, so you can see what you are actually buying.
• The same escalation path, ticketing and audit trail that already cover endpoints and servers cover the storefront too.
• Both stacks — Magento 2 and WooCommerce — run on one managed platform under one operational model.
• The trade-off, stated plainly: it costs more per month than an unmanaged box, and the case for it rests on the incident hours and deferred-upgrade risk it removes, which are real but harder to put on an invoice than US$11.

What a migration off an inherited server actually involves

Briefly, because this is usually the real anxiety rather than the pricing.

The first step is not migration, it is discovery: establishing what is actually running — stack versions, plugin and extension inventory, cron jobs, integrations, payment gateways, DNS, mail flow, TLS certificates and where each one is administered. On an inherited server this often takes longer than the migration and is where the surprises live.

The second is access recovery, which on a server like this is frequently the hardest single task, and which is far better done calmly now than urgently later.

Then the move itself: staged onto the new platform, tested against a real checkout flow rather than a homepage load, and cut over by DNS at a low-traffic window with the old environment left running until the new one has proven itself through a full order cycle.

And afterwards, the part that is the actual product: a patch cadence, monitoring with a defined escalation path, backups with a tested restore, and a change record.

It is worth setting expectations on effort honestly. Discovery on an inherited server with two stacks is typically the largest single unknown, because the scope of it is determined by what the previous owners did rather than by anything you can specify in advance. A migration where everything is documented and credentials are in hand is a straightforward piece of work. A migration where the starting point is a machine and a guess is a different size of job, and any provider who quotes the second as though it were the first has not looked at it properly.

The other thing worth deciding up front is whether the two storefronts stay on separate application installs. Consolidating a Magento 2 site and a WooCommerce microsite onto one managed platform does not mean merging them into one application — it means one operational model, one patch cadence, one monitoring configuration and one place where the alert goes, rather than two half-owned arrangements. That is the consolidation worth having, and it is achievable without touching either storefront's front end.

Frequently asked questions

What does "managed" actually include that unmanaged hosting doesn't?

Provisioning the environment correctly, migrating existing applications onto it, patching the stack on a cadence, monitoring it with somewhere for alerts to go, taking backups and testing that they restore, and providing a support path for problems above the operating system. Unmanaged hosting gives you a machine that is powered on and reachable. Everything listed above is yours.

Is US$11 a month really the cost?

That is the real, current public list price of a 1 GB DigitalOcean Standard server on the Cloudways platform, observed 19 August 2026. It is the cost of the server. It is not the cost of hosting, because it does not include any of the work described above — Brocent's management, migration and support are quoted separately, and platform prices are set by the vendor and can change.

Can you migrate an existing Magento or WooCommerce site without downtime?

Migration is planned to minimise disruption rather than to promise zero seconds of it, and anyone promising literally zero downtime on a live storefront with payment integrations is overselling. The practical approach is to stage the site on the new platform, test a real order end to end, cut over DNS at a low-traffic window, and keep the old environment available until the new one has handled a full order cycle. Most of the risk in these projects sits in integrations and payment gateways, not in moving files.

Who patches PHP and the plugins?

On a managed plan, that is the point of the plan: patching is part of the defined scope on an agreed cadence, with application-level updates coordinated rather than applied blindly. On an unmanaged server it is whoever remembers, which in practice is nobody until something breaks.

What happens when traffic spikes during a sale?

On a standard plan, a spike is handled by having provisioned for headroom and by monitoring that tells you early, and if the plan is genuinely undersized the answer is to resize — which is a decision someone has to make and execute. For WordPress and WooCommerce specifically there is an autoscaling option (Cloudways Autonomous) built for exactly this; every other stack, Magento 2 included, runs on the standard Flexible plans. If your spikes are severe and predictable, that difference is worth designing around before the campaign, not during it.

Do you host in Hong Kong?

We do not make a location claim, because the underlying cloud provider and region are chosen per deployment rather than fixed by the service. If data residency is a requirement for you, raise it early — it shapes the provider and region choice, and it is a design question rather than a plan tier.

What if we already have a hosting provider we're happy with?

Then the useful question is narrower: who is accountable for patching, monitoring, backup and restore testing on that arrangement, and can they name the last time a restore was tested? If those have clear owners, you likely do not have a hosting problem. If the honest answer is that the provider owns the machine and nobody owns the rest, the gap is the thing to fix, and it does not necessarily require changing providers.

Where this fits

For most companies in this position, hosting is not worth solving as a standalone procurement. It is one component of the question of who runs the company's IT, with what cadence, and against what record — which is the question our managed IT support plans and pricing exist to answer. Hosting is one of the things a plan can carry, alongside endpoints, servers, backup and the helpdesk, on the same audit trail.

The detailed platform tiers, provider options, add-ons and supported stacks are set out on the cloud hosting and application services page, and the wider architecture and migration side — multi-cloud design, cloud migration strategy — sits under cloud solutions and managed IT cloud services.

If your own storefront is running on a machine nobody has logged into since the last banner change, the first useful step is small: find out what is actually on it. Talk to us and we will start there.