AS50149 Is Silent, but the Platform Is Not: Inside Servercore and Selectel’s Continuity Boundary

Summary

• Servercore’s present customer-facing legal page names local contractors in Kazakhstan, Uzbekistan and Kenya, while Russian services are documented under JSC Selectel; a common interface or infrastructure catalogue does not erase that contractual split.
• Russia has the deepest disclosed physical footprint, but connected megawatts, rack counts and availability-zone labels do not reveal spare power, occupancy, inventory, route diversity or the capacity a particular customer can use during a failure.
• AS50149 remains registered with a Servercore/Selectel association but is not currently announced in RIPE’s observed routing data, so continuity must be tested against live service endpoints, contracts, facilities, copies and recovery paths rather than the old network label.

A Region Name Is Only the First Decision

Imagine a payments company opening a location selector and choosing Moscow because its users are in Russia. The label establishes a broad locality, but it does not answer the questions that matter during an outage. Which company invoices the customer? Is the virtual machine in one rack, one building or a pool distributed across buildings? Does its storage follow the same fault boundary as its compute? Can traffic leave by an independent carrier? If the account becomes inaccessible, can the customer recover a usable copy somewhere else?

The current Selectel location guide provides a unusually useful starting hierarchy. It distinguishes countries, regions, availability zones, pools and pool segments, and says the choice affects availability, fault tolerance and load balancing. That hierarchy matters because the terms are not interchangeable. A region can contain several availability zones. An availability zone can contain one or several data centres. A single-zone pool can still have segments in different racks while retaining the availability zone as a common failure boundary. A multi-zone pool can place segments in several data centres, but that does not mean every product, disk or customer configuration automatically spans those segments.

The current availability matrix makes the distinction concrete. It lists St Petersburg, Moscow, Novosibirsk, Tashkent, Almaty and Nairobi, then shows different product and hardware availability in individual pools. The matrix is evidence that an offer was publicly available at a stated location on a stated date. It is not evidence that two displayed locations have independent power feeds, independent upstream carriers, independent staff, equal spare inventory or a common recovery mechanism.

The commercial layer diverges at the same moment. Selectel’s dedicated-server conditions identify JSC Selectel as the provider for Russian regions and use separate provider treatment for locations outside Russia. The Servercore user agreement determines a contractor and applicable law from the account country. A buyer therefore cannot safely record “Servercore/Selectel” as a single undifferentiated supplier. The contract, service schedule, location code and invoice need to be recorded together.

Now follow the Moscow choice farther. A pool code points to compute and storage resources. Those resources sit in racks connected to power distribution, cooling and leaf switches. The racks sit in a named data-centre group. The data centre reaches other facilities and the internet through links and edge routers. Recovery may depend on a second zone, a backup cluster, an external copy, DNS and credentials that remain available when the primary control plane does not. The continuity claim is only as strong as the weakest unverified hand-off in that chain.

This approach also changes procurement. The buyer is not merely selecting latency and price. It is buying a bundle of physical, network, software, human and legal dependencies. A low-latency region may be entirely suitable, but the customer has to decide which failure it is designed to survive. Protection from a host fault is not protection from a rack power event. Protection from one building is not necessarily protection from a metropolitan fibre event. Replication within one provider is not necessarily portability beyond that provider.

The Company Name Splits at the Contract

The name “Servercore JSC Selectel” is understandable as a historical or network-resource association, but it is unsafe as a current contracting assumption. Servercore’s contracting-party page lists Servercore CIS, FE LLC for Uzbekistan, MSS LLP Modern Server Solutions LLP for Kazakhstan and Servercore Africa Ltd for Kenya. Its more expansive legal-information page publishes corresponding addresses, registration details, bank information and country-specific terms. Neither page presents JSC Selectel as the current Servercore contractor for those three account countries.

The Russian side is clearer in the separate Selectel user agreement, which identifies JSC Selectel and its Russian details. This is not a semantic difference. The named contractor determines governing law, currency, tax documentation, payment route, notice process and the entity against which a service obligation can be enforced. It also determines which supplier has direct responsibility when the advertised service depends on a partner facility or another company’s infrastructure.

