Flyservers' Panama address and 13 announced prefixes still do not

Summary

Flyservers is visibly active: its public shop lists six dedicated-server configurations, and three Flyservers autonomous systems originated 13 prefixes with broad route-collector visibility on 16 July 2026.
The evidence does not identify a Flyservers-owned data centre, a particular colocation rack, a backup site, physical carrier paths, power design, inventory reserve, sold load or tested post-failure throughput.
A buyer therefore has to separate four things that the company name can make look deceptively unified: the Panamanian contracting entity, the physical facility operator, the networks carrying each prefix and the legal and technical path for moving data out.

“Where, physically, will my virtual machine run, and where, physically, will its backup be when that site fails?”

That is the first question a prospective Flyservers customer should ask. It is not a philosophical question about “the cloud”. It is a request for two street-level answers and the dependency chain between them. The first answer should identify the facility, rack or at least metro in which the primary workload runs. The second should identify a genuinely separate failure domain for the backup: another room is not necessarily another building; another building is not necessarily another power feed; another city is not necessarily another carrier corridor; and another storage account is not necessarily outside the same administrative compromise.

The current Flyservers portal does not give those answers. Its dedicated-server storefront displays processors, memory, storage, a 100 TB traffic allowance marked either “T1” or “T2”, and monthly prices. It does not name a country, city, facility, rack operator, port speed, RAID mode, backup service, restore objective, power arrangement or service-level commitment. The network-status link exists, but the status page is restricted to logged-in users. The public announcements page reports that there are no announcements to display, while the knowledgebase has no categories or articles. A restricted support surface may work well for customers; it simply cannot answer an outsider’s infrastructure questions before purchase.

Following the question through the stack produces three different trails. The facility trail stops early because no attributable public site inventory was found. The carrier trail is richer: Flyservers has multiple active routing identities, and different prefixes are visible through different adjacent networks. The legal trail starts in Panama, where the company’s registry contacts sit, but then extends into the countries in which equipment, processors, backups and customers may actually be located. These are related layers. They are not interchangeable evidence.

A Panama seller is not the same thing as a Panama server

The strongest public identity evidence points to a Panamanian organisation. The RIPE NCC organisation record for Flyservers S.A. gives 50th Street, Global Bank Tower, Suite 1801, Panama City, and records the organisation entity from December 2018. The RIPE membership page repeats the Panama City address and lists Austria, Bulgaria, Switzerland, Germany, the United Kingdom, the Netherlands and Poland as areas serviced. LACNIC’s record for AS267784 also identifies Flyservers S.A. and a Panama City contact, while the company appears in the Panama section of LACNIC’s 2024 electoral roll.

Those records support a contracting and resource-holder identity. They do not turn Suite 1801 into a data hall. They do not say that a server is powered in Panama, that a backup remains in Panama, or that a technician can reach customer hardware from that address. The RIPE page’s “areas serviced” field is also not a facility list. It may reflect commercial reach, resource administration or service relationships. Converting those seven country codes into seven Flyservers sites would be an invention.

The domain adds another chronological distinction. The Verisign RDAP record for flyservers.com dates the domain to July 2001, much earlier than the current RIPE organisation entity and two of the company’s current autonomous-system registrations. Domain age is evidence that a name has been registered for a long time, not proof that the present Panamanian company has operated the same facilities, services or ownership structure since 2001. A buyer should not use the age of a URL as a substitute for a current corporate extract, a facility schedule or a contract counterparty check.

This distinction matters because a hosting transaction can allocate responsibility across several companies. Flyservers may be the seller and IP-resource holder. A colocation company may control the building, access list, power and cross-connect. A carrier may provide the circuit between a rack and the wider internet. A separate platform may host the billing and support portal. A storage vendor may hold backups. The customer experiences one service, but an outage, seizure, insolvency, access dispute or contract termination travels through those boundaries differently.

The public record does not establish that Flyservers owns any facility. It also does not establish that it owns none. The accurate conclusion is narrower: a physical facility owner or lessor is not publicly attributable from the reviewed material. That unknown changes the questions a customer must put in writing. Who is allowed into the rack? Which party can order a replacement drive? Who holds the cross-connect agreement? Can Flyservers move a customer to another site without consent? Does the customer receive notice when a subprocessor or storage country changes?

