ZEROSPACE Christian Wittenberg trading as Zerospace Cloud sells hosted capacity that still depends on racks, transit and repair windows

Summary

• RIPE RDAP identifies AS201801 as ZEROSPACE and ties it to Christian Wittenberg trading as Zerospace Cloud in Veldhoven, the Netherlands; RIPEstat's AS overview reported the AS as announced on 15 July 2026.
• The routed estate is small but visible: routing status showed one IPv4 prefix, 256 IPv4 addresses, eight IPv6 /48s and two observed neighbours, while announced prefixes listed 185.140.53.0/24 plus eight visible IPv6 /48s.
• Route-origin hygiene is a strength: RIPEstat returned valid RPKI for 185.140.53.0/24 and for 2a07:1a84::/48, with the IPv6 validation relying on a ROA over 2a07:1a84::/44 and maximum length /48.
• The operating proof is weak: PeeringDB lists Zerospace Cloud but shows zero public IX count and zero facility count; the geofeed maps address slices across ten metro labels, yet it does not prove local racks, power, hardware, support or customer migration capacity in those metros.

The company has a real network identity, but the identity is new

The first fact worth separating from the noise is that Zerospace Cloud is not merely a marketing phrase. RIPE RDAP at https://rdap.db.ripe.net/autnum/201801 registers AS201801 as ZEROSPACE, status active, with a registration event on 30 January 2026 and a last-changed event on 13 March 2026. The organisation entity in the same RDAP response is Christian Wittenberg trading as Zerospace Cloud, with Veldhoven, the Netherlands, as the public address label. The RDAP response also names Zerospace Cloud Network Operations as the administrative and technical contact and Zerospace Cloud Abuse Department as the abuse contact. For a small cloud or hosting provider, that is a useful baseline: there is a named organisation, a named network, and named operational contact roles.

The address records match the AS identity. RIPE RDAP at https://rdap.db.ripe.net/ip/185.140.53.0/24 identifies 185.140.53.0 through 185.140.53.255 as ZEROSPACE-CLOUD, assigned PA, country NL, status active, with remarks pointing to a geofeed at http://download.zerospace.cloud/ipam/geofeed.csv. RIPE RDAP at https://rdap.db.ripe.net/ip/2a07:1a84::/44 identifies 2a07:1a84::/44 as ZEROCLOUD, aggregated by LIR, country NL, status active, with the same organisation and the same geofeed reference. RIPEstat's prefix overview for https://stat.ripe.net/data/prefix-overview/data.json?resource=185.140.53.0/24 identifies AS201801 as the origin holder for the IPv4 /24.

Those records do not prove a mature hosting estate. They prove a current route holder with live registered resources. The age matters. The autonomous system and the IPv6 aggregate were registered in late January 2026, and the IPv4 /24 was registered in February 2026. That is recent enough that customers should treat public operating evidence as still forming. New infrastructure providers can be capable; they can also be in the stage where routing, branding, support processes and physical supplier contracts are still being hardened. The right question is not whether AS201801 exists. It does.

The right question is which customer services can safely be placed on top of it.

The public route signal is live. RIPEstat's AS overview at https://stat.ripe.net/data/as-overview/data.json?resource=AS201801 reported the holder as ZEROSPACE Christian Wittenberg trading as Zerospace Cloud and the AS as announced at the 15 July 2026 query. RIPEstat routing status at https://stat.ripe.net/data/routing-status/data.json?resource=AS201801 reported broad public visibility: 324 of 326 IPv4 RIS peers and 322 of 322 IPv6 RIS peers were seeing the routed space. That is not the signature of an unused registration. It is the signature of a small network that is visible to the global routing system.

For infrastructure buyers, live route visibility is necessary but not sufficient. A provider can route a /24 and several IPv6 /48s while still depending on leased virtual servers, reseller colocation, a single remote-hands supplier or a small set of upstreams. A route shows that packets can find the announced prefixes. It does not show that a customer can get replacement hardware after a drive failure, export a large dataset under time pressure, recover from a storage fault, or reach a human with authority to fix a power incident.

Hosted capacity turns route visibility into a service only when there are racks, power, cooling, hardware inventory, access procedures, support coverage and exit paths behind the prefixes.

