The Fifteen-Minute Host: Buying Continuity from LIVI HOSTING LTD

Summary

LIVI HOSTING LTD is a real, active UK company incorporated on February 12, 2026, and public internet-registry records make a strong identity bridge from that exact entity to livihosting.com and AS212706.
AS212706 is not decorative: on July 18 it was visibly originating 40 IPv4 prefixes and one IPv6 prefix through three upstream networks, with valid route-origin authorisation across every visible announcement checked.
That technical footprint does not establish a purchasable hosting product. The associated website remains a looping maintenance display, while public prices, specifications, service terms, support commitments, backup policy, data-processing terms and a status history are absent.
A prudent SME should treat LIVI as a potentially capable young network operator at the due-diligence and reversible-pilot stage, not as a continuity dependency, until the company passes contract, restore, support, security, jurisdiction and exit tests.

A countdown that does not count down

The most revealing part of LIVI HOSTING LTD’s public presence is a clock.

Visit livihosting.com and the page announces that the site is in maintenance. It displays a green status light, “server uptime” close to 100 per cent, a current load, a progress bar and an estimated completion time of fifteen minutes. It looks like a status console. It is not one. The page’s own browser code generates random uptime and load numbers, inches the progress indicator towards a ceiling, and resets the countdown to fifteen minutes whenever it reaches zero. The HTTP response observed on July 18 returned a normal 200 OK, while its Last-Modified header pointed back to February 12, the day the company was incorporated.

This is not evidence that the underlying network is down. Nor is it evidence of deceit: a young operator may have put up a temporary visual while building a commercial site. It is evidence that the numbers on the page are presentation rather than telemetry. A buyer cannot turn the displayed 99.98 per cent into an availability commitment, cannot inspect incident history and cannot identify which service is supposedly being maintained. Common destinations for terms, privacy, pricing, support, contact, service status, backups, refunds and a client area all returned 404 during this research.

The looping clock is therefore more than an unfinished landing page. It is a compact illustration of the procurement hazard around a new host. Hosting is sold in percentages, locations, response times and recovery promises. Those numbers matter only when their measurement, scope, remedy and responsible legal party are clear. A simulated status panel supplies the shape of assurance without any of its contractual content.

LIVI’s case is unusually useful because the opposite side of the ledger is substantial. Behind the thin commercial surface sits a live autonomous system with thousands of routable IPv4 addresses, an IPv6 allocation, multiple upstreams and careful route-origin authorisation. This is not a story about a company registration attached to an entirely imaginary network. It is a story about the distance between being able to announce internet routes and being ready to carry a small company’s payroll portal, booking system or primary email.

That distinction should govern the analysis. The public evidence supports the proposition that an operating network exists. It does not yet support a claim about a particular virtual server, managed-hosting plan, customer-support arrangement or recovery service. The burden is not on a buyer to convert infrastructure clues into promises. It is on a supplier to state what it sells and accept responsibility for it.

The exact company, and the bridge to the network

The legal starting point is unusually clean. Companies House records show LIVI HOSTING LTD, company number 17028456, as an active private company incorporated in England and Wales on February 12, 2026. Its registered office is Stoney Works, 8 Stoney Lane, London SE19 3BD. Its stated activities include data processing and hosting, web portals and other information-technology services. Its first accounts cover the period to February 2027 and are not due until November 2027, so there is no filed balance sheet, revenue history or cash-flow evidence from which to judge financial resilience.

The filing history contains the incorporation filing and a £100 statement of capital. That figure is nominal share capital, not a live bank balance, insurance limit or measure of the resources available to repair an outage. It should neither be sensationalised nor mistaken for creditor protection. The important conclusion is narrower: the company is too young for the ordinary record of accounts, confirmation statements and changing officers to have accumulated.

There is one active director. Companies House identifies Vitalii Tretiakov as a Russian national resident in Russia, appointed on the incorporation date. The people-with-significant-control record says the same person owns at least 75 per cent of the shares and voting rights. It also records that his identity was verified by an authorised corporate service provider before incorporation. That verification is useful: it strengthens confidence that the named controller is a real person. It is not a certification of hosting experience, financial strength, security controls or service quality. Companies House itself warns that inclusion on the register should not be read as validation of all information filed; its public disclaimer is explicit about the limits of registry checks.

The decisive identity evidence comes from RIPE, the regional internet registry. The RIPE organisation record for ORG-LHL20-RIPE names “LIVI HOSTING LTD”, gives registration number 17028456, repeats the Stoney Works address and lists an email address at livihosting.com. This is a much stronger bridge than name similarity. Exact legal name, public company number, postal address and domain all converge in an operational internet-number record.

