Cloud Vault SRL sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Cloud Vault SRL is publicly tied to real network resources. RIPE RDAP for AS50819 names STAR-STORAGE-AS, lists Cloud Vault SRL as the registrant organisation through ORG-CVS5-RIPE, and gives a Bucharest address under the Cloud Vault organisation record.
• The route evidence is current. RIPEstat's AS overview marked AS50819 as announced on 12 July 2026, and announced-prefix data showed IPv4 and IPv6 prefixes including 185.18.226.0/23, 91.234.168.0/23, 185.102.88.0/22, 194.1.169.0/24, 80.96.50.0/24, 2a0c:eec0::/29 and 2a00:1480:3::/48.
• The company's own service pages sell infrastructure functions: data-centre services, IaaS, disaster recovery, backup as a service, connectivity, managed services and security.
• The evidence grade is Medium. Cloud Vault is visible as an operating Romanian cloud network, but public pages and routing records do not by themselves prove customer-specific multi-site failover, spare-hardware depth, support escalation, backup restore performance, data export terms or the exact upstream capacity behind each service.

The company is visible, but the capacity still has to be mapped

Cloud Vault SRL is easier to analyze than a purely generic cloud brand because several independent records point in the same direction. The public company-facing site at cloud-vault.ro presents Cloud Vault as a provider of cloud, data-centre, security, connectivity and professional services. Its service pages do not merely sell advice; they describe infrastructure products that customers would naturally rely on for compute, storage, backup, recovery, connectivity and managed operation.

The registry evidence is more concrete. RIPE RDAP for AS50819 lists the autonomous system name as STAR-STORAGE-AS and shows the status as active. The same RDAP response includes Cloud Vault SRL through ORG-CVS5-RIPE, with an address at Bd Dimitrie Pompeiu Nr 8, Lot 1, Bucuresti Sector 2, Romania. RIPE RDAP for ORG-CVS5-RIPE independently exposes the organisation entity behind that AS record. The naming history matters because older route and AS names can preserve a previous commercial identity even after a corporate or brand transition. It should not be used to invent a separate public entity; it should be treated as a continuity clue that the same operating surface has older network-resource roots.

The commercial question is not whether Cloud Vault exists. It does. The question is how much of the customer's service is covered by the public evidence. A company can have a live AS, a data-centre service page and backup products while still leaving major recovery details outside public view. Customers need to know the production site, the recovery site, the power design, the carrier mix, the hypervisor and storage boundary, the backup retention rules, the support route and the exit path. Public routing and marketing pages start that inquiry; they do not complete it.

That is why this article treats Cloud Vault as an operating infrastructure dependency with a Medium evidence grade. The route surface is real. The Romanian cloud-service offer is real. The public record is not deep enough to say that a given customer workload can survive a rack fault, an upstream outage, a failed storage array, a billing dispute or a rushed migration without additional contract evidence.

AS50819 turns the service claim into observable network evidence

The strongest public evidence for Cloud Vault is AS50819. RIPEstat's AS overview reported holder STAR-STORAGE-AS Cloud Vault SRL and marked the AS as announced on the 12 July 2026 query. That one line does useful work: it connects the Cloud Vault name to an autonomous system that the global routing system can see.

The announced-prefix view adds scale without turning it into a capacity guarantee. RIPEstat announced-prefix data for AS50819 returned visible prefixes including 185.18.226.0/23, 91.234.168.0/23, 2a0c:eec0::/29, 185.102.88.0/22, 194.1.169.0/24, 2a00:1480:3::/48 and 80.96.50.0/24 for the checked window. RIPEstat RIS-prefix counts counted nine originating IPv4 prefixes and two originating IPv6 prefixes at the query time, with no visible transiting prefixes. RIPEstat routing-status data showed full RIPE RIS peer visibility at the checked time: 326 of 326 IPv4 peers and 322 of 322 IPv6 peers seeing the route surface.

That is much stronger evidence than a static company profile. It says Cloud Vault is not only selling a cloud story; it is operating, or at least controlling, visible routed number resources. It also says the visible network is a customer-facing origin network rather than a transit provider carrying large numbers of third-party routes. A customer can use that fact in due diligence. It is reasonable to ask which products use which AS50819 prefixes, which prefixes are production, which are management, which are backup or test, and which are customer-assigned.

