Eternity Cloud Limited sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Eternity Cloud Limited is a new UK private company with a public hosting presence, an active AS number, and a small but visible IPv4 route. The official Companies House profile records incorporation on 27 October 2025, active status, a London registered office and a consultancy SIC code rather than a facilities or carrier classification.
• The company's own public site points users toward etyCloud, Whitewhale, identity, checkout and documents surfaces. The public ety.one site and the etyCloud site describe a cloud or hosting service, while Whitewhale advertises European VPS plans, own-AS routing, Tier-1 data-centre placement, DDoS protection and a 99.9 percent uptime promise.
• The network evidence is real but narrow. RIPE's AS201830 entity names Eternity Cloud Limited, RIPEstat shows one announced IPv4 /24 during the observation window, and RPKI validation marks the current origin for 82.41.36.0/24 as valid.
• The practical risk is dependency concentration. Public routing data points to a one-prefix footprint, a single observed neighbour in the current AS view, no visible IPv6 announcement, Cloudflare-fronted web and account surfaces, and no public facility list, maintenance history or incident record. That makes Eternity a plausible small hosting provider, not a proven multi-site infrastructure operator.

Why Eternity Matters Despite Its Size

Small hosting companies can look marginal from the outside because their legal filings are thin, their websites are simple and their route tables are small. That does not make them irrelevant. A low-cost VPS provider can still sit in the path between a developer and a live application, between a small business and its control panel, or between a regional project and the only server it can afford to operate. The infrastructure question is not whether Eternity Cloud Limited is large enough to compare with the biggest cloud platforms.

It is whether a buyer can understand what is actually being bought when the offer says cloud, VPS, European locations, own ASN, DDoS protection and cheap monthly capacity.

The public record gives a mixed answer. Eternity has more substance than a landing page alone. The UK company exists. The public company record names Eternity Cloud Limited as an active private limited company. RIPE records connect the company's name and London address to AS201830, and public routing data shows an IPv4 prefix originated by that AS. The service surface is not only a logo page: the etyCloud application presents a hosting account environment, and the Whitewhale page gives plan names, prices, resource sizes and network claims.

The same record also shows why the company should be read cautiously. Eternity was incorporated on 27 October 2025, so it had not yet filed a first set of accounts at the time of this review. The first accounts are due in 2027 according to the Companies House filing page. The capital statement visible in the incorporation filing is small. The registered office is a central London address often used by many companies, not evidence of a data centre. The officer and control records identify a single active director and significant controller, Mikhail Karlov, whose Companies House correspondence address is the same registered-office address. None of those facts makes the company suspect by itself. They simply define the starting point: a young operator with little public financial history and a narrow public operating footprint.

That distinction matters for infrastructure buyers because the risk in hosted capacity is rarely located in the marketing noun. "Cloud" is a commercial promise, but the service still depends on particular racks, upstreams, address blocks, DNS, identity systems, billing systems and support labour. If a server fails, a route is withdrawn, an account service rejects logins, a payment link breaks, a DDoS event triggers filtering, or a leased address block must move, the customer needs practical recovery paths. Public records cannot answer every support question, but they can show which dependencies are visible and which remain opaque.

Eternity's public footprint suggests a provider operating at the edge of that transition. It is visible enough to sell capacity under its own name and network number. It is not yet visible enough to let a buyer independently verify facility diversity, carrier diversity, hardware ownership, repair staffing, backup practice, incident transparency or migration guarantees. The result is a company that can be meaningful for low-cost hosting demand while still deserving a weak network-evidence grade for public assurance.

The Company Record Says New, Active And Closely Controlled

The legal starting point is straightforward. The Companies House profile lists Eternity Cloud Limited as company number 16810688, an active private limited company incorporated in England and Wales on 27 October 2025. Its registered office is 71-75 Shelton Street, London, WC2H 9JQ. The listed SIC code is 62020, "Information technology consultancy activities." The record says the first accounts are made up to 31 October 2026 and due by 27 July 2027, with a first confirmation statement due in November 2026.

