REGRU "Domain names registrar REG.RU", Ltd sells hosted capacity that still depends on racks, transit and repair windows

Summary

• REG.RU exposes a genuine operating surface: IANA lists the registrar as accredited, RIPE-observed routing shows hundreds of IPv4 and IPv6 announcements behind AS197695, and the branded catalog sells shared hosting, virtual machines, bare metal, storage, databases, Kubernetes and colocation. That is more than a storefront, but it does not establish that the named registrar company owns every facility or operates every product layer itself.
• Resilience is not inherited from the size of the portfolio. REG.RU publishes multiple Russian locations, backup and migration tools, floating addresses, private networks and a 99.95% cloud service target, yet site choice, backup separation, maintenance exclusions, hardware replacement, support escalation and cross-location application design determine the recovery customers actually receive.
• The clearest operating conclusion is therefore conditional. The network and active product inventory support treating REG.RU as an operating infrastructure provider. Facility ownership, per-service capacity, cross-region replication and historical incident performance remain only partly visible, so a customer should verify the exact contracting entity, location, recovery objective, route design and export procedure for each service before treating a REG.RU deployment as redundant.

A registrar account became an infrastructure control surface

REG.RU is still recognisably a domain registrar. The IANA registrar identifier register lists “Registrar of Domain Names REG.RU LLC” as accredited under identifier 1606 and points to its RDAP service. Its own company details identify the Russian limited-liability company whose English rendering appears in the directory entry, with tax identifier 7733568767 and a Moscow legal address. Those facts establish the subject of this profile more securely than branding alone.

The customer proposition, however, extends well beyond registration. REG.RU’s company page describes an OpenStack- and VMware-based cloud range, dedicated servers and colocation. The current REG.Cloud service catalog lists virtual machines, physical bare-metal servers, managed databases, Kubernetes, S3-compatible storage, private OpenStack and VMware environments, network services and rack space. A small organisation can therefore buy the name, authoritative DNS, website hosting and server capacity through related REG.RU surfaces. A larger customer can rent physical equipment or combine it with virtual resources and managed services.

That bundling matters operationally. A registrar account is no longer merely where a renewal date is stored. It can become the place where public names, address records, compute orders, backup policies, support tickets and payment balances meet. The convenience lowers the cost of getting a service online. It also concentrates administrative authority. Loss of access, a payment mistake, an incorrect DNS change or an account-level security incident can affect several layers even when the underlying machines remain healthy.

This is the first distinction customers should preserve: commercial integration is not technical redundancy. Buying a domain and a server from the same family may simplify configuration and support. It does not create a second authoritative DNS provider, a second cloud, an independent copy of the data or a separate administrative credential. A recovery design must deliberately create those separations.

The converse is also important. The wide catalog should not be dismissed as a list of resold labels. REG.RU has observable network resources, publishes specific facility locations, advertises stocked physical configurations and documents its own operational controls. The task is to identify where that evidence is strong and where a brand-level statement is being asked to carry more weight than it can.

One brand does not mean one operator or one ownership model

The legal boundary is unusually important here because REG.RU’s public surfaces use one name for several kinds of service. The site rules identify “REG.RU Domains Hosting” LLC as the administrator of the web properties and identify “Domain names registrar REG.RU” Ltd as a partner that provides services under its own customer agreements. Separately, the registrar’s support rules describe support provided by the registrar company across registration, hosting and other services. Current promotional terms for cloud GPU have also named the registrar company as organiser. The documents show close operational integration, but they do not support treating the two legal persons as interchangeable.

The same caution applies to buildings. REG.RU says it uses a mixture of its own and connected data-centre capacity. Its product pages name commercial facilities as well as REG.RU-branded sites. The VPS page identifies locations including KIAEHOUSE at the Kurchatov Institute site, SafeData, Medvedkovo-2, DataPro, a facility at Varshavskoye Highway, Data Centre No. 1 in St Petersburg and Zhiguli Valley in Tolyatti. A June 2026 announcement says a third Moscow cloud region was opened at Datahouse’s Magistralny-1 facility. Those names indicate leases, hosting arrangements or other facility dependencies alongside any building the group may own directly.

