Summary

  • XServerCloud's Ukrainian identity is supported by more than branding. RIPE records tie AS48031 and AS202656 to the XServerCloud name, Vitaliy Ivanov, Kharkiv contact details and the same Ukrainian telephone number shown by the service. AS48031 was registered in 2008, close to XServer's claimed 2007 operating start.
  • The current contracting party is much newer. XServer's public offer names XServer OÜ, while Estonia's official business register says that company was entered on May 20, 2026, with Vitalii Ivanov as management-board member and direct beneficial owner. That aligns the new company with the founder, but it does not make the Estonian company itself 19 years old.
  • Service-proof records are unusually accessible. XServer publishes IPv4 and IPv6 test endpoints for Kyiv, Sofia, Gdynia, Frankfurt, Amsterdam, London and Miami. The IPv4 endpoints are originated across AS48031, AS202656 and, in Miami, AS204957 registered to Green Floid LLC, showing a mixture of XServer-registered and partner network surfaces.
  • The largest assurance gap is contractual consistency. The home page says 99.9 per cent uptime, the public offer says the contractor will endeavour to maintain 99.5 per cent monthly availability, and the detailed SLA address named in those terms returned no page. Backup inclusion, support response and legal-locality statements also vary across the public site.

One cloud name, several kinds of identity

The quickest way to misunderstand a hosting company is to ask where it is from and accept one country as the complete answer. A provider can have its founder in one country, network registrations in the same place, a contracting company somewhere else, machines in seven countries, an email supplier in another jurisdiction and customers everywhere. Each fact may be true. The risk begins when they are treated as interchangeable.

XServerCloud is a particularly clear example. The BTW directory record identifies XServerCloud as a company associated with AS48031. XServer's own company history says the business began in 2007, first selling inexpensive self-built servers, then offering rent-to-own servers in 2008 and virtual servers in 2009. It describes a first Kharkiv data-centre location in the 2010-13 period, expansion into Bulgaria, a VMware-based cloud cluster, and later sites in the United States, the Netherlands, Poland, Germany and Britain.

There is real public evidence behind that narrative. RIPE's record for AS48031 calls the network XServerCloud, marks it active and dates its registration to October 2, 2008. It identifies Vitaliy Ivanov in the administrative and technical roles and connects the resource to a Ukrainian registrant in Kharkiv. The telephone number in that record is the same number published on XServer's current contact page. The timing does not independently prove every event in the company's history, but a network registration from 2008 is a meaningful contemporary trace. It is far stronger than a copyright footer changed to display an old year.

The current legal seller is another matter. XServer's public offer says that services under the XServer trademark are offered by XServer OÜ, registration number 17511911. The official Estonian e-Business Register says XServer OÜ was entered into the register on May 20, 2026. It is a private limited company at Kaupmehe 7-120 in Tallinn. The register names Vitalii Ivanov as its management-board member and direct beneficial owner from the date of registration.

These records fit together more closely than a random brand and a shelf company would. The public company page calls Vitalii Ivanov XServer's chief executive and founder. The Estonian register gives that name control of the new company. RIPE uses the transliteration Vitaliy Ivanov and repeats the brand's Ukrainian telephone contact. The reasonable reading is that a long-running Ukrainian hosting operation has recently placed its public contract under an Estonian company controlled by its founder.

But that is an inference about continuity, not a legal shortcut. XServer OÜ cannot have been the contracting company in 2007 because it did not exist until 2026. A customer needs to know which person or business supplied the service before May, whether existing accounts were transferred, which entity received prepaid balances, and whether earlier warranties, liabilities and data-processing commitments moved with them. The brand's operating history can be old while the current counterparty is new. Both points should appear in a serious assessment.

The 2007 claim belongs to the operation, not the Estonian company

Company-age claims are often treated as soft marketing, yet they matter in hosting. A provider that has managed hardware, addresses, abuse reports, billing disputes and failed disks for nearly two decades has accumulated knowledge that a newly assembled team may lack. Long customer relationships can also indicate that the business has survived technology changes and price cycles. XServer's account of its past contains details that sound like operational memory rather than a generic anniversary line.