For an infrastructure reader, those entries are less about formality than about maturity. A provider can begin trading before its first accounts are filed, but the absence of accounts means there is no public balance sheet, no filed turnover, no filed liabilities, and no audited or unaudited view of the assets behind the service. A hosted-capacity customer therefore cannot use the UK corporate record to infer the number of servers, the scale of supplier commitments, the volume of revenue, the level of working capital or the depth of repair resources. The record confirms existence and status. It does not confirm operating scale.

The control record is similarly concentrated. The officers page lists Mikhail Karlov as the active director, appointed on the incorporation date. The persons with significant control page lists Mr Mikhail Karlov as holding 75 percent or more of the shares, 75 percent or more of the voting rights, and the right to appoint or remove directors. Companies House also records an identity-verification due date in November 2026 for the officer and controller records.

Close control is common in early-stage hosting companies. It can make decisions fast, keep pricing aggressive and reduce bureaucracy. It can also create key-person risk. If routing, supplier relationships, billing disputes, abuse handling, identity recovery and customer support all depend on a small founding group, the service may be more fragile than the product page suggests. The public record does not show a board, a management bench or named technical staff beyond the company-associated NOC role in RIPE records.

A buyer therefore has to assume that continuity depends heavily on a small human layer unless Eternity publishes stronger operational disclosures.

The registered office also needs careful treatment. Shelton Street is a legal correspondence address in London. It should not be read as a hosting location or a network facility. RIPE records use the same address for the company and contact entities, but those records establish administrative contact, not rack location. The Whitewhale site speaks of European data-centre locations, and the routing data points to European upstream relationships, but the public company address itself is not evidence of servers in London.

That is a recurring theme in Eternity's public profile. The records are not empty. They simply do not do more work than they are built to do. Companies House proves that the company exists, is active and is controlled through a named person. RIPE proves that an AS and route objects have been registered. The service pages prove that someone is advertising VPS and cloud capacity under the Eternity/etyCloud/Whitewhale umbrella. None of those records, on its own, proves how much physical capacity is deployed, how repair windows are handled, whether spare hardware is stocked, or how a customer would be migrated during a supplier dispute.

The Service Surface Is A Cluster, Not One Product Page

Eternity's public-facing service is spread across several domains. The root ety.one site presents the Eternity brand and links to products, support, account sign-in and registration. Public page text and assets tie the brand to etyCloud and Whitewhale, and the footer uses the Eternity Cloud Limited name. The site also exposes public support contact points such as [email protected] and links to a document centre in English and Russian. That gives the brand more structure than a placeholder page, but the structure is still compact.

The etyCloud site is the direct cloud-hosting surface. Its public page description says in Russian that etyCloud provides reliable and fast hosting solutions for business and developers. The site title frames it as affordable hosting. Its application text shows user account actions, server ordering, invoices, tickets and server details such as processor, memory, storage, location, channel, storage type and price. The site therefore reads as a hosting control environment rather than a general corporate brochure.

That matters because a control environment is where cloud promises become operational promises. If a buyer orders a server through etyCloud, the experience depends on identity, account creation, payment generation, invoice handling, server provisioning, IP assignment, ticket routing and support response. Public site assets show those components exist as web interfaces. They do not prove how much automation sits behind them, how exceptions are handled, or whether server delivery is immediate, manual or supplier-dependent.

Whitewhale adds a more explicit commercial offer. Its English page calls Whitewhale a cloud provider on European locations, describes "own ASN AS201830," advertises plans from EUR 1 per month and lists support at [email protected] plus billing at [email protected]. The plan cards include KRILL at EUR 1 monthly with 1 vCPU, 2 GB RAM and 10 GB NVMe, NARWHAL at EUR 4 monthly with 2 vCPU, 4 GB RAM and 40 GB NVMe, ORCA at EUR 8 monthly with 4 vCPU, 8 GB RAM and 80 GB NVMe, LEVIATHAN at EUR 15 monthly with 6 vCPU, 12 GB RAM and 160 GB NVMe, and a WHITEWHALE+ custom tier from EUR 25 monthly. The page also advertises unlimited traffic, shared uplinks, DDoS protection, European locations and 99.9 percent uptime.

