Summary
- CloudWall Cloud Wall Ltd. has a live public network signal: RIPEstat shows AS58294 as announced for holder CloudWall Cloud Wall Ltd. at the 12 July 2026 query time, and RIPEstat announced-prefix data lists 91.206.228.0/24 and 195.230.23.0/24.
- The footprint is small. RIPE RIS prefix counts show two originating IPv4 prefixes, no originating IPv6 prefixes and no visible transit role, while PeeringDB returns no AS58294 network profile.
- The visible route dependency is concentrated. RIPEstat neighbour data shows one unique neighbour, AS9002, and BGP.tools describes AS58294 as a small network with one upstream carrier, RETN Limited.
- CloudWall should therefore be treated as a thin-public-footprint hosting dependency, not as a proven multi-site cloud platform. Customers should verify facility placement, upstream diversity, spare hardware, support escalation, backup restore paths, billing controls and data portability before placing critical workloads.
A visible network is not the same as a proven cloud platform
CloudWall Cloud Wall Ltd. sits in the awkward but common middle ground of internet infrastructure research: there is enough public evidence to say the entity is not merely a name, but not enough evidence to say its service resilience is mature. The public route record is real. RIPEstat's AS overview for AS58294 shows the holder as CloudWall Cloud Wall Ltd. and marks the autonomous system as announced at the 12 July 2026 query time. RIPE RDAP for AS58294 lists the AS name as CloudWall, status active, registration on 30 January 2020, and a last-changed date of 6 May 2025. RIPE RDAP for ORG-CWL5-RIPE identifies Cloud Wall Ltd. as a Bulgarian organisation with an address on Shipchenski Prohod Boulevard in Sofia and a public office contact.
That is the strongest part of the case. The weaker part is the operating surface. The company website listed in third-party routing views is cloudwall.bg, but a direct DNS observation from the working resolver returned 127.0.0.1 for the apex name, while the site did not serve a normal public page from this environment. The domain does have active-looking DNS administration: it uses Cloudflare nameservers and Google Workspace-style mail exchanger records. Those DNS facts show that the domain is managed. They do not show a live product catalogue, current hosting packages, a customer portal, a support desk, data-centre locations or service-level terms.
For buyers, that distinction matters more than the label "cloud". A cloud, hosting, VPS or managed-service provider is not abstract just because customers buy it online. The customer is still depending on servers, storage, switches, power, cooling, transit providers, route objects, billing systems, support shifts and replacement hardware. If the public record proves only a small AS and a pair of visible /24s, the buyer should treat the service as a dependency that needs a direct operational questionnaire, not as a commodity substitute for a tested multi-provider design.
CloudWall's name also invites over-reading. The public evidence does not prove a defensive cloud-security platform, a managed firewall service or a large distributed edge. The visible record is closer to address holding and hosting-network operation. BGP.tools labels AS58294 with hosting-related tags, lists the network type as content, and shows two IPv4 prefixes originated. That is useful market intelligence, but it remains a third-party observation. It cannot answer who owns the racks, who operates the facility, who replaces failed drives, where backups sit, or whether a customer can fail over to a second site.
The right conclusion is neither dismissal nor blind trust. CloudWall has enough public network presence to analyze as an infrastructure provider. It also has a thin public operating footprint. The rest of this article treats that thinness as the core fact to be managed.
The legal and registry picture points to Sofia, but not to a rack room
The clearest entity anchor is the RIPE organisation record. ORG-CWL5-RIPE names Cloud Wall Ltd., gives the country context as Bulgaria, and lists a Sofia address. It is also tied in the same public record to AS58294 and several IPv4 resources. That gives customers a jurisdictional and administrative starting point: the entity is in the RIPE region, appears as a Bulgarian local internet registry organisation, and has public routing and abuse contacts.
The address is not the same as a data-centre location. Many hosting companies use an office address, registered address or administrative address that is separate from the facility where servers are actually installed. Nothing in the public RIPE record proves that customer equipment or CloudWall-owned servers sit at the Sofia address. Nothing in the route record proves whether the servers are in Bulgaria, in another European facility, or in leased space operated by a third party.
Customers who care about data locality should therefore ask a direct placement question: where does each service run, which legal entity controls the rack contract, and which facility operator controls the building systems?
There are two separate CloudWall organisation handles in the RIPE data. ORG-CWL5-RIPE is the Sofia-address organisation tied to the LIR-style allocation records. ORG-CL581-RIPE is another CloudWall Ltd. organisation handle with a broader "Europe" address label that appears on assigned address records for 91.206.228.0/24 and 195.230.23.0/24. The two records do not contradict the basic CloudWall identity, but they do show why customers should avoid assuming that every address registration field explains the live service operator. Registry records are administrative facts; they are not a facility tour.
The abuse-contact record reinforces that point. RIPEstat's abuse-contact finder returns [email protected] as the authoritative contact for AS58294. The address records also contain remarks saying abuse or security complaints should be sent there and that messages will be processed in order and forwarded in a few business days. That is useful for network governance, but it is not a customer support promise. A buyer with production workloads needs a separate support path with escalation names, hours, response commitments and authority to change routing, reboot hardware or release data.
The entity picture is therefore clear at the top and cloudy underneath. CloudWall Cloud Wall Ltd. is visible in RIPE records. The records point to Bulgaria and to AS58294. They do not prove where racks sit, how many servers are installed, whether CloudWall owns or leases hardware, or what happens when a customer needs urgent repair.
AS58294 is live, small and IPv4-only in the checked public view
The routing surface is easier to describe than the service surface. RIPEstat announced-prefix data for AS58294 lists two prefixes, 91.206.228.0/24 and 195.230.23.0/24, visible over the default window ending 12 July 2026. A longer RIPEstat query from 1 January to 12 July 2026 shows the same two prefixes across that period. RIPE RIS prefix counts show two originating IPv4 prefixes, no transiting IPv4 prefixes, no originating IPv6 prefixes and no transiting IPv6 prefixes.
That is a small network. It may still host many customer services, because two /24s contain enough IPv4 addresses for a compact hosting operation, especially if virtual hosting, shared hosting, NAT, control-panel hosting and CDN fronting are involved. But it is not a broad route surface. There is no public IPv6 origin in the checked RIS count. There is no visible transit role. There are no dozens of originated prefixes suggesting a large, heavily distributed estate. The public record supports a focused hosting or content network, not a large cloud region.
The prefix-level evidence is consistent. RIPEstat prefix overview for 91.206.228.0/24 says the prefix is announced by AS58294 and associates the holder with CloudWall Cloud Wall Ltd. RIPEstat prefix overview for 195.230.23.0/24 says the same for the second visible /24. RIPEstat routing consistency shows both prefixes present in BGP and in RIPE whois routing data. The route objects are therefore not merely stale text sitting beside an unrelated BGP announcement; the checked public sources align.
The BGP-state samples add reachability detail. RIPEstat BGP state for 91.206.228.0/24 returned 335 route observations at the checked timestamp, with paths ending in AS9002 and then AS58294. The equivalent BGP-state sample for 195.230.23.0/24 returned the same route-observation count and the same visible last-hop pattern. A customer should not read 335 route observations as 335 independent providers. It means many collectors see routes, while the path structure still points to a narrow immediate upstream view.
This is a useful but modest routing profile. It says CloudWall can originate two IPv4 /24s into the global table. It does not say the customer receives redundant transit. It does not say the customer can survive a top-of-rack switch failure, a facility power event, a remote-hands delay, a server-stock shortage or an upstream contract problem. The route table can prove visibility; it cannot prove resilience.
The upstream picture is visibly concentrated around RETN
The most important resilience question in the public route view is upstream concentration. RIPEstat's AS-neighbours endpoint for AS58294 shows one unique neighbour for the 11 July 2026 query window: AS9002. RIPEstat's AS overview for AS9002 identifies that AS as RETN-AS RETN Limited, and RIPE RDAP for AS9002 gives RETN Limited as the registrant organisation. BGP.tools also describes AS58294 as a small network with one upstream carrier and lists AS9002 as RETN Limited.
The RIPE whois policy text is slightly broader than the visible neighbour data. RIPEstat whois for AS58294 includes import and export policy lines for AS9002 and AS3257. RIPEstat routing consistency, however, marks AS9002 as present in BGP and whois, while AS3257 appears in whois but not in the checked BGP view. That distinction should be preserved. It is fair to say the registered policy includes a GTT path. It is not fair to say the checked public BGP evidence proves active diversity through both RETN and GTT.
For a small hosting network, a single visible immediate upstream is not automatically disqualifying. Many small providers buy reliable transit from one strong carrier and operate acceptably for ordinary workloads. But a customer should price the concentration honestly. If AS9002 is impaired, if a commercial dispute affects connectivity, if maintenance is scheduled on the handoff, or if route filtering changes, the public evidence does not show another live immediate upstream carrying AS58294 at the same time. If CloudWall has private backup arrangements or rapid reconfiguration plans, those are not visible in the public route data.
The same question applies inside the rack. Upstream diversity at the BGP layer is only one part of service continuity. A customer also needs to know whether the server uplinks are dual-homed to separate switches, whether both switches leave the building through physically diverse paths, whether the customer can buy a second handoff, and whether the provider can move the service to another rack during maintenance. A route table can show AS-path diversity. It cannot show fibre entries, cross-connect diversity, switch redundancy or repair staffing.
CloudWall's route evidence therefore supports a disciplined buyer position: treat the network as live, treat the route surface as small, and verify any claim of transit diversity in writing. A customer should ask for a current upstream list, handoff locations, maintenance-notice policy, escalation process, and the exact circumstances under which traffic can be moved away from AS9002.
Address records show both CloudWall control and operator-boundary questions
The address-resource picture is more complicated than the two-prefix route summary. RIPE RDAP for 91.206.228.0/24 shows the network name BG-CLOUDWALL-20220829, type allocated PA, country BG, and Cloud Wall Ltd. as an organisation in the record. The same record includes a remark saying the IP range is not used by Cloud Wall Ltd. and gives the abuse contact for complaints. RIPEstat whois for 91.206.228.0/24 shows a route object for 91.206.228.0/24 with origin AS58294 and CloudWall as maintainer.
RIPE RDAP for 195.230.23.0/24 shows a CloudWall network record under 195.230.23.0 - 195.230.23.255, with country EU and organisation handle ORG-CL581-RIPE. It also includes the same kind of "not used by Cloud Wall Ltd." remark. RIPEstat whois for 195.230.23.0/24 shows an AS58294 route object for that /24. The route object and the BGP origin align. The operational meaning of the "not used by" remark is less clear from public data and should be treated as a boundary warning, not ignored.
The CloudWall organisation record also references other IPv4 resources. RIPE RDAP for 178.255.220.0/24 ties that allocation to Cloud Wall Ltd. in a Bulgarian record. Yet RIPEstat prefix overview for 178.255.220.0/24 shows the prefix announced by AS44901, holder belcloud Belcloud LTD, at the 12 July 2026 query time. RIPEstat's AS overview for AS44901 confirms the holder label as belcloud Belcloud LTD. That does not prove anything improper. It does show that address registration and live operation can diverge.
Another example is RIPE RDAP for 213.155.30.0/23, which places BG-CLOUDWALL-20080402 in a Cloud Wall Ltd. record, while RIPEstat prefix overview for 213.155.30.0/23 says the aggregate was not announced at the checked time and points to a more-specific 213.155.30.0/24. RIPEstat's overview for that /24 shows AS215508, holder HOST-DOT-NET Dot Net Ltd, as the origin. Again, the public signal is not "CloudWall has no resources." It is "CloudWall-related records need operator-boundary review."
This is not a minor detail. If a customer buys hosted capacity, IP reputation, routing rights, abuse handling and exit planning can depend on the difference between the address registrant, the BGP origin, the hosting operator, the upstream carrier and the entity that signs the customer contract. A buyer should ask whether the assigned IPs are CloudWall-owned, leased, delegated, reassigned or third-party operated; whether reverse DNS can be changed; whether clean replacement IPs are available after a reputation event; and whether the customer can retain addresses during migration.
The public records give enough reason to ask those questions before something breaks.
DNS and hosting signals point to real hosted use, but not to guaranteed quality
Public DNS observations around the CloudWall domain and prefixes suggest an operating hosting context. The cloudwall.bg domain uses Cloudflare nameservers in the observed DNS output and Google mail exchanger records. It also has a Google site-verification TXT record. The apex A record observed locally points to 127.0.0.1, which explains why the domain is not a normal public brochure from this environment. That is not evidence that the network is down; it is evidence that the public web domain is not a reliable product source at the time checked.
The prefix DNS view is more service-like. BGP.tools for AS58294 lists hosting-oriented tags, including VPN Host and Server Hosting, and shows the network as originating two IPv4 prefixes. Its prefix pages show many observed names inside the two /24s. The page for 91.206.228.0/24 includes reverse or forward-DNS samples with cPanel-style cprapid.com names and other hosted domains. The page for 195.230.23.0/24 shows a similar pattern, including cprapid.com, plesk.page and da.direct style names in the observed DNS list.
Those signals are useful because they are consistent with hosted web capacity. cPanel, Plesk and DirectAdmin-style hostnames usually appear around shared hosting, reseller hosting, control-panel servers or managed web-hosting environments. They suggest that the two visible CloudWall-originated /24s are not empty routing curiosities. They appear to carry names associated with websites, panels or hosted customer environments.
But DNS names do not prove service quality. A control-panel hostname does not tell a customer whether the server is patched, how backups are handled, whether mail queues are monitored, whether snapshots are isolated, whether abuse complaints are processed quickly, or whether the provider has spare SSDs and RAM on hand. It also does not prove that CloudWall is the direct retail seller for every name seen on the prefixes. Hosting supply chains often include resellers, white-label panels, delegated infrastructure and customers who manage their own content.
The buyer inference should therefore be careful. The hosted-use signal is stronger than a blank website would suggest. The continuity evidence is still weak. Customers should verify plan details, panel access, backup schedules, resource limits, support hours, acceptable-use enforcement and migration methods before assuming that the visible hosting names translate into dependable production capacity.
Physical dependency is the missing map
Every CloudWall customer ultimately needs the same map: where is the service, who controls the site, and what fails together? The public sources do not answer those questions. They show a Sofia-linked RIPE organisation, two live /24s, a visible upstream through RETN, DNS signals and hosted-use clues. They do not name a data centre, rack count, power design, cooling design, storage design, second site, backup location or hardware replacement process.
That absence is the central risk for a cloud-service dependency. A VPS can be sold as instant capacity, but it still runs on a physical host. If the host fails, recovery depends on spare capacity, storage design, snapshots, orchestration and staff response. A dedicated server can be sold with root access and predictable resources, but it still depends on available hardware, replacement parts and remote hands. Shared hosting can be inexpensive and convenient, but it depends on control-panel health, database servers, DNS, mail reputation and backup integrity.
Managed service can reduce customer workload, but it also makes the customer dependent on the provider's queue, priorities and account controls.
Facility locality matters for Bulgarian and regional customers. A buyer may choose CloudWall because the entity is Bulgarian, because the IP records carry BG context, because latency to local users is acceptable, or because the buyer wants a non-hyperscale European provider. But the public record does not prove that both active prefixes are hosted in Bulgaria. RIPEstat MaxMind geolocation for 91.206.228.0/24 places the representative prefix in Bulgaria at the checked result time, while the equivalent geolocation endpoint for 195.230.23.0/24 places that prefix in Helsinki, Finland. IP geolocation is imperfect, but the split is enough to warn against assuming one location for every service.
Customers should ask for placement by product and by workload. Is the web server in Bulgaria? Is the mail server in the same country? Are backups local, regional or outside the country? Does the customer portal run on CloudWall's own prefixes or on a third-party platform? Are nameservers hosted with Cloudflare only for the corporate domain, or are customer zones also delegated to external DNS? Does support data leave Bulgaria? Which law and jurisdiction govern data processing? If a customer needs Bulgarian data locality, the answer must be service-specific.
The same map should include power and repair. Which facility provides power? Are racks dual-fed? Are power supplies dual-corded? Is the customer's service on redundant storage? Does a failed host require manual replacement? Are spare disks, power supplies and RAM stocked on site? Can the provider migrate a VM before a planned maintenance window? Does the customer receive notice before upstream maintenance? The public route table cannot answer any of those questions, but those are the questions that decide whether hosted capacity survives an ordinary failure.
Installed address space is not the same as usable customer capacity
CloudWall's two visible /24s give it 512 IPv4 addresses before network, broadcast, infrastructure, routing, filtering, monitoring, panel, mail and reserved-use allocations are subtracted. In IPv4-constrained hosting, that can be commercially meaningful. It can support shared hosting, VPS nodes, mail servers, reseller accounts, VPN endpoints, dedicated servers or small managed-service clusters. It is also finite, and it says nothing by itself about CPU, memory, disk, power or staff.
The address records show a useful age spread. 195.230.23.0/24 appears in RIPE records with a creation date in 2014 and an AS58294 route object created in 2020. 91.206.228.0/24 appears as a later allocation and route object from 2022. AS58294 itself was registered in 2020. The network is not a brand-new one-day artifact. It has enough history to be worth evaluating. But history of route objects is still not a capacity plan.
What a customer needs is installed-versus-usable capacity. How many physical hosts back the VPS or hosting offer? How much spare compute exists after normal load? Are accounts packed densely onto a few nodes? Is storage local to each node or shared across a storage network? How many customers can be restored at once after a host failure? How much outbound bandwidth is included before throttling or billing changes? What happens if many customers need data export at the same time?
The answer matters especially for migration and recovery. A provider can have enough capacity for normal operation but not enough capacity for emergency restores. A shared-hosting platform can appear healthy until a backup restore, malware cleanup or mail queue event creates a support backlog. A VPS platform can survive a disk failure if snapshots are current and spare nodes exist; it can become a long repair window if both are missing. A dedicated-server platform can sell low-cost servers until a component fails and no replacement is stocked.
Public evidence gives CloudWall credit for operating a visible, small network. It does not justify assuming spare inventory. Customers should ask for resource limits, oversubscription policy, backup scope, restore tests, hardware replacement times and any exclusions. Without those answers, the customer is buying capacity without knowing how much of it remains available under stress.
Route security is incomplete in the public validation view
Routing security is another place where CloudWall's public evidence is visible but not complete. RIPEstat RPKI validation for AS58294 and 91.206.228.0/24 returns status unknown and no validating ROAs. The same endpoint for AS58294 and 195.230.23.0/24 also returns status unknown and no validating ROAs. BGP.tools marks the prefix rows as matching a trusted IRR source, and RIPEstat routing consistency shows both prefixes present in BGP and whois, so there is IRR support. The RPKI signal is the weaker part.
An RPKI unknown result is not the same as invalid routing. It means the checked validator did not find a Route Origin Authorization covering the prefix-origin pair. Many networks still operate in that state. But for customers who depend on stable reachability, especially financial, public-sector, healthcare, SaaS, e-commerce or identity services, unknown origin validation is a due-diligence item. Some upstreams and networks apply stricter filtering over time, and route-security posture can affect incident response when hijacks, leaks or misconfigurations occur.
The buyer should ask whether CloudWall can publish ROAs for customer-facing prefixes, whether route objects are maintained for all announced routes, who is authorised to change route policy, and how quickly a routing incident can be escalated to upstream carriers. Customers with their own provider-independent address space should ask whether CloudWall can originate it with proper authorisation and whether the provider supports RPKI and IRR updates before cutover.
Route security also intersects with exit planning. If a customer migrates away from CloudWall, DNS changes may not be enough. Firewalls, mail reputation, payment processor allowlists, API partner allowlists, VPN endpoints and customer integrations may all depend on the old IPs. If the customer cannot take the IP addresses with it, the customer needs a renumbering plan. If the customer can bring its own addresses, the customer needs route-policy and RPKI coordination. This is not glamorous work, but it is the difference between a move that takes hours and a move that drags through a repair window.
CloudWall's current public validation view should therefore be read as partial hygiene: route objects exist and BGP origin aligns for the two active /24s, but RPKI validation is not proving those origins in the checked endpoint. A critical customer should close that gap before treating the network as a hardened dependency.
Support and abuse handling are not the same function
The public contact evidence is mostly network-administrative. RIPE records expose organisation contacts, technical contacts and abuse contacts. The address-record remarks direct abuse, hacking or security-related issues to the CloudWall complaint address and say emails are processed in order and forwarded in a few business days. That is a useful public abuse-handling channel. It is not the same as a customer support desk that can reboot a server, restore a backup or authorize an emergency migration.
This matters because the main failure paths for a small hosting provider are often ordinary support bottlenecks. A failed disk, blocked mail queue, compromised shared-hosting account, billing hold, broken DNS zone, expired certificate, lost panel password or upstream route filter can all become customer outages. The difference between a small incident and a business interruption is the escalation path: who answers, who can act, who has authority, who can reach the facility, and who can coordinate with upstreams.
Customers should ask CloudWall for separate answers by service type. For VPS, who can restart or migrate a VM when the host is unhealthy? For dedicated servers, what component replacement times apply and what parts are stocked? For shared hosting, what restore windows apply and how many restore points exist? For DNS, who can change zones if a customer loses panel access? For mail, how are queues, blocklists and mailbox exports handled? For billing, who can prevent an administrative suspension during a dispute or card failure? For abuse, how quickly can a customer receive evidence and avoid unnecessary service interruption?
The contact design should also account for customer-side failures. If the customer's only authorised contact leaves, if a mailbox is locked, if the billing card fails, or if a security incident compromises the account, can the customer still reach someone? Can multiple authorised contacts be set? Is there an emergency verification procedure? Are support and billing independent enough that a payment issue does not block urgent incident repair? The public record does not answer these questions. A serious customer should require the answers before production placement.
CloudWall's public evidence is enough to identify a responsible contact surface. It is not enough to prove operational support maturity. The customer should not learn that difference during an outage.
Billing, domain control and account access can become outage causes
Small hosting environments often fail through administrative pathways before they fail through exotic engineering events. A customer can lose service because an invoice email went to the wrong person, a domain renewal notice was missed, a DNS panel password was lost, a fraud filter held a payment, or an abuse complaint froze an account pending review. These are not secondary concerns. They are part of the infrastructure because they control whether the customer can keep using the servers, domains and mailboxes it paid for.
CloudWall's corporate DNS posture shows that the company itself uses external control-plane services: Cloudflare nameservers for the corporate domain and Google mail exchanger records. That is ordinary and sensible for many businesses. It also illustrates the layered nature of hosting operations. A customer's CloudWall-hosted website may depend on CloudWall routing, a third-party DNS provider, a mail provider, a control panel, a registrar, and customer credentials. If one layer fails or if account control is unclear, the customer may have to coordinate several parties under time pressure.
For domain-linked workloads, customers should ask whether domains are registered through CloudWall, through a reseller, or directly by the customer. If CloudWall controls the registrar account, how quickly can the customer obtain transfer codes? Are domains locked? Who receives renewal notices? What happens during billing disputes? If DNS is hosted elsewhere, who holds the keys? If DNS is hosted with CloudWall, can the customer export a zone file and move it rapidly?
For mail, customers should ask about mailbox export formats, anti-spam controls, MX cutover timing, queue retention and blocklist response. Mail is often the hardest service to move cleanly because users, DNS records, passwords, devices, archives, compliance retention and sender reputation all interact. A hosting provider can offer mailboxes as a convenience, but a customer that treats those mailboxes as business-critical needs a documented exit and restore path.
For account access, customers should maintain multiple authorised contacts, shared credential governance and an emergency procedure. A CloudWall service can be technically healthy while the customer is operationally stuck because it cannot access the panel, prove authority or pay a bill. The provider should be able to explain how it prevents account takeover without trapping legitimate customers during crisis. The public evidence does not settle that balance.
Data sovereignty is plausible only when placement is named
CloudWall's Bulgarian entity record makes data locality a natural topic, but it does not settle it. The active AS holder is CloudWall Cloud Wall Ltd. in RIPEstat. ORG-CWL5-RIPE points to Sofia. One representative prefix, 91.206.228.0/24, geolocates to Bulgaria in RIPEstat's MaxMind view. Those are useful signals for customers looking for Bulgarian or European hosting. They do not prove that every CloudWall customer service, backup copy, support record or log file stays in Bulgaria.
The second active prefix complicates any simple locality claim. RIPEstat's geolocation endpoint places 195.230.23.0/24 in Helsinki at the checked result time. IP geolocation can be wrong, especially for hosting networks and reassigned address space, but it is still a warning that prefix identity, legal identity and physical service placement are not interchangeable. A customer cannot rely on a Bulgarian entity name alone to satisfy a data-locality requirement.
Customers with sovereignty or compliance needs should ask for a service-placement statement that covers the full chain: primary compute, storage, backups, snapshots, logs, mailboxes, DNS, support tickets, monitoring, billing records and third-party processors. The statement should distinguish customer content from account data. It should also identify which services can be kept in Bulgaria, which are European but not Bulgarian, and which depend on global SaaS or carrier services.
The same statement should explain failure and migration. If the Bulgarian site fails, is there a second site? If there is a second site, where is it? Is failover automatic, manual or customer-managed? If a backup is outside the country, is that acceptable to the customer? If a customer must leave quickly, can data be exported without moving through a third-country platform? Locality without recovery planning can become a trap: the service satisfies a location preference until the customer needs the data elsewhere in a hurry.
The public evidence supports a cautious phrasing. CloudWall is a Bulgarian-linked network and address-resource holder with visible hosting signals. It does not publicly prove a Bulgarian-only hosting estate. Data sovereignty is therefore a contract and architecture question, not a brand assumption.
The most likely failure paths are practical and testable
The assignment's core failure path is not an exotic collapse. It is the ordinary chain of rack, upstream, hardware-stock, support, billing, migration or provider-contract failure. CloudWall's public evidence makes that chain especially relevant because the route surface is small and the service surface is not well documented. Customers can still use a small provider safely, but only if they know which pieces fail together.
The first test is rack and host failure. If a VPS host fails, can CloudWall restart the virtual machine on another host? How recent are snapshots? Are snapshots stored on the same local disk, the same storage shelf, the same rack, or a separate system? If a dedicated server fails, how quickly can a replacement be provisioned? Are spare drives and power supplies stocked? If a shared-hosting node fails, how many accounts compete for restore time?
The second test is upstream failure. The visible neighbour picture points to AS9002. What happens if that handoff is impaired? Is AS3257 active as a backup despite not appearing in the checked BGP view? Is there a second physical path? Does CloudWall have a written maintenance-notice process from its upstream? Can it accept customer-provided monitoring evidence and escalate quickly? Does it have a looking-glass, status page or incident update channel?
The third test is support capacity. A provider can have a valid route and still leave customers waiting if staff cannot respond. What support hours apply? Which issues are emergency issues? What is the escalation path? Are remote hands available at the facility, or does CloudWall depend on a third-party data-centre team? Can customers reach someone by phone for severe incidents? Are after-hours actions included or billed separately?
The fourth test is billing and account control. What notices precede suspension? Can an authorised technical contact override a billing problem during an active outage? Can multiple contacts be maintained? How are ownership disputes handled? Can a customer retrieve data after cancellation? How long are backups retained after a service is terminated?
The fifth test is migration. Can a customer export a VM image, database dump, mailbox archive, DNS zone, SSL material and account list? How much bandwidth is available for emergency export? Are temporary migration windows supported? Can CloudWall provide a clean list of IPs, hostnames, reverse DNS entries and dependencies? These questions turn a vague hosting relationship into a recoverable dependency.
Unofficial market signals should inform questions, not conclusions
Unofficial market signals can be useful when the provider's own public brochure is thin. BGP.tools' hosting tags, DNS samples, prefix rankings and cPanel/Plesk-style names help interpret the two visible /24s. They suggest that CloudWall-originated space is associated with hosted web environments. They also show a scattering of domain names that look like normal shared-hosting tenancy, reseller hosting or control-panel managed sites.
But unofficial signals cannot prove customer counts, revenue, uptime, legitimacy of every hosted site, direct CloudWall retail relationships or support quality. DNS can be stale. Domains can move. Hostnames can be generated by panels without reflecting active paying customers. A third-party ranking can be useful directionally while still being unsuitable as a capacity or reliability guarantee. The correct use is to generate due-diligence questions.
One question is abuse and reputation. The public address-record remarks route complaints to a CloudWall contact. Hosted web and VPN-tagged networks can attract mixed customer behaviour, and reputation events can affect neighbouring customers if IPs are shared or if mail reputation is pooled. Customers should ask how CloudWall isolates customers, handles abuse reports, replaces tainted IPs and prevents one customer's issue from affecting others.
Another question is reseller layering. If cPanel, Plesk or DirectAdmin-style names appear, some end users may be several layers away from the network operator. A buyer should know whether CloudWall is the direct seller, a wholesale host, a reseller platform, or an address/network supplier for another hosting brand. That matters during outages because a customer who buys through an intermediary may not have direct escalation to the network operator.
A third question is service type. Hosting signals do not automatically mean cloud compute, managed Kubernetes, enterprise backup or high-availability infrastructure. They may mean shared web hosting, reseller accounts, small VPS nodes or dedicated servers. Buyers should match the claim to the evidence. If they need elastic multi-zone cloud capacity, the public record does not support that assumption. If they need compact European web-hosting capacity and can verify support terms, CloudWall may still be relevant.
Unofficial signals should therefore sharpen the inquiry, not settle it. They are enough to say CloudWall's active address space looks service-bearing. They are not enough to say the service is resilient.
What a buyer should ask before placing workloads
A CloudWall buyer should begin with placement. Which facility hosts the service? Is it owned, leased or colocated? Who operates the building? Are there multiple racks? Are there multiple sites? Which products run in which location? Do the two active prefixes map to the same physical site or different sites? Where are backups and management systems?
The second question is network diversity. Which upstreams are active today? Why does the checked public view show AS9002 as the visible neighbour? Is AS3257 a live backup, a dormant policy entry or a historical record? What happens during RETN maintenance or outage? Are there private interconnects, IX connections or other paths not visible in the public view? Can the customer buy a route-diverse service?
The third question is resource and hardware resilience. For VPS or shared hosting, how many host nodes exist and how are customers distributed? What storage design is used? Are snapshots automatic? How often are restores tested? For dedicated servers, what replacement parts are stocked? For customer-owned equipment, what remote-hands service is available and what is excluded? For all products, what maintenance notice is required?
The fourth question is data and exit. Can the customer export all data in standard formats? Are VM images available? Can databases, DNS zones and mailboxes be exported without support intervention? How much bandwidth is available for emergency export? Can the customer leave during a dispute? What data is deleted after cancellation, and when? Is there an assisted migration service out of CloudWall as well as into CloudWall?
The fifth question is account governance. How many authorised contacts can be listed? Can technical and billing contacts be separate? What happens if the main email account is inaccessible? What verification is required for emergency changes? Does support continue during a billing dispute? Who has authority to approve route changes, reverse DNS changes, domain transfers and backup restores?
The sixth question is route security and reputation. Can CloudWall create RPKI ROAs for all customer-visible prefixes? Are route objects current? How are abuse complaints handled? Are IPs shared among customers? Can mail reputation be isolated? Are logs available to customers after an incident? Is there a documented process for DDoS, route leak or takedown events?
These questions are not signs of distrust. They are the normal due diligence required when a small hosting provider becomes part of a customer's production chain. CloudWall's public evidence makes the questions concrete. It does not answer them on the customer's behalf.
Bottom line
CloudWall Cloud Wall Ltd. has a real public network footprint. AS58294 is announced. RIPE records tie the AS and multiple address resources to CloudWall-linked organisation records. RIPEstat shows two active IPv4 /24s originated by AS58294. Route objects align with those origins. BGP-state samples show the prefixes visible from many collectors. DNS and third-party hosting observations suggest the active space is service-bearing rather than empty.
The network evidence is nevertheless thin. There is no visible IPv6 origin in the checked RIS count. There is no public PeeringDB network profile. The checked neighbour view shows one unique neighbour, AS9002, while AS3257 appears in registered policy but not in that BGP snapshot. RPKI validation returns unknown for both active /24 origins. The company website is not a usable public product source from this environment. Public records do not name facilities, racks, power design, backup design, hardware stock, support hours, failover process or customer export rights.
That combination calls for a downgrade from any broad "cloud platform" assumption. CloudWall should be read as a small Bulgarian-linked hosting and network dependency with two visible IPv4 /24s and signs of hosted web use. It should not be treated as a proven multi-site cloud service unless the customer receives current, contract-backed evidence for placement, redundancy, support and portability.
The practical advice is simple. Use the public route evidence to start the conversation, not to end it. Ask where the workload runs, what upstreams are active, what fails with AS9002, how backups restore, who replaces hardware, how support escalates, how billing can interrupt service, how abuse complaints are handled, whether RPKI can be cleaned up, and how data leaves. If CloudWall can answer those questions with current operational evidence, it may be a suitable small-provider dependency for the right workload.
Without those answers, the safest reading is narrow: real network, limited public proof, and customer resilience still dependent on racks, transit and repair windows.