netplans-cloud NetPlans GmbH sells hosted capacity that still

Summary

netplans-cloud NetPlans GmbH is linked in the BTW directory to AS202661; RIPEstat and RDAP establish a public route identity, but not a complete view of racks, power, support, customers or restore capacity.
July 2026 public routing data shows 1 IPv4 prefix-count entries, 1 IPv6 prefix-count entries and 108 observed neighbours; PeeringDB reports 1 exchange entries and 2 facility entries.
The procurement question is whether customers can verify upstream diversity, facility dependency, address control, support escalation, backup restoration and data portability before depending on the service for production workloads.

The public record is a map, not a capacity certificate

The BTW directory profile puts netplans-cloud NetPlans GmbH into the public infrastructure watch list because it links the company to AS202661. RIPEstat's AS202661 overview names the holder as netplans-cloud NetPlans GmbH and shows the AS as announced on 15 July 2026. The matching RDAP autnum record gives the administrative number-resource view: handle, country or contact entities where the relevant registry exposes them. Those records are useful because they identify a routable dependency that can be tested from outside the company. They are not enough to conclude that every marketed cloud, VPS, server, mitigation or data-centre promise is resilient.

NetPlans Cloud is a useful small-cloud case because AS202661 has a modest route set but PeeringDB reports named German facility presence and a DE-CIX Frankfurt peering entry. That is better physical disclosure than many small hosting records, yet it still leaves buyers needing proof that Munich, Karlsruhe, transit, support and restore paths are all tied together in a recoverable service.

RIPEstat's July 2026 data for AS202661 shows 1 IPv4 prefix entries and 1 IPv6 prefix entries in the prefix-count call; the routing-status view reports 108 observed neighbours and announced-space fields of {'v4': {'prefixes': 1, 'ips': 1024}, 'v6': {'prefixes': 1, '48s': 65536}}. Announced-prefix examples include 185.197.40.0/22, 2a0e:d1c0::/32. PeeringDB adds 1 exchange entries, 2 facility entries, scope Regional, which is helpful context but not an audited statement of usable server capacity. That distinction is the starting point for this article.

An ASN can be a real operational asset and still be a poor proxy for customer-ready capacity. A customer needs to know what the AS reaches, who controls the addresses, where the machines sit, which carriers carry production traffic, how support is staffed, and how a workload exits if the provider or one supplier fails.

What the AS-level evidence actually says

The strongest public facts are the network facts. RIPEstat's routing-status view reports first-seen and last-seen routing observations for AS202661; in the cached July 2026 data, the first observed route was 185.197.40.0/22 at 2022-11-04T00:00:00, while the latest observed route was 185.197.40.0/22 at 2026-07-15T00:00:00. The same call reports visibility fields of {'v4': {'ris_peers_seeing': 326, 'total_ris_peers': 326}, 'v6': {'ris_peers_seeing': 322, 'total_ris_peers': 322}}. Those values matter because a route that is visible from many RIS peers can affect real users, but the values still describe reachability of prefixes, not the health of servers or storage.

The announced-prefixes call returned 2 visible prefix entries in the local extract, with examples such as 185.197.40.0/22, 2a0e:d1c0::/32. The prefix-count call counted 1 IPv4 prefix entries and 1 IPv6 prefix entries in its July sample. For a buyer, the important translation is simple: these numbers describe installed route surface. They do not describe installed compute, installed storage, spare parts, remote hands, customer density, DDoS headroom, backup throughput, or the number of workloads that can survive a facility event.

PeeringDB and website signals need careful reading

PeeringDB's AS202661 query returns a profile named NetPlans Cloud. Where a profile is present, it reports a traffic band of not disclosed, scope of Regional, 1 exchange entries and 2 facility entries. The detail calls add more colour: netixlan shows DE-CIX Frankfurt: DE-CIX Frankfurt Peering LAN, while netfac shows EMC Home of Data MUC I/II - MuCon-X in Munich, DE, TelemaxX IPC4 in Karlsruhe, DE. These fields are valuable because they reveal what the operator or community directory is willing to publish. They are not audit results. Zero facility rows do not prove there are no facilities; named facility rows do not prove a workload is actually deployed there.