The Whitewhale page is useful because it makes the offer concrete. It is also where buyers should slow down. Very low prices and unlimited-traffic language can be legitimate when capacity is shared, oversubscription is managed and abuse rules are strict. They can also become pressure points when network events, noisy neighbours, support queues or supplier costs rise. Whitewhale's own comparison table says entry plans share 500 Mbps while other text on the page says high-speed uplink at 1-3 Gbps on all VPS.

That may be a presentation inconsistency rather than a service contradiction, but it shows why the exact committed rate, fair-use boundaries and congestion practice should be confirmed before relying on the plans for production workloads.

The product cluster also separates several roles that customers may experience as one service. Eternity is the UK company. ety.one is the brand and account gateway. etyCloud is the hosting application. Whitewhale is the VPS/cloud offer with the strongest public network claims. The identity surface is under auth.ety.one, and the payment surface appears under checkout.ety.one. The document centre is under documents.ety.one. In practice, a customer outage can arise in any of those layers. A server may still run while the account portal is unavailable. The account portal may be reachable while the customer's routed IP range is degraded.

Billing may fail while compute is healthy. The public footprint should therefore be read as a service chain, not a single system.

This is also where Cloudflare enters the picture. HTTP headers for ety.one, cloud.ety.one, auth.ety.one, checkout.ety.one, documents.ety.one and Whitewhale show Cloudflare at the web edge, and public DNS for ety.one, cloud.ety.one and whitewhale.help resolves to Cloudflare address space. That is a normal and often sensible choice for public web delivery. It also means the visible website path is not the same thing as the AS201830 customer-server path. Cloudflare can mask origin location, absorb some web-layer attacks and keep a marketing or account page reachable even when the provider's own routed prefix has a different problem. The web surface is evidence of service presentation, not proof of back-end compute resilience.

The Routed Network Is Real But Narrow

Eternity's strongest infrastructure evidence is in the routing record. The RIPE aut-num entity for AS201830 names the AS as ETERNITY-CLOUD-MNT, associates it with ORG-ECL85-RIPE, and records it as assigned. The entity was created on 29 January 2026 and last modified on 5 February 2026. It lists import and export relationships with AS16276 and AS24940. AS16276 is OVH, and AS24940 is Hetzner. Those are substantial European infrastructure networks, and their appearance in the policy record fits the Whitewhale claim of European hosting and own-AS routing.

The RIPE RDAP AS record makes the company connection clearer. It names the handle AS201830, gives the name ETERNITY-CLOUD-MNT, lists Eternity Cloud Limited as the registrant entity, and shows a NOC contact under the Eternity Cloud name. The address in those RIPE entities matches the London registered office. The RDAP record also lists an abuse contact associated with [email protected]. Taken together, these records show a real registered network identity rather than a marketing-only claim.

Routing visibility, however, is smaller than the existence of an AS can make it sound. RIPEstat's AS overview reports AS201830 as announced and names the holder as Eternity Cloud Limited. RIPEstat's announced-prefixes view shows one current IPv4 prefix, 82.41.36.0/24, during the observation window. RIPEstat's routing-status view for the AS shows one announced IPv4 prefix, 256 IPv4 addresses, full IPv4 visibility in the reporting set, no IPv6 announced space in that view, and one observed neighbour.

That is enough to say Eternity has a live routed footprint. It is not enough to say it has a broad network. A single /24 can support real customer service, especially for small VPS plans, but it also creates concentration. If the prefix is filtered, withdrawn, disputed, hijacked, blacklisted or exhausted, there is little public evidence of alternative address pools. If the observed neighbour count remains one, customer reachability may depend on one effective upstream path even if the registry policy lists more than one allowed provider.

If no IPv6 is visible, customers needing dual-stack service have to ask whether IPv6 is unavailable, unannounced, supplied through another path, or simply not represented in the current public view.

The prefix record adds another layer. RIPEstat's prefix overview for 82.41.36.0/24 identifies AS201830 as the announcing origin. The RIPE route object records origin AS201830 for that /24 and was created on 29 January 2026. RPKI validation reports the origin as valid, with a ROA allowing AS201830 to originate the exact /24. That is positive hygiene. A valid ROA reduces one class of route-origin ambiguity and helps networks reject conflicting invalid origin announcements.