The timing reinforces, but does not independently prove, that bridge. RIPE says the organisation record was created on February 12 at 08:45:06 UTC. The .com registry’s RDAP response says livihosting.com was registered ten seconds later, at 08:45:16 UTC. The domain response does not expose a registrant, so it cannot by itself prove ownership. In combination with RIPE’s company number, matching address and domain-based contacts, however, the identity bridge is strong enough for analysis of the exact assigned entity rather than a similarly named brand.

Six days later, RIPE assigned AS212706. Its autonomous-system record names it LIVI-HOSTING-AS, points back to the company’s RIPE organisation record and identifies three declared transit relationships. A separate RIPE role record names a “NOC LIVI HOSTING” and gives [email protected]. Those records do not tell us how many people answer the mailbox, whether the network operations centre is staffed around the clock or whether the contact is available to retail customers. They do prove that the company identity is being used in the control plane of the public internet.

This chain is the foundation for everything that follows:

the UK register proves the legal entity exists;
the RIPE organisation record ties the exact company number to the domain;
the ASN record ties that organisation to AS212706;
live route observations show that the ASN is in use.

It is materially better evidence than a logo, testimonial or self-written “about us” page. It still stops short of proving who signs customer contracts, who owns the servers, who employs the administrators or what a customer receives for payment. Those require a second chain of evidence that the current public surface does not provide.

A real routing footprint, assembled at speed

At midnight UTC on July 18, RIPEstat’s routing-status view observed AS212706 originating 40 IPv4 prefixes, representing 10,240 addresses, and one IPv6 /32, representing 65,536 possible /48 customer networks. The IPv4 routes were visible to all 325 of the RIPE Routing Information Service peers counted by the endpoint; IPv6 was visible to 319 of 320. RIPEstat first saw a route originated by the ASN on March 6, less than four weeks after incorporation.

Those numbers deserve precise language. LIVI was originating the address space: it was the final autonomous system named in the observed Border Gateway Protocol paths. That does not mean it owned every address. Much of a hosting network’s space may be assigned, sub-allocated, sponsored or leased through other resource holders. The useful fact is operational reachability. Other networks were accepting routes that said AS212706 was the destination for those prefixes.

The routing set was also broad rather than a single experimental subnet. RIPEstat’s announced-prefix list showed dozens of /24 blocks. LIVI’s self-published geofeed mapped them to Amsterdam, Frankfurt, London, Helsinki and Paris. A geofeed is an operator’s coarse mapping intended for geolocation databases; RFC 8805 describes it as self-published data. It is not a deed to a data centre, an audit of rack location or proof that storage remains in the named city. For procurement, each location remains a claim to reconcile against facility suppliers, service orders and test measurements.

There is a positive routing-security signal. Every one of the 40 IPv4 announcements and the one visible IPv6 announcement returned valid when checked against RIPEstat’s route-origin validation endpoint. In the language of RIPE’s RPKI guidance, a valid result means at least one cryptographically verifiable Route Origin Authorisation permits that ASN to originate that prefix. This reduces the risk of accidental or unauthorised origin announcements. It does not validate the rest of the BGP path, secure a virtual machine, encrypt a disk or prove that an administrator will answer a severity-one ticket.

LIVI is not directly connected to the whole internet. No network is. RIPEstat’s neighbour observation found three upstreams on July 18: AS209847, AS57043 and AS199152. The RIPE records identify them respectively as WorkTitans B.V., HOSTKEY B.V. and Virtual Data Center Inc. The ASN’s own registration declares the same three relationships. Three upstreams can provide useful route diversity, but a list is not an architecture. A buyer still needs to know whether all links enter the same building, share a fibre path, depend on one router, carry both IPv4 and IPv6, and have tested automatic failover.

Another dependency is more direct. RIPE lists ZTV CORP LLC, a Russian local internet registry, as the ASN’s sponsoring organisation. RIPE’s explanation of independent resources says an end user requests an ASN through a sponsoring LIR and has a contractual relationship with it. Sponsorship is a normal feature of the RIPE system, particularly for smaller networks; it is not evidence that the sponsor operates every machine. It is nevertheless a real dependency that belongs in a supplier map. Changes to sponsorship, address assignments or route-maintenance arrangements can affect continuity even when a customer’s virtual server is healthy.

