Varna Data Center EOOD has to prove whether marketed data-centre capacity can survive power and carrier constraints

Summary

• Varna Data Center EOOD has a real public infrastructure footprint. The company site advertises colocation, VPS/cloud, dedicated server and IP communications services, while the contacts page separates an office address from a data-centre address at 128 "8 Primorski Polk" boulevard in Varna.
• The network anchor is AS57619. RIPEstat's AS overview identifies the holder as VDC-AS Varna Data Center EOOD and marked it announced on the 2026-07-12 query window; RIPE DB lists the organisation as Varna Data Center EOOD, country BG, registration number 201520130, and the AS name VDC-AS.
• Public routing is useful but compact. RIPEstat routing status showed four IPv4 prefixes, 1,024 IPv4 addresses, no IPv6 prefixes and seven observed neighbours on the checked window; announced prefixes listed 77.71.112.0/24 through 77.71.115.0/24.
• The facility claims are specific: the infrastructure page says the site has a 35 cm raised floor, 47U standard racks, N+1 A and B UPS systems, a diesel generator, two utility loops, redundant fibre paths, gas extinguishing and 24/7 on-site engineering support. The same public record does not publish rack count, contracted power, current load, generator fuel runtime, chiller model, maintenance results or tested customer failover.
• The evidence grade is Medium. Varna Data Center EOOD is not just a name on a map, but the public material supports a careful buyer's question list more than it supports a clean resilience verdict.

The marketing claim is physical, not abstract

Varna Data Center EOOD presents itself as a local infrastructure company rather than a pure software reseller. The colocation page describes customer equipment being deployed in the company's Varna Data Centre. The VPS/cloud page describes physical servers split into several virtual servers, with migration in real time and low-level archiving offered as possible advantages of virtualization. The dedicated-server page says the customer gets full control of a physical server owned by VDC and provided entirely to that customer's needs.

Those claims matter because they move the service out of the realm of generic hosting language. Colocation depends on racks, floor load, cable trays, cross-connects, access controls and customer hardware. VPS depends on host density, storage headroom, hypervisor design, backup practice and operational staff. Dedicated server rental depends on owned or leased physical hardware, spares, remote access, power supply replacement and hands-on repair windows. A company can market all three products only if it has access to a real facility base or to someone else's facility base.

The public evidence for Varna Data Center EOOD points to its own Varna site, but the evidence still needs careful handling because public pages are not a load test.

The most important public address split is on the contacts page. It lists "Office VDC" at 18 "Nikola Mihaylowski" Street in Varna and a "Data Center" at 128 "8 Primorski Polk" boulevard, also in Varna. That separation is useful. It keeps the reader from mistaking a commercial office for the technical room and gives customers a specific facility location to check against local power, building, fibre and access constraints.

The older Bulgarian "About us" page adds useful history. The Bulgarian page says the project started in 2011 with the ambition to meet the need for an independent high-technology data centre in Varna and the region. It also says the company's strategic position lets customers choose connectivity with one or several internet providers. Those are not proof of present capacity, but they help explain the company thesis: a regional Varna facility can matter if businesses want local hosting, local technical access and more than one route out of the city.

That regional thesis is credible. It is also not enough. A data-centre buyer does not only need to know that a room exists and that products are listed. The buyer needs to know how many cabinets are installed, how much usable electrical capacity remains, how the A and B power paths are tested, how many carriers enter the building, how fibre paths avoid the same trench, whether customer failover has been tested, and how support responds when a failure happens at night or during a city-wide utility incident.

The public identity anchor is AS57619

The clearest network identity anchor is RIPEstat's AS overview for AS57619, which identified the holder as VDC-AS Varna Data Center EOOD and showed the ASN as announced on the 2026-07-12 query window. The more detailed RIPE database search for AS57619 is even more useful. It lists an aut-num entity for AS57619, AS name VDC-AS, organisation ORG-VDC1-RIPE, assigned status, creation in 2011 and a last modified date in 2026. The same result lists an organisation entity whose name is Varna Data Center EOOD, country BG and registration number 201520130.

That is stronger than a brochure. An autonomous-system entity is not an uptime guarantee, but it is a public control surface. It means the company is visible in the internet routing system and has records that other networks and customers can test. If a facility offers colocation and hosting but has no public ASN, a customer may have to rely entirely on another carrier's disclosure. Varna Data Center EOOD at least gives buyers a named ASN to monitor.