The same data limits the claim. Prefix count is not server count. A /22 or /23 can support many services, but it does not reveal how many hypervisors, storage nodes, racks, cross-connects, UPS strings, generators, engineers or customer recovery contracts sit behind the addresses. IPv6 visibility is encouraging, but it does not prove every customer product is dual stack, monitored and covered by the same failover procedures. Routing data proves reachability; it does not prove recoverability.

The service pages sell a wide dependency stack

Cloud Vault's service pages matter because they show where customers may become dependent. The data-centre page frames the company around hosted physical infrastructure. The IaaS page sells infrastructure-as-a-service capacity. The disaster-recovery page sells continuity. The backup-as-a-service page sells protection of customer data. The connectivity page makes network access part of the offer. The managed-services page puts operational labour into the service. The security page adds another customer-critical layer.

Those pages are relevant because a hosted-capacity provider can fail through several layers at once. A compute service can be up while the customer cannot authenticate. A backup can exist while restore bandwidth or approval rules make it slow. A data-centre service can have power while an upstream route is degraded. A managed-service desk can be responsive during normal incidents and overloaded during a regional fault. A security service can protect the customer but also become part of suspension, quarantine or incident-response decisions.

For Cloud Vault, the public service mix suggests a provider that is selling a combined stack rather than a single commodity server. That can be valuable. Customers often want one provider to carry hosting, backup, recovery, connectivity, security and day-to-day operations. The same bundling increases dependency. If one account, one support chain or one physical site becomes the center of the customer's IT estate, an outage is no longer only a server issue. It becomes a business-continuity issue.

The right customer question is therefore not simply "does Cloud Vault have cloud services?" The answer is plainly yes. The useful question is "which part of my workload, backup, management access, monitoring and exit path depends on Cloud Vault-controlled assets, and which part depends on third parties that Cloud Vault coordinates?" Public pages can describe the service categories, but they rarely disclose the full repair map. That map should be requested before production dependency grows.

The upstream picture is visible but not fully documented

RIPEstat's neighbour data gives a useful snapshot of the public routing boundary. ASN-neighbour data for AS50819 showed two observed left-side neighbours at the 11 July 2026 query time: AS12302 and AS39737. The response identified two unique neighbours and no uncertain neighbours in that snapshot. That does not equal a signed carrier inventory, but it does say that route collectors saw AS50819 connected through two upstream or adjacent AS paths.

The public due-diligence value is straightforward. Two observed neighbours are better than a single visible path, but they are not the same as proven physical diversity. The two paths may share a facility, a meet-me room, a duct, a metropolitan fibre dependency, a router vendor, a power domain or a commercial parent. Conversely, Cloud Vault could have private or backup arrangements that are not visible from public collectors. Public BGP sees only what it sees.

Customers should ask for four layers of diversity. The first is logical routing diversity: can routes stay visible if one neighbour fails? The second is commercial diversity: are the counterparties meaningfully independent? The third is physical diversity: do the circuits enter different equipment, rooms, ducts or sites? The fourth is operational diversity: can staff diagnose, authorize and execute the route change during an incident without waiting on one person or one third-party queue?

Cloud Vault's route evidence supports the first part of that conversation. It does not close the last three. A customer with ordinary workloads may accept that uncertainty if price, locality and support fit. A customer with regulated, revenue-critical or public-facing workloads should require more evidence: current upstream names, committed capacity, maintenance windows, failover testing, route-filtering practice, RPKI posture and customer communication procedures.

Prefixes are not the same as customer portability

The announced prefixes are a useful map of public reachability, but they also raise portability questions. Cloud Vault's visible route set includes multiple IPv4 and IPv6 prefixes. Some will be Cloud Vault-held or Cloud Vault-maintained resources; some may reflect allocation history, reassignment or older Star Storage naming. That is normal in European network operations. The problem for customers is not the history itself. The problem is assuming that an address used for a customer service can move freely whenever the customer needs it to move.

A cloud or hosting customer often builds hidden dependencies around IP addresses. Firewalls allowlist them. DNS records point to them. Certificates, reverse DNS, mail reputation, partner integrations, monitoring systems and access-control rules all become attached to them. If an outage or migration requires renumbering, the service interruption is not limited to Cloud Vault's internal repair time. It includes customer-side change control, partner approvals and cleanup of old addresses.

