BONSAIHOST Bonsai Hosting ltd sells hosted capacity that still depends on racks, transit and repair windows

Summary

• BONSAIHOST Bonsai Hosting ltd is not just a trading name in a search result. Companies House lists BONSAI HOSTING LTD as an active private limited company incorporated on 30 March 2021 with SIC 63110, and RIPE lists Bonsai Hosting ltd as ORG-BHL13-RIPE, a GB local internet registry tied to company number 13303584.
• The strongest public operating evidence is network evidence. RIPEstat's AS overview marks AS204928 as announced, while announced-prefix data showed three IPv4 /24s and one IPv6 /32 visible on 11 July 2026.
• The service footprint is still thinly documented. The RIPE aut-num shows declared imports from Hetzner and Global Secure Layer, but RIPEstat routing consistency also showed observed neighbours that were not in the registry entity. That is normal enough in BGP, but it means public data cannot prove contract diversity.
• A live Bonsai panel and a public EnviroMC customer document tie the name to bare-metal and colocation control surfaces, but they do not prove rack ownership, support staffing, spare-parts depth, or customer migration guarantees.
• The evidence grade is Medium for the network and Weak for the facility/support boundary. Bonsai looks active and routable; it does not yet look transparent enough for a customer to rely on marketing language without testing restore paths, transit failover, billing continuity and data portability.

The visible company is smaller than the service promise

The first thing to get right about BONSAIHOST Bonsai Hosting ltd is that the company is not imaginary. The Companies House overview lists BONSAI HOSTING LTD, company number 13303584, as active, incorporated on 30 March 2021, registered at Unit 10, 80 Lytham Road, Fulwood, Preston, and classified under "Data processing, hosting and related activities." That is the correct corporate class for a company selling hosting, virtual machines, bare-metal capacity, or related managed infrastructure.

The same public record also limits what can be inferred. Companies House is a legal filing service, not an engineering audit. It can tell a reader that a company exists, that its officers filed accounts and confirmation statements, and that its stated business activity fits hosting. It cannot tell a customer whether a physical server is powered, whether a network card has a spare on site, whether a cross-connect is diverse, whether the support desk has round-the-clock authority to touch the system, or whether an export of customer data can be produced while the main platform is degraded.

That distinction matters because the words "hosting" and "cloud" often flatten physical risk. A customer sees a control panel, a monthly invoice, an IP address and an uptime claim. Behind that interface sit cabinets, routers, disks, optics, power feeds, contracts, remote hands and people. The public record for Bonsai proves enough to justify scrutiny, but not enough to outsource judgment.

Corporate filings also describe a very small operating base. The officers page lists Benjamin Edward Woods as the sole officer, appointed on the incorporation date, and the persons with significant control page lists the same person as having at least 75% of shares and voting rights and the right to appoint or remove directors. That is not a criticism. Many small hosting businesses begin as tightly held technical businesses. It is, however, a concentration signal. If technical control, customer escalation, financial control and registry administration depend on a narrow team, customers need to test how the service works when that team is asleep, unavailable, travelling, or handling multiple incidents.

The filings reinforce the small-scale reading. The filing history shows micro-company accounts for the years ended 31 March 2024 and 31 March 2025, confirmation statements, and earlier full accounts. The 2022 and 2023 accounts disclosed turnover and hardware-like assets; later micro-entity accounts disclose much less operating detail. The 2023 statutory accounts showed turnover of GBP 69,098, tangible plant and machinery with a net book value of GBP 40,000, and one average employee. The 2025 micro accounts showed one average employee again, current assets of GBP 23,160, creditors due within one year of GBP 10,182, and capital and reserves of GBP 12,978. These are not bad numbers by themselves. They are just numbers that do not look like a large multi-site cloud provider with deep disclosed reserves, stocked depots and visible operational separation.

There is also filing-history friction to treat carefully. Companies House records first-gazette compulsory strike-off actions in 2022, 2024 and 2025, with later discontinuation or suspension entries. Those entries should not be inflated into a service-outage allegation. Administrative filing problems and late accounts can happen without customer impact. They do, however, belong in procurement due diligence because the ability to keep statutory filings current is one proxy, among many, for back-office reliability.