The public website endpoint reviewed was https://www.netplans.de/, whose title or first-page metadata was consistent with IT-Systemhaus für den Mittelstand | NetPlans – 15 Standorte, ISO-zertifiziert. That website signal is useful for product-boundary analysis, especially when the page clearly markets hosting, cloud, VPS, connectivity or data-centre services. It is weaker for resilience. Marketing pages tend to describe what a customer can buy in normal conditions; they rarely disclose port utilisation, exact facility dependency, current failover headroom, hardware-spare depth, RPKI state, prefix ownership, recovery runbooks or support staffing. A customer should therefore use the website to identify the likely product family and use the registry and routing records to identify the dependency map.

Physical dependencies behind the routed surface

Every public route ultimately depends on physical places. For netplans-cloud NetPlans GmbH, the visible AS202661 surface has to terminate through some combination of owned racks, colocation cages, wholesale compute platforms, cross-connects, leased circuits, routing hardware, address-authorisation records and people who can act during an incident. The public record does not expose all of that.

Even when PeeringDB names facilities, those rows do not tell whether customer servers sit in each site, whether the provider has A/B power, whether storage is replicated across rooms, whether a single switch is a concentration point, or whether a second site has enough spare capacity to receive a failed workload.

This is why the procurement question is not only "is the ASN live?" The better question is "what capacity remains usable when the most likely dependency fails?" A small AS with one prefix can be perfectly adequate for low-risk hosting if backups, DNS control and migration rights are clean. A large AS with hundreds of prefixes can still trap a customer if account control, address authorisation, snapshots and support escalation are locked inside one supplier.

Physical evidence should include facility city or operator disclosure under nondisclosure, power feed design, generator/runtime assumptions, remote-hands contract, spare-router and spare-server policy, carrier diversity, maintenance windows, and a dated contact path for emergency decisions.

Installed capacity versus usable capacity

Installed capacity is what the public record can hint at. For AS202661, RIPEstat can count prefixes, report neighbour visibility and show whether IPv4 or IPv6 routes are present. PeeringDB can add traffic bands, exchange entries, facility rows and peering policy. A website can show a brand and a sales offer. Those are all useful. Usable capacity is narrower and harder. It is what remains after existing customer load, oversubscription, upstream commits, breaker limits, DDoS filtering, maintenance reserves, cooling margins, backup windows and failover assumptions are accounted for.

Customers should ask netplans-cloud NetPlans GmbH to present current utilisation by product, not by slogan. For VPS or cloud service, the relevant evidence is node count, storage design, snapshot schedule, backup restore time, hypervisor evacuation procedure and the number of customer instances that can move during a host or rack failure. For bare-metal or server hosting, it is spare inventory, remote-hands time, disk replacement and whether out-of-band management survives a network incident. For IP transit or routed services, it is port speed, commit, upstream diversity, route policy, RPKI/IRR control and blackhole procedure.

For a data-centre product, it is power, cooling, fire controls, carrier meet-me paths and permission to enter or move equipment. The ASN touches each of those products differently; the customer must not let one visible metric stand in for all of them.

Route control and address portability

The route layer is where hidden contractual boundaries often surface. RIPEstat's ASN-neighbours call reports 108 observed neighbours in the cached July 2026 extract. That count is not a contract list, but it shows that the AS is seen in relation to other autonomous systems. The whois call and the relevant RDAP record show administrative contacts and registry handles; the RIR mapping call anchors the number-resource registry context. The customer needs to turn those public facts into operational commitments.

For every prefix assigned to a customer, the provider should identify whether the address block is provider-owned, customer-owned, leased, delegated, downstream-routed or temporary. Then it should state who controls the ROA, who controls the IRR route object, who can update reverse DNS, who receives abuse notices, who can authorise a move to another origin, and what notice period applies if the block has to be withdrawn. The RIPE NCC RPKI documentation and RFC 7454 explain why route-origin and filtering practices matter, but the operational answer must come from the provider's current records. A customer that cannot move its data or replace its addresses quickly is buying more dependency than it may realise.

Failure paths customers should model

The first failure path is carrier or upstream loss. If the visible route surface for AS202661 depends heavily on one or two adjacent networks, a single upstream policy change, port failure, settlement issue or route-filter mistake can remove reachability even while the provider's servers are powered. If the AS has many neighbours, the failure mode changes: route leaks, inconsistent filters, partial prefix loss and uneven traffic engineering become more important. Either way, customers should monitor every production prefix from outside the provider and test how traffic changes when one upstream is withdrawn.