This is not a weakness unique to REG.RU. Most infrastructure services are layered businesses. A provider can own servers, lease cages or racks, contract for power, buy transit and use third-party facilities while still operating the customer service. But each layer changes the incident boundary. A facility operator controls the electrical plant and cooling. A carrier controls an external circuit. REG.RU controls its server fleet, virtualisation, service configuration and customer response to varying degrees. The customer controls the application, credentials, data placement and much of the recovery plan.

The practical procurement question is therefore more precise than “Does REG.RU own its data centres?” It is: for this ordered service in this selected location, who owns the server, who provides remote hands, who controls the network edge, who maintains the hypervisor and storage, and which company owes the contractual remedy? A bare-metal machine advertised as physically available is a different arrangement from a virtual machine on a shared cluster, and both differ from a customer-owned server placed in colocation.

REG.RU’s documentation is useful because it reveals parts of that division, but it does not publish a complete ownership and responsibility matrix for every product and location. Until a contract or technical schedule supplies that matrix, portfolio-wide ownership claims should be treated as unverified. The service can be real and operating without every rack being a corporate asset of the directory entity.

The physical estate is Russian, distributed, and unevenly described

REG.RU’s hosting-location guide gives five principal addresses: three in Moscow, one in St Petersburg and one in Tolyatti. It says shared virtual hosting is at the Kurchatov Square location in Moscow. It also says the facilities have backup power, cooling and layered security. This is useful service-specific evidence because it ties shared hosting to a named place rather than merely saying “Russia.”

The provider’s wider catalog is broader. The VPS page supplies facility names, power figures, rack counts and service types. It describes Data Centre No. 1 at Predportovaya Street in St Petersburg as a Tier III-designed site with 2 MW and 260 racks, and Zhiguli Valley in the Samara region as certified against Uptime Institute Tier Design and Tier Facility standards. The page also includes Moscow sites with different combinations of bare metal and public cloud. An independent check is possible for at least one of these dependencies: Data Centre No. 1’s own contact page gives the same Predportovaya Street address, confirming that REG.RU’s St Petersburg location corresponds to a separately operated facility.

REG.RU’s newest portfolio statement is more expansive. In announcing NVIDIA Blackwell instances in June 2026, the company said the branded cloud had ten data centres, 85.5 MW of aggregate capacity and 300 Gbit/s of optical-channel throughput. It described the new Moscow-3 region at Datahouse Magistralny-1 as an independent infrastructure contour with its own OpenStack cluster and hypervisors. The announcement attributes 1,100 racks, up to 15 kW per rack and a 99.99% facility target to that site.

Those numbers are evidence of the scale REG.RU is marketing, not a direct measure of capacity available to a particular customer. A facility’s total utility feed includes space used by other tenants. A rack count says nothing about how many racks REG.RU occupies. A maximum rack density does not show the average deployed load. Optical-channel throughput is not the same as uncongested customer transit at every location. Ten connected sites do not imply that every service can run in all ten, or that data is automatically replicated among them.

The more decision-useful evidence appears in the order path. REG.RU’s dedicated-server inventory lets customers filter physical machines by several named Moscow locations, and individual listings identify a processor, memory, disk layout, remote-management option, network port and placement. That is installed or orderable capacity, though it remains a changing inventory rather than an audited fleet total. The cloud order documentation similarly tells customers to choose a placement region. These selectable locations matter more than a large aggregate estate figure because they define where a customer can actually put a workload today.

The result is a layered map. Shared hosting has one disclosed primary Moscow address. Bare metal appears across several named sites. Managed cloud services expose a smaller set of regions or zones that evolves by product. St Petersburg and Tolyatti expand geographic choice, while new Moscow sites expand metropolitan capacity. None of this by itself proves synchronous redundancy between cities, buildings or clusters.

Installed capacity is not usable capacity

Cloud marketing converts physical machines into simple units: vCPU, memory and storage. The conversion hides the utilisation and maintenance decisions that determine whether a requested unit is available when demand rises. REG.RU’s catalog demonstrates a substantial range, but the distinction between installed and usable capacity remains essential.