That makes data portability and network portability part of the same question. If a customer can export data but cannot move the route, then a migration still requires DNS, firewall and application changes. If a customer can keep addresses during a Cloud Vault internal migration but cannot take them outside the provider, then the exit plan is different from the failover plan. If backup systems use different address space or private links, the customer needs to know which controls survive a primary-site incident.

The public record does not answer those details. It gives the prefix names and the AS origin. A serious buyer should ask whether the assigned addresses are provider-assigned or portable, what notice is required before renumbering, whether reverse DNS can be changed in an emergency, whether customer-owned prefixes can be announced, and whether Cloud Vault supports bring-your-own-address arrangements where appropriate. Those questions turn route evidence into a practical migration plan.

Data-centre evidence has to be separated from data-centre claims

Cloud Vault sells data-centre services publicly, but a service page is not the same as an independent site audit. The data-centre page is relevant because it shows the company wants customers to understand it as a physical infrastructure provider. It is still not a substitute for customer-specific evidence of where a workload runs, how power is backed up, how cooling is protected, which carriers are present and how access is controlled.

The Bucharest address in RIPE RDAP for ORG-CVS5-RIPE is an organisational anchor, not a rack coordinate. A corporate address can be an office, a data-centre campus, a registered location or an operations base. The address is valuable because it ties the AS holder to Romania and to a named location. It does not prove the production hall, the backup site or the legal place of every customer dataset.

That distinction matters for Romanian and European customers. Locality can be a buying reason. A customer may prefer a Romanian provider for latency, language, procurement, local support or data-residency expectations. But data residency has several layers: production data, backups, logs, monitoring, support tickets, identity records, billing records and administrator access. A service can be Romanian in brand and registration while still using third-party components, remote tooling or cross-border support under certain circumstances.

The best evidence would be a location schedule. It should state production region, backup region, management platform location, log location, support access boundary, subcontractor roles and circumstances under which data may move. The public pages do not supply that full schedule. Until a customer receives it, Romania should be treated as a strong operating signal rather than a complete data-sovereignty guarantee.

Backup and disaster recovery are only as good as restore proof

Cloud Vault's backup-as-a-service and disaster-recovery pages are important because they turn Cloud Vault from a capacity provider into a recovery provider. Recovery services are more sensitive than ordinary hosting. If the provider stores the backup and hosts the recovery target, a customer may depend on the same organisation for both failure and repair.

The public buyer question is simple: when was the last full restore test, what was restored, how large was it, how long did it take, and what failed during the test? A backup product without restore evidence is only a promise. A disaster-recovery product without a failover runbook, measured recovery time and clear responsibility boundary can become an expensive confidence device rather than a recovery system.

Cloud Vault's public materials signal that the company knows continuity is part of the offer. They do not publicly disclose customer-level RTO, RPO, restore throughput, isolation between production and backup, immutable backup settings, ransomware recovery procedures, emergency approval contacts or export formats. That is not unusual; many providers reserve those details for contracts. It does mean public readers should not infer a strong recovery guarantee from the presence of a DR page alone.

Customers should test restore under degraded conditions. Can data be restored if the normal management panel is unavailable? Can an administrator approve recovery if the usual account owner has left? Are backups reachable over a separate path if production connectivity is impaired? Can Cloud Vault restore to a different site, a different tenant or a customer-controlled environment? Are logs and configuration metadata included, or only data volumes? Those questions matter more than a generic backup label.

Managed services make support labour part of the availability surface

Cloud Vault's managed-services page adds another kind of dependency: people and procedures. Managed service customers do not only buy servers or circuits. They buy monitoring, response, patching, escalation, change control and advice. During a normal week, that can improve resilience. During a major incident, it can become the bottleneck.

Support labour is part of infrastructure because it determines repair speed. A storage fault, DDoS event, route leak, backup failure, certificate problem or billing lock may require technical access, commercial authority and customer approval at the same time. If the support desk can diagnose but cannot authorize a route change, recovery slows. If an account manager can approve but cannot reach the engineering team, recovery slows. If a customer contact is unavailable, recovery may stop despite the provider having spare capacity.