The public website adds an intriguing layer. DNS resolved livihosting.com to 193.17.92.15 during this research. RIPE’s number-resource response for that address places it in a ZTV CORP LLC range originated by AS43581, not in AS212706. There is nothing inherently wrong with a network operator hosting its brochure site elsewhere. Sensible operators often separate corporate services from the customer network. Here, though, the choice reinforces the central question: which components does LIVI operate itself, and which come from its sponsor or other suppliers?

The speed of assembly suggests competence and prior relationships. Creating a company, a domain and a RIPE organisation record on the same day; obtaining an ASN six days later; bringing routes into broad visibility in March; and reaching 40 visible IPv4 prefixes by July is not what an entirely fictitious operator looks like. It is reasonable to infer that the people involved had access to existing network suppliers, address space and operational knowledge. That is an inference, not a verified employment history.

It could reflect a reorganisation, a white-label arrangement, a network migration or a newly incorporated wrapper around experienced operators. Public evidence does not choose among those explanations.

What the network proves—and what it cannot

AS212706 answers an important part of the assignment’s qualification question. The exact legal entity is connected to a live, globally visible network used for hosting-class traffic. Independent network-data providers also classify the ASN as hosting and detect domains across it. That is more than a company registration and a generic sales page.

But “operates a hosting service” contains several different claims:

Routing operation: announcing prefixes, maintaining route permissions and exchanging reachability with upstreams. Public evidence supports this.
Infrastructure operation: controlling servers, storage, switching, virtualisation and remote hands in particular facilities. Public clues are consistent with it, but do not establish ownership or control boundaries.
Commercial operation: publishing products, taking orders, invoicing customers and accepting contractual responsibility. The public surface does not establish this.
Managed service: patching operating systems or applications, monitoring workloads, restoring data and responding to incidents. No public evidence defines such a service.
Continuity service: committing to availability, recovery objectives, support response and an orderly exit. No public contract or measured history supports this.

For a buyer, these are not semantic niceties. A company can be competent at BGP and sell only IP transit. It can originate address space for a related provider without selling virtual machines itself. It can sell unmanaged servers while leaving every backup and patch to the customer. Or it can quietly serve wholesale customers without a public retail catalogue. Each arrangement allocates failure and labour differently.

The strongest evidence of customer activity is circumstantial. Commercial internet-intelligence services report hosted domains and responsive servers within the ASN, and Scamalytics’ network view says it observes thousands of addresses associated with LIVI and related names. Those observations make empty route announcements unlikely. They do not reveal a contract, prove that a domain owner pays LIVI or identify the legal entity on an invoice. A workload can sit behind a reseller, a related company or a borrowed address. Public routing shows use, not privity of contract.

Accordingly, the fair verdict is deliberately split: LIVI is a verifiable young network operator; a generally available LIVI hosting product and its customer proposition remain unverified. That is not a fraud finding. It is a limit on what a procurement committee can responsibly approve.

The missing customer journey is itself evidence

A mature self-service host normally lets a prospective customer answer basic questions without entering a private sales conversation. What can be bought? In which location? Is the processor shared or dedicated? What storage underlies the disk? How much traffic is included? Is an IPv4 address extra? Does “backup” mean a snapshot in the same failure domain or an independently retained copy? Is support for the platform only, or will someone log into the guest operating system?

LIVI’s associated site answers none of them. There is no visible catalogue, configurator, order flow, account portal, acceptable-use policy, service-level agreement, privacy notice, data-processing addendum, refund policy, support matrix or incident archive. The maintenance page does not display the company name, number, registered address or jurisdiction. UK government guidance on company trading disclosures says business websites should show the registered number, registered office, place of registration and limited-company status. Because the page is merely a maintenance display and domain ownership is inferred through RIPE rather than exposed by domain-registration data, this observation calls for clarification rather than a legal conclusion. It still makes the page unusable as a contracting surface.

The absence may have an innocent commercial explanation. LIVI may sell by referral, serve a handful of wholesale accounts, or be preparing a site before a public launch. A private quote could contain excellent terms. Yet private sales increase the buyer’s verification burden because there is no public baseline against which to compare the quote. The buyer must preserve every version of the proposal, service description and contract; confirm that the counterparty is LIVI HOSTING LTD rather than a similarly named brand; and ensure that invoices and payment instructions identify the same party.

The first procurement test should therefore be documentary, not technical. Ask LIVI to produce one coherent pack:

a service description that distinguishes virtual servers, dedicated servers, colocation, IP transit and managed work;
a price schedule with billing unit, currency, tax treatment, traffic charges, address charges, backup charges and support charges;
terms that identify company number 17028456 as the supplier;
an SLA defining availability, exclusions, measurement point, claim process and service-credit remedy;
a support policy with hours, channels, severity definitions, response targets and escalation;
a backup and recovery schedule with retention, encryption, failure-domain separation and restore responsibilities;
a privacy notice, processor terms, subprocessor list and data-location statement;
an exit schedule covering export, assistance, deletion and final billing.

Any mismatch matters. If the quote names another company, the buyer needs a documented relationship and clear responsibility. If the bank beneficiary differs from the contracting entity, it needs explanation before payment. If the service is a ZTV or HOSTKEY product resold under the LIVI name, that may be perfectly workable, but the underlying supplier and remedy chain belong in the contract. A young reseller can add valuable support; it cannot make its dependencies disappear.

Procurement should proceed as a sequence of reversibility

The usual small-company mistake is to treat vendor selection as a single yes-or-no decision. With a new host, it should be a sequence in which each step buys information while limiting the cost of being wrong.

First, verify the counterparty. Match the proposal, invoice and bank details to LIVI HOSTING LTD and company number 17028456. Confirm that the person signing has authority. Use a known domain contact obtained independently of an emailed invoice. The public identity bridge is strong, but payment fraud often exploits the gap between a real company and a false instruction.

Second, buy one month, not one year. Annual prepayment transfers the supplier’s financing risk to the customer. A discount is economically meaningful only if the service survives the discount period and exit remains possible. A monthly card payment gives a young operator time to build history while limiting exposure. Payment method is not a substitute for due diligence, but bank transfer or digital currency only, long prepayment and a refusal to identify the beneficiary should each raise the threshold for approval.

Third, deploy something disposable. A pilot should resemble the intended workload in CPU bursts, disk writes, network traffic and management pattern, but contain no sole copy of data and no irreplaceable identity service. Synthetic monitoring should run from outside LIVI’s network. The customer should measure packet loss, latency, disk performance, noisy-neighbour variation, route changes and reboot behaviour rather than rely on the landing page’s generated statistics.

Fourth, create incidents on purpose. Open ordinary and high-severity tickets at different times. Reboot a guest, fill a filesystem, rotate an SSH key and request a reverse-DNS change. If a managed service is offered, ask the operator to diagnose a controlled fault. Record acknowledgement and resolution time. A support promise becomes useful only when the escalation path works without a founder’s personal messaging account.

Fifth, restore before production. Delete a test file, corrupt a database copy and rebuild the server into a fresh account or virtual machine. Measure recovery-point loss and recovery time. Require evidence that the backup used for the exercise is not merely a crash-consistent snapshot on the same storage system. If LIVI performs the restore, test authorisation procedures so an attacker cannot use support to overwrite or exfiltrate data.

Sixth, leave while the relationship is healthy. Export images, databases, logs and configuration. Move the workload to a second provider, change DNS and close the test service. Confirm the final invoice and request deletion confirmation. This exercise reveals proprietary formats, throttled exports, missing credentials and ambiguous notice periods before those become emergency costs.

Only after those gates should a buyer increase data sensitivity, business criticality, contract length or spend. This approach is not hostility to a young company. It is a way to let operational evidence accumulate without asking an SME’s customers or staff to underwrite the experiment.

The UK Government Digital Service’s guidance on evaluating a hosting supplier emphasises future needs and the level of support, including SLAs. Its separate hosting business-case guidance recommends understanding exit cost and retaining ownership of accounts and contracts. Those principles apply with extra force when the supplier’s public history is measured in months.

Architecture begins with a dependency map, not a city name

LIVI’s geofeed presents a five-city European footprint. A buyer might read that as five interchangeable regions. The public network evidence supports a much narrower statement: prefixes are labelled for geolocation in five cities and are globally routed through the same origin ASN. It says nothing about whether compute exists in all five, whether storage is replicated between them, or whether a customer can select and fail over among them.

A useful architecture interview would begin with one proposed server and trace every dependency:

Which legal entity owns or leases the physical host?
Which facility supplies space, power, cooling and physical security?
Which company provides remote hands?
Which network supplies each upstream circuit?
Which entity assigns the customer’s IPv4 and IPv6 addresses?
Which system holds the control panel, billing records and support tickets?
Where are snapshots and backups stored?
Who can access the hypervisor, storage plane and backup keys?
Which components are operated by LIVI, ZTV, an upstream, a data-centre company or another subcontractor?

