Network LIGA HOSTING LTD sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Network LIGA HOSTING LTD is the infrastructure-facing identity around LIGA HOSTING LTD's public hosting business. Companies House records company number 17069738 as an active England and Wales private limited company incorporated on 4 March 2026 with SIC 63110, while the company's own terms say the hosting operation has been active since 2019 and serves customers in more than 30 countries.
• The public service surface is real enough to test: LigaHosting advertises VPS Standard in Tulcea and Frankfurt, Ryzen 9 9950X Performance VPS in Frankfurt, cPanel web hosting with daily seven-day backups, and game hosting under the Romanian brand. The same site claims AS201131, DDoS protection, 10-40 Gbps uplinks, under-60-second VPS provisioning and a 99.9% monthly network and core-infrastructure SLA.
• AS201131 is currently visible. RIPE RDAP identifies AS201131 as LGH-Network, registered to LIGA HOSTING LTD on 3 March 2026; RIPEstat's latest routing-status view shows three IPv4 /24s and two IPv6 /48s with full or near-full RIS visibility. The three checked IPv4 route-origin pairs validate under RPKI, while the two current IPv6 /48s returned unknown validation in the checked RIPEstat view.
• The evidence grade is Medium. Public routing, product, status and contract evidence support an operating hosting footprint, but the record still does not prove rack ownership, facility operators, dual power paths, spare hardware, route diversity inside each site, tested restores or customer migration rights.

A new UK company wrapped around an older hosting story

The first fact to separate is legal identity from operating history. Companies House records LIGA HOSTING LTD as company number 17069738, active, incorporated on 4 March 2026, with a registered office at 3rd Floor, 86-90 Paul Street, London, EC2A 4NE and nature of business 63110, data processing, hosting and related activities. The officers page lists Ionel-Florin Florin Moisa as active director, appointed on the incorporation date. The persons-with-significant-control record records Ionel-Florin Moisa with ownership of shares and voting rights of 75% or more, plus the right to appoint or remove directors.

That makes the company visible, but young. Its first accounts are not due until December 2027 and its first confirmation statement is not due until March 2027. Customers therefore cannot yet read a mature filing trail, accounts history or long sequence of corporate events. That matters when a buyer is deciding whether a low-cost server is a durable counterparty or a fast-moving hosting brand that could change legal form, address-resource arrangements or operating suppliers.

The public site tells a longer trading story. LigaHosting's terms, last updated on 29 April 2026, say LIGA HOSTING LTD operates the brands ligahosting.com for international VPS and cPanel web hosting and ligahosting.ro for game hosting, has been active since 2019, serves customers in more than 30 countries and runs VPS infrastructure in Romania and Germany. That older-history statement may well describe the brand or trading operation before the UK company was incorporated. It should not be read as a Companies House history for company number 17069738.

The distinction is not pedantic. If a service has older customers, older panels or earlier infrastructure contracts, a new company can inherit some operating practices without inheriting a long legal filing record. If the company is a newly formalised wrapper around an existing Romanian or European hosting business, customers should ask which legal entity signs the current contract, which entity owns or rents the hardware, which entity holds supplier accounts and what happens to existing services if another brand, reseller account or old panel remains in the chain.

Nor is the London registered office a data-centre claim. The Companies House address and the site's structured organisation data identify a corporate address, not a rack location. It is consistent with a UK company selling Romanian and German infrastructure. It does not establish that customer data is processed in the UK, that support staff are in London, or that the company owns a UK facility. The hosting story has to be checked against product pages, status pages, routing tables and terms.

What the public product surface sells

The product pages show a service aimed at small and mid-range hosting buyers rather than a hyperscale cloud. The main LigaHosting site advertises "VPS Standard & Performance", DDoS protection, instant deployment, premium network connectivity, enterprise hardware and European reach in Romania and Germany. It names AS201131 as the company's own backbone and says VPS provisioning is under 60 seconds. It also advertises 10-40 Gbps uplinks and support responses in under 15 minutes. Those are commercial claims, but they are specific enough to translate into physical questions.