The RIPE entity also shows an operator boundary. It lists upstream import policies from AS29687, AS48355, AS174, AS57344 and AS60349, and customer import policies from AS213093, AS204784 and AS202593. Those policy lines should not be read as a perfect map of live traffic, because routing policy records can lag operating reality. But they are meaningful because they state how the network presents itself to the routing community. They show that Varna Data Center EOOD's public internet role is not limited to a single static website; AS57619 is positioned as a network that buys upstream connectivity and also serves downstream customers.

The route object adds more detail. The same RIPE DB query returns a route object for 77.71.112.0/22 with the description "Varna Data Center EOOD network" and origin AS57619. It also shows that the broader 77.71.0.0 - 77.71.127.255 allocation is associated with Geodim Ltd. as the local internet registry. That is a normal arrangement in which address space can be allocated and routed through a local operator relationship. It does mean the customer should distinguish "address resource visible through AS57619" from "property or capacity owned by Varna Data Center EOOD."

The useful conclusion is not that AS57619 proves resilience. It proves that there is a public network surface to interrogate. Buyers can ask for route maps, upstream contracts, BGP communities, maintenance windows, route-origin authorization, incident history and planned capacity changes. Without those answers, the route record anchors the company but does not settle the operating risk.

The route surface is compact and mostly IPv4

The RIPEstat routing-status view showed AS57619 first seen in 2011 and last seen on 2026-07-12 in the checked window. It reported four IPv4 prefixes, 1,024 IPv4 addresses, no IPv6 prefixes and seven observed neighbours. The announced-prefixes endpoint listed 77.71.112.0/24, 77.71.113.0/24, 77.71.114.0/24 and 77.71.115.0/24 for the 2026-06-28 to 2026-07-12 interval.

That is enough to support a live network claim. It is not enough to support a large-capacity claim. Four /24s are a regional hosting and colocation footprint, not the kind of public address surface associated with a large multi-campus operator. A compact route surface may be perfectly adequate for the service being sold. It may even be desirable if the company is serving local businesses with specific rack, VPS and communications needs. But it narrows the margin for inference. The reader should not convert "four routed /24s" into assumptions about cabinet count, megawatts, carrier blend or enterprise-grade failover.

The IPv6 point deserves specific attention. VarnaIX's members table lists Varna Data Center EOOD with an IPv6 exchange address, 2001:7f8:db::5:7619:1, on a 10G Varna port. RIPEstat's AS57619 routing-status snapshot, however, showed no current IPv6 prefixes for AS57619 itself in the checked public route view. Those two facts can coexist. A network can have an exchange-facing IPv6 address without announcing customer IPv6 prefixes, and route collectors may not show every private or limited-use arrangement. The practical buyer question is whether customer services have routable IPv6, whether it is production-supported, and whether IPv6 has the same resilience and support treatment as IPv4.

The route-origin authorization picture is stronger. RIPEstat's RPKI validation endpoints for 77.71.112.0/24, 77.71.113.0/24, 77.71.114.0/24 and 77.71.115.0/24 each returned valid origin status for AS57619 in the checked result. That is good routing hygiene. It lowers the risk that the visible prefixes are accidentally or maliciously originated by the wrong ASN. It does not prove that the facility has enough power, cooling or spare equipment.

The public route surface should therefore be read as "real but compact." It gives customers enough to set up external monitoring and to verify origin authorization. It does not give them enough to believe that every advertised service can withstand a local power event, a chiller fault, a maintenance mistake or a fibre cut without specific contract evidence.

Carrier diversity is plausible, but not fully disclosed

The strongest public carrier-diversity evidence comes from three places: the company infrastructure page, the RIPE policy entity and VarnaIX. The infrastructure page says the facility has a "link to multiply independent channel networks," two independent approaches to the colocation room, redundant fibre connectivity in diverse physical paths and individual internet connectivity up to 10 Gbps. The RIPE DB AS57619 entity lists multiple upstream import/export entries. RIPEstat neighbours showed seven observed neighbours in the checked public view.

The neighbour names help make the evidence concrete. RIPEstat identified AS174 as COGENT-174 - Cogent Communications, AS29687 as BGWAN-AS Geodim Ltd., AS57344 as TELEHOUSE-AS Telehouse EAD, AS60349 as VARTEH-AS Varteh LTD, AS202593 as AS_iGaming_Ltd iGaming.com Limited, AS204784 as SIS TECHNOLOGY AD, and AS213093 as PS BG EOOD. The AS48355 overview identifies VARNA-IX Varteh LTD, though RIPEstat marked it not announced on the query window while the AS57619 RIPE policy entity still listed it as an upstream policy entry.