The history starts with machines assembled from desktop parts. It says the company introduced rent-to-own servers in Ukraine in 2008, launched virtual servers during the financial crisis, acquired a business called My Hosting, opened in Kharkiv and sold HP servers. The later chronology describes a new customer account, Bulgarian expansion, VMware virtualisation, a US site, and European expansion. These are all first-party claims, not audited milestones. Still, AS48031's 2008 registration and Ivanov's RIPE contact created in 2009 give the early portion an external network trace.

XServer's 2024 review supplies a more recent and unusually specific operational episode. The company says it moved the servers in its first and largest location from Kharkiv to a new data centre in Kyiv during June and July. According to the account, an L2 tunnel joined the sites so VPS customers experienced no downtime. Dedicated servers were moved with interruptions ranging from ten minutes to several hours, depending on stored data. The company says old IP-KVM devices and 100 Mbps switches were retired and the new Kyiv core used a fault-tolerant Cisco cluster.

That story matters because it describes different migration mechanisms for virtual and physical services. A virtual server can preserve its network identity across a temporary Layer 2 extension while its workload moves between clusters. A dedicated machine must be powered down, transported or replaced, and brought back. The disclosed range for dedicated-server interruption is more credible than pretending every workload moved invisibly. Yet it remains the provider's account. No independent incident history or customer-by-customer migration result accompanied it.

The move also changes what "Ukrainian hosting" means. The network registrant and telephone identity remain anchored in Kharkiv, while the principal Ukrainian service location is now presented as Kyiv. The current Kyiv offer names United DC and describes dual internet providers, A and B power, remote management, national exchanges and direct connections toward Poland and Bulgaria. The service page says the site was rebuilt, while the annual review dates the physical relocation to 2024 and the home page labels Kyiv as rebuilt in 2025. Those statements may refer to successive stages, but the public material does not define where the 2024 move ended and the 2025 rebuild began.

A buyer should therefore separate longevity into three questions. How long has the technical team operated under the XServer name? The evidence points back to at least the AS48031 registration in 2008. How long has the current Ukrainian site operated in its present form? The public account points to a major move and upgrade in 2024-25. How long has the present legal counterparty existed? The official answer is since May 2026. One anniversary number cannot answer all three.

The Ukrainian identity survives a multinational footprint

The new Estonian company does not erase the Ukrainian character of the operation. XServer publishes a Ukrainian telephone number and says phone consultations are available in Ukrainian and Russian. The named founder, network registrant and network contacts all point back to Ukraine. Both XServerCloud ASNs are registered to an organisation whose RIPE address is in Kharkiv. The company's historical narrative is centred on the Ukrainian hosting market, and its main domestic location is in Kyiv.

The same evidence shows why "Ukrainian provider" should not be converted into "all activity occurs in Ukraine." The contact page gives XServer OÜ's Tallinn address and lists Ukraine, Bulgaria, the United States, the Netherlands, Poland, Germany and Britain as its presence. The public offer makes XServer OÜ the contractor but says Ukrainian law governs the agreement and that unresolved disputes go to the competent court at the place where the contractor's ultimate beneficial owner is registered. The service footprint crosses several countries even before payment, email and support systems are considered.

That mixed structure may be deliberate resilience. A Ukrainian operator serving customers during a full-scale war has sound reasons to maintain equipment, contracts and routes outside one country. XServer's own terms explicitly recognise the risk. They say the contractor cannot guarantee complete availability, data integrity or uninterrupted service for equipment in Ukraine when interruption is directly related to the armed conflict. Customers for whom continuity is critical are advised to use servers in data centres outside Ukraine.

This is unusually candid sales friction. The company offers Kyiv as a low-latency, locally paid and locally relevant choice, then tells continuity-sensitive buyers to consider another country. Those positions are not contradictory. Local processing and national latency can be valuable, while geographic redundancy reduces exposure to power, transport and physical-security events. The important point is that choosing a flag in a configurator is a risk allocation decision, not a badge of loyalty or a complete continuity plan.

There is also a legal wording problem that a careful customer should resolve before ordering. The Ukraine location page says all services are supplied by Ukrainian legal entities and paid in the national currency. The current public offer instead names an Estonian company. The home page announced that the base currency would change from US dollars to euros on July 1, 2026 and was displaying euro selection at review. It is possible that Ukrainian customers receive a different local seller or payment route, but the public pages do not explain the allocation.