The VPS Standard page names two infrastructure nodes: Tulcea, Romania, described as Standard on dual Intel Xeon Gold 6254 hardware, and Frankfurt, Germany, described as Standard on AMD EPYC 7702. Plan cards range from small VPS instances upward and include one IPv4 address and DDoS protection. The VPS Performance page concentrates the high-frequency tier in Frankfurt on AMD Ryzen 9 9950X processors, with plans that scale from 1 vCPU, 2 GB RAM and 100 GB NVMe to 12 vCPU, 64 GB RAM and 1.6 TB NVMe. That is a concrete compute story, not just a blank "cloud" label.

The web-hosting page adds a different product surface: cPanel hosting, SSD storage, free SSL, email accounts and daily backups. Web Starter advertises 20 GB SSD storage and one website. Web Pro expands storage and account scope. Web Business advertises unlimited SSD storage, unlimited websites and a free dedicated IP. The important dependency shift is that cPanel hosting concentrates multiple accounts on shared servers and shared administrative systems, while VPS hosting gives the buyer root access but also shifts more backup and configuration responsibility to the buyer.

The Romanian game-hosting brand adds another signal. LigaHosting.ro advertises game-server hosting in Romania and Germany, a 99.9% uptime target, 24/7 support and an infrastructure panel showing Romania at 5.180.33.0/24 and Germany at 163.5.26.0/24. It lists Romania compute as an Intel Core i9-14900K platform with 192 GB DDR5 and 2 TB NVMe, while Germany is an AMD Ryzen 9 9950X platform with 128 GB DDR5 and 2 TB NVMe. These page claims line up with two of the visible AS201131 IPv4 prefixes, but they still do not identify the facility operator or prove spare capacity.

The status page is also useful because it names service locations in operational terms: Tulcea, Romania for VPS Standard, and Frankfurt, Germany for VPS Standard, VPS Performance and Web Hosting. It showed "All systems operational" and no active incidents when checked, with both locations marked operational. A current green status page is not an uptime archive, but it tells customers what the provider treats as its public service components.

This is enough evidence to say LigaHosting is not merely a dormant shell. It has a public catalogue, active service locations, specific processor claims, a customer status page, terms and a live network. It is not enough to say the company owns the racks, controls the buildings or can move all workloads across regions. A VPS buyer sees a plan name, a CPU family and an IP address. The resilience decision depends on what sits behind those labels.

AS201131 is visible, but visibility is not the same as control everywhere

The strongest technical evidence is the network. RIPE RDAP for AS201131 identifies AS201131 as LGH-Network, registered on 3 March 2026 and last changed on 15 June 2026, with LIGA HOSTING LTD as the registrant organisation and abuse contact [email protected]. RIPEstat's AS overview identifies the holder as "LGH-Network LIGA HOSTING LTD" and marks the ASN as announced. That aligns the site claim with public routing evidence.

The current route set is compact. RIPEstat's routing-status view showed, for the latest 12 July 2026 query time, three IPv4 prefixes totalling 768 IPv4 addresses and two IPv6 /48s. It reported full IPv4 visibility across RIS peers and near-full IPv6 visibility. RIPEstat's announced-prefixes view also showed that several IPv6 /48s had appeared during the previous two-week window but were no longer in the current high-visibility set by 12 July. That is normal enough for a small network, but it means buyers should distinguish current production routes from recent or experimental route visibility.

The three current IPv4 prefixes line up with the product geography. 5.180.33.0/24, 163.5.26.0/24 and 146.19.215.0/24 were each visible with AS201131 as origin in RIPEstat's checked prefix-overview views. The Romanian game site explicitly maps 5.180.33.0/24 to Romania and 163.5.26.0/24 to Germany. The official product pages and status page place VPS and web-hosting services in Romania and Germany. That gives a plausible geography: Romania and Germany are the customer-facing service regions, with the UK company as the legal counterparty.

Route-origin security is a positive point for IPv4. RIPEstat RPKI validation for 5.180.33.0/24, 163.5.26.0/24 and 146.19.215.0/24 returned valid for AS201131. Valid RPKI does not make a server reliable, but it reduces one class of routing failure by telling networks that perform origin validation that AS201131 is authorised to announce those prefixes.

The IPv6 picture is weaker. The current prefix-overview checks for 2a06:9801:c2::/48 and 2a06:9801:22c::/48 showed them announced by AS201131, but the checked RPKI validation URLs returned unknown rather than valid. Unknown is not invalid. It means the checked view did not find a validating route-origin authorization for the queried origin-prefix pair. For customers who require native IPv6 and route-origin assurance, that is a question to settle before procurement.