VarnaIX is especially relevant because it is local. The VarnaIX home page describes a neutral internet exchange located in Varna with presence in points and data centers in Varna, Burgas and the region. Its members page lists Varna Data Center EOOD, ASN 57619, IPv4 address 185.1.137.28, IPv6 address 2001:7f8:db::5:7619:1, 10G port type, main router location Varna and community tag 48355:57619. PeeringDB's IX API record for VarnaIX also lists VarnaIX in Varna, Bulgaria, with the website varnaix.net.

Those sources support a serious but limited conclusion. Varna Data Center EOOD appears to have more than one upstream or interconnection path in the public routing record, and it appears as a VarnaIX member. That is materially better than a single-carrier hosting site with no independent ASN and no local exchange entry. But it still leaves the most important engineering questions unanswered. Are the upstreams delivered through physically diverse building entrances? Do the listed neighbours carry production traffic at useful capacity, or are some only policy entities or limited peering sessions?

Does the 10G exchange port have enough headroom during a carrier fault? Are there automatic route preferences, or does staff intervene manually? Are customer cross-connects available to carriers independently of AS57619 transit?

The PeeringDB network API query for AS57619 returned no public network profile in the checked result. PeeringDB absence is not a fault by itself; participation is voluntary and self-maintained. But absence removes a common public place where operators publish facilities, exchanges, traffic policy, looking-glass URLs, NOC contacts and peering terms. For a buyer, that means the due-diligence burden shifts back to direct documentation from Varna Data Center EOOD.

The facility page gives a verification map, not a capacity audit

The infrastructure page is the most specific public page in the record. It says the site has a 35 cm raised floor, perforated plates in front of racks, raised-floor weight capacity up to 1,000 kg per square metre, a standard rack footprint of 2150 x 600 x 900 mm and 47U cabinet height. On power, it says there are fully independent N+1 A and B UPS 220V systems, a diesel generator, individual meters for each cable or fuse, and Class-A main electrical power provided by two independent loops of the energy operator. On cooling, it says N+1 indoor units, a maximum distance of 10 m from the chiller, 20 degrees Celsius with a stated tolerance, relative humidity around 50 percent with a tolerance, cold air under the raised floor, perforated plates and separate hot and cold zones. On fire and security, it lists addressable smoke and high-temperature detectors, evacuation, NAF S125 gas extinguishing, 24-hour building security, video surveillance, access control and cabinet locks. On support, it lists 24/7 support engineer, on-site technical support and assisted customer access.

That is a useful question set. It is more detailed than a vague "enterprise grade" claim. It tells customers what physical systems to inspect: raised floor, rack loading, dual UPS paths, generator, utility loops, metering, chiller distance, hot/cold separation, fire detection and gas suppression. It also tells them what documents to request: commissioning records, preventive-maintenance logs, load-bank test results, generator fuel contracts, UPS battery age, chiller maintenance reports, access logs and incident history.

But the page does not publish the key capacity numbers. It does not say how many cabinets are installed, how many are available, how much power is contracted from the utility, how much of that power is already loaded, how many kilowatts per cabinet are supported, what the UPS autonomy is at actual load, how many hours the generator can run on stored fuel, whether generator refuelling has priority during road disruption, how many chillers are installed, whether N+1 remains true under summer peak load, or whether fire-gas zones cover every technical area.

The phrase "up to 10 Gbps" on individual internet connectivity is also not the same as a guarantee of port availability, upstream headroom or customer throughput during congestion.

This is where installed capacity and usable capacity separate. Installed capacity is the visible asset base: racks, power systems, cooling units, fibre paths and product pages. Usable capacity is what remains after a real fault. If one UPS module is out for maintenance, does N+1 still hold? If a utility loop fails during summer heat, can the generator carry the actual IT and cooling load? If the chiller closest to the room fails, does the air distribution design still keep inlet temperatures within limits? If one fibre path is cut, does the second path leave the building through a different duct and route to a different carrier meet point?

The public page gives enough detail to ask these questions; it does not answer them.