This is not a demand that a small provider own buildings. Asset-light hosting can be efficient. A small operator can lease racks, rent address space and buy transit while adding responsive engineering and careful automation. The problem arises when the contract presents this layered service as an indivisible black box. The NCSC’s cloud supply-chain principle asks customers to understand how data is shared with suppliers, how third-party risk is managed and which party implements each security function. LIVI’s public RIPE records already show why: the service’s route, sponsor and corporate site involve several organisations before a customer workload is considered.

Upstream diversity also needs failure-domain detail. AS212706 had three observed providers, a positive sign compared with a single-homed network. Yet three BGP sessions in one facility can fail together when power, fibre or a router fails. Conversely, one well-engineered upstream across two physically diverse sites may outperform three nominal links sharing a conduit. A serious proposal should provide topology at a level that lets the customer identify common points without disclosing security-sensitive details.

Storage deserves the same treatment. “NVMe” describes a protocol and likely performance class, not durability. A local NVMe disk can be very fast and vanish with its host. Distributed storage can survive a disk or node loss but create correlated software failures. RAID is not backup; replication reproduces deletion and corruption; a snapshot is only as independent as its storage and administrative credentials. Ask what fails when a host, rack, site, control plane or operator account is lost.

The NCSC’s asset-protection and resilience principle recommends confidence in physical controls, encryption at rest, backups that can return data to a known good state and architectures spanning failure domains when availability requires it. LIVI makes no public claim against those criteria. A buyer should not score that as failure; it should score it as unassessed and decline to put critical data behind it until evidence arrives.

Hosting economics without a public price

A missing price list does not mean a service is expensive. It means its cost structure cannot be inspected.

The visible network suggests costs that someone must recover: sponsorship, address space, transit from three upstreams, servers or wholesale capacity, facilities, support, fraud control, DDoS handling and replacement hardware. IPv4 is particularly revealing. AS212706 originated 10,240 addresses, but origin does not imply ownership; assigned or leased address space can carry recurring cost and counterparty risk. If LIVI sells low-priced servers with included IPv4, the quote should show whether an address is dedicated, shared through network address translation, replaceable after reputation problems and retained during a migration.

Compute price is only the first line of a hosting bill. A useful comparison normalises at least these variables:

committed or burstable CPU and any fair-use limit;
memory allocation and overcommit policy;
local versus networked storage, input/output limits and snapshot cost;
included inbound and outbound transfer, port speed and overage;
IPv4, IPv6, reverse DNS and address-replacement terms;
backup frequency, retention, storage and restore labour;
operating-system licences, control-panel licences and managed support;
DDoS protection thresholds and mitigation charges;
setup, cancellation, reactivation and data-export fees;
tax, currency conversion and payment-processing costs.

The mature-provider market makes the disclosure gap visible. As of July 18, DigitalOcean published entry virtual machines from $4 a month, described per-second billing and separately priced backups and snapshots. Its backup documentation states frequency, retention logic and whether charges are a percentage of the server or based on restorable storage. OVHcloud’s UK VPS page displayed processor, memory, disk, bandwidth, tax-exclusive and tax-inclusive prices, a daily backup and a 99.9 per cent SLA. These disclosures do not prove either provider will meet every customer’s needs. They establish the amount of information a buyer can reasonably expect before purchase.

LIVI may intend to compete elsewhere: unusual locations, permissive workloads, wholesale address capacity, personal support or bespoke network engineering. A private-sales approach can price those services more accurately than a fixed catalogue. But the quote must reveal the economic bargain. “Unlimited” traffic needs a port rate and acceptable-use boundary. “Managed” needs a task list and response window. “Backup included” needs frequency, retention, location and restore cost. “DDoS protected” needs a threshold, scrubbing route and policy for attacks that exceed it.

Financial continuity is the other side of price. The absence of accounts is a consequence of age, not evidence of insolvency. It still removes a normal source of assurance. A customer can compensate by limiting prepayment, asking for trade references, splitting production across providers and ensuring that its data and domain are not collateral to the supplier’s cash position. For a large commitment, the customer can request evidence of insurance and the contractual status of leased equipment or address space.

The aim is not to inspect a founder’s private finances; it is to ensure the service can survive an unpaid upstream bill, hardware loss or a burst of abuse work.

Cheap hosting often becomes expensive at the boundary between self-service and human labour. A £5 server with a £100 emergency restore is not necessarily unfair if the division is explicit. A low-margin host cannot promise unlimited administrator time. LIVI’s opportunity is to make that boundary legible. Until it does, a buyer cannot compare total cost or tell whether the business economics can finance the promised support.

Backups, support and the continuity claim