Which obligations survive if the relationship between Flyservers and a facility or carrier ends?

Four routing identities, but only three were carrying routes

Flyservers’ routing footprint is real enough to reject the idea that this is merely a dormant corporate shell. It is also fragmented enough to resist any simple claim that “the Flyservers network” is one location or one redundancy design.

The company is associated with four autonomous systems in authoritative registries:

AS209588, registered in January 2019 as FLYSERVERS-ASN.
AS48721, originally registered in January 2009 and now named FLYSERVERS-ENDCLIENTS.
AS267784, registered by LACNIC in February 2019.
AS211794, registered in February 2021 as FLYSERVERSv6-AS.

At 08:00 UTC on 16 July 2026, the first three were visible in the global routing system. The fourth was not. RIPEstat’s AS209588 routing snapshot reported four IPv4 /24s, one IPv6 /48, 1,024 unique IPv4 addresses and four observed neighbours. The AS48721 snapshot reported two IPv4 /24s, one IPv6 /48, 512 unique IPv4 addresses and one observed neighbour. The AS267784 snapshot reported three IPv4 /24s and two IPv6 routes, including a /36, for 768 unique IPv4 addresses and 4,097 /48-equivalents of IPv6 space. The AS211794 snapshot reported zero announcements, zero visible address space and zero observed neighbours.

Across the three active ASNs, that is 13 visible announcements: nine IPv4 routes and four IPv6 routes, covering 2,304 unique IPv4 addresses and 4,099 IPv6 /48-equivalents. The arithmetic describes address space, not servers. A /24 can contain infrastructure addresses, customer addresses, unused addresses, routed virtual services or systems outside a retail product. A large IPv6 allocation can be almost empty. None of these numbers reveals cores, RAM, storage, customers, traffic, bandwidth, rack units or machines ready for delivery.

The exact route sets reinforce that point. The AS209588 announced-prefix data shows 141.98.82.0/24, 141.98.83.0/24, 179.60.145.0/24, 92.51.2.0/24 and 2a10:9100:9::/48. The AS48721 data shows 194.165.16.0/24, 194.165.17.0/24 and 2a10:9100:3::/48. The AS267784 data shows 45.227.252.0/24, 45.227.254.0/24, 193.57.40.0/24, 2803:5120:c000::/36 and 2a10:9100:5::/48.

These are operating signals because route collectors could see the prefixes at a dated observation point. They are not proof that every address accepted traffic, that every customer service was healthy or that the hardware behind any prefix was in stock. RIPE NCC’s routing-status methodology is explicit that the result is the BGP state observed by RIS collectors. It measures public control-plane visibility. It does not inspect a hypervisor, storage array, generator, ticket queue or customer application.

The inactive AS211794 is equally instructive. Its registration proves that the number is assigned to Flyservers. Zero announcements in the dated snapshot means the collectors did not see it originate a route then. It would be wrong to count it as operational IPv6 capacity, but also wrong to declare it abandoned or unusable forever. It may be reserved, held for a design that is not currently announced, or used in a way not visible to the queried collectors. “Allocated” and “operational” are different states.

The carrier layer changes from prefix to prefix

Public AS paths show that Flyservers does not rely on one adjacent network across every visible prefix. That is useful. It still does not prove physical diversity, spare bandwidth or successful failover.

For AS209588, the RIPEstat neighbour observation identified four left-side neighbours: AS12302, AS39798, AS47890 and AS50867. The more detailed BGP-state snapshot separated them by prefix. 141.98.82.0/24 was seen through AS39798 in all 380 collected paths for that route. 141.98.83.0/24 was split between AS47890 and AS12302. Both 179.60.145.0/24 and 92.51.2.0/24 were seen immediately behind AS50867, while the IPv6 /48 was seen behind AS12302.

For AS48721, the neighbour dataset showed only AS9002. The BGP-state data placed AS9002 immediately before AS48721 for both IPv4 /24s and the IPv6 /48 across the collected paths.

For AS267784, the neighbour observation found AS174, AS6939 and AS49453. Its BGP-state snapshot again divided them cleanly by route: AS174 preceded 45.227.252.0/24 and 2803:5120:c000::/36; AS6939 preceded 45.227.254.0/24 and 2a10:9100:5::/48; AS49453 preceded 193.57.40.0/24.