An invoice sample and a location-specific order form would answer more than either sentence on its own.

Seven test locations make the service more inspectable

The strongest part of XServer's public service evidence is its looking-glass directory. It names seven facilities and provides test addresses for each: United in Kyiv, Telepoint in Sofia, ArtNet in Gdynia, Telehouse in Frankfurt, NorthC in Amsterdam, ServerChoice in London and Digital Realty in Miami. Each location page offers ping, traceroute, MTR, name lookup, speed testing and a downloadable test file.

This is useful because the endpoints turn a country menu into something a customer can examine before payment. The Kyiv page publishes 176.103.48.253 and 2a13:f580:1::252. The Sofia page gives 176.103.62.253 and 2a13:f580:2::252. Gdynia, Frankfurt, Amsterdam, London and Miami have their own IPv4 and IPv6 pairs. These are concrete network probes, not photographs of racks that could have been taken anywhere.

The endpoints do not prove everything the accompanying prose claims. A test address can establish that an address is reachable, show a route from a particular observer and reveal performance at a moment in time. It does not show the utilisation of a customer's future host, storage latency, noisy-neighbour behaviour, backup speed, support response or whether the test server shares the same switch and upstreams as the purchased product. XServer's looking-glass page goes too far when it says test results show high availability and Tier 1-grade reliability.

A short test cannot establish long-run availability, and "Tier 1-grade" has no disclosed measurement method there.

Even so, publishing endpoints is a serious positive. A buyer can record route behaviour from the networks that matter to it, repeat tests across business and peak hours, compare IPv4 with IPv6 and detect whether a path changes after purchase. A Ukrainian company serving users in Warsaw and London can compare Kyiv, Gdynia and London rather than rely on a map. A US-facing service can see that the Miami path is not simply the European path with a different location label.

The company's geofeed adds another layer. It maps XServer-associated prefixes to the seven advertised cities and includes individual addresses in Kharkiv within a larger Kyiv-labelled range. A geofeed is an operator-published instruction to geolocation users, not proof that every packet or machine is physically where the row says. It nevertheless shows that XServer is maintaining a location account at prefix level rather than leaving all interpretation to commercial geolocation vendors.

That distinction is important in cloud procurement. Country detection in an application, a search engine or a fraud service can differ from the server's actual building because such systems consume different location feeds. A customer that needs a formal data-residency commitment should not use an IP lookup as its contract. But a provider that publishes test addresses and a geofeed gives customers more material with which to detect obvious mismatches.

Two XServerCloud ASNs reveal a larger routing role

The directory record points to AS48031, but the current footprint cannot be understood through that autonomous system alone. RIPE also records AS202656 under the name XServerCloud. It was registered in April 2023, is active, uses the same Kharkiv registrant and XServer contacts, and names several network relationships in Europe. Both autonomous systems therefore belong in the current public assessment.

At the July 15 observation, RIPEstat's announced-prefix view for AS48031 found 568 routes visible to at least ten full-feed RIS peers during the July 1-15 window. The equivalent AS202656 view found 805. These are large counts beside the seven retail locations, but they must not be converted into a claim that XServer owns 1,373 address blocks or operates that many hosting networks.

Many of the originated prefixes are registered or described for other organisations. An autonomous system can announce customer, leased and delegated space as part of a transit or hosting arrangement. Some prefixes can also appear under aggregate and more-specific routes. The observed total is therefore evidence that the two ASNs have a substantial routing role, not a clean inventory of XServer's own addresses, servers, buildings, revenue or customers.

The topology is not single-homed in the public observation. RIPEstat's routing-consistency data for AS202656 showed six observed neighbours, including routes consistent with declared relationships to ServerChoice, 23M, A2B and RETN, plus other visible connections. The AS48031 result also showed six observed neighbours. A wider set of visible adjacencies is generally more encouraging than one upstream, because it creates options for location-specific reachability and failure response.

Neighbour count is not resilience by itself. Two sessions can share a fibre entrance, router, power feed or commercial parent. A route observed through several networks can still depend on one local cross-connect. Conversely, a private backup may not be visible in the selected observation. The records show routing relationships, not their capacity, contractual priority, physical diversity or performance during a failure.