Servercore’s public company page now presents its local infrastructure proposition through Kazakhstan, Uzbekistan and Kenya case studies. That focus is consistent with its current contractor list. At the same time, shared technical documentation and status visibility continue to expose Russian pools alongside the international ones. The result is a commercially connected family of services whose legal boundary is sharper than its operational presentation may first suggest.

That distinction should not be overstated in the other direction. Separate legal entities do not prove separate engineering teams, separate software, separate procurement or separate networks. Nor does shared technical language prove that one entity owns another entity’s building or guarantees its obligations. Public materials establish that the service catalogue, pool naming and operational visibility are related. They do not publish a complete intercompany responsibility schedule, asset register or cross-default arrangement.

For customers, the practical answer is a contract-to-resource record. It should state the account country, contractor, service region, zone, pool, facility operator where disclosed, data location, payment currency, support channel and export method. If a reseller, partner facility or affiliated company is involved, the customer should ask which obligation remains with the contracting party and which is passed through. The answer should cover service credits, data access, incident notices, remote hands and recovery assistance.

The distinction becomes especially important in a disruption that is legal or financial rather than electrical. A working server can become operationally stranded if a payment channel fails, an account is suspended, a corporate administrator leaves, or cross-border instructions cannot be executed. Conversely, a sound contract cannot keep a rack cool during a utility failure. Continuity planning has to join both layers without pretending they are the same layer.

Data sovereignty deserves the same precision. Locating a workload in a state can help meet locality requirements, and the contractor may provide supporting compliance statements. Yet locality does not by itself answer who can administer the service, where metadata is processed, what law governs the account, or whether a usable copy can be moved to another jurisdiction. A buyer should map each regulated data set to the actual service and contract, not to the umbrella brand alone.

What the Russian Footprint Actually Contains

Russia is the most deeply disclosed part of the combined infrastructure catalogue. Selectel’s data-centre page states that it has six Tier III data centres in Moscow and St Petersburg, with 3,612 racks and 30 MW of connected power. It identifies Tsvetochnaya 1 and 2 in St Petersburg, three Dubrovka facilities in the Leningrad region and the Berzarina facility in Moscow. The same page also identifies partner facilities, including Aviamotornaya in Moscow and Svetlaya near Novosibirsk, rather than silently treating every location as owned.

Those figures are valuable because they anchor the cloud in buildings. They show that the Russian offer is not a single anonymous hall. The listed sites have different rack counts and connected-power figures: the largest disclosed facility, Berzarina, is listed with 1,420 racks and 10 MW, while the smaller Dubrovka buildings have materially different footprints. Physical separation in St Petersburg and the Leningrad region creates options that a customer can use if the selected product supports them.

But “six data centres” is not the same as six independent failure domains for every service. The location guide groups Tsvetochnaya and Dubrovka into separate St Petersburg availability zones. In Moscow it now lists Berzarina, Aviamotornaya, a North Moscow group and Ryabinovaya across four availability-zone labels. Novosibirsk is represented by the Nextremum facility. A product can be absent from a listed zone, restricted to one pool, or available only by prior arrangement, as the availability matrix shows.

The colocation description adds another physical boundary. It says colocated equipment is placed in a pool at Tier III data centres and that Selectel supplies power, connectivity, environmental conditions and physical security. It also describes customer maintenance or remote service by Selectel engineers. That is a direct facility service, different from a cloud customer whose virtual machine is placed on provider-owned hosts and whose rack location is abstracted.

In March 2026 Selectel announced a new multi-availability-zone Moscow region based on three zones at data centres up to 15 kilometres apart. The announcement says managed Kubernetes master nodes, managed-database nodes and distributed backups can be placed across zones. This is stronger than a generic claim that “Moscow” is resilient because it describes the intended zone count, separation scale and services receiving automatic distribution.