That is a portfolio of logical dependencies, not one uniformly multi-homed service. A customer placed behind an AS48721 address does not gain AS209588’s four observed neighbours. A workload using 141.98.82.0/24 does not automatically fail over to the carrier observed for 179.60.145.0/24. Even within one ASN, separate prefixes can follow separate commercial, routing and physical arrangements.

Nor do four adjacent ASNs necessarily mean four independent fibre entrances. Two carriers can terminate in the same meet-me room, ride the same metro duct, depend on the same building power, or reach the customer through one cross-connect provider. A single router can hold several BGP sessions. A single colocation dispute can disable diverse routes at once. Conversely, one visible upstream ASN can deliver genuinely diverse protected circuits. BGP alone does not settle either case.

The RIPEstat BGP-state documentation says its AS paths are observed routes, with the last element representing the origin. The neighbour methodology describes the counts as combinations seen in RIS paths and warns that an AS can have more neighbours than collectors observe. Path counts are not traffic shares. An upstream seen 380 times does not represent 380 circuits or 380 units of capacity. It represents visibility from collectors and peers.

Route-origin security also needs its own category. The four AS209588 IPv4 routes were RPKI valid in the checked records, including the validation for 141.98.82.0/24. The three AS267784 IPv4 routes and its /36 were also valid, including the record for 45.227.252.0/24. By contrast, AS48721’s routes returned an unknown state, as the 194.165.16.0/24 result illustrates. A valid route-origin authorisation helps receiving networks reject an unauthorised origin. It does not keep a server powered, preserve a disk, reserve transit headroom or shorten a repair window.

Measurements point toward Europe, but they still do not name a facility

The registered country and the likely operating location of an IP address are not the same field. IPinfo states this directly on its AS209588 page: Panama is the country in which the resource holder is legally based and may not be where the addresses are used. Its June 2026 probes measured selected AS209588 endpoints at sub-millisecond or low-millisecond distance from Moscow, Iasi and Timisoara, with an IPv6 response measured from Bucharest. The AS48721 page recorded endpoints responding at about a quarter of a millisecond from Vilnius and an IPv6 endpoint at 4.71 milliseconds from Siauliai. The AS267784 page showed measured endpoints close to Vilnius, Amsterdam and Budapest, and classified that network’s observed geography as multinational rather than active in its registered country.

These observations are strong enough to challenge a naive “Panama address equals Panama server” assumption. They are not strong enough to place a rack. A low round-trip time from Vilnius suggests that the responding interface is topologically close to the probe and probably not in Panama, but it does not identify the building, equipment owner, storage location or customer workload. Anycast, remote interfaces, tunnelling, filtering and measurement selection can complicate interpretation. IP geolocation databases can also disagree or lag.

The right map therefore has uncertainty symbols rather than precise facility pins. It can show a verified legal address in Panama City. It can show RIPE’s seven service-area country codes as commercial or administrative scope. It can show measured proximity to several European cities as an operational clue. It can show logical adjacent networks by prefix. It cannot draw Flyservers fibre routes between those places, mark a Flyservers data centre in any of them, or infer that backups sit beside the measured interfaces.

One further boundary appears in the public control plane. The flyservers.com portal currently resolves to 45.227.255.30, and the public prefix record for 45.227.255.0/24 places that address in a prefix announced by AS43350 rather than any of the three active Flyservers origin ASNs. The record also identifies the address block’s registrant separately from Flyservers. This means access to the sales, login and support interface has at least one routing dependency outside the Flyservers-originated customer prefix estate. It does not prove a direct contract, a particular host or a shared failure domain. It does show why the website, billing plane and hosted service should be tested as separate systems.

If the portal becomes unreachable, customer servers may continue working. If a customer prefix disappears, the portal may remain available. If credentials or billing access fail, the hardware may be powered but operationally inaccessible. Recovery planning should not collapse those outcomes into the single word “down”.

The separation also changes how emergency access should be designed. A customer whose only support credential, invoice history and recovery instructions sit behind the same web login has a control-plane concentration even if the production workload uses several carriers. The practical countermeasure is not to guess whether the portal and server share a building. It is to obtain an out-of-band escalation method, preserve current account and configuration records, define who can authorise remote hands, and test whether support can identify the affected rack or virtual host without the normal portal session.