Upstream evidence needs careful language. The RIPE database aut-num record lists import and export policy involving AS209735, AS58061, AS58212, AS213323 and AS207841. RIPEstat's asn-neighbours view observed four neighbours at the latest checked time: AS213323, AS397373, AS58061 and AS58212. CAIDA AS Rank saw AS201131 as a small AS with three providers, no observed customers and no observed peers in its dataset. The exact names and roles differ across route-policy records and observation datasets, which is expected in BGP. The conservative conclusion is that AS201131 is multihomed in public observation, but the public record does not prove which upstreams serve each location, whether both are active in each region, or whether fibre paths and router pairs are physically diverse.

PeeringDB adds one more absence. The PeeringDB API query for AS201131 returned no network entity when checked. That is not a defect; many small networks do not maintain a PeeringDB profile. It does mean customers cannot use PeeringDB to confirm facility presences, exchange LANs, public peering policy or traffic levels. For an operator selling on "own backbone" language, publishing a basic interconnection profile would make the control surface easier to verify.

The rack story goes quiet at the most important point

A hosted server is sold as a software entity, but it fails as a physical entity. The site can provision a VPS in seconds only because a real server is already powered, cooled, connected and sitting in a rack. A game server can advertise low latency only because packets move through top-of-rack switching, edge routers, transit providers and DDoS mitigation. A cPanel account can promise backups only because storage and backup jobs run somewhere with enough disk, bandwidth and operator attention.

For LigaHosting, the visible locations are Tulcea and Frankfurt. That is better than a vague "Europe" claim. The remaining gap is facility identity. The public sources reviewed for this article did not identify the data-centre operator in Tulcea, the Frankfurt facility, rack ownership, cabinet count, power feed design, remote-hands provider, fire-suppression scope, cooling redundancy, carrier meet-me room or hardware replacement process.

The public site says "European cloud infrastructure in Romania and Germany"; it does not say whether LIGA HOSTING LTD owns hardware in colocated racks, leases dedicated servers, resells a platform, or mixes those models by product.

This matters because a facility, a rack and a virtualisation cluster are different layers. A Frankfurt data centre might have multiple utility feeds, UPS systems and generators, while a tenant still plugs a single-cord server into one power strip. A rack may sit in a good facility while its top-of-rack switch remains a single point of failure. A server may have two NVMe devices while snapshots sit on the same node. A site-level green indicator can coexist with one failed host or one overloaded storage pool.

The product evidence points to a compact platform. The VPS Standard page mentions Tulcea dual Intel Xeon Gold 6254 and Frankfurt AMD EPYC 7702 nodes. The Performance page mentions Frankfurt Ryzen 9 9950X. The game site mentions Romania Core i9-14900K and Germany Ryzen 9 9950X platforms. Those are familiar hosting-server classes, and they can deliver excellent price-performance for small workloads. They do not by themselves prove cluster failover, live migration, distributed storage or spare servers.

NIST's cloud-computing definition is useful here because it separates a true elastic resource pool from ordinary hosted virtual machines. A VPS product can offer broad network access and some self-service provisioning without proving rapid elasticity, measured service, cross-host pooling or multi-location resilience. The word "cloud" in a hosting site's footer does not settle architecture. The test is whether a customer can lose one node, rack or site and recover within a known window.

For a small provider, this gap is not unusual. Many real hosting businesses do not publish facility contracts or rack diagrams. The issue is not that the information is absent from the homepage. The issue is that customers buying production workloads need to ask because the evidence cannot be inferred. Which products are single-node? Which use replicated storage? Which have snapshots? Are Romania and Germany independent failure domains or simply separate product locations? Can a customer's VM move between them? Does the IP address move with it? Those answers decide whether the product is cheap capacity or resilient capacity.

Installed capacity is not recoverable capacity

The route table gives an upper bound on some network resources, not on compute. Three IPv4 /24s give 768 IPv4 addresses in the current public origin set. A one-IPv4-per-VPS plan can consume those addresses quickly, but address count does not tell how many physical hosts exist. One server can support many low-end VPS instances. One customer can consume many addresses. Some addresses sit reserved for infrastructure, abuse replacement, routing tests or future growth. IPv4 count is therefore a constraint, not a capacity register.