For an SME, a host rarely fails in isolation. It fails inside a workflow. The website disappears, orders stop, staff cannot reach records, password-reset email stalls and a developer discovers that the latest usable backup is two weeks old. The value of the provider is not merely keeping a virtual machine powered; it is reducing the duration and irreversibility of that chain.

LIVI publishes no recovery-point objective, recovery-time objective, backup schedule or restore procedure. The correct response is not to assume there are no backups. It is to define which party owns each recovery action and test it.

A contract should distinguish at least four layers:

Infrastructure recovery: replacing a failed physical host, network path or storage component.
Virtual-machine recovery: restoring a disk image or starting the guest elsewhere.
Application recovery: bringing databases, queues, certificates and dependencies into a consistent state.
Business recovery: confirming that transactions, customer communications and staff workflows are correct.

A host may be responsible only for the first layer. If so, the buyer needs its own system for the other three. A managed provider may accept more responsibility, but that must be written. Ambiguity tends to survive until the first outage, when each side discovers it bought a different meaning of “managed”.

Backups should be treated as a product with measurable attributes. Where are they stored relative to the source? Are they encrypted, and who controls the key? Can a compromised control-panel account delete both server and backups? Are databases application-consistent? What is the oldest and newest retained point? How long does a full restore take under load? Is egress throttled? Does cancellation delete backups immediately, and can the customer export them first?

The customer should maintain an independent copy under an account it controls. That might be an encrypted database dump and entity archive at a second provider, plus infrastructure configuration in a separate repository. Independence matters more than branding: two products in the same account, facility or administrative domain can fail together. The customer should also monitor backup completion from outside the host and perform scheduled restores, because a successful job log is not a recovered business.

Support is similarly multidimensional. RIPE exposes [email protected] and a dedicated abuse role, which is better than an uncontactable route origin. Those addresses are network contacts, not evidence of a customer helpdesk. A service proposal needs to say whether support is email, ticket, telephone or messaging; whether it operates around the clock; what language it uses; how it authenticates sensitive requests; and who takes over when the first responder cannot fix a fault.

Founder-led support can be excellent. The person who designed the network may answer faster and with more authority than a large provider’s first line. It can also create key-person risk. The test is not whether the founder is reachable on a good day, but whether escalation continues during illness, travel, an upstream dispute or a multi-customer incident. Ask for a second contact, an on-call rota, documented access recovery and a way to communicate when the main domain or ticket system is unavailable.

An SLA should be read as a measurement contract, not a headline. Which endpoint defines availability? Does packet loss count? Is planned maintenance excluded without a cap? Does the customer have to file a claim within a short window? Are credits the sole remedy? A 99.9 per cent monthly target permits roughly 43 minutes of downtime in a 30-day month; 99.99 per cent permits about four minutes. Neither number says whether data will survive. The looping 99.98 per cent on LIVI’s maintenance page is not measured and has no remedy, so it belongs nowhere in a business case.

Routing hygiene is not the same as workload security

LIVI’s all-valid route-origin posture is the clearest positive technical control in public view. It shows that the visible announcements are authorised by address-resource holders and reduces one class of routing mistake. The breadth and visibility of the routes also show sustained coordination with upstreams. These are worthwhile signals for a company only months old.

They should not be allowed to carry more weight than they can bear. RPKI origin validation does not inspect the hypervisor, customer isolation, administrator access, firmware, patching, logging or backup encryption. A valid route can lead to an insecure server. A valid TLS certificate for the maintenance page proves control sufficient to obtain the certificate, not the identity of the company or security of a customer platform.

A security questionnaire should be specific to the offered service. For virtual machines, ask how tenants are separated, how host patches are rolled out, whether secure boot or measured boot is used, how management interfaces are isolated, and how console access is authenticated and logged. For dedicated servers, ask about media sanitisation, remote-management controllers, firmware and replacement disks. For managed hosting, ask who has root access, how privileged sessions are approved, and whether customer secrets are visible to support.

The public abuse picture requires similar restraint. ProxyDB reported a functioning SOCKS5 proxy on one AS212706 address between April and June. Scamalytics, looking across its own traffic visibility, classified the network as low risk while saying a small portion of observed addresses served public proxies. Neither source can establish whether the proxy was an authorised customer service, a compromised machine or an operator service. One address cannot characterise thousands, and commercial reputation datasets have uneven visibility.

Older reports attached to some prefixes are even less useful for judging LIVI because address space is mobile. At least one public reputation page lists reports from 2025, before LIVI was incorporated and before AS212706 was assigned. Those events must not be attributed to the company. They do, however, illustrate why a host taking over leased ranges needs a process for inherited reputation. A clean route authorisation does not reset blocklists, reverse DNS or the history held by mail and fraud systems.