The routed estate is small, visible and unevenly advertised

The IPv4 picture is compact. RIPEstat announced-prefixes data at https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS201801 showed 185.140.53.0/24 announced continuously during the 1 July to 15 July 2026 window. Routing status counted that as one IPv4 prefix and 256 IPv4 addresses. For a hosting or cloud service, a /24 can be operationally useful, but it is small. It can support a focused anycast-like service, NAT gateways, customer management endpoints, a set of VPS nodes or a limited number of directly assigned customer addresses. It is not, by itself, evidence of a large compute estate.

The IPv6 picture is more expansive in address math and more nuanced in current visibility. The RDAP record covers 2a07:1a84::/44, which contains sixteen possible /48s. PeeringDB's network entity at https://www.peeringdb.com/api/net?asn=201801 lists one IPv4 prefix and sixteen IPv6 prefixes in the profile. RIPEstat's announced-prefixes endpoint, however, showed eight IPv6 /48s visible during the review window: 2a07:1a84::/48,:1::/48,:2::/48,:3::/48,:4::/48,:5::/48,:6::/48 and:9::/48. RIPEstat's AS routing consistency view at https://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS201801 added the useful detail that 2a07:1a84::/44 was in whois but not itself in BGP, while several /48s were both in whois and BGP and several other /48s were in whois but not BGP.

That difference matters for installed versus usable capacity. Installed address capacity is the registered IPv6 /44 and the PeeringDB statement of sixteen IPv6 prefixes. Usable routed capacity is the subset actually visible in BGP during the relevant period. Customer-usable capacity is narrower still: the prefixes that a customer can contract for, route through a known site, protect with RPKI, monitor, support and move if a provider, facility or upstream fails. A /44 can look huge on paper while only selected /48s are active in public routing and only a smaller subset is tied to production services.

The IPv6 timing also points to a network under active change. RIPEstat showed 2a07:1a84::/48 and 2a07:1a84:5::/48 visible from the start of July, with:5::/48 showing a short gap between 3 July and 5 July. It showed several other /48s starting visibility on 12 July 2026. That does not prove instability in a customer-impacting sense; new IPv6 locations or service nodes often come online in waves. It does mean the customer should ask which /48s are considered production, which are test or staging allocations, which are tied to a city label, and which have tested failover.

Route-origin validation is one of the better parts of the Zerospace record. RIPEstat returned a valid state for 185.140.53.0/24 at https://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=185.140.53.0/24, with origin AS201801 and maximum length /24. It returned a valid state for 2a07:1a84::/48 at https://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=2a07:1a84::/48, validating against a ROA over 2a07:1a84::/44 with maximum length /48. RPKI does not keep servers running, but it gives route filters a way to distinguish authorized origin announcements from unauthorized ones. For a new small network, that hygiene is important.

The upstream picture is visible, but the facility picture is not

The upstream record is clearer than the facility record. RIPEstat ASN neighbours at https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS201801 showed two observed neighbours: AS57758 and AS63473. RIPEstat's AS overview identifies AS57758 as CBWS Holding B.V. and AS63473 as HostHatch, LLC. The whois view at https://stat.ripe.net/data/whois/data.json?resource=AS201801 also lists import and export policy entries for AS20473, AS63473 and AS57758, while the public neighbour observation showed AS57758 and AS63473 at the time checked. AS20473 is The Constant Company, LLC in RIPEstat's AS overview, commonly associated with Vultr in the AS name.

This is enough to describe a dependency surface, not enough to certify diversity. Two observed neighbours are better than one if they are actually independent in the customer's service path, present in separate facilities or failure domains, and both configured for the customer's prefixes. But two ASNs can still share the same building, same meet-me room, same metro fibre, same power event or same remote-maintenance window. Public BGP data cannot tell us whether the Zerospace routers sit in one rack or multiple sites.

It cannot tell us whether both neighbours carry all production prefixes, whether failover is automatic, whether one neighbour is backup only, or whether the customer control plane depends on the same physical handoff.