The same applies to advertised processors. A Ryzen 9 9950X host can be attractive for high-frequency game and performance VPS workloads. It can also become a sharp failure domain if many latency-sensitive servers share one physical box. An AMD EPYC or dual Xeon node can carry many standard VPS instances, but spare capacity depends on memory headroom, storage headroom, CPU overcommit and whether another compatible node is available. The public pages state plan specs, not overcommit ratios or hot spare pools.

Storage is the other hidden boundary. NVMe can mean fast local drives on one host, mirrored local storage, a separate storage server, or a distributed storage system. Each design has different failure behaviour. Local NVMe can be extremely fast until a drive, controller or host fails. Mirrored local storage can survive one drive but not all host failures. Distributed storage can tolerate node loss only if replicas sit across independent machines, quorum survives and rebuild traffic does not overwhelm the network. LigaHosting's public pages advertise NVMe and SSD storage but do not describe the durability architecture for VPS plans.

The web-hosting product is clearer because the terms say cPanel web-hosting plans receive automatic daily backups retained for seven days. That is useful, but it is not the same as continuous replication or immutable off-site backup. It protects some customers from server loss and ordinary mistakes, provided the backups complete, remain readable and are stored outside the failure that damaged the primary server. The terms explicitly say internal backups are for disaster recovery at server level and that the provider does not guarantee their integrity or availability.

That is a careful limitation, and customers should read it as a warning to keep their own copies.

The VPS product is clearer in the opposite direction: backups are not included by default. The terms say VPS customers are responsible for their own backups and that snapshots or additional backups may be available for a fee. This is an honest boundary, but it changes the product from "host will restore my server" to "host may keep the VM running, but I own recoverability unless I buy and test more." Any buyer who treats a default VPS as backed-up infrastructure has missed the operating arrangement.

The provider's 99.9% SLA also needs to be read as a credit mechanism, not a recovery guarantee. The terms define 99.9% monthly availability for network and core infrastructure, about 43 minutes of unplanned downtime per month, with exclusions for planned maintenance, DDoS attacks exceeding mitigation capacity, force majeure, customer code and third-party software. If the SLA is missed, the customer's remedy is an account credit tied to monthly payment, capped at 50%. That does not rebuild a database, return a lost IP reputation or compensate a business interruption beyond the service fee.

This is normal for hosting economics. Low monthly prices depend on bounded liability, shared systems, automation and customer responsibility. The practical question is whether customers have matched their own risk to that bargain. A hobby game server may accept a few hours of downtime and a restore from a local copy. An agency hosting client sites, a payment-facing application or a mail server with IP allowlists should treat the default product as only one component in a broader recovery plan.

Transit diversity has to be tested inside each service location

AS201131's public routing is one of the better parts of the record. It is active, compact and visible. The three IPv4 routes validate, and RIPEstat sees multiple neighbours. The site claims 10-40 Gbps uplinks, premium European connectivity and DDoS protection at the network edge. Those facts support a real network operation. They do not prove every location has independent physical paths.

The difference matters during failure. A Romanian server can have an AS201131 address while depending on one local uplink, one switch or one facility cross-connect. A Frankfurt performance node can sit behind a stronger transit mix but still have a single customer-facing router pair. DDoS filtering can work well until attack size exceeds contracted capacity or filtering diverts traffic in a way that increases latency for game servers. A BGP table shows reachability from route collectors, not the cable path through a building.

RFC 7454 describes operational controls such as prefix filtering, AS-path controls, maximum-prefix limits and route-policy hygiene. RPKI validation complements that by answering whether a route origin is authorised. LigaHosting's checked IPv4 route-origin state is positive, but BGP hygiene is not the same as availability engineering. A valid route can still be withdrawn accidentally, filtered by an upstream, blackholed during mitigation, or stranded behind a failed cross-connect.

The route-policy record also shows why customers should ask direct questions. The RIPE aut-num lists imports from several ASNs, and RIPEstat observes a different live set. This is not suspicious by itself. It is how route registries and live BGP often differ. For production buying, however, the relevant question is not "how many names are in the policy entity?" It is "which upstreams actively carry this customer's prefix from this site, and what happens if one fails?"