The public record does not disclose Cloud Vault's staffing model, escalation ladder, incident communication cadence, out-of-hours authority or customer-specific support tiers. A customer should ask for those terms explicitly. Who answers first? Who can touch infrastructure? Who can change routes? Who can restore backups? Who can authorize emergency export? Who tells customers whether the incident is power, network, storage, platform, security or account state?

That is not a criticism of Cloud Vault. It is a reminder that cloud dependency becomes human dependency during a fault. The customer is not only buying equipment; it is buying the provider's ability to decide, communicate and act under pressure.

Security services can protect the customer and still create control risk

The security page belongs in the same resilience analysis. Security services can reduce risk through monitoring, detection, filtering, patching or response. They can also introduce control paths that affect availability. A security rule can block traffic. A quarantine decision can isolate a system. An abuse response can suspend a customer. A credentials problem can prevent administrators from reaching the console.

For customers, the question is not whether security is good or bad. It is how security actions are governed. Who can block an IP address? Who can disable a tenant? What evidence is required for emergency isolation? How are false positives reversed? Are backups protected from compromised credentials? Are customer contacts verified before destructive action? Can security logs be exported if the relationship ends?

Cloud Vault's public pages show that security is in the service mix. They do not publish the operational decision tree for security events. A customer with regulated or public-facing services should require one. Security response and availability response need to be coordinated, not treated as separate departments.

The same logic applies to DDoS, abuse and lawful requests. If a customer's traffic attracts mitigation, filtering or suspension, the service can become unavailable even when servers and routes still exist. That makes acceptable-use terms, incident notification, evidence thresholds and appeal mechanisms part of infrastructure due diligence.

The most exposed customers are the ones that accumulate state

Cloud Vault can be a rational choice for Romanian or regional customers that want a local cloud provider, support in a familiar market and services spanning hosting, backup, recovery, security and connectivity. The highest-risk customer is not necessarily the one that starts with a small virtual machine. It is the customer that starts small, accumulates state, points production DNS at the platform, connects backups, adds managed security, and only later discovers that the exit path was never tested.

Stateful workloads are unforgiving. Databases, business applications, file stores, identity systems, mail services, hosted desktops, call platforms and backup archives all depend on more than compute. They depend on consistent storage, authentication, logs, address continuity, restore rights, data export and support authority. A temporary outage can become a business crisis if the customer cannot move the data or prove what happened.

The visible AS50819 route set gives Cloud Vault a real operating surface. The service pages give the company a broad product surface. The missing public evidence is the customer-specific recovery surface. What happens if the primary site is unavailable? What happens if one upstream is degraded? What happens if a backup restore competes with many other customer restores? What happens if a customer wants to leave during a dispute? What happens if a security event requires isolation before the customer has exported data?

A buyer should answer those questions before treating Cloud Vault as a critical dependency. The answers may be strong. Cloud Vault may have private designs, contracts and procedures that are not visible publicly. The point is that the public record does not let outside readers assume them.

What would improve the evidence grade

Cloud Vault's evidence grade would move toward Strong if public or customer-shareable materials connected the visible routes, service pages and recovery claims into a single operating map. The most useful evidence would name production and recovery locations at a non-sensitive level, identify upstream and carrier diversity, explain which products use AS50819 address space, state backup and restore targets by service class, and show how customers can export data and configuration.

Route-security evidence would also help. A public RPKI posture, IRR-maintenance policy, route-filtering practice and monitoring statement would make the AS50819 route surface easier to evaluate. BGP evidence already says the AS is visible. Routing-security evidence would say more about how intentionally it is managed.

Facility evidence would help as well. Customers do not need rack coordinates in public documents, but they do need enough information to distinguish office address, data-centre site, backup site and support location. If Cloud Vault operates multiple sites or uses specific third-party data centres, the customer should know what each site does and what failure it protects against.

Finally, portability evidence would be decisive. A provider that can show export formats, DNS and reverse-DNS procedures, customer-owned key handling, account recovery, termination grace periods and tested migration steps gives customers a way to manage dependency. In hosting, the ability to leave is part of the ability to trust.

Contract boundaries decide what the customer can demand