PeeringDB deepens that caution. The Zerospace Cloud network record at https://www.peeringdb.com/api/net?asn=201801 lists AS201801, website https://zerospace.cloud, IRR as-set AS201801:AS-ZEROSPACE-CLOUD, one IPv4 prefix, sixteen IPv6 prefixes, policy_general Open, status ok, a creation timestamp in October 2022 and an update timestamp on 8 February 2026. But PeeringDB's exchange LAN endpoint at https://www.peeringdb.com/api/netixlan?asn=201801 returned no public IX LAN rows, and its facility endpoint at https://www.peeringdb.com/api/netfac?net_id=31374 returned no public facility rows. PeeringDB is operator-maintained and can be incomplete, so an empty facility list is not proof of no facility presence. It is proof that the public facility proof is absent.

For a cloud buyer, absence of facility proof is not a small detail. Facilities are where route promises become operational promises. A customer needs to know which data centre holds the servers, which entity contracts for the rack, which remote-hands team can touch the hardware, whether there are redundant power feeds, whether cabinets are within contracted power limits, how cooling is supplied, and which cross-connects reach which upstreams. Without a public facility list or first-party facility statement, customers have to ask directly and verify contractually.

That is especially true for Zerospace because the geofeed is global while the visible public facility evidence is empty. A geofeed can be useful for content localization, fraud controls, latency routing and customer expectations. It cannot replace a facility statement. A provider may geolocate small address blocks to a city because a VM, tunnel endpoint, reseller node, cloud instance or partner deployment is there. That does not prove owned racks, spare servers, spare optics, out-of-band management, battery runtime, generator coverage or local support.

The geofeed describes city labels, not guaranteed local infrastructure

The geofeed at https://download.zerospace.cloud/ipam/geofeed.csv is one of the most informative public artifacts in the Zerospace record. It maps 185.140.53.0/29 to Amsterdam, 185.140.53.8/29 to London, 185.140.53.16/29 to Stockholm, 185.140.53.24/29 to Seoul, 185.140.53.32/29 to Singapore, 185.140.53.40/29 to Hong Kong, selected /32s in 185.140.53.48 through 185.140.53.55 to Tokyo, 185.140.53.56/29 to Sydney, 185.140.53.64/29 to New York and 185.140.53.72/29 to Los Angeles. It maps IPv6 /48s to the same city pattern: 2a07:1a84::/48 to Amsterdam,:1::/48 to London,:2::/48 to Stockholm,:3::/48 to Seoul,:4::/48 to Singapore,:5::/48 to Hong Kong,:6::/48 to Tokyo,:7::/48 to Sydney,:8::/48 to New York and:9::/48 to Los Angeles.

That is a global service-area signal, not a global capacity proof. On IPv4, most city entries are /29s, meaning eight addresses each. The Tokyo IPv4 entries are individual /32s or very small groupings, and the geofeed does not cover every address in the /24 with an explicit named city. RIPEstat geolocation at https://stat.ripe.net/data/geoloc/data.json?resource=185.140.53.0/24 and the MaxMind GeoLite view at https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=185.140.53.0/24 reflected a similar spread, but also showed a large share of the IPv4 /24 as Sweden with no city in the queried view. That means the public geolocation picture is mixed: some address slices have precise city labels; much of the IPv4 address space does not present as a detailed city-by-city compute map.

The IPv6 location view also needs careful reading. RIPEstat geolocation for https://stat.ripe.net/data/geoloc/data.json?resource=2a07:1a84::/44 and the MaxMind GeoLite view at https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=2a07:1a84::/44 showed the /44 split across several city-labeled /48s, with a substantial share of the aggregate appearing as Sweden without a city. The geofeed lists:7::/48 for Sydney and:8::/48 for New York, while the announced-prefixes endpoint did not show those /48s among the eight visible prefixes during this review window. That is not necessarily a contradiction; geofeed entries can describe intended or registered locality while routing visibility changes over time. It is a reminder that locality claims must be tied to current route state.

Customers affected by this distinction are not only end users in those cities. A small cloud provider may be serving VPN gateways, edge nodes, managed hosting, developer workloads, backup targets, gaming infrastructure, test environments, small business services or regional access points. If an Amsterdam-labeled slice fails, a European customer may care about latency and legal location. If a Hong Kong or Singapore slice fails, Asia-Pacific users may see higher latency or failover to another region.

If the New York or Los Angeles slice is not currently routed, a customer planning a North American deployment needs to know whether that location is live, reserved, paused or pending.