The second failure path is facility concentration. A provider can show multiple routes while still concentrating compute, storage, control panels, billing and support in one facility or one wholesale account. Facility concentration is especially dangerous when customers rely on the provider for both hosting and authoritative operational controls. The third failure path is address or registry friction. If a prefix is blocked, invalid, disputed, reputation-damaged or slow to update, a workload can stay technically online but become unreachable to payments, mail, partner APIs or regulated customers. The fourth failure path is support overload.

During a routing or facility incident, the practical question is whether someone with authority can reach carriers, registry maintainers, remote hands and account systems quickly enough to stop the outage from becoming a migration crisis.

Who is exposed

The exposed population depends on the service model. Direct cloud, VPS, bare-metal, IP transit, DDoS-mitigation and colocation customers may depend on AS202661 directly. Resellers may depend on it indirectly and then pass the risk to their own customers. End users may feel the incident as latency, failed checkout, unreachable application endpoints, mail delivery problems, geolocation mismatches or support delays. Peers and upstreams are exposed to route hygiene and abuse handling. The provider's own support team is exposed when a problem crosses routing, facility, commercial and registry boundaries at the same time.

For netplans-cloud NetPlans GmbH, the public record suggests a compact route surface. That changes the number of people who may notice an outage, but not the underlying diligence logic. A compact network can still be critical if a customer places a production application on it. A broad network can still be fragile if a hidden dependency is concentrated. Customers should classify workloads by exit cost. If the workload can be rebuilt from external backups in hours, the provider can be used with a controlled risk budget.

If the workload has hard residency, reputation, customer-data or payment dependencies, the customer needs written proof of resilience before relying on the service.

What buyers should ask before production use

The first group of questions is about location. Where are the active servers, routers, storage systems and control systems? Which facilities are owned, leased or reached through a wholesale platform? Which workloads are in the same room, which are in the same metro, and which are genuinely in a different failure domain? If the answer is confidential, the provider can still supply city-level disclosure, facility class, power design and a letter or contract summary under nondisclosure. A public ASN cannot answer this for the customer.

The second group is about routing. Which upstreams carry production traffic? Which prefixes are valid under RPKI? Which route objects are current? Which communities support blackholing or traffic engineering? Which prefixes can the customer originate elsewhere during an emergency? The third group is about recovery. How are backups created, stored and restored? How often has a full restore been tested? What is the largest failure the provider has rehearsed? What remains available when one router, one rack, one site, one account system or one upstream is unavailable? The fourth group is about exit.

How long does export take, what formats are supported, who approves address movement, what happens to reverse DNS, and how long does the customer retain access after termination?

Signals that would improve confidence

Confidence would improve if netplans-cloud NetPlans GmbH published a current infrastructure page that links product families to operating evidence: route set, upstream categories, facility cities, status page, abuse policy, maintenance notification, RPKI/IRR practice, support hours and data-location terms. Confidence would improve if PeeringDB facility and exchange rows were current and aligned with measured traffic. Confidence would improve if customers could see a looking glass, a public status history, clear contact roles and a documented process for prefix movement or workload export.

Confidence would also improve through dated customer-facing proofs that are not public marketing. Examples include a failover test witnessed by the customer, current port-utilisation graphs, backup restore evidence, written remote-hands escalation, an incident report from a previous outage, a map of prefix authority, and a statement of which services remain under the provider's direct control. The NCSC cloud shared-responsibility guidance is useful here because it reminds buyers that responsibility changes by service model. The provider should be able to say which responsibilities it takes, which ones the customer keeps, and which ones belong to a hidden supplier.

Signals that would weaken the assessment

The assessment would weaken if the route surface grew while facility, support and address-control disclosure stayed absent. Growth is not bad by itself, but more prefixes and more neighbours increase the number of ways partial failure can appear. It would also weaken if RPKI or route-object mismatches appeared on customer prefixes, if PeeringDB details became stale, if public contact paths failed, if website claims stayed vague while production workloads grew, or if customers could not export data without manual intervention from the provider.

The assessment would weaken most if the provider used cloud language to imply resilience it could not demonstrate. Terms such as cloud, hosting, mitigation, data centre and network services are product labels; they do not automatically include multi-site design, independent backup, address portability or 24-hour engineering authority. A buyer should not demand perfect public disclosure from every small provider, but it should demand a private operational answer before moving irreplaceable workloads. If that answer is not available, the safe design is to keep the service peripheral, keep backups elsewhere, and maintain a second provider.

The editorial grade