The address assignment also carries a dependency clue. RIPE's whois data for 82.41.36.0/24 and RDAP IP record identify the netname NET-82-41-36-0-24, country EU, an end-user organisation linked to Eternity Cloud Limited, a route object maintained by netutils-mnt and a geofeed associated with IPXO. The address block is public and routed, but the maintenance and geofeed context points to an address-resource chain beyond Eternity itself. That is common in the IPv4 market. It is also relevant for customers because address-resource arrangements can affect portability, abuse handling, geolocation, reputation and continuity if a commercial relationship changes.

The visible path data reinforces the dependency picture. A RIPEstat looking-glass query for 82.41.36.0/24 shows many collectors seeing paths that end through AS16276 to AS201830. That aligns with the aut-num policy and suggests OVH is an important live upstream path for the announced prefix. It does not, by itself, prove facility location, spare upstream capacity or successful failover to Hetzner. A customer should treat the public path as evidence of reachability, not as proof of multi-carrier resilience.

Racks, Transit And Repair Windows Are The Hidden Product

The phrase "hosted capacity" sounds digital, but it is sold out of physical and contractual layers. Someone has to own or rent the servers. Someone has to provide power, cooling, cross-connects and remote hands. Someone has to carry packets to the rest of the internet. Someone has to maintain address records, route objects, RPKI and abuse mailboxes. Someone has to answer tickets when a server is down but the website is still up. The public evidence around Eternity identifies some of those layers, but it leaves the most operational parts unnamed.

Whitewhale says its infrastructure runs on European locations and top-tier data centres with redundant power and connectivity. It also advertises DDoS protection and an SLA of 99.9 percent uptime. Those are commercially meaningful claims. They also need detail before they become assurance. A 99.9 percent uptime promise can mean many things depending on whether it applies to network availability, server power, control-panel access, customer VM uptime, payment services, storage performance or support response.

It can also be measured over different periods, with different exclusions for scheduled maintenance, attacks, customer misconfiguration and upstream faults.

The public pages do not name the facilities, rack providers or cities behind the "European locations" claim. They do not publish a looking-glass page under Eternity's own branding, a network-status page, an incident archive, a maintenance calendar, a route-map, a list of transit providers in production, a BGP community guide, a DDoS mitigation partner, a hardware replacement target or a backup-retention promise. Some small providers choose not to publish those details for security or commercial reasons. But for a customer using the service as infrastructure, each missing detail becomes a question to ask before relying on it.

The first question is where capacity is physically hosted. If the servers are in OVH or Hetzner facilities, or in colocation connected to those networks, the reliability profile will reflect those suppliers' power, network and remote-hands rules. If the servers are rented dedicated machines rather than owned hardware, repair may depend on the supplier's support queue. If the servers are owned but placed in third-party racks, repair depends on spare parts, access rights and remote-hands response. If the provider resells virtual capacity from a larger platform while presenting an own-AS layer, the operational boundaries differ again.

Public records do not settle that question.

The second question is how upstream diversity actually works. The RIPE aut-num entity lists AS16276 and AS24940 policy entries. The RIPEstat AS view shows one observed neighbour. Looking-glass data for the current prefix strongly shows AS16276 paths. That does not prove that AS24940 is unused, but it means the public view at the time of review does not demonstrate active balanced diversity.

If an OVH-facing path fails, a buyer would want to know whether the route can move to Hetzner, whether that move is automatic or manual, whether prefix filters are pre-approved, whether DDoS scrubbing remains available, and how long convergence normally takes.

The third question is how addresses are governed. The 82.41.36.0/24 route is valid under RPKI, which is good. The block's whois and RDAP data also refer to netutils-mnt, IPXO geofeed information and an end-user organisation. That suggests an address-resource arrangement where more than one party's records matter. If geolocation is wrong, abuse reports are mishandled, a prefix develops a poor reputation, or the address contract changes, customers may experience problems that are not solved merely by rebooting a server.