Those are contractual and procedural safeguards around an unverified physical relationship.

Billing is part of the same chain. A payment dispute, automated suspension or expired card can interrupt management access without any failure in power or transit. A migration in progress may then become a race between data transfer and account state. The contract should distinguish failure response from ordinary billing enforcement, preserve a retrieval window, and specify whether a customer can receive a final image or data export while charges are disputed. Public routing data cannot reveal these terms, and a responsive server cannot prove that the customer still has the administrative authority needed to move it.

For that reason, service continuity should be tested in at least three planes: the data plane that carries application traffic, the management plane that controls the machine, and the commercial plane that governs payment, support and termination. A provider may be strong in one and brittle in another. The current evidence shows that Flyservers has an operating public network and portal surface. It does not show that all three planes fail independently or recover together.

Six server offers are marketed units, not a capacity inventory

The current storefront presents six dedicated-server configurations. At the low end, Dedi-1 lists an Intel E3-1230v6, 32 GB of DDR4 memory, two 240 GB SSDs, “100TB T2” and a price of $500 a month. At the high end, Dedi-6 lists an E5-1680v4, 128 GB of DDR4, four 1.2 TB SSDs, “100TB T1” and $2,000 a month. Between them are combinations of older Xeon processors, 32 or 64 GB of memory, SSD or SATA storage, and the same nominal 100 TB allowance.

The Dedi-1 configuration page makes the product selectable and exposes operating-system choices. It also labels $500 as a “3 Month Price”, whereas the category listing labels the same amount monthly. That mismatch may be a storefront configuration issue, a commercial term or a display artefact. Without completing an order or receiving a quotation, it should not be resolved by guesswork.

More importantly, “listed” is not the same as “installed”. A product page can exist while the matching server is awaiting procurement, held in reserve, already sold, being rebuilt or available only after a manual deployment. An “Order Now” button is evidence of commercial intent, not a live stock count. The public pages do not disclose how many machines of each configuration exist, how many are powered, how many are assigned, how many are held as compatible spares or how quickly another unit can be delivered after failure.

The storage descriptions are similarly bounded. “2 x 240GB SSD” tells a buyer that two devices are part of the advertised configuration. It does not state RAID level, controller design, hot-swap capability, endurance, spare media, encryption, monitoring or replacement time. Two disks can be mirrored, striped, independent or presented through another layer. Four disks can increase throughput, resilience, capacity or all three, depending on configuration. The storefront does not say.

“100TB T1” and “100TB T2” look like transfer allowances, but the public page does not define T1 or T2. They should not be translated into a port speed, carrier tier, service class or measured monthly delivery rate. One hundred terabytes over a billing period is a volume. It says nothing by itself about whether the port is 100 Mbps, 1 Gbps, 10 Gbps or shaped dynamically; whether traffic is symmetric; whether overage is possible; or what happens during congestion and failover.

This is where capacity language must be disciplined:

Designed capacity is what an architecture intends to support. No Flyservers facility, rack, power or transit design quantity was found.
Installed capacity is equipment physically present. The product catalogue does not reveal installed server counts or network ports.
Lit capacity is connected and activated transport or optical capacity. Public AS paths show reachability, not circuit rates or lit strands.
Powered capacity is equipment with usable energy and cooling. No power feed, UPS, generator, runtime or tested load was published.
Operational capacity is what is actually working at a dated moment. The storefront and broad BGP visibility support current normal-state operation, but only at a coarse level.
Sold capacity is the portion committed to customers. Customer count, assigned hardware and aggregate traffic commitments are not public.
Reserved capacity is what remains available for growth or recovery. Spare servers, disks, optics, ports, transit commits and technician time are not quantified.
Failure-usable capacity is what survives a defined fault. No public test states how many workloads or how much throughput remains after losing a rack, router, carrier, facility or management plane.

Adding the six server specifications to 2,304 IPv4 addresses and 13 routes would produce a number with no operational meaning. They use different units and refer to different layers. A credible capacity statement needs a date, an asset scope and a state: for example, “two powered but unsold servers of configuration Dedi-4 in Facility B” or “1 Gbps committed and 2 Gbps burstable on a physically separate secondary circuit”. Nothing comparable is public here.