The certificates page says Varna Data Center is ISO 27001:2013 certified in the scope of providing hosting services, colocation, virtual machines, rental of communication equipment, and developing and delivering web and cloud solutions. That is meaningful for information-security management scope. It is not the same as a public tier certification, a facility availability standard, a current audit report or a guarantee that every resilience claim has been independently tested. Customers should therefore treat ISO 27001 as part of vendor assurance, not as a substitute for facility engineering evidence.

Power is the main local dependency

Power is the most important failure path because every other promise depends on it. The facility page claims two independent loops from the energy operator, N+1 A and B UPS systems and a diesel generator. Those are exactly the systems a data centre needs. They also create the most direct diligence requests: single-line diagrams, utility-feed evidence, transfer-test results, UPS topology, breaker discrimination, battery maintenance, generator rated capacity, fuel storage, refuelling arrangements and incident procedures.

The local distribution context matters because Varna Data Center EOOD is a regional facility, not an abstract cloud zone. ENERGO-PRO's planned-outages page for ERP North says planned power outage information is provided by region and includes Varna among the regions. ENERGO-PRO also announced a digital notification system for planned power interruptions, saying customers can receive email warnings about scheduled repairs. A January 2026 notice said EPR North suspended planned outages in Varna region during an influenza epidemic, and another notice said ENERGO-PRO provided 66 duty teams across its north-eastern Bulgarian operating territory during a holiday period.

Those sources do not say the Varna Data Center facility lost power. They should not be used that way. Their relevance is more structural: distribution networks have planned works, emergency works and public-notification procedures. A data-centre operator that claims dual utility loops and generator backup should be able to explain how those utility realities are incorporated into maintenance windows and incident response. If a planned utility interruption affects one loop, the facility should know whether the second loop remains independent and whether generator tests are aligned with the risk window.

If a broader regional incident affects supply, the buyer needs to know generator runtime and refuelling rather than simply hearing that a generator exists.

The company's own contract language reinforces the point. The general terms say colocation clients must provide spare parts such as power supplies and hard drives for replacement if a component of the client's server stops working. That matters during power events because customer-owned equipment failures can follow utility disturbance, transfer events or thermal stress. The facility may maintain the room, but the customer may still own the server component risk. A buyer placing critical equipment should therefore keep spare parts on site or under a written support arrangement, and should understand which repairs are standard support versus chargeable work.

The same terms say the provider may make changes in the technical center to improve and optimize its work after obtaining prior consent from the client, and that such changes should not deteriorate the client's contractual use of the technical center. That suggests maintenance and technical change are contemplated by contract. It also means the customer should make maintenance notice, approval, rollback and incident-communication duties explicit in the individual contract, not assume they are implied by the marketing page.

Cooling and fire controls need live evidence

Cooling is the second major failure path. Varna's Black Sea location does not make cooling risk disappear. The public facility page says the design uses N+1 indoor units, chillers close to the room, underfloor cold air and separate hot and cold zones. Those are standard concepts for a small or regional data centre. The question is whether they hold at actual IT load, with current equipment density, during summer heat, while one unit is out of service.

Climate context raises the bar for evidence. The World Bank's Climate Change Knowledge Portal for Bulgaria provides country climate context, and its historical climatology page highlights heat stress as particularly relevant in urban areas. Copernicus reported that southeastern Europe had six heatwaves during summer 2024, including the region's longest and second most severe heatwave on record, in its page on heat and drought in southeastern Europe. Copernicus also reported rising European heat-stress days in its thermal-stress assessment.

Those climate sources do not specifically grade the Varna facility. They support a common-sense engineering point: cooling systems should be assessed against heat waves and high overnight temperatures, not only against a brochure operating point. A customer should ask whether the facility has recent inlet-temperature monitoring, whether there are cold-aisle containment practices, whether humidity excursions are logged, whether alarms are tested and whether chiller maintenance is scheduled before summer peaks.

If the design target is 20 degrees Celsius plus or minus a tolerance, the buyer should ask what temperatures were actually recorded during recent hot periods.

Fire protection is similar. The facility page lists multi-zone detection, high-temperature detectors, evacuation and a gas extinguishing system based on NAF S125. That is more useful than a generic "fire protected" statement. But suppression claims still need commissioning, cylinder inspection, zoning diagrams, maintenance dates, staff training and post-discharge recovery plans. A fire event in a compact data room can become a business outage even when suppression works, because customers may lose access, power distribution may need inspection, and equipment exposed to heat, smoke or suppressant discharge may require replacement.