The most useful disclosure would be a simple site-by-site connectivity statement: Romania has these upstreams, Frankfurt has these upstreams, both are monitored, DDoS mitigation sits here, planned maintenance is announced through these channels, and emergency route changes are authorised by these people. Facility names and router addresses need not be public. The point is to show whether the network advertised as a backbone has independent paths where the customer's server actually runs.

For game hosting, route quality is not just uptime. Latency and jitter matter. A route that stays up but detours through another country can make a server feel broken to players. The game site measures latency from the user's device and displays region probes, which is useful at purchase time. It does not replace historical latency data, packet-loss reporting or incident notes. Customers with competitive or community workloads should run their own probes from the player geographies that matter.

Billing and account control are part of the outage surface

The terms make one failure path unusually explicit. Services are billed in advance. If an invoice remains unpaid, reminder emails go out during days one and two past due, the service is automatically suspended on day three, a final termination warning appears on day seven, and on day fourteen the service is terminated and all data is permanently deleted. The terms say deleted data cannot be recovered and that reactivation after termination requires a new order and does not guarantee the same IP, hostname or data.

That is not just finance language. It is operational dependency. A working server can become unavailable because a card failed, a PayPal account was locked, cryptocurrency confirmation lagged, invoice email went to spam, an agency employee left, or a client-side account was compromised. From the outside, the service is down even though the rack, power and route are healthy. The fastest technical team cannot restore a terminated VM whose data has been deliberately deleted under the billing rules.

The day-14 deletion rule also affects migration. If a customer waits until a dispute or non-payment window has already started, the remaining time to export data, lower DNS time-to-live values, replicate databases and test another provider can be short. If the account holder is absent, the service owner may not even receive the reminders. Multi-person account access, monitored billing contacts and independent backups are therefore uptime controls, not administrative niceties.

The refund terms reinforce the same economics. The 30-day money-back guarantee applies to a first hosting-service order for new customers, not to domains, setup fees marked non-refundable, dedicated servers or customised hardware, renewals, accounts terminated for terms violations or certain cryptocurrency refund cases. That is normal for hosting. It also means customers should not use refundability as a substitute for testing. A workload should be benchmarked, backed up and restored elsewhere during the first month, when exit friction is lowest.

Account control can also affect IP continuity. The terms do not promise that a restored or reactivated service keeps the same IP address after termination. Many hosted workloads can move behind DNS if the customer controls the zone. Some cannot. Payment integrations, security allowlists, mail reputation, game-server communities and partner APIs often depend on stable IPs. A customer using LigaHosting should document which dependencies can tolerate an IP change and which require advance notification or a second provider.

Maintenance windows and restore tests decide the real product

The public terms commit to planned maintenance being announced at least 48 hours in advance and excluded from the SLA. That is a reasonable customer notice standard, but it still leaves practical questions. What channel carries the notice? Does it appear on the status page, by email, in the client area or on Discord? Does the notice name the affected location, node or product? Can a customer postpone a reboot? Is emergency maintenance handled differently? The current status page shows live state, not a maintenance archive, so a buyer cannot yet inspect how previous work was communicated.

Repair windows are especially important for small hosting providers because the failure often crosses supplier boundaries. If a node fails in Tulcea, the provider may need local hands. If a Frankfurt cross-connect fails, the facility or carrier must act. If a DDoS provider blackholes a destination, the network operator must coordinate filtering. If a Ryzen performance node has a motherboard fault, replacement depends on compatible stock. Customers do not need every vendor name, but they do need an expectation for who can act and how quickly.

CISA's ransomware guide recommends offline encrypted backups, regular availability and integrity tests, golden images and considering a second cloud provider. The guidance is written for cyber incidents, but the same recovery discipline applies to storage loss, account suspension and failed hardware. A backup that has never been restored is a hope, not a control.

NIST's contingency-planning material frames recovery around alternate equipment, alternate locations, alternate storage and telecommunications. For a LigaHosting customer, the practical version is simple: export the application, restore it on a different provider, point a test hostname at it, confirm authentication and email, and time the exercise. If the restore requires the original VPS to be online, the recovery plan is too dependent on the failed system.