For bare metal, usable capacity is visible as stocked configurations. The dedicated-server page advertises AMD EPYC, Intel Xeon, NVMe, hard-drive and GPU options and says equipment is in stock. Individual offers show a specific machine and state that delivery begins from 45 minutes for many servers. This is stronger than a conceptual product page: it suggests active inventory and an order mechanism. Yet stock changes, and a replacement part is not guaranteed merely because a similar machine appears in the catalog. Customers with strict restoration objectives need to know whether failed drives, power supplies, motherboards and accelerators have on-site spares at the selected facility and what substitution is permitted.

For virtual machines, usable capacity depends on cluster headroom, storage performance, scheduler limits and network availability. REG.RU’s cloud-server ordering guide shows standard, high-frequency and regulated-data configurations, plus GPU images. A June 2026 hardware announcement goes further, naming Supermicro systems, AMD EPYC 9554 processors and RTX 6000 Pro Blackwell Server Edition accelerators for the Moscow-3 region. That specificity supports the presence of a real new hardware pool. It still does not disclose oversubscription, free headroom or the number of installed hosts.

Storage has its own gap between a product claim and recoverable capacity. The S3-compatible storage page says entities are kept in three copies and the provider is responsible for infrastructure, replication, scaling and availability. Three copies can protect against some device or node failures. The page does not, however, say on its face that those copies are in three independent buildings or failure zones. Three replicas inside one site are not a regional disaster-recovery copy. A customer should ask for the placement policy, failure-domain boundaries, versioning behaviour and recovery process rather than assuming that “three copies” means “three regions.”

Even a facility’s electrical capacity is conditional. A 36 MW building can have strong infrastructure while the provider’s leased area, contracted power and installed network ports are much smaller. A 15 kW-per-rack design limit does not mean every rack has that load provisioned. The useful unit for a customer is not the campus rating; it is the capacity contract attached to a chosen service and the provider’s ability to deliver more of it during a failure elsewhere.

This is why failover tests must include scarcity. If a Moscow cluster fails, can the second location accept the displaced workload, not merely run a small standby machine? If a specialised GPU host fails, is an equivalent accelerator held in reserve? If a storage pool becomes unavailable, can the surviving pool serve both normal and recovery traffic? Public materials do not answer those questions, so they belong in technical due diligence.

AS197695 is the clearest independent sign of operation

The network record provides the strongest evidence that the named directory entity operates infrastructure rather than only selling another company’s service. RIPE registration and public routing observations associate AS197695, AS-REGRU, with “Domain names registrar REG.RU”, Ltd. A BGP.Tools snapshot describes the network as active and content-oriented and shows hundreds of originated IPv4 prefixes plus IPv6 announcements. A RIPEstat announced-prefixes response observed 477 announcements on 12 July 2026: 453 IPv4 and 24 IPv6 prefixes, excluding routes with very low collector visibility.

The breadth of that surface is material. It is consistent with a hosting provider serving many customer address blocks and services. One sample prefix, 176.99.13.0/24, is originated by AS197695 and contains addresses used by REG.RU name servers. The company’s main web domain also resolves into the same autonomous system according to Hurricane Electric’s DNS view. These observations link the corporate, DNS and hosting surfaces to an operated routing domain.

RIPE’s ASN-neighbours response showed numerous adjacent AS numbers in observed paths on the same date, including TransTeleCom, EDINAYA SET, Hurricane Electric, OBIT, RETN and ER-Telecom among others. That indicates varied external connectivity in the global routing view. It does not prove that every REG.RU facility has physically diverse entrances, that every named network is a paid upstream, or that two circuits do not share a duct. RIPE’s left/right path classification is an observation about AS-path position, not a commercial relationship label.

There are also two cautions. First, AS43146 is registered to the same organisation but BGP.Tools reports it as absent from the current global table. A registered autonomous system is not evidence of a live service; AS197695 is the relevant operating signal. Second, a query to the PeeringDB network endpoint returned no public network record for AS197695. PeeringDB participation is voluntary, so absence is not evidence of poor connectivity. It does mean the public record lacks a provider-maintained facility and exchange matrix that could otherwise help verify where REG.RU peers.