The backup is a second service, even when one invoice hides it

The customer’s opening question contains two workloads: the live machine and the recovery copy. Treating a backup as an accessory to the primary server is the easiest way to buy two copies of the same failure.

No public Flyservers page reviewed for this article identifies an included backup, snapshot frequency, retention period, immutable copy, backup country, restore interface, recovery time objective or recovery point objective. The absence of those details on public pages does not prove that Flyservers offers no backup service. It means a buyer cannot assume one, and cannot assume that “two disks” or a provider-side snapshot is a geographically separate backup.

Location matters at several levels. A backup in the same rack may survive one disk failure but not a rack power event. A backup in another rack may survive a top-of-rack switch failure but not a building evacuation. A backup in another building may survive a local incident but still share the same metropolitan carrier corridor or administrative credentials. A backup in another provider can reduce one concentration but increase migration complexity, egress expense and restoration time. The customer needs the actual failure domain, not the marketing category.

Security practice points in the same direction. CISA’s ransomware guidance recommends offline, encrypted backups and regular tests of availability and integrity in a disaster-recovery scenario. It also notes that some system images do not install correctly on different hardware or platforms and encourages consideration of multi-cloud approaches to reduce lock-in. NIST’s contingency-planning guidance distinguishes restoration using alternate equipment from recovery at an alternate location. Both are useful reminders that “a backup exists” is not the same assertion as “a service can be restored elsewhere within the required time”.

For a Flyservers buyer, a defensible backup schedule would name at least the following: source volume; copy frequency; retention; encryption ownership; immutable or offline control; backup operator; facility and country; account and credential separation; export format; expected full-restore rate; compatible destination; and the last successful restore test. If the provider manages the backup, the contract should say whether the copy remains accessible during a billing dispute, account suspension, insolvency event or termination period.

The network evidence cannot answer those questions. Seeing a primary address through one carrier and a backup address through another would still not prove physical or administrative separation. Conversely, a backup whose address is never publicly routed could be well protected. Backup quality is established by architecture, contract and test results, not by an ASN count.

The legal map follows the data, the contract and the equipment

Flyservers’ Panamanian identity matters. Panama’s Law 81 of 2019 establishes the country’s general personal-data protection framework, and Executive Decree 285 of 2021 regulates it. Panama’s data-protection authority explains in its public guidance that people must be informed when their data is obtained through a legal transfer or assignment so they can exercise their rights.

But corporate domicile does not by itself answer which law applies to a customer’s data, which authority can reach the equipment, or which transfer mechanism is required. Those questions depend on the customer, data subjects, processing roles, facility country, backup country, subprocessors and contract. A server sold by a Panamanian company but physically operated in Europe presents a different legal and latency profile from one physically operated in Panama, even if both use a Flyservers address.

The RIPE page’s service areas make the European layer commercially relevant. The European Commission’s guidance on transfers outside the European Economic Area explains that GDPR protection travels with personal data and that transfers to a third country without an adequacy decision generally need an appropriate mechanism, such as standard contractual clauses, binding corporate rules or another valid safeguard. Whether a particular Flyservers arrangement constitutes a transfer, and which party is controller or processor, requires facts the storefront does not provide.

Cloud exit rights add another contractual layer. The EU Data Act has applied since 12 September 2025; the European Commission summarises it as enabling cloud users to switch providers or use several providers in parallel. The underlying regulation requires covered data-processing service contracts to address switching and exportable data, includes a standard maximum transition period of 30 calendar days subject to a technically justified extension, and phases out switching charges by 12 January 2027. Scope, timing and customer rights depend on the service and contract; the rules do not magically make an undocumented image format portable or create spare hardware at the destination.

This is why a buyer needs a data-location schedule and an exit schedule before deploying. The first should identify primary and backup countries, facility operators and subprocessors. The second should specify exportable data, machine-image format, volume format, configuration data, credentials, network settings, logs, database-consistency steps, egress rate, fees, support and deletion evidence. If either schedule is missing, the buyer is financing uncertainty that becomes expensive precisely when bargaining power is lowest.