Low-cost hosting buyers often underestimate this layer until email delivery, payment verification, regional access rules or fraud scoring begins to treat an IP range badly.

The fourth question is repair timing. The etyCloud interface appears to include tickets, invoices and server details. Whitewhale publishes support and billing email addresses. The root Eternity site publishes support contact information. Those are necessary customer channels. They are not the same as a published repair guarantee. A small provider may answer quickly, but a public buyer cannot infer 24/7 staffing, spare-capacity pools, escalation rights with upstreams, or post-incident communication from contact emails alone.

The Whitewhale page says support is 24/7, but customers should still ask how urgent outages are classified, whether credits are offered, and what information is provided during a network event.

The fifth question is customer exit. Cheap VPS capacity is attractive because entry cost is low. Exit cost can be high if a customer has no current backups, no documented rebuild steps, no DNS plan, no alternate IP path and no test migration. Eternity's public pages do not publish backup portability, snapshot export, data-erasure, image-download or emergency-migration guarantees. That does not mean those features are absent. It means buyers should treat portability as their own responsibility unless the contract says otherwise.

Cloudflare Protects The Front Door, Not Every Customer Server

The public web edge is a separate dependency from the routed hosting network. DNS answers for ety.one, cloud.ety.one and whitewhale.help point to Cloudflare anycast addresses, and HTTP responses identify Cloudflare as the server in front of the pages. The authentication endpoint under auth.ety.one returns a protected response rather than a public application page, while checkout.ety.one returns an application-style response at the root. The document centre under documents.ety.one is also Cloudflare-fronted.

That arrangement is sensible for a young provider. Cloudflare can absorb common web attacks, provide TLS termination, cache public pages, improve page reachability and reduce exposure of origin servers. It can also make the brand look more available than the underlying compute network during some incidents. A marketing page might be reachable through Cloudflare while a customer's VPS on 82.41.36.0/24 is unreachable. Conversely, a customer server might still run while the auth or checkout surface is degraded. For customers, those are different outages with different remedies.

This distinction is often missed in small-provider due diligence. A buyer loads the website, sees the page is fast, and assumes the hosting platform is similarly resilient. But the website path uses Cloudflare's network. The customer server path, if assigned from Eternity's current routed prefix, depends on AS201830, its current upstream path, the address block, the facility network and the server itself. The account path depends on auth.ety.one. The billing path depends on checkout.ety.one. The documentation path depends on documents.ety.one. The support path depends on email and ticket handling. These layers can fail independently.

The public DNS also shows Cloudflare mail-routing records for ety.one and Whitewhale. That is again normal, but it means email receipt for support and billing addresses has its own service dependency. If a customer outage includes inability to receive or send mail, support communication can be affected by DNS, mail routing, spam filtering, account access and human response. None of this is unique to Eternity. It is the ordinary stack behind small hosting providers. The risk is that the low monthly price makes the stack feel simpler than it is.

There is also a governance angle. Cloudflare-fronted public pages can be updated quickly and can hide origin topology. That is useful for security, but it reduces what outside observers can verify. The customer sees brand, plan and checkout. The network researcher sees one AS, one visible IPv4 prefix, valid RPKI and Cloudflare web surfaces. The missing middle is the production platform: hypervisors, storage, backups, facility contracts, transit failover and staff practice. A serious buyer does not need all of that published on a landing page, but should request enough detail to match workload risk.

What Customers Should Infer From The Pricing

Whitewhale's price ladder is one of the clearest public signals about the intended market. Plans starting at EUR 1 per month are not enterprise cloud offers. They are budget VPS offers aimed at developers, small projects, experiments and cost-sensitive workloads. That can be valuable. Many internet services start on inexpensive virtual machines because the alternative is not a hyperscale contract; it is not launching at all.

The question is what a customer gives up at that price point. Low-cost VPS providers usually rely on high utilisation, shared uplinks, tight abuse controls, simple support flows and limited bespoke guarantees. Whitewhale's page is open about shared bandwidth on plan cards, while also advertising unlimited traffic. "Unlimited" in this context should not be read as infinite dedicated capacity. It usually means there is no fixed monthly transfer cap under acceptable-use rules, not that every customer can saturate the shared uplink continuously without consequence.