The public technical evidence tells a customer where to ask questions, but the contract decides what the customer can demand when the service is under stress. That distinction is especially important for a provider such as Cloud Vault, whose public surface combines data-centre, cloud, backup, security, connectivity and managed-operation services. A buyer may experience those as one offer, one account team and one invoice. Underneath, each service may have a different responsibility boundary, a different subcontractor, a different recovery target and a different exclusion.

The first boundary is the legal counterparty. The RIPE organisation record names Cloud Vault SRL, and the website presents Cloud Vault as the service brand. A customer still needs to know which legal entity signs the order, which entity holds the data-processing obligations, which entity invoices the service and which entity has authority to approve emergency action. If a reseller, integrator or parent relationship is involved in a customer deal, the customer should know whether Cloud Vault is the infrastructure operator, the service manager, the data processor, the carrier broker or a combination of those roles.

The second boundary is the product class. IaaS, backup, disaster recovery, managed services, connectivity and security do not fail in the same way. An IaaS agreement may define compute availability and storage durability. A backup agreement may define retention and restore scope. A connectivity agreement may depend on carrier service levels. A managed-services agreement may define response time but not guarantee that a third-party carrier or software vendor will repair within the same window. A security agreement may allow emergency isolation that protects the wider environment but interrupts one customer.

The customer should not accept one broad service-level statement as if it covered every layer equally.

The third boundary is evidence. If a customer asks for multi-site resilience, the contract should state what is replicated, how often it is tested and who pays for the test. If a customer asks for Romanian data placement, the contract should state which data categories remain in Romania and which operational data can move elsewhere. If a customer asks for address continuity, the contract should state whether provider-assigned addresses are portable, whether customer-owned prefixes are supported and what happens during termination.

If a customer asks for emergency restoration, the contract should state who can authorize it, which contact methods survive a portal outage and how competing restorations are prioritized.

The fourth boundary is termination. Many cloud risks become visible only when the relationship is ending. A customer needs to know how long backups remain available after cancellation, whether invoices or disputes can block export, how Cloud Vault deletes or returns data, whether logs can be preserved for audit, whether configuration records are included and whether professional services are required for migration. A provider that can answer those questions before a crisis reduces dependency risk even if the technical architecture is modest.

For Cloud Vault, none of these contract questions weakens the positive evidence. They simply translate public route and service evidence into customer protection. AS50819 can be visible and well operated, while a contract still leaves a customer exposed to renumbering, slow restore, unclear emergency contacts or limited export. The safer buyer treats the visible AS as the beginning of diligence, not as a substitute for enforceable service terms.

A real recovery test should include the awkward parts

Recovery testing is often described too neatly. A provider can show that a backup exists, a virtual machine can restart or a route can be announced. The harder test is whether the customer can recover while the usual path is impaired, while staff are busy, while change approvals are needed and while business users are asking for status. That is the test a Cloud Vault customer should run before treating the platform as a critical dependency.

The test should begin with inventory. Which virtual machines, databases, files, firewall rules, identity settings, DNS records, certificates, monitoring rules, backup jobs and support contacts are part of the workload? Which of those are stored inside Cloud Vault, which are controlled by the customer and which sit with third-party providers? If the inventory is incomplete, a restore can succeed technically and still leave the business unusable because a firewall rule, user directory, license server or partner allowlist was missing.

The second step is backup restore. The customer should restore a representative system, not just a small empty test machine. The restored system should include enough data to expose bandwidth, deduplication, storage and integrity issues. The test should record the recovery point, recovery time, data validation method and any manual actions required from Cloud Vault. If Cloud Vault's backup and disaster-recovery services are part of the purchase, the customer should also test whether recovery can happen when the ordinary management interface is unavailable or when the primary service route is degraded.

The third step is network cutover. If the workload uses Cloud Vault addresses, the customer should test how DNS, reverse DNS, certificates, VPNs, partner allowlists and monitoring change during recovery. If the workload uses private connectivity, the customer should test whether backup paths are physically and administratively separate. If the workload uses IPv6, the customer should test IPv6 recovery rather than assuming parity with IPv4. The AS50819 public route surface is a useful signal, but the customer needs a workload-level route test.

The fourth step is authority. The customer should simulate the absence of the usual administrator and the failure of the usual published contact points. Can Cloud Vault verify the customer and authorize recovery through another method? Can an emergency contact approve a restore? Can a billing or compliance hold be bypassed for data export while the dispute is resolved? Can support distinguish a customer configuration issue from a Cloud Vault platform issue quickly enough to avoid hours of circular diagnosis?