Network scale also does not erase concentration. Hundreds of prefixes can traverse one autonomous system and share routing policy, mitigation systems or operational staff. Customers that use REG.RU for authoritative DNS, hosting and the application origin may remain dependent on the same account and network even when IP addresses differ. True route diversity requires path testing from relevant user networks and confirmation of physical circuits at each selected site.

The service-level promise leaves room for repair windows

REG.RU’s cloud service-level agreement is unusually revealing about the difference between an availability target and uninterrupted service. The agreement effective 14 April 2026 sets 99.95% monthly targets for infrastructure, network and data-centre services such as power, heat, ventilation and cooling. In a 730-hour month, 0.05% corresponds to about 21.9 minutes, before exclusions are considered.

The exclusions matter. The agreement permits planned work interruptions totalling up to 48 hours a year and no more than six hours in a month, with at least 24 hours’ notice. Urgent work may last as long as required to remove or prevent an emergency, with notice immediately before the interruption. The agreement says those maintenance interruptions do not count as normal service unavailability. It also excludes several customer-caused or externally caused conditions and provides service-credit treatment for qualifying unavailability rather than compensation for the customer’s wider business loss.

This does not make the target meaningless. A written target across compute, network and facility systems is a useful baseline. It identifies a remedy and requires the provider to measure availability. But it changes the engineering interpretation. A customer cannot convert 99.95% into a promise that no six-hour maintenance window can occur. An application that cannot tolerate the permitted window needs a second service location and a tested method of moving traffic.

Product pages sometimes use different figures. The shared-hosting location guide advertises 99.9% uptime, while the Moscow-3 announcement attributes 99.99% to the facility. These percentages refer to different scopes and should not be blended. A facility design or facility target is not the same as application availability. A server can remain powered while storage, a hypervisor, a route, DNS or customer software fails. Conversely, a platform can keep an application online during a host failure if the workload is distributed correctly.

Public incident transparency is thin. No clearly resolvable REG.RU public status host was found during this review, and the company’s news archive is not a structured incident history. Third-party monitors provide only weak signals. For example, Hosters.ru’s uptime page reported checks against the public REG.RU website, not the customer cloud estate, and Who.is likewise measures the corporate endpoint. A failed probe could reflect filtering, a redirect problem or the website itself; a successful probe says nothing about a customer VM in another region. These observations cannot validate or disprove cloud SLA performance.

A stronger transparency standard would include per-service status, region labels, incident start and recovery times, affected components, and post-incident explanations. In its absence, customers should request historical availability reports and ask how planned work, urgent work and partial degradation appear in service measurements.

Hardware failure turns cloud abstraction back into inventory and labour

A virtual machine feels independent of a particular server until a physical component fails. A bare-metal service never hides that dependency. REG.RU’s documentation shows both the advantages and the limits of its hardware operating model.

The dedicated catalog includes remote control, DDoS protection, a network port, operating-system installation and “operational replacement” of faults. Its IPMI guide explains that some servers expose independent out-of-band management and that KVM is available where IPMI is not. A customer can use that channel to inspect boot problems, restart a machine or install an operating system even when the main operating system is unavailable. This reduces support dependence for some faults.

It does not replace physical intervention. A dead motherboard, storage device, power supply or network interface still requires a person and a spare. “Operational replacement” is not a published replacement-time objective. The provider may restore service by swapping a component, moving disks, supplying a different server or rebuilding the operating environment, and those options have different consequences for data integrity and downtime.

Hardware generation also affects recovery. The catalog contains both recent EPYC and GPU systems and older Xeon configurations. That range is economically rational: customers trade performance and age for price. But a replacement policy must define whether the customer receives identical parts, equivalent performance or any available substitute. Legacy memory and disk interfaces may be harder to replace quickly than current stock. Specialised GPUs create an even tighter inventory constraint.