The right diligence question is therefore not "does the geofeed mention my city?" It is "which physical or virtual site serves my city-labeled address, who operates that site, what upstreams carry it, what power and hardware are behind it, and how will it be restored or migrated?" A city label can help a customer decide what to ask. It should not be used as evidence that Zerospace has owned infrastructure in all ten cities.

The website and DNS record reveal a separate availability dependency

The main website also needs to be kept separate from customer infrastructure. RIPEstat's DNS-chain endpoint at https://stat.ripe.net/data/dns-chain/data.json?resource=zerospace.cloud showed zerospace.cloud using Cloudflare authoritative nameservers, ali.ns.cloudflare.com and rudy.ns.cloudflare.com, with A records 172.67.142.47 and 104.21.87.70 and AAAA records 2606:4700:3035::ac43:8e2f and 2606:4700:3036::6815:5746 at the 15 July 2026 query time. The DNS-chain endpoint for https://stat.ripe.net/data/dns-chain/data.json?resource=download.zerospace.cloud showed the same Cloudflare-fronted addresses for the download host. The endpoint for https://stat.ripe.net/data/dns-chain/data.json?resource=www.zerospace.cloud returned the Cloudflare authoritative nameservers but no forward records for www.zerospace.cloud.

During a direct HTTPS check on 15 July 2026, https://zerospace.cloud did not return a usable page within a 15-second curl timeout from this environment. Earlier Cloudflare-fronted checks can surface 522-style origin reachability failures when the origin does not respond to Cloudflare. Even without relying on any one transient HTTP result, the DNS evidence shows the public website path is Cloudflare-mediated. That is common and often sensible. It also means the website's availability is not the same thing as AS201801's route availability.

There are two separate dependencies here. First, Zerospace's marketing or control web presence depends on Cloudflare DNS and proxying, plus whatever origin service sits behind Cloudflare. Second, Zerospace's routed customer prefixes depend on AS201801, its upstream neighbours and the physical or virtual locations carrying those prefixes. A buyer should not infer that because the website is behind Cloudflare, customer traffic is behind Cloudflare. Nor should it infer that because AS201801 is visible in BGP, the customer portal, documentation, status notices or support path will remain reachable during a website-origin fault.

The download host is interesting because it served the geofeed even though the primary site was not a readable public-service page during the check. That suggests some Cloudflare-fronted paths may be reachable while others are not. For customer operations, the question is whether critical portals, support forms, control panels, status pages, geofeeds and API endpoints are independently hosted or share the same origin dependency. If the only customer support route is a web form behind a fragile origin, then a network or origin fault can delay recovery even when the BGP route remains up.

The website evidence also reduces the amount of first-party service detail available to outsiders. Many providers publish facility pages, product terms, service-level objectives, support procedures, data export terms, backup policies and legal documents on their site. If the main site is not reliably readable, public diligence has to rely more heavily on registry and routing evidence. That is enough for a network identity article. It is not enough for a confident hosted-capacity purchase.

Physical dependencies are mostly hidden behind the network layer

Zerospace's public record gives us route resources, but it does not give us a full physical map. There is no public PeeringDB facility row for AS201801. There is no public facility page available from the main website in this review. There is no published cabinet list, power-density statement, cooling design, remote-hands provider, hardware inventory policy, backup architecture, status page or migration guide in the evidence available here. That does not mean those things do not exist. It means they are not proven publicly.

The physical dependency stack for a customer is still concrete. If Zerospace sells hosted capacity, some server or virtual instance must sit somewhere. That somewhere has a rack or host machine, power feed, cooling path, management network, upstream port, storage dependency and access process. If a disk fails, someone or some automation must replace or move the workload. If a router fails, a second path must carry the prefix. If a cabinet breaker trips, there must be a plan for that cabinet. If a facility has a maintenance window, the provider must know which customer services are exposed.

If a city-labeled address is actually a virtual endpoint in a larger cloud region, the customer should know that too.

Power and cooling are the least visible parts of the Zerospace record. A /24 and a /44 can be announced from very little physical infrastructure, from rented virtual machines, from partner hosts or from a small number of colocated servers. The number of IP addresses therefore says almost nothing about power headroom. Customers need to know the installed power allocation, the usable power after redundancy, the cooling density per rack, the UPS and generator assumptions of the facility, and whether a single high-density deployment could exhaust the provider's local margin.