If a customer is relying on a small provider for production hosting, it is fair to ask how billing, notice, renewal, account ownership and emergency contact processes are separated from the same thin administrative base.

AS204928 is real network evidence, not a facility audit

The strongest public signal for Bonsai is AS204928. The RIPE aut-num entity names AS-BONSAIHOST, links it to ORG-BHL13-RIPE, shows the ASN status as assigned, and records creation on 30 May 2022. The RIPE organisation entity identifies Bonsai Hosting ltd, country GB, registration number 13303584, organisation type LIR, and the same Preston address family seen in the corporate filings. These are high-quality identity records because they come from the regional internet registry system.

The RIPEstat AS overview adds that AS204928 was announced at the checked time and labels the holder as "AS-BONSAIHOST Bonsai Hosting ltd." The current announced-prefix view showed 194.153.216.0/24, 185.213.243.0/24, 128.254.184.0/24, and 2a12:e540::/32. The routing-status view summarized that as three IPv4 prefixes, 768 IPv4 addresses, one IPv6 prefix representing 65,536 /48s, and near-complete visibility across RIPE RIS peers: all 325 full-table IPv4 peers were seeing the route set, and 321 of 322 full-table IPv6 peers were seeing the IPv6 announcement.

That is meaningful. A dormant paper company does not usually maintain a visible ASN, valid route-origin records and current global route propagation. Public BGP evidence says there is an operating edge that other networks can see. It says Bonsai is not merely a shell with a parked domain.

But an ASN is not a data centre. It is not a rack list. It is not a power contract. It does not show whether customer servers are in owned cabinets, leased dedicated servers, virtualized capacity rented from another provider, colocation space, or a mixture of those arrangements. It also does not show the management path. A customer can lose service because of a hypervisor failure, a storage pool issue, a remote-hands queue, a billing lock, a bad route filter, or a management-panel problem while the ASN itself remains perfectly visible.

The right conclusion is therefore layered. Bonsai has credible public number-resource evidence. It has routeable address space that appears globally visible. It has valid RPKI for the visible origin-prefix pairs checked for this article. It does not have public evidence of multi-site compute, spare capacity, a declared maintenance calendar, an incident-status archive, a facility list, or an audited support setup.

That gap is not unusual for smaller infrastructure providers. The point is not to punish smallness. The point is to price it correctly. Small providers can be responsive, technically competent and cost-effective. They can also run close to the physical edge because every extra spare, router, cabinet and paid transit path costs money. Customers who benefit from the lower price need to know exactly which risks they are accepting.

The route table shows continuity and concentration at once

Bonsai's prefix set is small enough that every route matters. Three IPv4 /24s are not trivial, but they are also not a broad global cloud estate. A /24 is the minimum practical IPv4 prefix size many networks will accept globally; three of them give a provider room to host customers, separate uses, or operate in multiple upstream contexts, but the public table does not reveal the utilization inside the blocks.

The visible IPv4 prefixes also carry different registry stories. The RIPE inverse organisation search tied 194.153.216.0/24 to a RIPE inetnum with netname UK-BONSAI-20230516, country US, and Bonsai maintainers. The 185.213.243.0/24 route object points to origin AS204928 but is maintained by netutils-mnt, a sign that address administration can involve another maintainer even when Bonsai originates the route. The 128.254.184.0/24 prefix is visible behind AS204928, but ARIN RDAP identifies the parent allocation as Cloudmir, LLC and the customer assignment as Photon Hosting Limited. None of that invalidates Bonsai's current route-origin visibility. It does show that public address space can be leased, delegated, reassigned or otherwise administratively layered.

The IPv6 record is also instructive. RIPE lists 2a12:e540::/32 as allocated to Bonsai's organisation, while the inet6num country field is DE. The RIPEstat historical announced-prefix view for 2026 showed a shift from 2a12:e540::/48 early in the year to the larger 2a12:e540::/32 by mid-March 2026. That is a positive sign for IPv6 capability, but it is not the same as proof that customer workloads, backups, monitoring, firewalls, support systems and abuse handling are all mature across IPv6.

Route-origin validation is better. RIPEstat's RPKI checks returned valid status for 194.153.216.0/24, 185.213.243.0/24, 128.254.184.0/24, and 2a12:e540::/32. That lowers one specific class of routing risk: other networks enforcing Route Origin Validation are less likely to reject these prefixes because the origin is unauthorized.