Migration cost starts with bytes, but it ends with compatibility and control

Moving a hosted service is not one file copy. A virtual machine includes disks, memory state or shutdown state, boot assumptions, network identity, firewall policy, DNS, certificates, secrets, monitoring, scheduled jobs, database consistency and dependencies outside the machine. A dedicated server can add hardware-specific drivers, storage layouts, licensed software and an IP reputation that does not travel.

NIST’s example for migrating a fully stopped virtual machine between cloud providers assumes that the root storage entity can be copied and that provider-specific configuration translations can be supplied. Its failure handling is blunt: if the destination cannot be used, choose another provider. The example is intentionally simple, but it exposes the real prerequisites—an exportable image, a compatible destination and enough time and bandwidth to transfer it.

Flyservers’ 100 TB allowance does not tell a customer the rate at which 20 TB of storage can be exported. At a sustained 1 Gbps, moving 20 TB takes roughly 44 hours before protocol overhead, throttling, retransmission, checksum validation or database synchronisation. At 100 Mbps, it takes roughly 18.5 days. If the provider permits only in-band transfer from a degraded host, if the surviving carrier is congested, or if a failed disk must first be rebuilt, the calendar stretches. If the backup is in the same failed facility, the transfer may not begin at all.

Live migration adds still more conditions. Source and destination hypervisors must be compatible enough; storage state must converge; the workload’s rate of change must remain below the effective copy rate; network identity must move or be translated; and the customer must tolerate a final cutover. A support engineer can coordinate these steps, but cannot compensate for missing egress, an inaccessible rack or a backup image that has never been restored.

Migration economics therefore include at least five reserves:

Data reserve: a recent, consistent copy outside the primary failure domain.
Bandwidth reserve: export capacity that is not already consumed by production traffic.
Compute reserve: a compatible destination that can be powered and assigned before cutover.
Address and configuration reserve: a plan for DNS, IP allowlists, certificates, routing and secrets.
Labour reserve: people with authority and time to execute the move while the original service is impaired.

None can be inferred from the number of announced prefixes. Multiple carrier adjacencies may create useful reachability options, but only if the affected workload can use them and the surviving path has enough capacity. Six listed server products may create hardware choices, but only if an appropriate unit is installed, unsold, powered and available at the right site. The distinction between nominal portfolio and failure-usable reserve is the heart of hosting resilience.

What a failure would actually test

Consider a customer running a virtual machine or dedicated server on an address originated by AS48721. The dated routing snapshot showed one observed adjacent ASN, AS9002, across its three routes. That does not prove one physical circuit, but it does define a question: what happens to those prefixes when the AS9002 path, the entity router or the delivery facility fails? The customer needs the alternate announcement policy, physical handoff, convergence test and survivor bandwidth.

The existence of other Flyservers ASNs does not answer automatically because an address cannot simply jump to a different origin without prior routing, filtering and operational arrangements.

Now consider a workload in AS209588. Four adjacent networks were visible across the ASN, but each route used a subset. A failure affecting AS50867 could matter directly to the two prefixes observed behind it while leaving another prefix visible through AS39798. That is useful partitioning if customer placement, storage replication and management access are designed around it. It is irrelevant if the primary and backup share the same rack, router, power domain or support bottleneck.

AS267784 shows an even cleaner split: one pair of routes behind AS174, another pair behind AS6939 and one IPv4 route behind AS49453. This may reflect geographically or commercially distinct deployments. It may also reflect address leasing, remote transit or separate customer environments. Without facility and contract evidence, the safest conclusion is that the prefixes have different logical dependencies. The difference should lead to a placement question, not a facility claim.

Failures also occur below BGP. A server may remain globally reachable while a storage device enters a degraded state. A hypervisor may be healthy while a customer’s virtual disk is corrupt. A rack may retain power while cooling fails. A carrier circuit may stay lit while billing or route policy withdraws a prefix. The support portal may work while remote-hands access is delayed. A backup may be intact while the account required to retrieve it is locked.

For each layer, the relevant measure changes:

Hardware failure: compatible spare count, replacement authority, remote-hands hours and rebuild time.
Rack or power failure: alternate power domain, UPS and generator runtime, tested transfer load and shutdown sequence.
Facility failure: second site, data recency, destination capacity and cross-site carrier independence.
Carrier failure: physical path separation, routing policy, convergence and remaining commit.
Routing-policy failure: prefix ownership, route authorisation, filters, escalation contacts and rollback.
Portal or billing failure: out-of-band support, emergency authentication and the right to keep service running during dispute resolution.
Provider-contract failure: retrieval period, export format, deletion timing, IP renumbering and access to backups.
Labour failure: on-call coverage, language, authority, simultaneous incident load and access to spares.

The public evidence supports normal-state operation but no quantified answer in any of those failed states. There is no published customer count behind a rack or prefix, so a blast radius cannot be calculated. There is no traffic series or carrier commit, so survivor throughput cannot be calculated. There is no spare inventory, so hardware recovery capacity cannot be calculated. There is no incident history in the public announcements section and no public status history accessible without login, so observed restoration performance cannot be calculated.

That is not a claim that Flyservers cannot recover. It is a claim that recovery is a private contractual and operational fact rather than a public, independently measurable capability. A serious buyer should obtain the missing facts and test the parts that matter.

A procurement test that matches the infrastructure

The most useful pre-purchase exercise is a one-page placement and exit matrix completed for the actual product, not the brand in general.

For the primary service, ask for the facility country and metro, facility operator, Flyservers’ role in the rack, server ownership, power arrangement, external port rate, traffic policy, IP prefix and origin ASN. Ask whether the quoted machine is already installed and powered, pending installation, available from stock or subject to procurement. If the hardware is shared or virtualised, ask for the hypervisor and storage failure domains.

For the backup, ask for the operator, site, country, credential boundary, encryption-key owner, schedule, retention, immutability, export format and most recent full restore. Make the supplier state explicitly whether the primary and backup share a building, campus, power system, carrier entrance, administrative account or support team. A “different location” answer is incomplete without the common dependencies.

For the network, ask which of Flyservers’ ASNs and prefixes the service will use. Request the physical carriers, handoff sites, port and commit rates, whether the circuits enter by separate routes and what throughput remains after the largest single failure. The public BGP record can then be used as a consistency check. It cannot replace the answer.

For operations, ask who can enter the facility at 03:00, who owns compatible disks and power supplies, what remote hands can do without further approval, and what happens during two simultaneous incidents. Repair windows are not a soft service detail. They convert installed hardware into usable service.

For law and exit, ask for the contracting entity, governing law, dispute forum, data-processing terms, subprocessor list, primary and backup countries, notification rules, retrieval period, switching support, fees, deletion evidence and access during suspension or insolvency. If the customer relies on EU data-transfer or switching rights, confirm applicability with counsel rather than assuming that a service-area code or company address settles it.

Finally, run a small restore and export before production data becomes large. Measure image creation, download rate, checksum verification, destination boot, DNS change and application validation. A 50 GB test will not predict every 20 TB migration, but it exposes missing formats, permissions and support paths while the customer still has leverage.

The useful conclusion is not a location guess

Flyservers is not invisible. It has a current storefront, a long-held domain, registry records in two regional systems and three autonomous systems carrying broadly visible routes on the research date. Its prefixes reach the internet through a varied set of adjacent networks, and external measurements strongly suggest that at least some responding infrastructure is close to European probes rather than Panama.

None of that locates a customer’s machine or backup with facility precision. It does not show who owns the rack, how many servers are installed, what is sold, what is reserved, how much carrier or power capacity survives a failure, or how fast a customer can retrieve data when the relationship ends. The Panamanian company is the visible legal centre; the physical and contractual centres remain product-specific unknowns.

That gap is commercially important because latency, jurisdiction, migration cost and outage recovery are not attributes of a corporate address. Latency follows the actual path to the actual machine. Jurisdiction follows entities, data, equipment and contractual roles. Migration cost follows bytes, compatibility, egress and labour. Recovery follows separate power, facilities, carriers, credentials, stock and people.

The customer’s opening question therefore remains the right one. Flyservers can answer it privately with a facility schedule, a carrier schedule, a backup design and an exit test. Until those answers exist, 13 announced prefixes are evidence of an operating network estate—not evidence that a particular virtual machine and its backup are in the right places when the rain, power, carrier or contract fails.