PeeringDB contributes little additional assurance. Its AS48031 entry names Ivanov Vitaliy Sergeevich but discloses no facilities, exchange connections, traffic range, looking glass or policy. No PeeringDB network entry for AS202656 was returned. This does not negate the RIPE and XServer records. PeeringDB is voluntarily maintained. It means a buyer cannot use that directory to verify the seven facility claims or discover public peering details.

Route authorisation is good hygiene, not service security

The location test addresses provide a manageable way to check route-origin authorisation. The London IPv4 endpoint falls in 91.216.155.0/24, Amsterdam in 193.203.50.0/23 and Frankfurt in 195.211.40.0/23; each was originated by AS202656 and returned valid in RIPEstat's RPKI validation. Gdynia's 91.207.60.0/24, Sofia's 176.103.62.0/23 and Kyiv's 176.103.48.0/21 were originated by AS48031 and also returned valid.

That is a useful control. A valid Route Origin Authorisation lets filtering networks determine that the observed ASN is permitted to originate the prefix. It reduces one class of accidental or malicious route-origin error. It also shows that the public test endpoints are not merely labels detached from the XServerCloud routing identities in five of the seven non-US and Ukrainian locations reviewed.

RPKI validity says nothing about server compromise, storage encryption, customer isolation or the honesty of an application. It cannot tell whether a route is congested, whether a disk will survive failure or whether support will restore a service quickly. It is one narrow form of network-resource evidence, valuable precisely because its scope is limited and testable.

The scale of the two ASNs makes that scope discipline especially important. A hosting network carrying many third-party prefixes has to manage route filters, customer authorisations, abuse contacts and changes across different resource holders. The public observation included valid authorisation for the selected retail test ranges, but it was not a complete audit of every announced route. Customers buying address space as an add-on should ask which ASN will originate it, who creates the authorisation, how quickly changes propagate and what happens to the route when service ends.

IP allocation also has an operational side. XServer's terms allow additional addresses as paid services and reserve broad blocking rights for abuse complaints, blacklisting, spam, attacks and sustained traffic. A customer should know whether a suspended address affects one server, a whole account or a shared routed block; how evidence is reviewed; and how an incorrect complaint is appealed. The public terms now include a 30-day appeal route for content-restriction decisions, but a time-sensitive routing or abuse error may need a much faster technical escalation.

Miami shows where a partner network enters the picture

Six of the seven published IPv4 test endpoints were originated by one of the two XServerCloud ASNs at the check. Miami was different. The address 193.203.48.253 was in 193.203.48.0/24 and was originated by AS204957. RIPE's record for AS204957 names GREENFLOID-AS and Green Floid LLC, with a US address. The route also had valid origin authorisation for AS204957.

This is not evidence of a false Miami location. It is evidence that the service's public network surface includes a partner or supplier ASN. XServer's own AS48031 record has historically named OneProvider among its relationships, and provider arrangements are normal in international hosting. Leasing racks, servers, addresses or transit can be more economical than reproducing an owned network in every country.

The distinction matters because "our infrastructure" can describe several levels of control. XServer may own the server and lease the rack. It may lease the server but control the operating system. It may operate a virtual cluster on provider-supplied network addresses. It may sell a service delivered substantially by a local infrastructure partner. Each model can work well, but incident authority, maintenance notice, hardware replacement and legal access can differ.

The public location cards name well-known data-centre operators, yet a facility name does not prove the commercial arrangement inside it. A provider can be a direct tenant, a customer of a reseller, or connected remotely through another network. The current material does not identify rack ownership, contract counterparties, cross-connects or which company holds hands-on access at each site. The looking-glass evidence proves more than a logo because it supplies reachable endpoints; it still does not prove physical or contractual control.

For customers, the right question is not whether every component is owned. Few cloud services are. It is whether XServer can meet the commitment when a supplier fails. In Miami, who receives the first alarm? Who can replace a disk? Can XServer move an address or workload if the local relationship ends? How much notice reaches the customer before supplier maintenance? Is the same 99.5 or 99.9 per cent availability language intended to apply? A partner can extend a Ukrainian operator's reach. The contract has to extend accountability with it.

The cloud product is a control surface around compute and storage