RPKI still protects only one part of the service. It says the route origin is authorized. It does not say a server has redundant power, that a storage pool is replicated, that an upstream has enough commit after failover, or that a support queue can answer at 03:00. The route table is a map of reachability, not a warranty of recoverability.

Transit evidence has to be read as a live snapshot

The public transit story is mixed, which is normal for a small network and important for customers. The RIPE aut-num entity declares two imports: from AS24940, Hetzner, and from AS137409, Global Secure Layer. It also declares exports to those same ASNs. Declared imports matter because they show what the operator put in the registry entity. They do not always match the current BGP graph.

The RIPEstat routing-consistency view showed AS137409 in both BGP and whois, but AS24940 only in whois during the checked snapshot. It also showed AS199626, AS214150 and AS15830 in BGP but not in the whois import/export list. The RIPEstat neighbours view reported observed neighbours AS137409, AS15830, AS199626 and AS214150. PeeringDB identifies those ASNs as Global Secure Layer, Equinix as15830, Flamegrid and Prism Cloud, respectively, while Hetzner's PeeringDB entry identifies AS24940 as Hetzner Online.

That should not be read as wrongdoing. BGP relationships change, route collectors see only what they see, registries can lag live operations, and neighbour type labels are not the same as commercial contracts. The useful point is narrower: public records do not prove transit diversity by themselves. They show that Bonsai can be seen adjacent to more than one network. They do not prove that two default-capable paid upstreams are available in the same site, that traffic can drain automatically, that the remaining path has enough capacity, or that the physical cross-connects enter the building separately.

Customers should separate four forms of diversity. Logical route diversity means BGP can choose another path. Commercial diversity means different counterparties are contracted to carry traffic. Physical diversity means the connections do not share the same router, patch panel, duct, fibre provider, meet-me-room dependency or power domain. Operational diversity means different people and systems can restore the path when one access method is down. A public ASN neighbour list helps only with the first layer, and only partially.

This is especially important for workloads sold as virtual or managed capacity. A VPS customer may never see the transit arrangement. A bare-metal customer may see a port speed and bandwidth allowance but not the commit size or route preference. A colocation customer may control a server but still depend on the provider's cross-connect, addressing, remote hands, access process and billing standing. In all three cases, a route that looks resilient from a global collector can still fail through one local choke point.

The control panel is live, but it is not the rack

Bonsai's most visible customer-facing surface is not the apex website. It is panel.bonsaihosting.com, which returned a live noindex JavaScript application shell in a July 2026 check. The same hostname resolved to 116.202.105.151, and RIPEstat's network-info view for that IP mapped it to AS24940 and 116.202.0.0/16. The RIPE whois view for the panel IP identified 116.202.96.0/20 as CLOUD-FSN1, country DE, under Hetzner Online GmbH.

That architecture can be sensible. Hosting a management panel on a different provider can keep account access alive when a customer network has trouble. It can also create a dependency on another provider's cloud, DNS, TLS, app session, mail and support path. If the panel is needed to reboot a server, open a ticket, pay an invoice, reset a password or request rescue access, then the panel's own hosting location becomes part of the customer recovery design.

A public EnviroMC documentation page also points users with bare-metal and colocation services to https://panel.bonsaihosting.com, while directing game-server and VPS users to different panels. That is a useful operating signal because it ties the Bonsai panel to customer tasks in the bare-metal and colocation categories. It is not, by itself, proof of Bonsai-owned racks or a durable commercial relationship between the named services. It is a public customer instruction that should trigger questions about boundaries.

The boundary questions are practical. If a bare-metal server fails, who owns the hardware? If the customer colocates hardware, who controls facility access and remote hands? If the panel is down, how does a customer authenticate an emergency reboot request? If the panel is up but the rack network is down, which system declares the fault and which team has authority to change routes? If the customer wants to leave, can the panel export tickets, invoices, network allocations, reverse DNS, console access logs and configuration history, or does the customer have to reconstruct those manually?

Control panels create an impression of direct control. In hosting, they often broker control. A reboot button may call an out-of-band management controller; a billing page may gate service access; a support ticket may trigger a facility ticket; a migration request may depend on storage copies, spare ports and staff time. If any one of those layers is thin, the customer finds out during the incident, not during onboarding.