For virtual cloud, the provider can move or recreate a guest on another host only if the cluster, storage and network design supports it and spare capacity exists. REG.RU describes its cloud as fault tolerant, but public product pages do not disclose the host-evacuation policy or the fault domains of every service. Managed Kubernetes documentation says a fault-tolerant cluster can switch to a reserve master node, which protects that control component. It does not automatically make customer workloads multi-site or guarantee that stateful data survives a facility loss.

The customer’s application design therefore remains decisive. Stateless services can be recreated from images and configuration more easily than a single mutable database. A bare-metal database with local disks needs replicas or recoverable backups elsewhere. A virtual machine with a snapshot in the same storage domain can still be exposed to a storage-domain failure. The brand can supply useful components, but no catalog selection turns a single instance into a recovery architecture.

Backups are products, not proof of recoverability

REG.RU offers several backup mechanisms, and the differences among them are consequential. Shared hosting receives automatic daily backups, according to the hosting backup guide. The guide says copies are retained for 30 days, are made overnight and become available later the next day. This is appropriate for many websites, but it implies a potentially long recovery-point gap for frequently changing data.

Cloud-server backup is separately enabled and billed. The cloud backup guide says the default policy preserves three copies, including a weekly and the two latest versions, with daily creation. Customers can change retention policies and restore a server from a saved copy. Restoration may require updating domain records when an address changes. That last detail is operationally significant: compute recovery and traffic recovery may be separate steps.

Dedicated servers have more choices. REG.RU’s backup product page describes daily file-level copies for Linux, Veeam options, FTP storage, S3 and private designs. It says backups are stored separately from the server, and its standard Linux description retains the previous seven days. More elaborate designs can place recent copies on disk and longer archives on tape. “Separately from the server,” however, does not necessarily mean “in a separate building” or “outside the provider.” Customers need the exact location and administrative separation.

The S3 service adds another option and supports an open interface. An S3-compatible endpoint can make application integration and data transfer easier than a proprietary-only storage product. REG.RU says the service maintains three replicas and permits management through the S3 API and Terraform. That supports portability at the entity level. It does not prove that a large dataset can be exported within the required time, that versions are enabled, or that the provider’s internal replicas protect against account deletion or compromised access keys.

A credible recovery test has four parts. The copy must contain the required data. It must be isolated from the initiating failure. The customer must be able to authenticate and retrieve it during an incident. The restored system must pass an application-level integrity check. Backup completion messages establish only the first part imperfectly.

This is especially important when domain, DNS, compute and backup use one account. An attacker or administrator with broad rights may be able to change records, delete machines and remove copies. Customers should separate credentials, use independent copies for critical data, protect deletion with retention controls where available and practise restoration into another environment. The presence of a backup button is valuable, but a timed restore is the evidence that matters.

Multi-site choice is not automatic multi-site service

REG.RU has added meaningful location choice. A 2023 announcement described a St Petersburg cloud site alongside three Moscow data centres. A 2024 operating update said the company connected a new site in Tolyatti while expanding cloud products. In March 2026, REG.Cloud announced a second Moscow location for managed databases, allowing customers to deploy DBaaS in Moscow-1 or Moscow-2 and to restore into a new cluster. In June, Moscow-3 added a separate OpenStack contour.

These are not all the same kind of redundancy. A second facility within Moscow can reduce exposure to a building failure, local maintenance or a cluster incident. It remains exposed to metropolitan hazards, regional network controls and some shared staff or control systems. A Tolyatti or St Petersburg deployment increases geographic separation but may offer a different product set, capacity pool or latency profile. Public materials do not claim that every service can fail automatically across all these sites.

The DBaaS update is a good example of precise but limited progress. It says customers can select either of two Moscow locations, restore a backup into a new cluster without stopping the original, and use point-in-time recovery for PostgreSQL. Those capabilities reduce the cost of testing recovery and moving to a clean instance. The announcement says a second location improves load distribution and resilient design; it does not say databases are synchronously replicated across both locations by default.