The sensible resilience test is operational rather than rhetorical. Ask for evidence that alarms have been tested, that suppression zones match the actual room layout, that customer access is controlled during maintenance, and that emergency procedures specify who can enter, who communicates, who powers down, and who verifies safe restart. For hosted services, ask whether snapshots, backups and virtual-server images are outside the affected zone. For colocation, ask where customer spare parts are stored and who is authorized to install them.

Hosted services shift some risk back to the customer

The service menu creates three different customer risk models. In colocation, the customer's equipment is in the facility and the facility provides space, power, cooling, connectivity, access and support. In VPS or cloud service, Varna Data Center EOOD provides virtualized capacity on physical servers. In dedicated server rental, the company provides a physical server to the customer. The failure modes overlap, but accountability differs.

The VPS/cloud page describes virtual servers created by dividing a physical server and says virtualization can offer live migration and low-level archiving without disturbing system performance. That phrasing is careful: it says such options may be offered; it does not say every plan includes automatic failover, continuous replication or guaranteed live migration. The general terms add that all virtual servers and VPS hosting services are unmanaged by default, and that customers must manage their own virtual servers unless they buy management. They also say the provider is committed to put a virtual server into service within 24 hours after receiving payment.

That means a VPS buyer should not assume the provider owns the entire recovery problem. If the guest operating system is misconfigured, compromised or missing backups, unmanaged service language may leave recovery largely with the customer. If a host fails, the buyer needs to know whether migration is automatic, manual or unavailable for the purchased plan. If storage fails, the buyer needs to know whether low-level archive exists, how often it runs, where it is stored, and how restoration is requested.

The dedicated-server page says the customer gets full control over a physical server owned by VDC. The server-for-rent promotion lists a Dell PowerEdge R630 with two Intel Xeon E5-2680v4 processors, 128GB RAM, two 1000GB SSDs in RAID 0 or 1, two power supplies and a monthly price. That is concrete enough to show the kind of rented hardware being marketed. It is not a statement about available stock, hardware replacement time, RAID rebuild policy, out-of-band access or backup inclusion.

The FAQ explains why server-grade hardware differs from desktop machines, including multiple processors, disk arrays, redundant power, component replacement without stopping the server, upgradeability and reliability for continuous operation. That is educational material, not a plan-specific commitment. A customer should therefore insist that the order form, SLA and support procedure translate those concepts into concrete duties: spare power supplies, disks, remote hands, response times, maintenance approval, monitoring thresholds and data protection.

The virtual IP PBX page and BCM page broaden the affected-user set. Varna Data Center EOOD is not only selling rack space. It is also marketing communications and business-management software that can sit directly in customer call flows, contact histories and support operations. If the same facility or network underpins those services, a power, cooling or carrier failure can interrupt not only websites and servers but also telephone, CRM and call-centre functions.

Who is affected when the system fails

The affected parties are easy to understate because the public footprint is not hyperscale. A regional data centre can still be critical to its customers. Colocation customers may have their own routers, servers, storage and security appliances in the room. VPS customers may run small business websites, internal tools, accounting systems, remote desktops or application servers. Dedicated-server customers may host databases, e-commerce sites, backup targets or specialized applications. Communications customers may depend on IP PBX, SIP or BCM services for phone calls, customer records and internal coordination.

The failure chain can start in several places. A utility outage tests UPS, generator start, load transfer and fuel logistics. A cooling fault tests airflow, chiller redundancy and staff response before server inlet temperatures rise. A carrier-meet interruption tests physical fibre diversity and BGP path selection. A fire alarm or suppression event tests evacuation, safe-entry rules and restart discipline. A planned maintenance error tests change control. A customer hardware fault tests spare-part availability and remote hands.

A billing or contract dispute tests whether account administration can disable a service even when the technical system is healthy.

The general terms show how some of these responsibilities are assigned. Colocation clients must provide spare parts for their own equipment. VPS is unmanaged by default. Standard support for equipment in the technical center includes installation or replacement of communication blocks, reboot or connecting leased lines. The provider is entitled to optimize software for technical reasons and make technical-center changes with prior consent if they do not deteriorate contracted use. Those clauses are not unusual. They show why the customer has to read the contract as an infrastructure document, not only as legal boilerplate.