Accounts show hardware economics, not durable headroom

The accounting trail is one of the rare places where Bonsai's physical base peeks through. The 2022 accounts disclosed turnover of GBP 51,861 and fixed assets including tangible plant and machinery. The 2023 accounts disclosed turnover of GBP 69,098, GBP 40,000 of tangible plant and machinery at net book value, stock of GBP 12,889, and one average employee. The notes described computer, server and network hardware as assets that wear and lose resale value over time. That language is consistent with a small hosting operator that has purchased or capitalized physical infrastructure.

The later accounts tell a quieter story. The 2024 micro accounts showed fixed assets of GBP 20,000, current assets of GBP 7,942, creditors due within one year of GBP 20,539, net current liabilities of GBP 12,597, and one average employee. The 2025 micro accounts showed current assets of GBP 23,160, creditors due within one year of GBP 10,182, net current assets of GBP 12,978, capital and reserves of GBP 12,978, and again one average employee.

Because micro-entity accounts are intentionally sparse, they do not show revenue, gross margin, precise hardware inventory, hosting locations, customer count, supplier commitments or maintenance reserves.

For customers, the important phrase is "hardware economics." A small provider can buy a set of servers, sell capacity, depreciate the assets and earn a useful margin if failure rates are low. That bargain becomes fragile when growth, replacement cycles, remote-hands charges, IPv4 lease costs, transit, power and support obligations all arrive together. A cheap VPS or bare-metal plan is not only a CPU allocation; it is a claim on future repair labour and replacement capital.

Hardware-stock risk is therefore real even when route-origin evidence looks clean. If a motherboard fails and the provider has a spare in the same facility, repair can be fast. If a spare must be ordered, shipped, approved by a facility, and installed by remote hands, the service window changes. If the customer requires a migration to another host, the provider needs free capacity, compatible storage, working backups, enough transit and staff time. Public filings do not answer those questions for Bonsai.

The single-average-employee figure sharpens the issue. It does not mean only one person ever helps the company; contractors, facility staff, software vendors and network providers may be involved. It does mean the company itself has not disclosed a broad payroll base. If the service depends on third parties, the customer's restore plan must know which tasks are inside Bonsai and which are delegated.

The same applies to abuse handling and account disputes. RIPE lists an abuse mailbox at the Bonsai domain. That is useful. It does not say how quickly abuse reports are triaged, whether a customer server can be suspended automatically, whether a false positive can be reversed, or whether a billing lock could block access during a network incident. Billing and abuse systems are not secondary to infrastructure; they are part of the same availability surface when a provider has the power to suspend or restore a customer's machines.

Data locality is unsettled by design

Bonsai is a GB company in Companies House and a GB organisation in RIPE. That does not make every customer workload British. Public network records already push against that simple reading. One RIPE inetnum tied to Bonsai uses a US country field. The IPv6 allocation uses a DE country field. The panel IP is in Hetzner's German cloud range. The ARIN record for 128.254.184.0/24 points through a US registrant, Cloudmir, and a Canadian customer label, Photon Hosting Limited, while AS204928 is observed originating the /24. A VPSBenchmarks YABS result from September 2023 labels a Bonsai Hosting ltd server as a KVM virtual machine in Washington, District of Columbia, with AS204928.

None of those signals proves where today's Bonsai customers are placed. Geolocation and benchmark sites can be wrong, stale or based on test conditions that no longer exist. Registry country fields can refer to address administration, not physical server placement. Customer assignments can be temporary. A panel host can be a management layer rather than the workload layer. But together they make one thing clear: a customer should not assume data locality from the company address or the ASN holder country.

Data sovereignty for a hosting customer has at least six locations. The first is the primary compute location. The second is backup storage. The third is the management panel and its session, password-reset and audit logs. The fourth is support ticketing and email. The fifth is billing and payment data. The sixth is the staff or supplier location from which administrators can access systems. A provider can be legally British while placing any one of those functions elsewhere.

That is not automatically bad. International placement can improve price, routing and resilience. It becomes a risk when the customer was relying on a jurisdictional assumption that was never written down. For Bonsai, the public evidence supports a data-locality warning rather than a data-locality conclusion. The customer should ask for a location schedule, not a country-code assurance.