XServer's VPS page describes more than a conventional virtual machine sold by fixed size. Customers can choose CPU, memory and storage, change those resources during service, install an operating system, use a browser console, take snapshots and join virtual servers in private Layer 2 networks, including across XServer locations. The page names VMware vSphere 8, HPE and Dell hosts, HPE shared storage, RAID10, N+1 clustering, multipath networking and active-active storage.

These are sales claims, but they describe the intended operating surface with useful specificity. Automation is central to the product. A customer is meant to provision and resize without waiting for a technician, control power and networking, reinstall an operating system, view traffic and initiate restoration. This changes where reliability sits. The service is not only a machine in a data centre. It is also the account, identity controls, orchestration logic, inventory, billing state and remote console through which the machine is managed.

The public company page says a new client-management platform at app.xserver.cloud launched in 2026. Current navigation points there, while the public offer still describes my.xserver.cloud as the personal cabinet and some location pages continue to link to the older host. A transition between account systems is not unusual. It does create questions about which system is authoritative for server state, tickets, invoices and notices, and whether every older virtual server can be managed from the new account.

The terms draw an important boundary around automation. They say XServer supplies automated tools for initial setup, including operating-system and optional software installation. After the customer's first successful SSH or RDP connection, further administration of server software belongs to the customer unless there is a separate agreement. The contractor's standard responsibility is limited to physical components, the virtualisation platform and network issues inside the data centre.

The VPS FAQ is broader in tone, saying support can help with setup, software installation, troubleshooting and optimisation, while still stating that applications and data remain the customer's responsibility.

That difference is manageable if it is made explicit at order. A buyer should decide whether it wants infrastructure support or managed operations. If a web application stops because its disk is full, a database is corrupt or an update broke a dependency, the cause can sit above XServer's standard contractual boundary even though a support agent may choose to help. Helpful assistance does not become a restoration commitment unless its scope, priority and authority are defined.

Control-plane security matters for the same reason. An account able to reinstall an operating system, open a console, change network state and cancel a server is a privileged administrative system. XServer has publicly described two-factor authentication and confirmation of sensitive actions in its account tools. A business customer should verify that all privileged users can use strong authentication, that roles can be separated, that recovery cannot bypass those controls, and that actions are logged with enough detail for investigation.

Cross-location private networking deserves particular care. It can simplify a distributed application and let Ukrainian and EU systems communicate as though on one local segment. It can also blur locality and expand a failure or security domain. The customer needs to know where that traffic is carried, whether it is encrypted, how broadcast and loop risks are contained, which sites can join, and whether an operator can isolate one location during an incident. Convenience at Layer 2 should not obscure geography at the legal and physical layers.

Backup language needs a dated product answer

XServer clearly treats backup and snapshots as product features. The current home page says weekly VPS backups cost USD1 per month and retain copies for up to 28 days, while daily backups cost USD5 and retain seven days; snapshots last up to 24 hours. The VPS feature list says automatic backups are included at no extra cost, its detailed section says virtual servers are backed up automatically and describes daily backups as a USD5 option, and its FAQ says automated daily backups are provided.

Those statements cannot all define the same default service at the same time. They may refer to different plans, locations or revisions, but no such distinction is visible in the wording. A customer should treat the account's actual order description and a dated written response as decisive, not select the most generous sentence from the public site.

Retention is only one part of backup assurance. The customer needs the location of the copy, whether it sits on storage independent of the production cluster, whether it is encrypted under separate keys, which failures trigger loss of both primary and backup, and who can delete it. A Kyiv workload with a copy in another country may be more resilient but no longer wholly local. A copy in the same building may preserve locality while failing the same physical event.

The restore method also matters. A one-click date selector is useful, but a restoration should be tested at application level. The provider can restore a virtual disk perfectly while the database remains inconsistent or the service lacks an external dependency. Recovery-point and recovery-time expectations need to state what XServer promises and what the customer must test. Snapshots, in particular, are convenient rollback tools, not necessarily independent backups.

The public offer adds a separate form of retention after non-payment. It defines a two-day grace period, suspension, cancellation after five days and an archive in which server data is retained for seven days before complete deletion. This is not a backup promise. It is an account-lifecycle rule, and restoration requires contacting finance. A customer should not treat an overdue-service archive as disaster recovery. It should, however, understand who can authorise restoration and how quickly support and finance coordinate when a payment or billing error threatens data.