It still needs to be read as a product-specific architecture. A metropolitan design can reduce exposure to a building failure, local power incident or single rack event. It does not automatically protect against a defect propagated through shared software, a common account action, a metropolitan connectivity problem or a regional legal interruption. The provider’s statement that sites are connected by a common high-speed network with low latency is useful for synchronous services, but common connectivity can also become a shared dependency if customer traffic has no tested alternative.

The most defensible description of the Russian footprint is therefore layered. There are disclosed owned and partner buildings; named availability zones and pools; product-specific multi-zone features; and shared network and control services. There is enough public information to design meaningful separation. There is not enough to assume separation merely because two resource codes appear under one region.

Outside Russia, Partner Facilities Change the Boundary

The international locations make the operator boundary more visible. The location guide identifies two Tashkent availability zones at UNICON on Mingbulok Street and East Telecom on Yangishakhar Street, one Almaty zone at Kazteleport Sairam, and one Nairobi zone at iColo NBO1. These are named partner facilities, not evidence that Servercore or JSC Selectel owns the real estate, utility connection or every layer of site operations.

Servercore’s network-infrastructure page advertises one availability zone in Almaty, two in Tashkent and one in Nairobi, with different facility certifications and reliability descriptions. It also describes common network design, multiple suppliers and regional connectivity. Read together with the location guide, the page supports the existence of a current international service footprint while preserving the distinction between service provider and facility operator.

The Servercore PCI attestation for Uzbekistan supplies a narrower form of corroboration for a Tashkent data-centre scope. Such an attestation can support a compliance assessment for the named service and period. It does not establish ownership, available rack power, present occupancy, route diversity or the ability to recover in the second Tashkent zone. Certification evidence should therefore stay attached to the service and scope it actually covers.

The public Servercore status page is particularly revealing. On 18 July 2026 it displayed international pools such as uz-1a, uz-2a, kz-1a and ke-1a, Russian pools such as ru-1a through ru-9a, and separate categories for cloud, bare metal, network services, data centres, power, cooling, interfaces and billing. It also showed all systems operational at the observation time while retaining incident history. This supports current operational visibility across the broader platform. It does not say that all resources share a contractor, facility owner or recovery guarantee.

The status page is a point-in-time indicator, not an availability audit. A green mark shows what the provider’s monitoring system reports at that moment. It cannot establish the absence of partial customer impact, the physical diversity of two paths or the success of an individual restore. Its incident history is more useful when combined with a customer’s own telemetry because the two can reveal detection delays, scope differences and correlated failures.

International customers face a further asymmetry. Tashkent has two disclosed zones, while Almaty and Nairobi have one each in the present location catalogue. A single-zone country can still have redundant power, cooling and network devices inside its facility, but it does not offer the same in-country building separation. A customer needing in-country data residence and building-level continuity may have to combine provider services with an independent second site, or accept that recovery crosses a national boundary.

That choice has legal as well as technical consequences. The contractor follows the account country, and a cross-country recovery target can introduce another set of data-transfer, tax and payment requirements. The design cannot be completed by an engineer looking only at latency. Legal counsel cannot complete it by reading only the agreement. Both need the same map of data, service, facility and recovery location.

AS50149: Registered, Maintained and Currently Silent

AS50149 is the sharpest example of why a network label must be tested rather than inherited. RIPEstat’s AS overview for AS50149 returned the holder text “Servercore JSC Selectel” on 18 July 2026 and marked the autonomous system as not announced. That holder string explains the directory association. It is registry evidence, not proof of current packet carriage or of a single present-day legal entity bearing the whole phrase.

RIPEstat’s routing-status record is more decisive about current visibility. It showed no IPv4 or IPv6 space announced, no observed neighbours and zero RIPE RIS peers seeing the autonomous system. It reported the last observed prefix under AS50149 on 18 April 2023. The separate announced-prefixes response returned an empty prefix list for the recent observation window and explicitly noted that routes with very low visibility are excluded.

This is strong negative evidence for AS50149 as a currently visible internet origin. It is not proof that no internal device, private interconnection, customer address or configuration refers to the number. Public route collectors do not see every private path, and a network can deliver services through another autonomous system. What the evidence does rule out is the easy assumption that AS50149 presently represents a large, publicly announced Servercore cloud footprint.