The same warning applies to portability. If data is in a UK rack, a German management panel, a US routed prefix and a third-party billing system, the customer needs a single exit procedure that works across all of them. Can the customer obtain disk images? Are reverse DNS entries portable? Can IP space move with the customer, or will services need renumbering? Can support export tickets and configuration records? Is there a paid emergency migration path? Public evidence does not answer those questions.

The main failure path is not one event, but a chain

The failure path to test for Bonsai is not simply "the network goes down." The more realistic path is a chain: a rack component fails, a route is withdrawn or congested, the panel remains hosted elsewhere, support has to coordinate facility access, and the customer discovers whether billing status, credentials and migration rights are clean.

Start with a rack failure. If Bonsai hosts customer workloads on physical servers it owns, a failed switch, router, PDU, disk shelf or hypervisor can affect many customers at once. If Bonsai uses rented dedicated servers or colocated customer hardware, the repair authority may sit with a third party. The customer needs to know which devices are redundant, which are single points, which spares are on site, and who can enter the facility.

Then add upstream trouble. The public BGP view shows multiple observed neighbours, but it does not prove that all customer traffic can fail over without congestion or manual work. If one neighbour drops sessions, filters a route, rate-limits traffic or has a dispute, Bonsai's routers must still keep customer prefixes reachable. The remaining path must have enough capacity. Monitoring must see the problem before customers do. Someone must have the authority to change local preference, open tickets and roll back bad filters.

Next, add hardware stock. The accounts suggest hardware existed, but they do not disclose a current inventory or spares policy. A provider can have enough servers to sell new plans but not enough idle capacity to migrate failed hosts quickly. It can have spare compute without spare storage. It can have spare disks but no spare controllers. It can have a tested image process for standard VPS plans but not for bespoke bare-metal machines. Customers should not accept "we have backups" as a substitute for a timed restore test.

Then add support load. A one-person or very small company can provide excellent support on normal days. During a multi-customer incident, the support queue becomes part of the outage. Customers ask for updates, reboots, console access, backups, invoice exceptions, IP-route changes and migrations at once. If the same person handles network, facility coordination, customer communication and billing, the limiting resource is not bandwidth. It is attention.

Finally, add billing and migration. If the customer account is overdue, disputed, manually renewed, or tied to a failed email address, access to the panel or support path can become contested just when urgent action is needed. If the customer wants to leave, migration may require IP changes, DNS changes, reverse DNS updates, snapshots, large data transfers, new firewall rules and careful timing. A provider that can keep a route alive may still fail the customer if it cannot help them exit cleanly.

What a customer should ask before relying on Bonsai

The due-diligence list for Bonsai should begin with placement. Which country, city and facility hold the primary service? Which entity owns the hardware? Which entity signs the facility contract? If the answer is "we use suppliers," the customer should ask which responsibilities are retained by Bonsai and which require a supplier ticket.

The next question is redundancy. Are there two sites or one? If there are two sites, can the second site run the workload, or is it only a backup target? Are router pairs physically separated? Are power feeds independent all the way to the rack? Are upstreams default-capable and committed to enough traffic? Is IPv6 tested during failover, or is it a best-effort add-on? Can the provider show a recent failover test with dates and measured recovery times?

Restore paths matter more than backup language. A customer should ask for the last successful restore test, the maximum restore size, the recovery point and recovery time by product, and the exact path used when the customer cannot reach the normal panel. For bare-metal customers, the questions become more physical: is remote console available, is rescue media available, are spare disks stocked, and who pays for emergency hands?

Support escalation needs names, roles and hours. "Open a ticket" is not enough if the panel is unavailable, mail is delayed or the affected service includes the ticketing dependency. Customers should ask for emergency contact methods, escalation thresholds, incident-update cadence, and authority boundaries. Does first-line support have authority to reboot hardware, change routes or contact the facility? If not, who does?

Data portability is the final test. Customers should require a documented exit path before production use. That path should include disk export format, database dumps, configuration export, DNS and reverse-DNS procedures, IP renumbering support, transfer bandwidth, billing closeout, and the survival of account access after cancellation. The most dangerous provider is not the one that admits a narrow footprint; it is the one that makes exit sound easy without proving the mechanics.