For cPanel users, the seven-day provider backup window is useful but short. It may protect against a broken update discovered quickly, but it may not cover slow corruption, a compromise that remained hidden for weeks, or a client who asks for recovery after the account has been terminated. For VPS users, the default is starker: no included backups. Snapshots can help with immediate rollback, but snapshots under the same provider account do not protect against account closure, provider-side deletion or a region-wide service event.

The clean customer pattern is therefore a tiered one. Keep provider snapshots if they are affordable and tested. Keep independent backups outside the account. Keep DNS and domain registration under the customer's own control. Store deployment notes, credentials and configuration in a separate system. Test restore to a small VM in another location. For workloads where the IP address itself is part of the service, maintain a communication plan for changing allowlists and a standby route through another provider.

Locality is split across UK incorporation and EU infrastructure

The company is incorporated in England and Wales. The public service locations are Romania and Germany. The game-hosting brand is Romanian-facing and the product copy is bilingual or multilingual across the public surface. This is a workable European hosting arrangement, but it means "local" depends on the buyer's question. A UK customer may have a UK legal counterparty and EU-located compute. A Romanian gaming community may have a Romania service region but a UK company contract. A German performance VPS customer may care less about company domicile than Frankfurt routing and data handling.

Personal data makes this a contract and mapping question. The ICO's international-transfer guidance explains that organisations need to understand when personal information is transferred or made accessible across borders. The ICO's controller and processor guidance explains why the role of each party affects obligations. A hosting customer cannot answer those questions from an IP country code alone.

The EU-to-UK relationship is also not the same as "anywhere in Europe is the same." The European Commission's adequacy information explains the mechanism under which the Commission may decide that a non-EU country offers adequate protection, and the Commission announced in January 2026 that it renewed the UK adequacy decisions. That helps EU-UK data flows, but it does not settle all onward transfers, remote support access, subcontractor access, backups or logs.

EU cybersecurity law adds another lens. The NIS 2 Directive covers important digital infrastructure categories including cloud computing and data-centre services, subject to national implementation and size or role thresholds. A small hosting company may or may not fall into a particular national scope, and this article is not a legal assessment. The operational point is that customers should identify which entity provides the service, where the data and backups are stored, and which subcontractors can access the systems.

Data sovereignty also includes failure handling. If a backup is copied to another country, if support staff can access a console from another jurisdiction, if DDoS mitigation diverts traffic through another network, or if logs are retained in a third-party SaaS service, the practical data map is broader than the advertised VPS location. LigaHosting's public terms say customer content remains the customer's property and grants the provider a limited right to store, copy for backup and redundancy, and transmit content to provide services. The terms do not publish a country-by-country subprocessor or backup-location map.

For ordinary low-risk workloads, the UK-Romania-Germany structure may be enough if the customer understands it. For regulated personal data, sensitive communities, public-sector workloads or customers with strict locality commitments, the buyer should request a written data-processing agreement, a location map for production and backup data, support-access controls, deletion rules and subcontractor details. The public site gives a starting point, not a complete sovereignty answer.

Who is affected when the system fails

The likely exposed users are not only the people whose names are on invoices. A small agency may host many client sites on one cPanel plan or several VPS instances. A game-server owner may support a large community that only knows a domain name and Discord channel. A developer may run an API for paying users. A business may host email on a shared plan and discover during outage that password resets, invoices and support communications all depend on the same provider.

For VPS customers, the direct failure modes are familiar: a host node crashes, a storage device fails, a DDoS filter overreacts, an upstream changes policy, or a billing event suspends access. The indirect failures are often worse. A customer has no current offsite backup. DNS is held by the same account. The only administrator uses an email mailbox on the failed server. The application depends on a hard-coded IP. A snapshot exists but cannot be downloaded or restored elsewhere. In each case, the provider's recovery window becomes only part of the outage.

For web-hosting customers, shared-server risk is different. One abusive or compromised account can affect server reputation, mail deliverability or resource limits. The terms reserve the right to throttle, request upgrades or suspend services that affect other clients on the same physical server. That is necessary for shared hosting, but it means the customer does not fully control the performance environment. "Unlimited" bandwidth and storage language is bounded by normal use and excludes large file distribution, media streaming, download servers or CDN-like use on shared hosting.