The evidence grade for netplans-cloud NetPlans GmbH is Medium for network presence, weak for customer-ready capacity proof. The network identity is visible through AS202661, RIPEstat and RDAP. The route surface has measurable public characteristics: 1 IPv4 prefix-count entries, 1 IPv6 prefix-count entries and 108 observed neighbours in the available July 2026 data. PeeringDB adds a profile with traffic band not disclosed, scope Regional, exchange count 1 and facility count 2, while the website signal points to a public product or brand endpoint.

The practical conclusion is restrained. netplans-cloud NetPlans GmbH may operate useful infrastructure, and in some cases the public record is stronger than many small-hosting profiles. But the public evidence does not by itself prove customer-ready capacity, facility diversity, power redundancy, support depth, backup success or migration rights. Customers should treat AS202661 as a map of dependency and questions, not as a certificate of resilience.

The right buying posture is to verify racks, routes, power, people and portability before production use, then design the workload so that a provider failure becomes a controlled move rather than a business interruption.

A practical due-diligence exercise

A practical buyer can turn the public record into a short exercise before signing. Start with a test instance or small routed service. Place monitoring outside the provider, preferably from at least three networks. Record the address block, reverse-DNS path, application endpoint, backup target and DNS authority. Ask netplans-cloud NetPlans GmbH to identify which part of the service is under its direct control and which part depends on a supplier. Then simulate a move: export data, rebuild the service elsewhere, change DNS, replace or re-originate addresses if needed, and measure how much manual support is required.

This exercise is more valuable than a long marketing comparison because it exposes the actual exit cost.

For netplans-cloud NetPlans GmbH, the test should include prefix-level observation. If the workload uses 185.197.40.0/22, the customer should monitor that prefix separately from the provider's homepage or control panel. If the workload uses 2a0e:d1c0::/32, the same rule applies. A service can look healthy from inside one AS while unreachable from another market. The customer should also ask whether the provider can isolate one customer's abuse or DDoS event from another customer's prefix.

Shared reputation is a real infrastructure dependency: mail, payments, security vendors and enterprise firewalls can all respond to address history, not just current uptime.

How to design around the dependency

The safer architecture is to keep the provider useful without making it irreplaceable. Authoritative DNS should sit outside the provider. Backups should leave the provider's account and region. Application deployment should be reproducible from images, configuration and secrets stored elsewhere. Monitoring should test the public service and the route, not just the virtual machine. Customer data should have a current export path. If the provider assigns addresses that cannot move, the customer should rehearse a replacement-address event before launch.

That design is not a vote against netplans-cloud NetPlans GmbH. It is normal continuity engineering for any hosted-capacity purchase. The smaller or less documented the public record, the more important the outside controls become. The larger the route surface, the more important prefix-specific monitoring and route hygiene become. The common rule is that customers should never confuse public routing evidence with their own recovery evidence. RIPEstat, RDAP and PeeringDB help identify what to ask. They do not restore a database, ship a disk, update a ROA, restart a router session or answer a support call during a failed maintenance window.

What Mara Voss would keep watching

The continuing watch points are concrete. First, whether AS202661's prefix count or neighbour count changes materially after this July 2026 snapshot. Second, whether PeeringDB gains or loses facility, exchange, policy or contact detail. Third, whether the public website becomes more specific about infrastructure products, location, support and resilience. Fourth, whether prefix-level RPKI and route-object state stays clean for customer-facing addresses. Fifth, whether public outage, abuse or reputation signals begin to show stress around the AS.

These watch points matter because infrastructure companies often change shape faster than their public descriptions. A provider can add transit, move a facility, lease new address blocks, retire a wholesale platform, change support ownership or shift from hosting to network services without rewriting every public page. Customers should therefore treat the purchase as a living dependency. The contract, monitoring, backup and exit plan should be revisited when the route surface changes, when the customer adds a critical workload, or when the provider's public records stop matching the service being sold.

Additional procurement note for AS202661

For netplans-cloud NetPlans GmbH, the final test is whether the provider can answer the same questions with dated evidence after the customer identifies a real workload. Which prefixes are assigned? Which upstream carries them? Which facility hosts the workload? Which backup is outside the provider? Which person can approve emergency action? Which contract lets the customer leave? Public links such as RIPEstat AS202661, PeeringDB AS202661 and the relevant RDAP record make the dependency visible; only provider evidence makes it usable. Until that evidence is supplied, critical systems should keep independent DNS, external backups, separate monitoring and a rehearsed migration path.