Without that information, a buyer cannot distinguish a city edge node from a resilient hosting region.

Hardware inventory is similarly opaque. A provider can route addresses globally but still depend on a limited pool of hosts. If Zerospace offers VPS or managed services, the buyer should ask how many production hosts sit behind each location, whether storage is local or shared, how failures are evacuated, whether spare nodes exist in the same location, and whether replacement capacity requires ordering from a third-party host. The small IPv4 allocation makes efficient address use likely; it also means public IP scarcity may affect migration and expansion plans.

Support is visible only at the network-contact level. RDAP names network operations and abuse roles, which matters for route operations and abuse handling. It does not show customer support hours, escalation levels, incident response objectives, paid support tiers, languages, ticket tooling or emergency authority. A customer buying infrastructure capacity should treat network-contact existence as the floor, not the support promise. The real recovery question is who can act when a router session drops, a host fails, a city endpoint disappears or a customer needs to evacuate data on short notice.

Failure paths: route, upstream, facility, support and migration

The first failure path is upstream reachability. AS201801 had two observed neighbours in RIPEstat, AS57758 and AS63473, and a whois policy list that also named AS20473. If AS57758 or AS63473 loses a session, the result depends on whether both neighbours carry the affected prefixes, whether traffic engineering is symmetrical enough for return paths, and whether the fault is isolated to one upstream. If both sessions terminate in the same site or depend on the same local handoff, the redundancy may be less useful than the AS count suggests.

Customers should ask for a route diagram showing which upstreams carry each production prefix and where those sessions live.

The second failure path is route authorization or filtering. RPKI is valid for the IPv4 /24 and IPv6 /44-to-/48 pattern, which is good. But customers should still ask whether Zerospace monitors route leaks, invalid announcements, max-length mistakes and geolocation drift. A valid ROA can become operationally painful if a provider later announces a more specific route beyond max length, if an upstream filters unexpectedly, or if a city-specific /48 is added without matching route authorization. The current RPKI state is a positive control; it is not a substitute for change control.

The third failure path is facility loss or hidden facility concentration. Because PeeringDB lists zero public facility rows, customers cannot independently tell whether multiple cities represent multiple facilities, one upstream overlay, or a reseller estate. If an Amsterdam-labeled address and a London-labeled address are both dependent on one provider account, one billing relationship, one remote-support team or one tunnel concentrator, a fault in that provider relationship could affect more than one apparent region. Multi-city geofeed entries should be verified against independent facility, supplier and routing evidence.

The fourth failure path is the control and support plane. The primary domain's Cloudflare-fronted DNS, the empty www record and the unavailable main site during the check all point to the importance of knowing how customers reach support during a fault. If the customer portal, status notices, documentation and support forms share a fragile origin, the provider can lose communication while the network problem is still unfolding. Infrastructure recovery depends on contact paths as much as packets. Buyers should require an out-of-band incident contact, not only a web form.

The fifth failure path is migration. New networks change. Zerospace's 2026 registration dates, July 2026 IPv6 visibility changes and city geofeed layout suggest a platform still being expanded or adjusted. That can be promising, but it makes exit rights and migration paths essential. Customers need to know whether they can export disk images, snapshots, database dumps, logs and DNS records; whether they can keep IPv4 addresses during a move; whether IPv6 /48 assignments are portable within Zerospace locations; how long data export takes; and what happens if a location is retired or rerouted.

Installed capacity, usable capacity and bought capacity are different things

The Zerospace evidence is a useful example of why cloud capacity has three layers. Installed capacity is what the provider can plausibly claim to possess or control: AS201801, 185.140.53.0/24, 2a07:1a84::/44, registered route policy and a PeeringDB profile. Usable network capacity is what appears in public routing and can be reached with valid origin authorization: one IPv4 /24, eight visible IPv6 /48s in the review window, two observed neighbours and broad RIPE RIS visibility. Bought capacity is what a customer can actually consume under contract, with compute, storage, bandwidth, support and migration terms attached.