When a data centre fails, the business question is not simply "who caused it?" It is "who can act?" If a customer server needs a disk, does the provider have authorization to open the chassis? If a virtual machine is down after host trouble, who owns the backup? If a carrier route is congested, can the provider shift traffic or only open a ticket? If a power event damages customer equipment, who verifies the fault and who pays for parts? If a contact-centre application is unavailable, do customer service teams have a fallback number or offline list?

The article's operating-status hypothesis is therefore cautious. Varna Data Center EOOD's public footprint is real enough to justify commissioning analysis, but not rich enough to grant a high-confidence resilience rating. The downgrade is not a negative verdict; it is an evidence discipline. A facility can be well run and still publish little. But when public disclosure is thin, the buyer must move from marketing pages to engineering documents before depending on the service.

The evidence that would settle the question

The buyer's verification list should start with power. Ask for the utility single-line diagram, evidence that the two loops are physically and electrically independent, UPS topology, actual load percentages, battery-maintenance status, generator rating, generator test dates, fuel capacity, refuelling agreements and the conditions under which the generator has carried real customer load. Ask whether maintenance can place the site temporarily below N+1 and how customers are notified when that happens.

The second list is cooling. Ask for as-built airflow diagrams, chiller and indoor-unit inventory, maintenance records, capacity at summer design temperature, actual temperature and humidity logs, alarm thresholds, and the response plan for a failed indoor unit or chiller. If cabinet densities vary, ask whether high-density cabinets are capped, isolated or priced differently. If the facility is older, ask how it handles newer server power densities relative to the 47U rack standard and raised-floor airflow.

The third list is carrier and route resilience. Ask for current upstreams, port speeds, committed rates, physical entrance routes, meet-me arrangements, cross-connect options, BGP communities, route-filtering practice, DDoS handling, planned maintenance windows and failover tests. The route record shows AS57619 is active and validly originates four /24s. VarnaIX shows a 10G exchange port. That is the starting point. The final answer depends on whether those paths are actually diverse enough for the customer's application.

The fourth list is service recovery. For VPS, ask whether migration is live, cold or manual; whether backups are included; where images are stored; how long restore takes; and whether the customer can export images. For dedicated servers, ask for hardware replacement targets, spare stock, IPMI or remote-console access, disk replacement policy and data-retention handling. For colocation, ask what work is included in standard support and what requires a separate order. For IP PBX and BCM-type services, ask how voice and customer-history functions continue during facility or carrier disruption.

The final list is proof. Ask for recent incident summaries, maintenance notices, sample customer communications, monitoring screenshots with sensitive customer information removed, security-audit scope, fire-system maintenance records and insurance limits. Public pages can establish that the facility and network exist. Proof establishes whether the site behaves as advertised under stress.

The operating verdict is medium, with a clear downgrade

Varna Data Center EOOD clears the first threshold. The company has a public Varna data-centre address, service pages for colocation and hosted capacity, a detailed infrastructure page, ISO 27001 scope language, an active ASN, valid route-origin checks for its four visible IPv4 prefixes, multiple observed BGP neighbours and a VarnaIX member entry. That is a materially stronger record than a shell hosting brand with no route trace and no facility page.

It does not clear the second threshold. The public material does not prove installed rack count, usable power headroom, generator runtime, chiller capacity at peak heat, carrier entrance diversity, customer cross-connect availability, current service inventory, failover tests, backup restoration performance or incident history. The network page on the company's own English site says only "Coming soon!", which is awkward for a data-centre operator whose resilience claim depends heavily on network transparency. The route system partially fills that gap, but it cannot answer physical and procedural questions.

The fair conclusion is a medium network evidence grade and a cautious operating posture. Varna Data Center EOOD looks like a real regional data-centre and hosting provider in Varna. Its marketed capacity should be treated as plausible. Its resilience should be treated as unproven until the company supplies direct engineering evidence. For low-risk workloads, the public record may be enough to begin a vendor conversation.

For regulated data, customer-facing production systems, call-centre services or equipment that cannot be quickly moved, the buyer should require written answers on power, cooling, carrier diversity and recovery before relying on the service.

The company does not have to look like a hyperscale campus to matter. A small Varna facility can be valuable precisely because it is local: it can give regional businesses nearby racks, local hands, exchange access and Bulgarian operating context. But that local value is strongest when it is paired with transparent resilience evidence. Until then, the marketed data-centre capacity is best read as a serious claim still waiting for the hard proof that it can survive the failures that matter.