The RIPE WHOIS response adds important context. It lists the AS name as Servercore, links the resource to ORG-SL223-RIPE, shows MNT-SELECTEL among the maintainers and records a modification in April 2026. Registration maintenance and route announcement are different acts. The resource can remain assigned and recently maintained even when it originates no routes visible to the collector network.

For comparison, RIPEstat’s AS overview for AS49505 identified “SELECTEL JSC Selectel” and marked that autonomous system as announced on the same date. This does not prove that every Servercore or Selectel service traverses AS49505, nor does it disclose the exact physical path to a customer. It does show that the active Selectel network identity in public routing is not AS50149.

The operational implication is straightforward. A customer should identify the actual origin autonomous system and upstream path for each production endpoint, not copy AS50149 from an old profile. Servercore provides a public Looking Glass for latency and route observations. Those observations should be repeated from the customer’s important user networks and from the proposed recovery site. One measurement is not enough: paths can change by destination, protocol, time and upstream policy.

AS numbers also say little about facility independence. Two zones can advertise through the same autonomous system and still use physically diverse links; two autonomous systems can still share a duct, building or upstream carrier. BGP evidence establishes routing identity and reachability, while facility documents establish named locations. Only route disclosures, carrier information and repeated measurements can begin to connect the two, and even then an exact fibre route should not be inferred from a logical map.

The Backbone Is Redundant Only Within Defined Limits

Servercore describes six routers in each region, a target maximum link load of 50%, N+1 infrastructure and several network-equipment suppliers. Its network page names Juniper, Arista, Huawei and H3C and describes leaf-spine cloud fabrics, redundant connections and several telecom operators at the edge. These are sensible design choices. Multiple devices can absorb a component failure, traffic headroom can accommodate rerouting, and vendor diversity can reduce reliance on one supply chain.

They are still provider assertions about architecture and operating targets. “Six routers” does not identify which functions those routers perform, which failure domains they occupy or whether every customer product traverses all of them. “Maximum 50% link load” does not publish time-series utilisation, traffic distribution or the condition after multiple failures. N+1 protects against the defined loss of one required component; it does not promise survival of every common-mode event.

The Selectel Global Router description draws a valuable service boundary. It states that the private L3 service can connect products and pools, uses reserved equipment and dynamic routing, and provides a base bandwidth of 25 Gbps within a region and 1 Gbps between regions. It also says the router cannot connect products in different countries. A customer cannot treat the common catalogue of Russian, Uzbek, Kazakh and Kenyan locations as one private routed recovery fabric.

Cross-country or external connectivity requires another mechanism. The Global Connect description says connections to global cloud platforms are arranged through Megaport, with a dedicated VLAN and a pre-provisioned reserved link on the Selectel side. This can be a useful hybrid path, but it introduces partner and provisioning dependencies. A dedicated logical connection also does not by itself prove a physically disjoint route from the customer’s ordinary internet path.

For inbound service, the fault-tolerant load-balancer description says the product can distribute internet traffic across services in different regions and availability zones, using an external address announced through BGP anycast. It depends on the Global Router to join target infrastructure. That combination can reduce reliance on one server or zone, but it remains a chain: external announcement, load-balancer service, private routing and healthy targets must all work.

The customer should consequently demand failure-conditioned answers. What bandwidth remains after one link or router is lost? Which path carries replication traffic if the ordinary inter-zone path fails? Does control traffic share the same edge? Can support change an upstream during an incident, and how is that request authenticated? Is the recovery environment reachable if the primary account interface is degraded? Those answers are more useful than an unqualified “redundant network” label.

There is also an economics dimension. Redundant ports, carriers and reserved bandwidth cost money even when idle. A low headline compute price can coexist with charges for egress, cross-region traffic, dedicated connections or higher bandwidth. A continuity comparison should price normal operation, replication, routine restore tests and at least one realistic failover interval. Otherwise the “backup region” may be designed but not funded for use.

Capacity Numbers Stop Before Usable Capacity