The distance between those layers is where risk hides. A customer might see ten geofeed cities and assume ten production regions. The evidence does not support that assumption. A customer might see sixteen IPv6 prefixes in PeeringDB and assume all sixteen are live. RIPEstat showed eight visible /48s during this window, with some whois-listed /48s not present in BGP. A customer might see two observed upstream neighbours and assume route redundancy. That is only true if the two neighbours are independent for the customer's prefixes and failure domain. A customer might see valid RPKI and assume operational resilience.

RPKI helps route authenticity, not server repair.

This does not make Zerospace unusable. It makes it a provider that should be bought with a narrow evidence model. A developer who needs a small routed service, an IPv6 lab, an edge experiment or a non-critical hosted endpoint might find the public footprint adequate, provided the commercial terms match the risk. A business moving production workloads, customer data, payment-adjacent systems, health data or regulated records should demand more than public routing evidence. It should demand facility details, support commitments, backup separation, customer exit terms and proof that the city or region being purchased is actually live.

The lack of public facility rows also changes how to think about redundancy proof. Redundancy is not a count of city names. It is a proof that two failures do not share the same cause. For Zerospace, that proof would need to show at least: upstream independence, facility independence, power independence, storage or backup independence, management-plane independence and support escalation independence. If any one of those is missing, then a labelled second region may still fail with the first.

Installed versus usable capacity also affects price. Small providers can be attractive because they are flexible, affordable and technically direct. But a low-cost offer may exclude the spare parts, staff hours, transit headroom or backup retention that larger cloud buyers assume. Customers should price the missing pieces explicitly. If a workload needs fast recovery, the customer should pay for and test that recovery. If a workload only needs a public endpoint and can be rebuilt elsewhere, the customer can accept a lighter service and maintain its own portability.

Data locality is declared through geofeed, but legal and operational locality remain open

The geofeed gives a data-locality signal, but it is not a data-sovereignty contract. It tells geolocation consumers how Zerospace wants address slices to be interpreted. It does not say where disks sit, where backups sit, which company operates the host, where support staff are located, which law governs the service, or which subcontractors can access customer data. That distinction is essential for customers in Europe, Asia-Pacific and North America who may read Amsterdam, London, Hong Kong, Tokyo or New York as a compliance or latency statement.

For European customers, the Dutch organisation record and Netherlands country code on the address records are useful, but they do not prove that all customer data remains in the Netherlands or the European Economic Area. The geofeed itself points outside Europe for several slices. For Asia-Pacific customers, the labels Seoul, Singapore, Hong Kong, Tokyo and Sydney may be useful for latency, but the customer still needs to know whether data is processed locally, proxied through another country, backed up elsewhere or operated by a third-party hosting supplier. For U.S. customers, New York and Los Angeles labels require the same questions.

The safest reading is that Zerospace has declared network locality for address blocks, not data-residency guarantees. Customers should ask for region-specific terms that name the hosting supplier or facility class, define where customer data and backups live, identify support access locations, and describe how logs, snapshots and exports are handled. If the service is only a network overlay or small edge presence, the contract should say that clearly. If Zerospace has local physical infrastructure, the contract should state the operating boundaries.

Locality also intersects with failure response. If a Hong Kong-labeled address is served by a partner in Hong Kong, the repair path may depend on that partner's support queue. If it is served by a virtual node from a global cloud provider, repair may depend on that provider account and region status. If it is served through a tunnel from another location, the geofeed label may be useful for applications but not for physical independence. None of these models is automatically wrong. What matters is disclosure. A customer cannot design resilience around a city name unless it knows what the city name actually means.

Who is affected if the service fails

The affected users depend on what Zerospace is actually selling. The public evidence supports a cloud or hosting-style network identity, but it does not publish a product catalogue that can be independently read here. Still, the dependency classes are clear. Customers using Zerospace for hosted endpoints, VPS instances, edge nodes, VPN gateways, DNS-adjacent services, small business sites or application back ends would be affected by route withdrawal, upstream failure, server failure, storage loss, support delay or website-control failure.