Floating public addresses also have a bounded scope. REG.RU’s floating-IP guide says an address can be attached to a device within one private subnet. That is useful for failover between instances in that network. It is not evidence that the same address can move to another region or survive loss of the network control layer. Similarly, private networks join resources, but they need route, address and security design from the customer.

Managed Kubernetes offers reserve control-plane nodes, and S3 provides replication, but each protects a specific component. Resilience emerges only when the application’s dependencies align: compute in more than one failure domain, data replicated or restorable, traffic steering independent of the failed site, secrets available, capacity reserved and operators able to execute the switch.

Customers should also ask whether the target region can be selected at order time for every component. A virtual machine in Moscow-2 paired with storage available only in Moscow-1 may retain a hidden cross-site dependency. A managed database may support two locations while the backup repository remains shared. Public documentation supports the presence of choices; it does not provide a complete dependency map.

Transit diversity must be proven at the service edge

AS197695’s observed neighbours and hundreds of prefixes make a single-carrier network unlikely at the autonomous-system level. REG.RU also advertises a roughly 200 Gbit/s private-network capacity and duplicated 40 Gbit/s access channels on its VPS page, while the newer portfolio statement cites 300 Gbit/s of optical channels. These figures indicate a substantial network, but they are not a substitute for per-site route evidence.

The network can fail at several layers. A top-of-rack switch can isolate a group of servers. A facility cross-connect can fail while the wider autonomous system remains visible. A route leak or filtering error can make selected prefixes unreachable from some networks. DDoS controls can protect capacity while also introducing false positives. A customer-side firewall or address change can look like a provider outage. DNS can continue answering with an unreachable origin, or the origin can work while the REG.RU account used to change DNS is unavailable.

For a customer, the relevant test begins from the application address, not the provider’s ASN headline. Route observations should be collected from user populations and from more than one external network. Traceroutes do not prove physical diversity, but repeated measurements can show whether paths converge on the same carrier. Contract documents or network diagrams should identify separate cross-connects, meet-me rooms and building entrances when those details matter.

The lack of a public PeeringDB record makes this verification harder. PeeringDB could have listed exchanges, facilities, capacity and policy, but its voluntary nature means REG.RU may simply use private arrangements or choose not to publish. RIPE data confirms Internet reachability and varied adjacency; it cannot locate each interconnection. The correct evidence grade is therefore strong for an active, sizeable network and medium to weak for facility-specific route diversity.

The distinction also affects “multi-site” designs inside one provider. Two REG.RU regions may use separate hosts and storage but share AS197695, mitigation services, address management or external transit policy. That may be an acceptable trade-off. It protects against many local failures while preserving low operational complexity. It is not equivalent to using an independent DNS provider, a second autonomous system and a second cloud for the most critical path.

Billing, support and account control are infrastructure dependencies

Infrastructure failure is not limited to broken hardware. REG.RU’s cloud terms describe a balance that is charged as resources are used, and the SLA excludes interruptions associated with failure to meet payment conditions. A service can therefore become unavailable through commercial state even when the rack, route and hypervisor are healthy. Organisations should treat balance alerts, renewal rights and payment methods as production controls.

The account has similar importance. Hosting services in Russia require customer identification, and REG.RU’s cloud identification guide applies that requirement to virtual machines, databases, Kubernetes, S3 and physical dedicated servers. Identification can strengthen accountability, but it introduces documentation and access dependencies. A corporate customer should ensure that more than one authorised employee can manage the account and that ownership records remain current when staff change.

Support coverage is differentiated. REG.RU advertises round-the-clock technical support, while its cloud support guide directs customers to choose a service-specific queue and lists daily telephone consultation hours. Holiday notices have said technical support for domains, hosting, corporate and cloud products continues around the clock, while some office or general-request functions close. That makes ticket routing and escalation rights important during a complex incident.

Support also crosses responsibility boundaries. On an unmanaged bare-metal or cloud server, the provider may restore power, network or hardware while the customer repairs the operating system and application. Managed services move some responsibility upward, but customers still own data classification, application behaviour and access configuration. The S3 page explicitly divides responsibility: the provider runs replication and physical infrastructure; the customer manages permissions, lifecycle, versioning, integrations and keys.