A buyer should ask LIVI for its acceptable-use and abuse-handling policy, rate limits, outbound email controls, complaint response target and process for a customer assigned a tainted address. The provider should be able to explain how it distinguishes compromise from intentional abuse, preserves evidence, warns customers and avoids suspending unrelated tenants. A public status or incident page would help buyers separate network-wide faults from account enforcement.

There is no credible public evidence in the frozen source set of a disclosed LIVI outage, data breach or enforcement action. That sentence should not be read as a clean incident history. With a company this young and no status archive, the observation period and disclosure surface are too small. “No incident found” and “evidence of no incident” are different claims.

Jurisdiction follows access, not the flag beside an IP address

The legal and operational map crosses borders. LIVI is incorporated in England and Wales. Its sole director and controlling shareholder is resident in Russia. Its sponsoring LIR is a Russian company. Its corporate website sits in a Russian-registered ZTV address range. Its geofeed labels customer-facing prefixes in five European cities, while two of its observed upstream organisations are Dutch and one is American.

None of those facts is misconduct. Nationality is not a security finding, and a Russian-resident director can lawfully run a British company. Nor does a geofeed prove where data is stored or who can reach it. The combination matters because a customer cannot infer jurisdiction, access or subprocessing from the supplier’s UK registration alone.

The first compliance question is which legal entity signs the contract. The second is which separate entities can access personal data. The UK Information Commissioner’s international-transfer guidance makes a useful distinction: contracting with a UK provider does not become a restricted transfer merely because servers are geographically outside the UK, but the provider’s use of a separate overseas subprocessor or remote access by such an organisation may create one. The customer needs the actual flow of data and contracts, not an IP-location badge.

If LIVI processes personal information on a customer’s behalf, the parties need processor terms. The ICO’s controller–processor contract guidance covers documented instructions, confidentiality, security, subprocessors, assistance, audits and end-of-contract deletion or return. LIVI’s public site supplies none of this, so a buyer must obtain it privately before moving personal data.

The operational questions are concrete:

Where are primary data, replicas, snapshots, ticket attachments and monitoring logs?
Which companies provide the facilities, hardware, control panel, email and backup system?
From which countries can administrators connect?
Are overseas administrators LIVI employees or staff of separate organisations?
What technical controls restrict and record privileged access?
How are government or legal requests assessed and disclosed?
What happens to data when a subprocessor changes?

The answers may be reassuring. The network could be physically European, with the director administering systems as an employee of the UK company and no transfer to a separate overseas entity. Or services could rely heavily on a Russian supplier. Public evidence cannot decide. A data-flow map and subprocessor schedule can.

For sensitive work, a buyer should also ask for independent assurance scoped to the actual service and locations. A certificate held by an upstream or facility is not automatically inherited by LIVI. Conversely, a small provider without a costly certification can sometimes demonstrate strong controls through architecture, access logs, penetration testing and customer audit rights. The assurance must attach to the system being bought, not to a company somewhere in its supply chain.

The exit test should come before the uptime test

The largest switching cost in small-business hosting is rarely the virtual machine itself. It is the collection of dependencies that quietly grows around it: DNS records, mail reputation, hard-coded addresses, backups in a proprietary panel, firewall rules, certificates, cron jobs, monitoring and the one administrator who remembers how they fit together.

LIVI’s youth increases the value of an early exit test because there is little public evidence about contract renewal, product retirement or long-term support. It does not mean exit is inevitable. It means portability should be designed while everyone is cooperative.

The customer should own its domain registration and authoritative DNS account. It should avoid making the provider’s nameservers, email and identity service a single recovery dependency unless each has an independent escape path. DNS time-to-live values should support migration, and the customer should know how to update records if the hosting panel is unavailable.

Workloads should be reproducible from configuration rather than recoverable only as a provider snapshot. Databases need portable logical or physical backups. Images should use common formats where possible. Secrets should live outside machine images, and monitoring should run from another network. If LIVI offers a custom panel, test its export and API before building automation around it.

Address portability deserves explicit treatment. A small virtual-server customer usually cannot take a provider-assigned IPv4 address to another host. Moving changes allowlists, partner integrations and mail reputation. The exit plan should inventory those dependencies, use DNS names where appropriate and avoid hosting primary outbound email on an address whose history and replacement process are unclear. Larger customers buying transit or announcing their own resources need a different contract covering letters of authorisation, route objects, RPKI changes and withdrawal timing.