Regional end users would notice the geofeed layer first. If traffic meant for Amsterdam, London or Stockholm shifts to a more distant location, latency-sensitive applications may degrade. If Seoul, Singapore, Hong Kong or Tokyo slices are unavailable, Asia-Pacific users may see longer paths or service failure. If New York or Los Angeles slices are not routed when expected, North American users may not get the locality promised in a commercial design. The geofeed map therefore creates expectations even when it does not prove capacity.

Customers would also be affected by address scarcity. With only one IPv4 /24 visible, IPv4 assignments are a finite resource. If a customer needs more public IPv4 addresses, fast expansion or clean migration to another provider, the limited IPv4 pool becomes a practical constraint. IPv6 is more abundant, but IPv6 adoption still depends on the customer's users, networks and applications. A service that works well over IPv6 may still need IPv4 for customers, mail, legacy systems or third-party integrations.

The most exposed customer is the one that treats Zerospace as a full cloud platform without testing recovery. If the service is used for non-critical edge experiments, the customer can rebuild elsewhere. If it holds primary databases, customer-facing production services or irreplaceable backups, the customer needs stronger proof. The public record does not yet show enough to justify treating AS201801 as a mature multi-region platform by default.

What would raise the evidence grade

Zerospace could raise the evidence grade quickly by publishing a dated infrastructure statement. The most useful public statement would distinguish owned infrastructure, rented colocation, virtualized nodes and partner locations. It would map each city in the geofeed to the type of deployment there, name whether customer compute is available in that location, state whether IPv4 and IPv6 are both production, and explain which upstreams carry each prefix. It would not need to reveal sensitive details; it would need to separate marketing geography from operational dependency.

The next improvement would be facility and support proof. PeeringDB facility rows, a public status page, a customer support page, out-of-band emergency contacts, a backup and restore policy, and a migration or data-export guide would materially improve buyer confidence. A small provider can be credible without publishing every supplier name, but it should show how customers recover when a host, route, facility or account fails. The current public record is heavily weighted toward registry and BGP evidence.

RPKI should remain a strength. Zerospace already has valid route-origin authorization for the reviewed IPv4 and IPv6 routes. Future public evidence should keep that discipline as new /48s appear. If:7::/48 and:8::/48 are meant to become live city locations, route visibility and validation should line up with the geofeed. If some geofeed entries are reserved or planned, the provider should say so rather than letting customers infer production locality from an address-location file.

The evidence grade would fall if AS201801 lost broad route visibility, if RPKI became invalid, if the geofeed continued to advertise locations that remained unrouted without explanation, if the website remained intermittently unreadable without a separate support path, or if customers could not obtain facility and recovery details. It would also fall if the provider sold multi-region resilience while depending on a single account, single facility, single support queue or single upstream failure domain.

Bottom line for dependent operators

Zerospace Cloud has enough public evidence to be treated as a real routed network, not enough to be treated as a proven global hosting platform. RIPE records tie AS201801, 185.140.53.0/24 and 2a07:1a84::/44 to Christian Wittenberg trading as Zerospace Cloud. RIPEstat shows the AS announced with broad IPv4 and IPv6 visibility. RPKI is valid for the reviewed IPv4 and IPv6 origins. PeeringDB lists a Zerospace Cloud network entity. The geofeed is detailed and current enough to support serious questions about geographic service design.

The caution is equally clear. The IPv4 estate is one /24. IPv6 visibility covers eight /48s in the review window, not every /48 implied by the /44 and profile. PeeringDB shows no public facility or IX rows. The main website was not a reliable source of service details during the check. The geofeed maps cities, but it does not prove racks, power, cooling, hardware, support or migration capacity in those cities. The current upstream picture shows two observed neighbours, but public routing data does not prove independent failure domains.

A practical buyer should therefore use Zerospace only with explicit evidence for the exact service being purchased. Ask where the workload runs, who operates the facility or host, which upstreams carry the prefixes, whether IPv4 and IPv6 are both live in the requested location, how power and hardware failures are handled, how support is reached during a website fault, how backups are separated, and how data can be exported. Treat the geofeed as a map of claimed address locality, not as a map of guaranteed cloud regions.

For non-critical workloads, the public record may be enough to justify testing. For production services, the missing evidence is too important to ignore. Hosted capacity always resolves back to physical dependencies. In Zerospace's case, the public Internet can see the routes; customers still need proof of the racks, upstream independence, support authority and migration paths behind them.