A practical escalation plan should identify the contract holder, technical contacts, billing contacts and the evidence required in a ticket. REG.RU’s SLA asks for detailed service and fault information and may require access to a server for investigation. During an incident, delays in finding credentials or authorisation can extend downtime even if support is staffed.

The most dangerous concentration is an account that controls domain registration, DNS and infrastructure with one credential and one payment path. A safer design separates roles, protects high-impact actions, keeps an offline record of resource identifiers and has a second method to communicate. This is ordinary operational hygiene, but the breadth of REG.RU’s catalog makes it especially consequential.

Portability exists, but migration has a cost and a sequence

REG.RU provides several open or familiar interfaces that reduce lock-in. Virtual machines can run common Linux and Windows systems. Dedicated servers expose IPMI or KVM and allow customer operating-system images. Object storage uses an S3-compatible interface. Terraform is supported for some cloud provisioning. Data can be copied with standard tools, and DNS remains based on portable records.

The provider’s cPanel-to-ispmanager migration guide is valuable because it shows the actual sequence: identify files and databases, make an archive and database dump, record the software version, create the target environment, load files, import data, test before DNS changes, update records and move mail separately. This is a migration into REG.RU, but the same components must be understood for a migration out.

Portability is therefore not a yes-or-no feature. A small static site can be copied quickly. A large database needs replication or a maintenance interval. A managed database may expose standard engine tools but still require compatible versions and extensions. A terabyte-scale entity store can use a standard API while taking significant time to transfer over the available connection. Public IP addresses usually do not travel to another provider, so DNS, certificates and allow lists must change.

REG.RU’s service combination can help a staged move. A customer can build a new server, restore data, test it through a local hosts-file entry or temporary name, and switch the public record only when ready. The migration guide explicitly recommends pre-switch testing. Yet using REG.RU DNS for both the old and new service means the switch still depends on the same control surface. Critical migrations may justify an independent secondary DNS arrangement and advance reduction of record lifetimes.

Backups should also be exportable before an emergency. A provider-hosted backup that can restore only into the same service is useful for local mistakes but weak for provider exit. S3 compatibility and standard file copies improve options, provided credentials and bandwidth remain available. Customers should time a representative export and record dependencies such as encryption keys, database users, certificates and licence files.

The economics of exit belong in the original architecture. Cheap, quickly available capacity can still be expensive to leave if data volume, proprietary managed features or address dependencies accumulate. REG.RU offers enough standard interfaces to make portability plausible. The public evidence does not quantify export throughput, support commitments for departure or how long data remains accessible after commercial termination, so those terms need direct confirmation.

Data locality is clear at country level and less clear within products

REG.RU consistently places the advertised infrastructure in Russia. The hosting guide names Russian cities and addresses. The cloud catalog says its Tier III facilities are in Moscow, St Petersburg and the Samara region. The S3 page makes the same country-level claim. For organisations required to keep Russian citizens’ personal data in Russia, that is a relevant foundation.

The provider also offers cloud servers designed for Federal Law 152-FZ requirements. Its regulated-server documentation identifies a Moscow location and describes the provider’s responsibility for infrastructure, a certified facility and technical protections. This is more specific than a generic promise of “local cloud.” It still does not transfer all compliance responsibility to the provider; the customer remains the personal-data operator and must configure and govern its system accordingly.

Locality has several levels. Country locality asks whether primary data remains in Russia. Facility locality asks which city and building holds it. Replication locality asks where copies and backups go. Administrative locality asks who can access it. Support locality asks where staff and remote management operate. Public pages answer the first question more clearly than the others.

Product geography can also change. The S3 marketing page refers to Moscow, St Petersburg and Samara, while specific cloud features may be available in only one or two regions. The DBaaS announcement describes two Moscow locations, and the Blackwell launch is tied to Moscow-3. A customer cannot infer a product’s placement options from the full corporate map. The order interface and contract schedule must identify the chosen region.