For game hosting, the impact is social as much as technical. Player communities notice lag, packet loss, restarts and region changes immediately. A node that is technically online but congested can still empty a server. A changed IP can break server lists, saved favourites and community instructions. The Romanian site gives useful region and hardware information, but customers running serious communities should ask how game panels, data directories, mod packs and databases are backed up and how quickly a server can be moved between Romania and Germany.

For all three product families, the strongest customer control is portability. Keep domain names independent. Keep payment and support contacts monitored by more than one person. Keep application configuration outside the server. Keep backups in another account and another provider. Test a restore before the first serious incident. These are not signs of distrust. They are the normal division of responsibility in budget and mid-market hosting.

What evidence would justify a stronger verdict

Network LIGA HOSTING LTD could move from medium evidence to strong evidence without exposing sensitive internals. The first improvement would be a concise infrastructure statement: which cities are active, whether the company owns hardware or leases dedicated capacity in each city, which product families run in each site, whether each site has at least two upstream paths, and whether customer IP space can move during a supplier failure. A public PeeringDB record would help, but even a plain text network page would make the backbone claim easier to verify.

The second improvement would be facility and power context. Customers do not need rack numbers. They do need to know whether servers sit in professional data centres, whether power is dual-fed, whether hosts are single-cord or dual-cord, whether remote hands are contracted, whether replacement parts are stocked locally, and whether planned facility maintenance has a no-downtime design or a customer reboot window. Uptime Institute's tier material is a reminder that facility capability and tenant topology are not identical; a certified building does not automatically certify every hosted node.

The third improvement would be backup and restore evidence. The terms already draw a clear boundary around cPanel backups and default VPS responsibility. The stronger next step would be product-specific restore targets: cPanel restore request time, snapshot retention options, offsite backup location choices, download/export formats, and the result of the last provider-run restore exercise. For VPS, a paid backup product should state whether it is stored off-node, off-rack or off-site.

The fourth improvement would be status history. A green page at one moment is useful; a history of incidents and maintenance is more useful. Customers should be able to see how often Romania and Frankfurt had planned work, whether any incidents crossed regions, how long restoration took and what was changed afterward. This is not just transparency theatre. It lets buyers compare the claimed 99.9% monthly target with actual operating behaviour.

The fifth improvement would be exit rights. The terms already state that terminated services may not retain IPs, hostnames or data. A production-friendly provider can still publish how customers export VPS images, retrieve cPanel backups, lower DNS dependency, transfer domains and request emergency data access before deletion. Hosting lock-in often appears during failure, not during purchase.

Verdict: visible hosting capacity, unproven deep resilience

Network LIGA HOSTING LTD is a better evidenced hosting subject than the initial sparse directory snapshot suggested. The UK company exists and matches the hosting SIC code. The public site and terms describe concrete VPS, cPanel and game-hosting services. The status page names Tulcea and Frankfurt service locations. AS201131 is registered to LIGA HOSTING LTD, active in public routing and currently originates three IPv4 /24s plus two visible IPv6 /48s. The checked IPv4 route-origin state is valid. These points support a real operating footprint.

The ceiling is equally important. The company is newly incorporated. The public record does not name the facilities, rack ownership, remote-hands provider, cross-connects, hardware spare stock, exact upstream mix per location, DDoS capacity, storage replication design, restore-test history or customer migration rights. The SLA is primarily a service-credit promise. VPS backups are not included by default. Billing rules can suspend service on day three and delete data on day fourteen. These are not flaws by themselves; they are the actual shape of the dependency.

For experimental VPS use, game communities with their own backups, small websites and workloads that can move by DNS, LigaHosting's public evidence may be sufficient if price, latency and support fit. For regulated data, client production hosting, revenue-critical applications or services with strict recovery objectives, the buyer should treat the platform as hosted capacity that still needs independent recovery design. Ask for site, backup and route evidence. Test restore outside the account. Own DNS and domain registration. Know what happens if a bill, rack, node, upstream or provider contract fails.

The central fact is not that AS201131 exists, nor that Tulcea and Frankfurt appear on a status page. It is that every virtual server sold under that surface still resolves into a small chain of physical and contractual dependencies: a server, a rack, power, cooling, transit, DDoS mitigation, support labour, billing state and an exit path. Network LIGA HOSTING LTD has enough public evidence to be taken seriously as an operating host. It has not yet published enough evidence to let customers outsource resilience to the provider.