Availability means different things on different XServer pages

The home page says XServer guarantees 99.9 per cent uptime and attributes it to redundant infrastructure, 2N power, multiple network providers and enterprise hardware. The public offer is less strong. It says the contractor will endeavour to maintain network infrastructure and virtualisation platform availability of at least 99.5 per cent per calendar month, excluding planned maintenance and force majeure. It then points to xserver.cloud/sla for calculation, exclusions and compensation.

At review, that SLA address returned no page. The gap is material. In a 30-day month, 99.9 per cent availability allows about 43 minutes of downtime; 99.5 per cent allows about three hours and 36 minutes. A guarantee and an endeavour are not the same obligation. Nor does the public offer specify a default credit in the text that remains available. Without the detailed document, a customer cannot see the measurement source, whether partial packet loss counts, whether storage and account access are included, or how a claim is made.

The war clause further limits the Ukrainian service. It excludes responsibility for interruptions directly related to armed conflict and tells continuity-sensitive customers to use another country. That is understandable, but it places more weight on the design of a customer's multi-location service. XServer's ability to connect sites does not automatically replicate a workload, fail it over or keep data consistent. Those are separate technical arrangements.

There was no public status history in the fixed material sufficient to compare the percentages with achieved performance. Hardware redundancy claims are design statements, not uptime measurements. A dual power feed can terminate in a shared upstream component; an N+1 cluster can fail through software; several transit providers can share a path; and a working host can still be inaccessible because the account or storage system has failed.

XServer can resolve much of this ambiguity without disclosing sensitive design. It can publish a current SLA with a version date, service definitions, maintenance rules, monitoring points, incident severity, credit schedule and claim process. It can distinguish network, host, storage, control-account and support availability. A public history of incidents and planned maintenance would then show how the definitions work in practice. Until that exists, the lower and more conditional contractual statement should carry more weight than the home-page percentage.

Data locality is more than the selected server city

XServer gives customers more geographic choice than many providers of similar size. A workload can be ordered in Kyiv, Sofia, Gdynia, Frankfurt, Amsterdam, London or Miami. Dedicated-server pages name the data-centre operators, and test endpoints let a buyer check network paths. For a customer primarily concerned with the location of a production disk and host, that is meaningful evidence.

Data sovereignty extends beyond the production host. The account contains identity, billing and service metadata. Tickets may contain logs, IP addresses, credentials or application details. Monitoring and network systems create operational records. Backups and snapshots can sit somewhere else. Administrators can access systems remotely. Payment providers and email services process their own data. A server-country choice does not locate all of these surfaces.

The public offer's privacy section lists account and device information, explains several processing purposes and says personal data is kept for the agreement plus three years. It provides rights for European Economic Area residents and a privacy email. It also says the contractor does not transfer or sell customer personal data to third parties, but it does not publish a service-provider list, processing locations, transfer safeguards or a data-processing agreement on the page reviewed.

Public DNS supplies one small example of the broader surface. The XServer website resolved directly to its Amsterdam test range at the check, and its authoritative name servers were under xserver.cloud. Its mail exchangers pointed to Google mail services. This can be a sensible separation of web and email operations. It means a message to sales or support may involve a supplier outside the selected server location, subject to whatever arrangement XServer has with that supplier. DNS does not reveal where every mailbox or ticket is stored, so the observation should lead to a question rather than a geographic claim.

The new Estonian contractor adds another jurisdictional layer. Estonia is in the European Union; Ukraine is not yet a member; Britain and the United States have their own transfer contexts; and the service can be placed in each. The public offer invokes Ukrainian law despite the Estonian seller. A regulated customer needs to identify the data controller, processor roles, sub-processors, transfer mechanism, government-request process and breach contact for the exact order. General GDPR references do not replace that map.

Locality can still be a strength. XServer's domestic history, Kyiv service and Ukrainian-language contact make it a plausible supplier for organisations that need local latency and people familiar with the market. Its foreign locations can provide a practical path to geographic resilience. The stronger version of that proposition is not "Ukrainian data stays Ukrainian by default." It is a documented architecture in which the customer chooses where production, replicas, backup, management records and support access are allowed to exist.

Support has named people, but the promise changes by hour

