Summary
- LUNAR HOSTING LTD is an active British company incorporated on 19 April 2026. Its AS198685 currently originates two IPv4 /24 routes, one registered with a Germany country tag and a Falkenstein geofeed, the other with a Netherlands country tag. Current public observations show no IPv6 route and only one visible neighbouring network.
- The network evidence supports a limited conclusion: a small routed hosting footprint is operating under the Lunar name. It does not prove ownership of a data centre, server inventory, redundant power, independent transit, backup coverage, staffed support or a tested exit path.
- A buyer should treat resilience, data locality and recoverability as open contract questions. The most important evidence would be named facilities, hardware and upstream responsibility, tested restore results, service-specific availability terms, support escalation times and a documented method for exporting complete workloads.
A company can obtain an ASN faster than it can build resilience
LUNAR HOSTING LTD presents a compressed infrastructure story. The current British company was incorporated on 19 April 2026, with company number 17166654 and a registered office at 42 Rupert Street in London. The register describes it as active and gives it two business classifications: information technology consultancy, and data processing, hosting and related activities. The RIPE record for AS198685 was created the next day. By July, route collectors could see two IPv4 /24s originated by that autonomous system.
Those are not trivial achievements. An autonomous system number lets an operator express routing policy under its own identifier. A visible route means other networks are accepting and propagating a path to the addresses. A route-origin authorisation can tell validating networks that the named AS is permitted to originate a prefix. Together, these features are stronger operating evidence than a company name, a social-media page or a dormant domain.
They are still only the network edge of a hosting service. They do not say whether Lunar owns a single server. They do not show a lease for a rack, a power allocation, spare drives, remote-hands terms, backup media, a hypervisor cluster or a technician on call. They say even less about the commercial machinery around the machines: whether an invoice dispute can suspend a rack, whether a supplier can reclaim addresses, or whether a customer can extract a working image before a contract ends.
This distinction matters because small hosting companies often sell one commercial entity while assembling it from several physical and contractual entities. The customer sees a virtual private server, a dedicated machine or a managed service. The provider may be combining rented hardware, sub-allocated address space, a sponsored ASN, third-party transit, a facility contract, anti-DDoS filtering and a billing panel. Each component can be legitimate and competently run. But each also has its own renewal date, failure mode and party with the power to disconnect it.
The public evidence therefore supports a narrow description. Lunar is a newly incorporated UK hosting-related company associated with a recently assigned ASN and a small, globally visible IPv4 footprint. It does not support the larger claim that Lunar owns a data centre, controls multiple independent sites or has demonstrated continuity under failure. That larger claim would require evidence closer to the machines and contracts than the routing table provides.
There is also an older British company with the same name, company number 15058184, which was dissolved on 14 January 2025. Its registered address and business classification differ from the active company. Nothing in the current network record requires the two companies to be connected, so the dissolved namesake should not be used to infer history, liabilities or continuity for company 17166654. The safest anchor is the active company number repeated in the current RIPE organisation record.
Two /24s are visible capacity, not a census of machines
On 12 July 2026, RIPEstat's announced-prefix view listed 144.31.136.0/24 and 94.183.224.0/24 under AS198685. That is 512 IPv4 addresses in routeable blocks. Its routing-status view showed both prefixes visible to all 326 IPv4 peers in the relevant RIPE Routing Information Service sample. It showed no announced IPv6 space.
The address count is useful, but only within strict limits. A /24 can support many customer addresses, a smaller number of network-address-translated services, infrastructure interfaces, spare assignments or addresses withheld because of reputation and operational policy. It can sit in front of a large virtualisation cluster or a very small set of hosts. It can also move between physical suppliers while the customer-facing IP remains unchanged. Counting addresses cannot reveal processor cores, memory, storage throughput, oversubscription, rack density or the number of paying tenants.
The difference between installed and usable capacity is wider still. Installed capacity is what exists in a rack or supplier account: machines, disks, ports and licensed software. Usable capacity is what can be sold without violating performance targets, redundancy reserves or repair assumptions. If ten servers are installed but every customer depends on the same storage controller or top-of-rack switch, the useful failure tolerance may be much smaller than the server count suggests. If every address leaves through one external path, adding machines increases revenue capacity without increasing route diversity.
Lunar has not published enough verifiable material to calculate either measure. There is no public inventory tying the two prefixes to host counts, processor generations, storage design or reserved spare capacity. There is no public utilisation series that would show whether the service is empty, comfortably loaded or running near a resource boundary. A secondary network-data service, IPinfo, classified the AS as hosting, counted a small set of hosted domains and described around-the-clock activity when observed. Those are useful signs that the addresses carry traffic. They cannot identify customers, validate invoices or prove that the advertised commercial capacity is available.
This is where hosting economics becomes physical. A low-cost virtual server can be created in seconds only because somebody previously bought or rented a chassis, powered it, connected it, installed storage and reserved enough memory to admit another guest. The marginal act is digital; the capacity underneath it is not. When a provider has a thin public footprint, a customer cannot safely substitute the speed of provisioning for evidence of sustained headroom.
A serious capacity statement would identify the service class and its limiting resource. For a virtual server, that might include whether CPU is dedicated or shared, whether storage is local or networked, what IOPS limit applies and how much host failure reserve exists. For bare metal, it would include stock status, replacement-part targets and whether equivalent hardware can be provided at another site. For managed service, it would include the labour boundary: who patches the host, who responds after hours, and how quickly the provider will act when the customer cannot reach the machine.
Without those disclosures, the strongest statement is that Lunar controls the current origin of two globally visible IPv4 routes. That is real network capacity. It is not a reliable proxy for compute capacity, storage durability or the number of failures the service can absorb.
The location evidence points to Germany and the Netherlands, with important caveats
The two address blocks carry different locality signals in RIPE records. The inetnum entity for 144.31.136.0/24 labels the block lunar-cloud, gives it a Germany country code and links a geofeed that places the /24 in Falkenstein. The inetnum entity for 94.183.224.0/24 labels the block LUNAR_HOSTING_LTD and gives it a Netherlands country code. These fields are relevant because they are specific assertions attached to the address resources.
They are not a substitute for a facility address. RIPE country fields are administrative attributes, and a geofeed is an operator-published location statement intended to improve IP geolocation. Neither establishes where a disk is bolted into a rack, where backups are copied, or from where an administrator can access customer data. The NCSC's asset protection and resilience guidance explicitly separates countries of storage, processing and management from the legal base of the provider, the support location and ownership of the physical data centre. Lunar's public record leaves most of those layers unnamed.
Falkenstein is specific enough to form a testable hypothesis: at least some addresses in 144.31.136.0/24 are intended to be represented as being in that German city. It is not enough to attribute Lunar's hardware to any particular facility operator. Several companies operate infrastructure in and around major European hosting locations, and an IP location alone does not identify the landlord, the server owner or the remote-hands contractor. The Netherlands tag on the second block is broader and provides no public city-level anchor in the RIPE entity reviewed for this article.
The corporate and web layers add more geography without resolving the physical question. Lunar is registered in Britain. Its lunarhost.pro domain redirected to lunarcloud.ru when tested on 12 July, while the destination presented an anti-DDoS verification page. The storefront's DNS endpoint was not in AS198685. This separation is ordinary in hosting: a sales site may use a protective edge even when customer servers use the provider's own routes. It also means that the continued availability of the web page says little about the health of customer machines, and an outage in AS198685 need not take the sales site down.
For a UK customer handling personal information, the correct question is not simply, "Is the provider British?" The ICO's updated international-transfer guidance asks organisations to understand the separate legal entities, contracts and information flows involved. Remote access by a separate overseas organisation can matter even if the bytes remain on a server in Europe. Conversely, traffic merely transiting another country is not automatically the same as a restricted transfer. The factual map has to include storage, backup, administration and support.
Lunar's two country-tagged prefixes make data locality a first-order due-diligence issue, not a resolved selling point. The evidence needed is concrete: the facility country selected for each service, whether the location can change, where replicas and support access reside, which subcontractors can touch the system, what notice accompanies a move, and what happens to residual copies after termination. An invoice naming a region is useful only if the technical and contractual arrangements enforce it.
The ownership boundary is the centre of the risk
The current RIPE records show that Lunar's network relies on resources and organisations beyond the company itself. AS198685 is a sponsored assignment. The two IPv4 blocks are provider-aggregatable space rather than a clearly documented direct allocation owned outright by Lunar. The 144.31.136.0/24 entity is marked as sub-allocated provider-aggregatable space; the 94.183.224.0/24 entity is assigned provider-aggregatable space. These labels do not make the service inferior. They do show that continued use depends on upstream commercial and registry relationships.
That dependency is visible in the route history. Before AS198685 became the stable observed origin, the same /24s appeared under other origins at different times. The 144.31.136.0/24 history shows several origin changes before the Lunar route. The 94.183.224.0/24 history is even more active in 2026, with multiple origins preceding AS198685's current announcement. Address leasing and re-origination are common in a market where IPv4 scarcity has made blocks valuable and portable. For customers, the operational question is whether the provider's rights to use the addresses last at least as long as the service they underpin.
The public aut-num entity declares import and export arrangements with AS212743 and AS213529. Yet RIPEstat's observed-neighbour view showed one current neighbour, AS202413, for the review date. Registry policy declarations and observed paths answer different questions and can change at different speeds. The mismatch is not proof of a fault. It is evidence that a static record should not be read as a live topology map.
This is the practical ownership stack a customer needs to understand. Lunar may own the customer contract and operate AS198685. Another party may sponsor the AS. One or more parties may supply the address blocks. Another may provide transit. A facility company may control power, cooling and physical access. A hardware lessor may own the servers. A mitigation provider may protect the public website or service traffic. Every layer can have a right to suspend service if its own bill, abuse policy or contract is breached.
The worst failures in this structure are not always technical. A disk can be replaced. A fibre can be repaired. A supplier dispute can deny the provider physical access or remove addresses with little time for orderly migration. A small operator can be technically competent and still have weak bargaining power with a landlord or lessor. That is why proof of corporate existence and proof of route control need to be joined by proof of durable supplier rights.
Customers do not need every commercial term disclosed publicly. They do need contractual assurances that map to the dependencies: notice before address or facility migration where feasible; a defined response if a supplier terminates service; continued access to customer data during an orderly exit; and a clear account of which party is responsible for equipment, power, transit and physical intervention. A provider unable to name those boundaries leaves the customer carrying risks it cannot monitor.
Route security is a positive signal, but path diversity is not demonstrated
Both observed prefixes had valid route-origin authorisations for AS198685 when checked through RIPEstat. For 144.31.136.0/24, the validation result named AS198685 as the valid origin while treating several other possible origins as invalid under the current authorisation. For 94.183.224.0/24, the valid authorisation likewise pointed to AS198685. This is a worthwhile control. Networks performing route-origin validation can reject an announcement whose origin conflicts with the authorised AS, reducing one class of accidental or malicious mis-origination.
Route-origin validity does not say that the path is redundant, short or uncongested. It validates the relationship between a prefix and the origin AS, not the full sequence of networks carrying traffic. It does not prevent a correctly originated route from disappearing because a router loses power, a transit invoice goes unpaid or the only external session is reset. It also does not secure the server behind the address.
The main resilience warning is the single observed neighbour. RIPEstat counted one unique adjacent AS and IPinfo independently described AS198685 as a single-homed stub. Measurements can miss private interconnections or backup sessions that are idle, and an operator may have multiple physical circuits to one transit network. Even with those caveats, the public view does not demonstrate independent upstream diversity. The absence of a PeeringDB network record removes another common place where operators disclose facilities, exchange points and peering policy.
The distinction between two links and two fates matters. Two cables to the same upstream router can fail together. Two routers in the same room can lose the same power feed. Two carriers can lease the same duct. Two addresses in different /24s can still terminate on the same host. Real diversity requires separation at each relevant layer: physical path, router, upstream network, power domain, facility and operating team. A route table can expose some of that structure, but not all of it.
The Internet Engineering Task Force's site-multihoming goals describe the failures redundancy is meant to survive: physical cuts, router faults, routing-session failures, provider failures and exchange failures. Against that standard, Lunar's public evidence establishes reachability but not continuity. There is no visible proof that traffic fails over to a second independent transit provider, nor a published test showing how long convergence takes and whether existing sessions survive.
The lack of IPv6 is a separate constraint. It does not make an IPv4 hosting service unusable, and many customers still operate comfortably on IPv4. It does mean the public network footprint is not dual-stack and that customers needing native IPv6 cannot infer a route from the ASN record. It also concentrates all publicly observed service addressing into two scarce IPv4 blocks whose supplier terms matter.
The appropriate conclusion is balanced. Lunar has done something positive by authorising its current origins and keeping both routes globally visible. That reduces one routing risk. The same evidence does not demonstrate a second independent path, and the current observed topology suggests that an upstream or adjacent-network failure remains a material common-mode event.
A rack failure turns a virtual promise back into hardware
Virtualisation changes the unit sold, not the physics beneath it. A customer may buy vCPU, RAM and storage by the month, but those resources still reside on processors, memory modules, drives, network cards and switches. Their continuity depends on power feeds, cooling, firmware, hypervisors and the ability of a person to reach a failed component.
Lunar has not publicly identified whether customer capacity is on owned servers, rented dedicated machines, nested virtual servers or a mix. Each model produces a different failure path. Owned servers give the operator more control over configuration and spares but require capital and logistics. Rented hardware can speed expansion but leaves replacement timing and access with the supplier. Nested virtualisation can make capacity very flexible while adding another control plane and another provider whose limits may be invisible to the end customer.
Consider a single host failure. If customer disks are local and there is no live replica, every guest on that host remains unavailable until the machine is repaired or its drives are moved. If storage is shared, compute can be restarted elsewhere, but the shared storage becomes a larger concentration of risk. If replicas exist in the same rack, a rack power or top-of-rack switch failure can disable both copies. If replicas exist in another facility, recovery is stronger, but replication lag, bandwidth and orchestration determine how much data and time are lost.
The words "backup" and "snapshot" are particularly easy to overvalue. A snapshot on the same storage system may help undo a customer error but may not survive storage loss. A backup in the same administrative account may be deleted by the same compromised credentials. A replica may faithfully copy corruption. The NCSC's resilience guidance recommends the ability to return to a known good state and stresses that service design, rather than an availability credit, prevents loss.
A useful claim therefore needs a recovery point objective, a recovery time objective, isolation from the primary failure domain and evidence that restores have been tested.
Hardware stock is another hidden constraint. A provider can have spare compute capacity but no compatible drive, power supply or network card on site. Replacement may then depend on a courier, customs, a supplier's warehouse and a facility access window. For a newly incorporated operator with an undisclosed hardware base, there is no public evidence of stocked spares or guaranteed replacement times. Customers should distinguish a support response target, which may mean only that a ticket is acknowledged, from a repair or restoration target.
Maintenance introduces planned versions of the same risk. Firmware changes, switch replacements and power work can be harmless when capacity is drained and redundant paths are proven. They can become outages when the backup path has not carried production load or when guests cannot move because of storage or processor incompatibility. Lunar has not published a maintenance policy, notice period or maximum emergency window that could be verified for this review.
The rack-level conclusion is therefore not that Lunar's machines are unreliable; their identity is not public enough to judge. It is that the service promise cannot be separated from unverified physical dependencies. Until the company names its facility model, hardware responsibility, spare policy and restore design, customers should assume that a fault may require third-party labour and that recovery time is not established by the speed of the control panel.
Transit failure can isolate healthy servers
A server can be powered, cooled and running correctly while being unreachable to every customer. That is the defining risk of transit dependency. The host still executes instructions, but the route that gives its address meaning has disappeared or degraded.
For AS198685, the public route collectors saw one adjacent network. That makes several scenarios important. The BGP session could reset. The neighbour could withdraw Lunar's prefixes. A physical cross-connect could fail. The upstream could experience congestion or an internal routing fault. A denial-of-service response could discard legitimate traffic along with an attack. A contractual issue could cause the upstream to suspend service. The result for an end user is similar in each case: the IP stops responding or becomes unusably slow.
Two announced /24s do not solve that problem if both leave through the same neighbour. Nor does valid route-origin authorisation. A second block can help with address management and supplier transitions, but redundancy comes from a viable alternate path carrying or ready to carry the route. Public observations do not show that alternate path.
There are possible mitigations the public view would not see. Lunar could maintain a cold backup session, use tunnels to a second network, buy multiple circuits from the same provider, or arrange emergency re-origination. Each can reduce some risk. Each also needs testing. A cold route may take time to propagate. A tunnel may traverse the same failed carrier. A second circuit may enter the building through the same duct. Emergency re-origination may conflict with route filters or current authorisations if it was not prepared in advance.
Customers also need to understand denial-of-service protection as a path with its own capacity and rules. The public web domain's anti-DDoS edge protects the storefront observed during this review, but it does not prove that the two customer-service prefixes receive the same protection. Scrubbing may be always on, activated on demand or limited by attack type and contracted volume. A provider can remain reachable at its support site while customer addresses are null-routed. The reverse can also occur.
Performance failures are subtler than total withdrawal. A single upstream can remain visible to route collectors while suffering packet loss on one regional path. Customers in one country may see severe latency while others see normal service. The route's existence does not measure application quality, and a single global looking-glass trace is not a service-level history. Useful evidence would include diverse probes, loss and latency over time, incident records and the ability to move traffic when one path degrades without disappearing entirely.
The most revealing question for Lunar is not, "Do you have redundant networking?" It is, "Which exact failures can the current design survive without changing customer IPs, and when was each failover last tested under load?" A credible answer would name independent transit providers, physical handoffs, facilities, route policies and expected convergence. In the absence of that answer, the visible one-neighbour topology should be treated as a concentration risk.
Support labour is part of the infrastructure
Hosting is often described through machines because machines are countable. During an incident, labour becomes the scarce resource. Someone has to classify the fault, decide whether it is customer configuration or provider infrastructure, contact the facility, authorise a reboot, replace hardware, change a route, restore a backup, communicate status and prevent hurried recovery from making the damage worse.
The Companies House officer page listed one active director for Lunar at the time of review. That says nothing definitive about staffing; a company can employ people, use contractors or share operations with another service. It does mean public corporate records do not reveal a broad leadership bench. The service site did not yield a verifiable public staffing rota, network operations centre description or escalation map during this research.
Thin disclosure matters most outside ordinary hours. An automated monitor may detect a failed host immediately, but restoration still depends on authority and access. Can the first responder change a route? Can that person enter the facility or instruct remote hands? Is a second engineer available to review a destructive storage command? Does the upstream accept urgent requests around the clock? Is customer communication handled by the same person repairing the fault?
Small teams can operate reliable services by reducing variation, automating routine actions, documenting supplier contacts and buying strong facility support. They can also become overloaded when several customers report the same incident, because ticket volume rises just as technical work becomes most urgent. A one-hour first response is not the same as a one-hour restore. A claim of continuous support is meaningful only if it identifies the channel, response target, escalation level and activities covered.
Abuse handling is another labour dependency for a hosting network. The RIPE record publishes an abuse contact, which is a necessary public route for reports. Hosting addresses attract complaints ranging from compromised websites to scanning and copyright disputes. Poor handling can damage address reputation or provoke an upstream suspension; overaggressive handling can disconnect an innocent customer. The operator needs enough staff and evidence to make timely, proportionate decisions.
Billing support can become operational support when service access is automated. A failed renewal, fraud flag or payment-provider error can suspend a server even though every technical component is healthy. Customers need to know whether data remains recoverable after suspension, how long it is retained, whether an appeal pauses deletion, and how an urgent billing error is escalated. These policies are especially important when the provider's public capacity and ownership chain are not well documented.
The NCSC's operational security principle treats vulnerability management, monitoring, incident response and change management as service properties. That framing is useful here: people and decisions are part of the hosted product. Lunar's public network records show addresses and routes, but no equivalent public evidence yet establishes patch times, incident notification, change notice or support depth.
Migration is the recovery path for failures the provider cannot fix
Every hosting assessment eventually reaches the exit question. Redundancy tries to keep a service running inside the provider. Portability lets the customer recover when the provider, supplier relationship or commercial arrangement itself is the failed component.
Portability is more than downloading files. A working service may include virtual disks, entity data, relational state, DNS zones, certificates, firewall rules, private networks, assigned IPs, monitoring history, access logs, automation credentials and documentation known only to the people who built it. The more of those elements remain trapped in a proprietary control panel or an inaccessible provider account, the longer a migration takes.
Lunar has not published a verifiable export specification for the reviewed service footprint. It is therefore unknown whether a customer can obtain a complete disk image, which formats are supported, whether large exports incur transfer charges, how quickly a terminated account is erased, or whether a failed server can still be exported. It is also unknown whether customer IP addresses are portable. Given that the visible prefixes are provider-aggregatable space supplied through other parties, a typical small customer should assume the assigned IP stays with the provider unless a contract says otherwise.
That assumption has consequences. Moving a web server to a new address may require DNS changes, certificate checks, firewall updates, allow-list changes and time for caches to expire. Moving mail service can disrupt sender reputation and reverse DNS. Moving an application that partners have hard-coded to an IP can take longer than moving its disk. A provider can make compute portable while the address remains the strongest lock-in.
The safest migration design begins before an incident. Customers can keep infrastructure definitions outside the provider, maintain independent copies of encryption keys and DNS access, export application data regularly, and test restoration onto a second environment. Those actions are customer responsibilities, not substitutes for provider clarity. Under the NCSC's shared-responsibility model, security and availability duties depend on the service model and must be understood by both parties.
An exit test should be timed and complete. The relevant measure is not how quickly a file can be downloaded, but how long it takes to restore a functioning service elsewhere with acceptable data loss. The test should include the largest realistic data set, dependencies such as DNS and certificates, and validation by someone other than the person who designed the original deployment. If it has never been done, portability remains an aspiration.
Provider-contract failure deserves its own scenario. If Lunar loses a rack, address supplier or transit agreement, can it retrieve customer data and move services before termination? Does it have a contractual cure period? Can customers contact the underlying facility, or would that violate security and commercial boundaries? Are backups held under a separate account that survives the primary supplier dispute? Public records do not answer these questions, but the layered resource structure makes them material.
For customers, the migration path is the ultimate limit on dependence. A low monthly price can be rational even with modest redundancy when the workload is easy to recreate elsewhere. The same service can be a poor bargain for unique data or a hard-coded public endpoint if exit takes weeks. Lunar's current evidence is not strong enough to price that risk for the customer; only service terms and a restore test can do so.
Data sovereignty is a map of control, not a flag on an IP
The Lunar footprint crosses several administrative signals: a British company, a Germany-tagged block with a Falkenstein geofeed, a Netherlands-tagged block and a web destination under the Russian country-code domain. None of those facts alone identifies the jurisdiction governing every copy of customer data.
Data sovereignty begins with location but extends to control. A disk may sit in Germany while support staff in another country can open its management console. A backup may be copied to a second region. Logs may go to a monitoring service elsewhere. A billing provider may hold customer identity and payment data in yet another jurisdiction. An incorporated British reseller may contract with a non-British infrastructure supplier. Each relationship changes which organisation can access information and which legal process may reach it.
The ICO makes a useful distinction between transfer and transit. Packets routed through another country are not necessarily a restricted transfer if information is going between UK organisations without being accessed or stored there. Making personal information accessible to a separate overseas organisation can be a transfer even without a bulk copy. This is why traceroutes and IP geolocation cannot complete a legal assessment. The contracts and access design matter.
Lunar's public material does not identify a processor chain, support countries, backup locations or customer-selectable residency controls. The Germany and Netherlands tags are therefore best treated as leads. A customer seeking a particular residency outcome should require the service order to name the selected location, restrict moves and remote access, identify subprocessors, describe backup geography and provide notice of changes. The same terms should cover metadata and logs, not only primary storage.
Encryption changes exposure but does not erase every locality issue. Customer-held keys can reduce the provider's ability to read stored data, provided snapshots, logs and memory are treated consistently. It does not keep an application available during a facility outage, and it does not make an undeclared transfer acceptable by itself. It may also make recovery impossible if key custody is poor. Location, access, encryption and recoverability should be analysed together.
The absence of native IPv6 does not directly determine sovereignty, but it illustrates the broader point: the service characteristic must be observed and contracted, not inferred from a cloud label. In the same way, a UK company number does not turn every server into a UK region, and a German geofeed does not prove German-only administration.
Customers with no regulated or sensitive data may reasonably accept broad location flexibility in return for price or performance. Customers with legal, contractual or client-imposed residency duties need a higher standard of proof. At present, Lunar's public footprint does not provide that proof. It does provide enough information to know which questions must be answered before the service is treated as local to any one jurisdiction.
What would move the evidence grade
Lunar's route visibility is stronger than its general public profile. The company is active, AS198685 is announced, two /24s are visible and both current origins validate under route-origin authorisation. Those facts justify describing a live small network footprint. The grade remains Weak because the evidence does not reach the service's physical, contractual and recovery layers.
Several disclosures would materially improve confidence. First would be a location and ownership statement that names the countries and facility operators used for each service class, while distinguishing owned equipment from rented servers. It need not reveal rack numbers or security-sensitive diagrams. It should identify who controls power, cooling, remote hands and replacement hardware.
Second would be a current network statement. It should explain whether AS198685 has one or multiple independent upstreams, whether physical paths and edge routers are diverse, which prefixes receive denial-of-service protection, and whether native IPv6 is planned or available through another service. A public PeeringDB entry and consistent RIPE policy entities would make the topology easier to verify, though observed routes would still be needed.
Third would be service-specific availability and maintenance terms. A useful document would define what counts as unavailable, the measurement point, excluded events, notice for planned work, emergency maintenance treatment, support response targets and the remedy. Credits alone do not create resilience, but precise terms show what the provider is willing to measure.
Fourth would be recovery evidence: backup scope, isolation, retention, customer controls, recovery point and recovery time targets, and dated restore-test results. The strongest version would separate host, rack and site failures and state which service tiers survive each one. A statement that backups exist, without a restore result, would be only a small improvement.
Fifth would be portability terms. Customers should know the available export formats, transfer limits and charges, retention after suspension, deletion timing, access during termination and whether IP addresses can move. A documented migration exercise to another provider would convert an abstract exit promise into operational evidence.
Finally, Lunar could publish a concise supplier and jurisdiction account: the legal entity contracting with the customer, the entity operating the network, the categories of infrastructure and support subcontractor, and the countries from which customer data may be stored or accessed. This would help customers reconcile the British company with the Germany and Netherlands network tags.
None of these requests assumes that a young or small provider is unsound. Small operators can offer close support, simple products and good value. The point is to align the claim with the evidence. Today, the visible network proves more than a mere registration but less than a resilient cloud. The most defensible reading is that LUNAR HOSTING LTD sells capacity at the top of a chain whose racks, transit, repair labour and supplier rights remain largely outside public view.
The purchasing decision should follow the workload's tolerance for uncertainty
For an easily rebuilt development server, a temporary relay or a replicated edge node, Lunar's small public footprint may be an acceptable risk if the price and direct service experience are good. The customer can keep authoritative data elsewhere, automate replacement and treat an address change as routine. In that use case, the missing public details are a reason to limit exposure rather than reject the service outright.
For the only copy of business data, a latency-sensitive production system, regulated personal information or a public endpoint that cannot change quickly, the same uncertainty has a different cost. A single observed neighbour, unverified site redundancy, unknown spare stock and undocumented export path become part of the system's own risk. The customer would need direct contractual evidence and independent backups before relying on the service.
The relevant questions are concrete. Which legal entity signs the order? Which facility and country hold the primary data and backups? Who owns the server? What happens if the host, rack, route or supplier fails? Which path is genuinely independent? How quickly can an authorised engineer act? What exact state can be exported? How long is data retained after suspension? When was a full restore last completed, and how long did it take?
Answers should be consistent with the public record. If a service is sold as Germany-located, the facility and backup statement should align with the Falkenstein geofeed or explain why it does not. If the provider claims diverse transit, current route observations should eventually show more than one viable neighbour or the provider should explain the standby design. If an availability claim depends on multiple sites, the service architecture should identify the failure domains and replication behaviour.
Customers should also monitor change. The present company and ASN are only months old. Address origins, neighbours, web destinations and supplier relationships have already changed over a short period. That can reflect normal construction of a young network. It also means an assessment made once will age quickly. Route visibility, authorisations, service terms and export capability should be rechecked at renewal and after any announced move.
The final judgement is deliberately limited. LUNAR HOSTING LTD has enough current evidence to be treated as more than a paper company: its autonomous system originates globally visible address space, the origins are authorised and secondary measurements see hosting-like activity. It does not yet have enough public evidence to treat the offered capacity as multi-site, independently connected or demonstrably recoverable.
That gap is the centre of the story. Hosted capacity feels abstract only while every dependency works. A rack fault makes it hardware. A route withdrawal makes it transit. A failed drive makes it spare stock. An unanswered incident makes it labour. A terminated supplier agreement makes it contract law. An untested export makes it customer lock-in. Lunar's public network is visible; the resilience behind it is not yet visible enough.