The Russian data-centre disclosure of 3,612 racks and 30 MW is the strongest public capacity evidence in this profile, but its meaning has limits. The page describes power connected to the facilities. Connected power is not the same as IT load currently installed, power sold to customers, power available after redundancy reserves, or capacity that a new customer can contract. Rack count likewise does not state occupied racks, power density, stranded space or the number ready for a particular server configuration.

The individual facility figures are more informative than the aggregate because they reveal concentration. Two facilities account for 20 MW of the disclosed 30 MW, while smaller St Petersburg and Leningrad-region sites range from 2 MW to 3 MW. A customer spreading instances across two pool codes should determine whether those pools really occupy different buildings and power systems. The aggregate cannot answer that question.

The availability matrix provides a second kind of capacity signal: whether products and particular processor families are shown as available, unavailable or available by pre-order in a pool. This is closer to customer-usable inventory than a design megawatt figure. Yet it remains a dated catalogue, not a reservation. “Available by pre-order” can imply procurement or deployment lead time, and a check mark does not disclose quantity. The customer needs a quote, delivery commitment and substitution policy.

Servercore’s public price list documents products and charges across its markets. Pricing can help estimate the cost of reserved recovery resources, but it does not publish installed compute, free hosts, storage headroom or guaranteed emergency inventory. Pay-as-you-go access is valuable in normal scaling; it is not a promise that identical hardware will be free during a region-wide demand surge.

Demand is visible indirectly. Selectel reported 2025 revenue of RUB18.3 billion, with 87% from cloud infrastructure services and 32,900 customers at year-end. Those figures indicate a substantial and growing operating business. They cannot settle capacity headroom. Revenue growth may support investment, but customer growth and heavier workloads can also consume new capacity.

Product terms expose another useful distinction. The cloud-server description says virtual servers run on Selectel physical resources and distinguishes regular service from preemptible instances. The separate preemptible-server guide says those instances can be stopped at any time, including when the host lacks resources for other servers, and do not receive the ordinary cloud-platform availability guarantee. Capacity is therefore not one undifferentiated pool: cheap interruptible compute and continuity-grade compute have different failure-conditioned usability.

A responsible capacity statement must stop at what is public. Russia has disclosed connected power and rack totals. Product matrices disclose location-specific offers. Financial results demonstrate operating scale. No reviewed public material establishes current occupancy, sold power, reserved customer capacity, aggregate CPU or GPU inventory, storage utilisation, generator runtime under load, cooling headroom or spare capacity after a compound failure. Those unknowns belong in the purchasing questions, not in an invented estimate.

Power, Cooling, Hardware and Staff Are the Real Dependencies

Every cloud region eventually resolves into electricity, heat removal, equipment and people. Selectel’s data-centre page describes uninterrupted power, cooling, security and monitoring, while the colocation documentation assigns those facility functions to the provider. These controls reduce ordinary site risk. They do not eliminate dependencies on utility feeds, switchgear, UPS systems, generators, fuel, cooling loops, fire controls and the staff authorised to operate them.

The most important continuity question is not whether redundancy exists, but where it stops. Dual power supplies in a server help only if they reach independent distribution paths. A generator helps only if starting, switching, fuel and cooling remain available for the outage duration. Two facilities help only if the workload and its data actually occupy both and no shared network or control action disables them together. The public location hierarchy is a basis for asking these questions, not a substitute for the answers.

Hardware supply is especially relevant across the Servercore and Selectel boundary. Servercore’s use of several network-equipment brands can reduce dependence on one manufacturer. It can also require more spare types, software compatibility work and specialised skills. Compute hardware presents a similar trade-off: a customer may gain access to alternative processors, but an exact bare-metal replacement or GPU can have a longer lead time than a virtual machine.

The customer-provider responsibility split changes by product. The responsibility guide assigns physical infrastructure and much of the cloud virtualisation layer to Selectel, while customers retain responsibility for important operating-system, application, identity and data controls depending on the service. A resilient building cannot repair an application that has one database leader, an expired credential or a destructive administrator action replicated to every zone.