A buyer should ask about fair use, throttling, DDoS thresholds, port restrictions, mail policy and what happens when traffic affects neighbours.

The plan table also points to hosting economics. The KRILL plan offers 1 vCPU, 2 GB RAM and 10 GB NVMe for EUR 1 monthly. Even at large scale, that price leaves little room for costly manual intervention. A support ticket that takes an hour can exceed many months of gross revenue for that customer. That does not mean support will be poor. It means the service must be standardized, automated and strict about scope to be sustainable. Customers with unusual needs should not assume custom engineering comes with a budget VPS plan unless it is explicitly sold.

Eternity's public account surfaces reinforce that self-service shape. etyCloud appears to present server ordering, tickets, invoices, server status and configuration fields. The checkout endpoint is separated under checkout.ety.one, and the identity surface is separated under auth.ety.one. That is a standard pattern for a small provider trying to reduce manual work. It gives customers a familiar way to buy and manage servers. It also means the control surface itself becomes part of the service. If invoices, payments or account access fail, server changes and renewals may be affected even when the underlying VM is still powered.

For production users, the pricing should lead to tiering. A EUR 1 or EUR 4 server may be fine for a monitoring node, test environment, personal project, small relay, staging workload or low-risk website. It is not automatically suitable for a revenue-critical application unless the customer has backups, monitoring, secondary DNS, a second provider, tested restore steps and clear acceptance of downtime. Eternity's public evidence does not justify treating the service as a sole-provider platform for high-value workloads without further assurances.

For privacy-sensitive or jurisdiction-sensitive users, the "European locations" language is attractive but incomplete. Whitewhale says locations are European and mentions GDPR/EU location in its comparison text. The RIPE prefix record lists country EU. The company itself is UK-registered, the controller's Companies House residence is Georgia, the officer nationality field says Russian, and the web edge is Cloudflare. None of that is inherently disqualifying. It simply means data-location and jurisdiction questions should be precise. Where is the VM host? Where are backups? Which legal entity contracts with the customer?

Which law governs the agreement? Which subprocessors handle identity, payment, DDoS filtering, email and support? The public pages do not fully answer those questions.

Abuse, Trust And The Cost Of Being Cheap

Any low-cost VPS provider has to manage abuse. Cheap, fast virtual servers attract legitimate developers and unwanted traffic alike. Spam, credential attacks, scanning, proxy resale, copyright complaints, payment fraud and DDoS retaliation can arrive faster than revenue. Whitewhale's page emphasizes clear rules and lawful use. RIPE records publish abuse contacts. Those are good signs, but abuse management is another area where the public record is thin.

The address block matters here. A single /24 contains only 256 IPv4 addresses. If a small number of customers burn reputation through spam, malware callbacks or proxy abuse, innocent neighbours can inherit the consequences through blocklisting, payment-risk scoring, CAPTCHAs, geolocation suspicion or mail rejection. RPKI protects route-origin validity; it does not protect IP reputation. Cloudflare protects public web pages; it does not make customer-origin traffic trusted. A customer using Eternity for outbound-sensitive workloads should test IP reputation and ask whether clean replacements are available if an address is already damaged.

The abuse contact structure is also split. AS RDAP data shows an abuse contact associated with ety.one. The prefix RDAP record for 82.41.36.0/24 lists an abuse email under abuseradar.com. That is not necessarily a problem; address-resource providers often manage abuse contacts for assigned blocks. But it means reports may pass through more than one organisation's handling rules. Customers who host user-generated content, mail, proxies, game servers or other complaint-prone services should understand whose decision can suspend a server, null-route an IP, or require customer information.

Trust is also shaped by documentation. Eternity's document centre provides a public legal-document surface with language options, and the root site links to subscription-agreement materials. The presence of documents is positive. The public buyer still needs to inspect the exact agreement used at signup, because small-provider terms often control the most important parts of the service: refund eligibility, renewal deadlines, cancellation, suspension, prohibited use, data retention, liability caps, SLA credits, jurisdiction and termination rights. The operational risk is not only whether the server is fast; it is whether the contract gives the provider broad rights to suspend service during disputes or abuse events.