The fifth step is exit. A recovery test that only restores inside the same provider does not prove portability. The customer should export one representative workload, restore it outside Cloud Vault, update dependencies and measure the time to usable service. That test may show that Cloud Vault is a good long-term provider. It may also show that the customer has hidden lock-in around addresses, configuration, logs or managed-service knowledge. Either result is valuable because it turns assumption into evidence.

Who feels the failure

The end user of a Cloud Vault-hosted service may never know the name Cloud Vault SRL. They may see a Romanian business application, a customer portal, a backup restore, a remote desktop, a security tool, a file service, a managed firewall or a connectivity service. That distance matters because infrastructure failures often propagate invisibly. The direct customer knows the provider; the affected user only sees slow logins, missing files, failed payments, broken voice calls, unavailable reports or delayed support.

Small and mid-sized businesses are especially exposed to bundled dependency. They may choose a provider such as Cloud Vault precisely because they do not want to manage data-centre contracts, backup systems, network routes and security controls separately. That can be efficient, but it concentrates knowledge. If the provider also manages security, backup and recovery, the customer must make sure it retains enough documentation to operate during a provider-side incident or migration.

Regulated customers have another exposure. They may need to explain where data was stored, who accessed it, when it was restored and whether logs are complete. Public Cloud Vault evidence supports a Romanian infrastructure reading, but it does not provide a full data-location schedule. A regulated customer should require written placement and access terms before relying on country, city or brand assumptions. The same customer should ask whether support tickets, monitoring records and backup metadata have the same locality as production data.

Connectivity-dependent customers face a route problem. If their service depends on Cloud Vault address space or Cloud Vault-managed connectivity, a route outage or upstream dispute can affect them even when their application code is healthy. The observed AS neighbours suggest route adjacency, but the customer needs to know which path carries its service and what alternate path exists. A customer with partner allowlists should be particularly careful, because a fast move to new addresses can still fail if partners need days to approve changes.

Backup customers face a timing problem. In an ordinary restore, Cloud Vault may have enough staff, bandwidth and storage to recover quickly. In a broader incident, many customers may request restores at the same time. The customer should ask how restore priority is handled, whether dedicated capacity is reserved, whether large restores are throttled and whether emergency professional services are available. A backup that is technically valid but operationally delayed may not meet the business need.

Security customers face a control problem. If Cloud Vault-managed security detects a threat, the provider may need to isolate systems, block traffic or preserve evidence. Those actions can protect the customer and still interrupt operations. The customer should agree in advance which actions Cloud Vault can take without approval, which require approval and how disputes are handled after the fact. Security response is strongest when the customer understands the availability consequences before the incident.

The public conclusion is therefore not alarmist. Cloud Vault appears visible and operational enough to warrant serious consideration. The risk is that customers treat a visible Romanian cloud provider as if every recovery, locality and migration detail were already solved. The better approach is to map who feels the failure, who can fix it, which evidence proves the fix and which parts of the business remain under the customer's own control.

Evidence grade

The evidence grade is Medium. The positive case is clear: Cloud Vault SRL is named in RIPE organisation records, AS50819 is active, RIPEstat shows current IPv4 and IPv6 route visibility, the public route set is broader than a single token prefix, and the company's own site sells relevant cloud, data-centre, backup, disaster-recovery, connectivity, security and managed-service products.

The limiting case is equally clear. Public sources do not prove customer-specific multi-site failover, spare hardware depth, support escalation authority, restore performance, address portability, upstream physical diversity, customer export terms or exact data-location boundaries. Observed neighbours and visible prefixes provide a route map, not a recovery contract. Service pages describe offerings, not tested customer outcomes.

The cleanest conclusion is therefore practical: Cloud Vault SRL is a visible Romanian hosted-capacity provider whose network evidence deserves attention, but a customer should treat resilience as a verification task. Before relying on Cloud Vault for critical state, the buyer should obtain the production and recovery map, upstream and route-security evidence, restore-test results, emergency support contacts, suspension rules, data-location schedule and exit procedure. That is the difference between buying a local cloud service and understanding the physical dependency behind it.