XServer's about page names three operational leaders: Vitalii Ivanov as founder and chief executive, Serhii Shkil as co-founder and chief technology officer, and Roman Bazhan as head of technical support and lead system administrator. Publicly naming responsible people is useful. It gives the service more accountability than a generic contact box and suggests that technical and support leadership are close to the infrastructure.

The contact page adds tickets, live chat, email, telephone and a Telegram bot. It says existing customers should use the support system and displays a two-minute response. The weekday schedule, from 09:00 to 19:00 UTC+2, describes responses ranging from two minutes to two hours and covers server issues, basic administration, finance and other questions. The overnight section, from 19:00 to 09:00, lists network connection problems, power issues, critical incidents and client equipment assistance.

That is more informative than simply saying 24/7. It suggests round-the-clock technical cover with a narrower overnight focus, while ordinary administration and finance are daytime matters. The dedicated-server page nevertheless says its ticket system ensures a two-minute response during business hours, and the main marketing copy says support responds within minutes. None of these statements defines whether response means an automated acknowledgement, first human reply or useful diagnosis. Resolution targets are not published.

The telephone route is explicitly limited to Ukrainian and Russian. This supports the local-labour proposition in one sense: a Ukrainian customer can reach a number and languages associated with the company's home market. It does not establish where every support agent works, whether they are employees or contractors, how many people cover each shift, or who can attend equipment in London or Miami. The Tallinn office lists weekday office hours, but that address is not evidence of a staffed 24-hour operations centre.

The standard contract narrows support responsibility to host hardware, the virtual platform and data-centre network, with optional help on administration. That division should be visible in incident priorities. If an automated OS installation fails, it is likely within the service. If the installed application fails after a customer change, it may not be. If a private network across two cities breaks, responsibility could involve XServer's control system, a carrier or customer configuration. A good support process identifies the boundary without using it to stop diagnosis.

For a business buyer, local support should be made specific. Does it mean Ukrainian-language handling, engineers employed in Ukraine, a named Ukrainian escalation manager, Kyiv hands-on access, or simply a Ukrainian telephone number? What happens when the head of support is unavailable? Who has authority to move a route, restore a backup, waive an automated suspension or contact a foreign facility? Named leaders create confidence; documented delegation makes that confidence durable.

The public record supports trust, but not a blank cheque

XServerCloud is not an empty name. The evidence joins in several places that are hard to manufacture casually. The 2008 AS48031 registration aligns with the claimed early operating years. The same founder name connects the service, the network record and the new Estonian company. A Ukrainian phone number recurs across the website and RIPE records. The company has described a technically plausible migration from Kharkiv to Kyiv, publishes a current multi-country product catalogue, exposes location-specific test endpoints and maintains valid route-origin authorisations for the selected XServer test ranges.

The record also shows why assurance cannot be granted at brand level. The contractor is only weeks old, even if the operation is much older. The directory names one ASN while current test services use two XServerCloud ASNs and a partner ASN. Facility labels do not state ownership or remote-hands authority. Route counts do not equal owned addresses or servers. A green RPKI result does not secure a workload. A selectable country does not locate tickets and backups. A named support team does not define overnight staffing or restoration time.

Most importantly, the commercial pages and terms need reconciliation. Customers can currently encounter 99.9 and 99.5 per cent availability, different backup entitlements, a missing detailed SLA page, app and my account addresses, Estonian and Ukrainian seller language, and different descriptions of response time. None of those differences proves poor service. Together they make it unsafe to infer a binding commitment from marketing copy.

The best procurement response is not a generic demand for more certificates. It is a short, dated service schedule tied to the chosen location and product. It should name XServer OÜ or any local seller, identify the facility and originating ASN, state who supplies hands-on work and transit, define availability and credits, list backup location and retention, map the account and support data, and set incident and exit procedures. For a critical service, it should explain how a workload leaves Kyiv or another city when the underlying failure is larger than one host.

XServer's history is relevant because the public network record suggests that people behind the service have been operating for a long time. Its Ukrainian roots are relevant because they explain the phone, languages, network registrations and domestic service. The Estonian company is relevant because that is who the current terms say will take the order. The seven locations are relevant because they broaden both resilience and the supplier surface. Trust comes from keeping those facts separate, then making them meet in the contract a customer is actually buying.