Contract language should set the notice period, the availability of service during notice, export bandwidth, assistance rates, final invoice, backup retention and deletion confirmation. If the supplier can suspend immediately for an abuse complaint, the customer needs a way to retrieve data and contest mistaken attribution without prolonging harm. If the supplier ceases trading, an external backup and documented rebuild should make the event inconvenient rather than existential.

An exit rehearsal also reveals the real support proposition. A provider confident in its service should be able to explain how customers leave. Obstructive exports create short-term retention and long-term distrust. Transparent exit can be a competitive advantage for a new operator because it lowers the risk premium buyers otherwise attach to its age.

The procurement decision: pilot the operator, do not outsource trust

LIVI occupies an unusual middle ground. It is much more substantial than its website suggests and much less commercially legible than its network footprint implies.

The positive case is real. The exact UK entity is linked through a public company number to a RIPE organisation, domain and ASN. The network became visible quickly, now originates a sizeable set of IPv4 routes and an IPv6 route, uses three observed upstreams and maintains valid route-origin authorisation. A dedicated abuse contact and a self-published geofeed show some of the operational housekeeping expected of a network. This is credible evidence of routing capability.

The limiting case is equally real. There is no public product definition, ordering surface, price, SLA, support commitment, backup policy, security description, processor contract, subprocessor list, status history, customer reference or exit policy. The associated website’s apparent operational metrics are generated in the browser. The company has no filed accounts because it is new, and the visible architecture depends on sponsors, address suppliers and upstream networks whose roles are not explained to a customer.

These facts support neither a blanket endorsement nor a claim that the company is fraudulent. They support a procurement status: evidence-gathering and reversible pilot only.

For a static brochure site with external backups and easy DNS migration, a well-priced LIVI server could be a rational experiment after the supplier identifies the contract and service. For an SME’s only domain controller, primary mail system, regulated customer database, booking engine or sole backup repository, the current public evidence is limited public evidence. Critical deployment should wait until the contract pack exists and the customer has completed support, restore and exit exercises.

The decisive qualification question can therefore be answered with precision. Does this exact legal entity operate a verifiable hosting service? It operates a verifiable hosting-class network. Public evidence does not yet prove a defined, generally purchasable hosting service or the continuity obligations attached to one. What would distinguish a real young operator from a registration plus a generic surface is not age alone, and not even an ASN alone. It is a continuous chain from legal counterparty to product, infrastructure, support, recovery and exit—tested by the customer.

What to watch next

The next year can add far more evidence than the first five months. Buyers and counterparties should watch for changes that close, or widen, the gap between network and proposition.

The website launch. A real commercial launch should identify LIVI HOSTING LTD and its company number; define products and locations; publish prices or a clear quotation process; and expose terms, privacy, support and status information. The maintenance clock should disappear rather than acquire more simulated indicators.

The first contractual documents. The most valuable new evidence would be a service description, SLA, acceptable-use policy, backup schedule, data-processing terms, subprocessor list and exit terms that all name the exact entity. Marketing claims should reconcile with those documents.

Route stability and dependency changes. AS212706’s prefix count, upstream set, RPKI validity and sponsoring organisation should be monitored. Prefix churn is not automatically bad in an address-leasing business, but unexplained rapid changes can affect reputation and continuity. Loss of one upstream should be tested rather than merely observed after an incident.

Support and incident history. A public status page with dated incidents, maintenance notices and honest post-incident explanations would be more persuasive than an unbroken 100 per cent graph. Buyers should retain their own ticket and monitoring history.

Customer proof. Named, contactable references using the service in a comparable way would establish far more than reverse-IP counts. A reference should say what was bought, for how long, how support behaved and whether a restore or incident was handled. Permission and confidentiality matter; private verification is acceptable.

Corporate filings and control. The first confirmation statement is due in February 2027 and the first accounts in November 2027. Those filings will begin to show continuity of control and, later, financial shape. Changes in director, registered office or ownership should be reconciled with contracts and payment details.

Domain and operational continuity. The public domain’s current registration period ends in February 2027. Routine renewal, a real service site, stable mail and independently reachable support would add modest but useful operational history. A domain renewal is not solvency evidence; an unexplained lapse would be an avoidable warning.

Young providers can become excellent suppliers. They can be closer to customers, quicker to customise and more disciplined than incumbents carrying years of technical debt. The responsible way to give one that chance is not to pretend that youth does not matter. It is to convert each unknown into a document or test, keep the first deployment reversible and let demonstrated behaviour replace the looping promise of fifteen more minutes.