People bridge these layers. Remote-hands service can replace a component for a colocation customer, while provider engineers maintain cloud hosts and network devices. During a widespread incident, the same staff may be handling power, hardware, customer communication and recovery priorities. Buyers with strict recovery objectives should ask about escalation coverage, authorised contacts, replacement stock, access during a site closure and how competing incidents are prioritised.

Jurisdiction and payment are physical dependencies in another form. Servercore’s country-specific contractors use local banking and currencies, which can make ordinary local operations easier. But a company depending on cross-border funding or central approval should test how invoices are paid during a banking disruption and what notice precedes suspension. Selectel’s information-security guidance points customers to service terms for data destruction after services are ended or unpaid and tells them where maintenance and incident notifications appear. Financial continuity and data retention cannot be left to an accounts-payable assumption.

Local data placement also carries a portability cost. The cloud-server description says Russian cloud servers comply with the stated Russian personal-data framework by default, while Servercore markets local compliance in its three current countries. That can satisfy an essential requirement, but a recovery copy outside the country may not be permitted. If the copy must remain inside a country with one disclosed zone, the architecture needs an independent in-country option or an explicit acceptance of the remaining facility risk.

Recovery Is a Workload Design, Not a Product Label

Backups are the point at which continuity language meets a recoverable entity. Selectel’s backup-method comparison says cloud-server backups are not performed by default. It distinguishes scheduled or manual volume backups, images, snapshots, host-based backup software and external-copy options. Most importantly, it says a snapshot remains on the same hardware as the volume and is deleted with it, so a snapshot is not a full backup.

The storage boundary varies by method. The network-volume backup guide says full and incremental backups are stored in three copies on dedicated equipment. In a single-zone pool, each segment has an isolated cluster that stores backups and disks; in the multi-zone ru-6 pool, a shared storage cluster serves all pool segments. Three copies improve media and server resilience, but copy count alone does not establish building or provider independence.

Portability also varies. The method comparison says ordinary volume backups cannot be downloaded, while images can be downloaded and moved to third-party infrastructure. It notes that images are stored separately from volumes but in the same pool segment unless the customer moves or exports them. A buyer whose exit plan depends on a backup should verify the format, export time, encryption keys, bandwidth and boot procedure before choosing that method.

Creation success is not recovery success. The backup-creation guide says backups have no automatic integrity or functionality check and recommends periodic restoration. That recommendation should become an observed recovery test: create the new volume, boot a clean instance, start the application, validate data consistency, restore secrets through an independent path and measure elapsed time.

The multi-zone Moscow announcement improves the options for selected managed services and distributed backup, but it does not remove application responsibilities. A database service may distribute its own nodes while the customer leaves an identity service, message queue or entity dependency in one zone. A Kubernetes control layer can span zones while its ingress, registry or external database does not. The recovery map has to include every critical dependency, not just the most visible compute cluster.

For larger VMware estates, the DRaaS failover guide describes switching protected machines to the Selectel cloud and later arranging failback or reverse replication. This is a more explicit recovery mechanism than a passive copy. It still depends on prior replication, access to the relevant interfaces, network changes, application ordering and sufficient resources at the recovery site. Recovery time and recovery point are properties of the tested configuration, not of the product name.

The best design usually has two layers. The first is fast recovery within the provider, using another rack, zone or region where the service supports it. The second is a slower but more independent copy under different credentials and, when law permits, a different operator or jurisdiction. The first reduces downtime for common hardware failures. The second addresses account compromise, control-plane faults, contractual disruption and events that correlate across the provider.

Five Failure Tests for Buyers

The first test is a facility loss. Select a production resource and trace its compute, primary data, backup data and network ingress to named zones and facilities. Then assume the primary building has no power or cooling for a day. A passing design has healthy compute elsewhere, a consistent copy, enough reserved capacity, working traffic steering and staff who can execute the change without entering the failed site. Merely having another zone in the menu is not a pass.