Country concentration is both a benefit and a risk. It supports data-residency requirements and local latency for Russian users. It also means the advertised estate is exposed to one national legal, power-market and connectivity environment. Customers serving users elsewhere must test international routes and consider whether an independent copy outside the provider is legally permitted and operationally desirable. The answer depends on the data and the customer’s obligations, not on a generic cloud label.

What failure looks like for different customers

A small business using REG.RU for a domain, shared hosting and mail is most exposed to account, DNS and shared-platform failure. Daily backups may restore the site, but changes made after the last copy can be lost. If the same account controls the domain and hosting, an access problem can block both diagnosis and redirection. The best improvement is often modest: independent account recovery, an external copy of site and mail data, and a documented way to move DNS.

A software company on cloud virtual machines faces cluster, storage and region failures. Floating IPs and private networks can help within a location. Backups and snapshots can restore instances. Neither substitutes for a second running location when downtime objectives are short. The company needs application-level replication, external monitoring and enough spare capacity in the target location.

A customer on bare metal owns more operating responsibility. IPMI can restore console access, and REG.RU can replace faulty hardware, but the application may remain tied to local disks and a specific machine. Mirrored disks protect against some device failures, not site loss or corruption. A second server and off-machine data copy are the minimum credible resilience measures for a critical workload.

A regulated-data customer has another constraint: the recovery target must satisfy the same residency and security requirements as production. A backup in an unspecified location or a hastily chosen alternate cloud may be unusable from a compliance perspective. REG.RU’s multiple Russian sites can be useful, but exact placement and controls need written confirmation.

Domain customers are affected even when they buy no hosting. The live AS197695 network and authoritative DNS addresses show that naming services have physical and routing dependencies too. Registrar accreditation and data escrow protect aspects of the registration relationship, but they do not make a customer’s chosen DNS architecture continuously available. Registration, authoritative DNS and application hosting are separate functions and should be assessed separately.

In each case the most important failure path is a chain. Power loss can remove a rack; a route failure can isolate a healthy machine; a storage fault can leave compute running without data; an account problem can prevent a traffic switch; an expired payment can interrupt a healthy service; and a slow support escalation can extend every one of them. The customer experiences the longest unresolved dependency, not the strongest component in the portfolio.

The operating verdict: real network, partial transparency, customer-built resilience

REG.RU clears the threshold for an operating infrastructure provider. The named registrar company is current in IANA’s registry, holds RIPE network resources and originates a large live routing surface through AS197695. The branded service estate contains orderable bare-metal inventory, virtual machines, storage and managed products. Documentation exposes physical addresses, remote-management methods, backup behaviour and a contractual availability target. Those are substantive operating signals.

The evidence is less complete at the boundaries. Public material blends group branding and multiple legal companies. Portfolio figures combine facilities that appear to have different owners and roles. Facility ratings and aggregate megawatts do not reveal REG.RU’s occupied or spare capacity. The global routing view does not prove circuit diversity at each site. Product pages do not provide a common map of replication and recovery domains. A structured, public incident history was not available for comparison with the SLA.

That combination deserves neither dismissal nor unqualified confidence. The network evidence is strong. The product evidence is strong for current availability of services. Facility ownership and product-by-product redundancy evidence are medium to weak. Historical outage evidence is weak. The correct customer response is to narrow every claim to the ordered service.

Before placing a critical workload, a buyer should obtain written answers to a short set of operational questions: the contracting company; the selected facility and its operator; the compute, storage and network failure domains; the location and immutability of backups; the recovery-point and recovery-time commitments; planned-work treatment; hardware replacement terms; support escalation; balance and suspension rules; and the tested export route. For multi-site designs, the buyer should also confirm whether capacity is reserved at the alternate location and whether DNS, identity and management remain usable when the primary location fails.

REG.RU’s value proposition is the reduction of friction. A customer can start with a name and add increasingly physical forms of infrastructure without leaving the same commercial environment. The underlying reality moves in the opposite direction: each added service introduces servers, disks, network links, facility contracts, support teams and recovery decisions. The cloud interface makes those dependencies easier to buy. It does not make them disappear.