Low-cost providers also live under supplier pressure. If upstream fees rise, a prefix lease changes, DDoS traffic increases, or a facility imposes stricter abuse rules, a small provider may need to change prices, locations, address ranges or terms quickly. Public customers should watch for signs of continuity: renewal notices, status posts, public incident explanations, stable support channels, clean route history and consistent pricing language. Eternity's current public footprint is too young to show a long pattern.

The Best Reading Of The Evidence

The generous reading is that Eternity Cloud Limited is a young, real provider assembling a European hosting offer around a UK company, its own registered AS, an IPv4 /24, Cloudflare-fronted public services, a self-service hosting interface and a budget VPS brand in Whitewhale. The company has registered the necessary public network entities, originated a valid route, published support and billing contacts, and presented concrete plan details. That is more than a vague company page.

The conservative reading is that the visible operating surface remains narrow. A single current /24 and one observed neighbour do not show broad network resilience. Public pages do not identify facilities, hardware ownership, active upstream diversity, repair commitments, backup guarantees or a long incident record. The company is newly incorporated and closely controlled, with no filed accounts yet. The web surfaces are fronted by Cloudflare, which improves public presentation but separates website availability from the availability of customer servers.

The address block appears to sit inside a broader address-resource chain, which is normal but adds another dependency.

Both readings can be true. Eternity can be a real small provider and still be a weakly evidenced infrastructure bet. That is the right category for buyers to hold in mind. The service may fit low-risk, cost-sensitive workloads. It may be useful as a secondary node, a test server, a small web host, a lab environment, a regional relay or a project that values low monthly cost over formal enterprise guarantees. It should not be treated as a proven resilient platform merely because it uses cloud language, advertises an own ASN, or has a valid route.

The most important upgrade would be operational transparency. Eternity could materially improve its public assurance by publishing a status page, a facility or metro list, a short network page naming active upstreams, an IPv6 plan, a route-looking-glass page, an abuse policy, an SLA document that defines measurement and credits, a backup and snapshot policy, and an incident archive. It could also clarify whether Whitewhale is a product of Eternity Cloud Limited, how etyCloud and Whitewhale relate contractually, which legal entity invoices customers, and which terms govern each service.

None of those disclosures require revealing sensitive topology. They would simply reduce ambiguity.

Customers can reduce their own risk without waiting. They should test a trial server before moving a workload, check latency and packet loss from relevant regions, verify outbound mail and payment-risk behaviour, confirm the assigned IP range, read the agreement, test support response, ask about backups, keep off-provider copies, use independent DNS, monitor from outside the network, and maintain a second provider for critical systems. The lower the monthly price, the more these customer-side controls matter.

Bottom Line

Eternity Cloud Limited should be read as an emerging hosting operator with a real but small public network footprint. The company exists in UK records, advertises hosting and cloud services through its own web properties, connects its brand to etyCloud and Whitewhale, holds AS201830 in RIPE records, originates 82.41.36.0/24, and has valid RPKI for that route. Those are meaningful facts.

The same facts do not prove that Eternity controls deep physical capacity, has redundant live transit, maintains spare hardware, operates across multiple facilities, or can restore customer service quickly during complex incidents. The product sold to customers is not only CPU, RAM and NVMe storage. It is a chain of rack access, supplier contracts, transit policy, address governance, DDoS handling, Cloudflare-fronted account services, payment paths, documentation, tickets and repair labour. Public evidence shows parts of that chain and leaves other parts unverified.

That makes the current evidence grade weak rather than negative. The provider is visible, routed and commercially present. The uncertainty is not whether there is any public footprint; the uncertainty is whether the public footprint can support the resilience implied by the word cloud. Until Eternity publishes more operating detail or builds a longer public history, buyers should treat it as a budget hosting option that may be useful in the right tier, not as an infrastructure dependency to trust without backups, monitoring and a clear exit path.