The second test is a backbone or control-plane incident. Assume customer traffic cannot reach one edge, or the account interface and programming endpoint are unavailable while existing machines continue to run. Observe the real origin and path from several networks through the Looking Glass and independent measurements. Confirm whether DNS, anycast, private routing and support access fail together. Pre-authorise a traffic change that does not depend on the impaired interface.

The third test is a hardware-supply constraint. Assume an important server, accelerator or network part fails and an identical replacement is unavailable. Ask which substitute is stocked, whether software and licences permit it, how data moves, and what performance is lost. For bare metal, record delivery time and spare commitments. For cloud, establish whether the recovery pool actually offers the required processor, memory, GPU and storage class rather than relying on the country-level product name.

The fourth test is a legal-entity or payment disruption. Assume the ordinary payment rail, corporate administrator or local contractor is temporarily unavailable. Confirm the contracting party, governing terms, account owner, emergency contacts, grace period, invoice alternatives and authority to export data. Keep more than one trained administrator and make sure recovery credentials are not stored only inside the affected account.

The fifth test is portability. Start with the copy that the team claims can leave the platform. Export it, verify its checksum, restore it on a clean target, rebuild networking and identities, and run a business transaction. Measure cost, bandwidth and elapsed time. If the copy cannot be downloaded, document the conversion or application-level export needed. If data cannot leave the jurisdiction, use a genuinely independent target within it or state the accepted limitation.

These tests sort customers by exposure. A single virtual machine with an attached disk in one pool depends on the host, rack, zone, account and provider. Two instances in different racks improve host and rack tolerance but may retain zone-level dependencies. A properly distributed multi-zone service can survive more physical faults, yet may still share metro networking, software and contractor risk. An external copy adds independence, but only if credentials, keys, capacity and legal permission survive.

The tests also make service guarantees easier to interpret. A credit after downtime helps with price, not recovery. A high availability percentage says little about a rare long outage if the excluded conditions, measurement method and customer obligations are unknown. Buyers should use the guarantee to understand incentives, then use exercises and telemetry to understand survivability.

The Continuity Verdict

Servercore and Selectel expose enough current information to support serious infrastructure planning. The public materials identify Russian and international facilities, name availability zones and pools, disclose a meaningful Russian rack and power footprint, describe network redundancy, publish product-location matrices and maintain a granular status page. The legal pages also make the local contracting entities visible rather than presenting one universal counterparty.

The evidence does not support collapsing all of that into “Servercore JSC Selectel” as a single current operating fact. AS50149 retains that holder text in RIPEstat, but it is not currently announced and has no recently observed prefixes in the collector view. JSC Selectel is the documented Russian contractor and has a separately announced network identity. Servercore’s present legal perimeter names Kazakhstan, Uzbekistan and Kenya contractors. Partner data centres add another operator layer outside the deepest Russian footprint.

The strongest continuity proposition is therefore conditional. In Russia, a customer can choose among multiple disclosed sites and, for supported services, a multi-zone Moscow design. In Tashkent, two named zones create an in-country separation option. Almaty and Nairobi currently present one disclosed availability zone each, so building-level recovery requires an additional answer. Across countries, the private Global Router does not provide one seamless recovery network.

Capacity evidence is similarly conditional. Thirty connected megawatts and 3,612 racks demonstrate physical scale in the six disclosed Russian facilities. They do not reveal usable headroom under failure. Product matrices and pre-order labels help, but firm recovery capacity comes from reservation, contract and exercise. The same discipline applies to the network: N+1, multiple suppliers and traffic headroom are credible design claims, while current path independence requires measurement and disclosure.

For a buyer, the decisive document is not a region list. It is a dependency map that binds each production service to its contractor, facility or zone, pool, data copy, network path, support route and recovery target. The decisive event is not a sales demonstration. It is a restore or failover performed under a realistic loss assumption.

That produces a fair conclusion. The platform is visibly operating even though AS50149 is silent. Its continuity can be strong when the customer deliberately uses separate fault domains, maintains a portable copy and resolves the legal and partner boundaries in advance. It is weak when a shared interface, a green status mark or an old autonomous-system label is treated as proof that those boundaries do not exist.