None of these questions assumes Bonsai is unreliable. They assume that public infrastructure evidence is incomplete. A small provider can answer them honestly and still win the business. A customer can then decide whether the price, support style and locality tradeoff fit the workload. The wrong answer is to treat the existence of AS204928 as a substitute for tested service recovery.

The customers most exposed are the ones with stateful workloads

Static websites and disposable test machines can tolerate a thin provider footprint. A customer can redeploy, change DNS and accept some interruption. Stateful workloads are different. A database, game world, production application, customer file store, mail server, build system, control node or identity service depends on intact data, predictable network identity and timely administrative access.

Bonsai's public footprint suggests the highest-risk customer is not the one with a single hobby VM. It is the customer that buys inexpensive capacity, accumulates state over time, and never rehearses departure. That customer may begin with a low-cost VPS or bare-metal server, add user data, point production DNS at it, build firewall assumptions around the assigned addresses, and then discover during a fault that the plan did not include fast migration, spare hardware, route portability or managed backups.

Colocation customers face a different exposure. If a customer owns the server but depends on Bonsai for rack access, addressing, remote hands or cross-connects, the customer owns the asset but not the full repair path. They need clarity on access windows, shipping, storage, replacement parts, insurance, hands charges and who can authorize work. A colo server with no practical hands path can be less recoverable than a rented VPS with a disciplined backup process.

Bare-metal customers sit between VPS and colocation. They may get stronger performance isolation than a VPS and more predictable hardware, but they also inherit physical replacement risk. If a CPU, motherboard, NIC or storage controller fails, migration is not always instant. If the customer uses local disks, restore depends on backup design. If the customer uses provider-managed networking, IP and MAC changes can complicate replacement. The public documents do not show how Bonsai handles those scenarios.

The September 2023 VPSBenchmarks result is useful mainly as a cautionary market signal. It showed a one-core, roughly 2 GB RAM, KVM Bonsai-labelled server in Washington, DC, with IPv4 but no IPv6 in that test. It does not prove the current product catalog. It does not prove the machine was sold by Bonsai directly. It does not prove today's geography. It does show how public third-party traces can surface a service footprint that differs from a simple GB-company assumption.

The honest evidence grade is split

The public network evidence for BONSAIHOST Bonsai Hosting ltd deserves a Medium grade. The company record is active. The RIPE organisation record aligns with the UK company number. AS204928 is assigned and announced. RIPEstat sees current prefixes. RPKI validation is valid for the visible origin-prefix pairs checked. The control panel is reachable. External customer documentation points a bare-metal and colocation category toward that panel.

The facility, support and recovery evidence deserves a Weak grade. There is no public facility list, no PeeringDB network profile returned for AS204928, no disclosed rack count, no public status history found in the sources used here, no published spare-parts policy, no customer-facing restore test, no public multi-site capacity claim, and no clear data-portability guarantee. The accounts show a small company with one average employee in recent filings. The route table shows live reachability, not operational depth.

That split is the point. Bonsai should not be dismissed as non-operating simply because its marketing footprint is sparse. The routing evidence is too concrete for that. Nor should it be treated as a mature cloud platform simply because it has an ASN, a panel and visible prefixes. The physical dependency remains: racks or rented servers, upstream contracts, power, hardware stock, support labour, and customer migration paths.

A buyer using Bonsai for non-critical workloads can accept a higher share of that uncertainty. A buyer using it for production state should ask for proof before moving. The proof should be operational, not rhetorical: a recent restore, a failover diagram, a panel-down support path, a location schedule, an upstream and facility dependency map, an exit procedure and a named escalation route.

A practical buyer can treat that split grade as a contracting map. The route table can support questions about origin authorization, prefix reachability, upstream choice and monitoring. The company filings can support questions about hardware refresh, spare stock and balance-sheet tolerance for replacement cycles. The sparse facility evidence can support questions about site access, hands charges, supplier authority and recovery tests. None of those questions accuses Bonsai of weakness; they translate public uncertainty into verifiable terms that a small provider can answer with dates, locations, roles and limits.

The cleanest reading is this: BONSAIHOST Bonsai Hosting ltd is a small, active hosting infrastructure subject whose public route evidence is materially stronger than its public facility and support evidence. That is enough for an article, enough for procurement questions, and not enough for blind trust.