TEAMFELNULL’s 25 Gbps Tokyo testbed is visible; its hosted capacity is not

Summary

• TEAMFELNULL’s clearest current infrastructure fact is an operational 25 Gbps connection for AS58790 at INIXP in Tokyo; that is network-edge capacity, not proof of 25 Gbps of customer traffic, server inventory, storage, or saleable cloud capacity.
• Four Tokyo facility listings make the testbed physically plausible, but they do not establish four independent racks, four powered deployments, separate failure domains, or any right to the resilience advertised by the underlying data-centre operators.
• The public service surface is a community of game servers, software projects and a Discord bot, while commercial terms, support guarantees, backups, restore targets, billing protections and hosted-data export remain undocumented; users should treat the environment as an educational testbed unless private evidence proves more.

A 25 Gbps port, four facility names and one important silence

The strongest number attached to TEAMFELNULL is 25 Gbps. It appears in the current PeeringDB record for AS58790, where “SERVER-G TestBed TeamFelNull” is shown with an operational connection to Japan Community IX, or INIXP. The exchange’s own PeeringDB page repeats the 25 Gbps entry beside AS58790, with one IPv4 and one IPv6 exchange address. An Internet Society Pulse view of the same exchange membership characterises the network as educational or research and likewise reports a 25 Gbps port. Those records are unusually concrete for such a small public footprint.

They are also easy to misread. A port speed is the nominal rate of an exchange attachment. It is not a measurement of sustained traffic, an available customer commit, or the throughput of the machines behind the router. It says nothing about how many physical servers are installed, how much storage is healthy, how much rack power has been reserved, or whether any host can accept another virtual machine. PeeringDB explicitly leaves AS58790’s traffic level, traffic ratio and geographic scope undisclosed. It reports address-family and interconnection facts, but no sold load, utilisation curve or service-level commitment.

The same profile lists four facilities, all in Tokyo: AT TOKYO CC1/CC2, Equinix TY8, NTT DATA Otemachi Building and Otemachi Place West Tower. That creates a compelling outline of a metropolitan network. Yet it remains an outline. A facility listing in an interconnection database may reflect a physical port, a cross-connect, access through another party, or a remotely delivered service. It does not, by itself, reveal a TEAMFELNULL-owned server, a leased full rack, a power circuit, or a storage replica at each place. The record does not publish port identifiers, rack quantities, power draw, lease counterparties or server serials.

That distinction is the centre of the story. TEAMFELNULL has enough visible network evidence to show that AS58790 is not merely a name on an abandoned webpage. It does not have enough public operating evidence to support a conventional cloud-provider reading. A cloud customer buys the usable portion of a chain: compute, memory, storage, power, cooling, network paths, replacement hardware, support labour, billing continuity and a way to recover or migrate. The 25 Gbps figure describes just one link in that chain.

The silence is therefore more important than the headline number. No public page reviewed for this profile gives a current catalogue of VPS, bare-metal or managed-hosting plans under the TEAMFELNULL name. None states a guaranteed uptime, support response time, recovery point, recovery time, spare-parts policy, backup boundary, data-export format, maintenance notice period or compensation rule. That absence does not prove those arrangements do not exist privately. It means a prospective user cannot derive them from the public evidence and should not treat an exchange-port label as a substitute.

The name describes a testbed, not a conventional cloud vendor

AS58790’s public identity contains its most useful warning label: “TestBed.” PeeringDB classifies it as an educational/research network and places it under the SERVER-G Group organisation, with TeamFelNull as the alternate name. The public TeamFelNull homepage describes a community that runs seasonal modded Minecraft servers, plays games, develops modifications and adapts open-source software. It is an account of shared experimentation and enjoyment, not a sales pitch aimed at enterprises moving production workloads.

The wider group’s own language reinforces that reading. The SERVER-G group page says it provides environments for playing, learning and developing over the long term. It calls AS63800 the core network and describes TeamFelNull as a partner group receiving network and server resources for development, operations and play. That wording is important because it separates at least three things that can otherwise blur together: the umbrella group, the AS63800 backbone activity, and the TeamFelNull testbed associated with AS58790. Public records show affiliation and resource support; they do not disclose a contract that transfers ownership of racks, routers or servers to TeamFelNull.

SERVER-G’s AS63800 public history calls the backbone a non-profit network built to learn internet technology. Its chronology is frank about experimentation: obtaining address resources, finding upstreams, trying community exchanges, changing connectivity and building route-monitoring tools. The group’s about page says its main activity location is Tokyo and states purposes including connectivity, learning, construction and technical development. Those pages concern AS63800 and SERVER-G Group, not a separately documented corporate balance sheet for AS58790. They help explain the environment around TEAMFELNULL, but they do not prove that every AS63800 asset or policy belongs to the testbed.

This boundary matters whenever the word “group” is mistaken for a legal or operational guarantee. TEAMFELNULL’s public site uses “TeamFelNull” and “FelNull”; routing records use “TeamFelNull,” “SERVER-G Group” and “SERVER-G TestBed TeamFelNull.” The bot terms describe FelNull as an organisation. None of the reviewed pages identifies a conventional hosting company registration, a contracting legal name for infrastructure service, a billing address, or the party that would owe a customer service credits. It would be unsafe to infer those details from branding alone.

Even SERVER-G’s backbone description draws a line between community activity and limited commercial use. It says the network is student-led and basically non-profit, cites financial limits, and notes that some address use helps fund activities and operations. It also says those commercial addresses are not propagated or used from AS63800. That is evidence of a mixed economic context, not evidence that AS58790 offers a standard commercial hosting product. It makes contract-level clarification more necessary: who invoices, who owns hardware, whose network carries the service, and who remains accountable when one part fails?

A testbed can be technically competent and useful. It can provide real connectivity, host valued services and teach operators lessons that polished providers obscure. But its risk allocation is different. Informal support can be fast when volunteers are available and slow when study, work or life intervenes. Hardware may be bought opportunistically. Network paths can change as sponsorships or community relationships change. Users who understand that bargain may find it entirely appropriate. Users who assume enterprise continuity because they saw “25G” and four facility names would be buying a promise the public record does not make.

What TeamFelNull actually puts in front of users

The most visible services are specific and community-facing. TeamFelNull’s site presents seasonal Minecraft mod servers, software development and small public projects. Its Discord voice bot page advertises multiple instances of a text-to-speech bot, while its Reversi page offers a game activity for Discord. These are real user surfaces: people connect, submit content, expect state to persist for some period and notice when the service disappears. They are better evidence of an operating purpose than a generic claim of “cloud.”

The bot’s terms and privacy notice provide a rare view of the data boundary. They say user, server and channel identifiers may be stored to keep the service functioning; usernames, nicknames and messages may be collected to generate speech and retained only for the necessary period. The notice promises reasonable protective measures but disclaims complete security, allows the service or terms to change without notice, and disclaims liability for damages. Those provisions apply to that bot, not automatically to every server or network service, but they reveal the style of the only public user contract located here: broad operational discretion, limited assurance and no quantified restoration commitment.

The software side is documented more fully than the hosted side. A TeamFelNull launcher tutorial explains a customised game launcher and describes antivirus scanning during its build process. The SERVER-G documentation site focuses on that launcher, installation and game-instance handling. This shows a group capable of producing instructions for users. The contrast is telling: public guidance exists for client software, while equivalent pages for virtual-machine provisioning, storage durability, server backup, abuse handling, incident status and account termination are not visible.

A historical, unofficial Japan Minecraft Servers listing records a “TeamFelNull-24h-Server,” submitted in 2019, with a very low recorded uptime and a status saying it was down. That entry cannot establish the state of AS58790 in 2026. It may describe a different machine, address and operating period, and third-party probes can fail for many reasons. It is useful only as a market signal: the TeamFelNull name has been attached to a public game server, and at least one old endpoint did not remain continuously reachable. Current monitoring, an incident archive or an operator statement would be needed to connect that history to today’s testbed.

The public services also expose different dependency patterns. A game server needs compute, memory, storage, version-compatible software and a stable route; a voice bot additionally depends on Discord and speech engines outside TeamFelNull’s control. A launcher can remain usable on a person’s computer even if the community server goes away, but downloads, mod packs or authentication dependencies may not. Lumping all of this into “hosting” hides who controls which failure.

TEAMFELNULL may operate the application and some servers while SERVER-G or another party controls routing, a facility controls power, and external platforms control identity and distribution.

That is why “customer-facing capacity” should be interpreted narrowly here. There is evidence that resources are made available to users and partner communities. There is no public count of paying customers, active instances, managed servers, storage volumes or reserved cores. The correct operating picture is a set of community applications backed by an educational network, with an unquantified pool of physical and virtual resources. Any stronger statement needs a current inventory and the contracts that connect that inventory to the network identity.

Where the physical system may touch Tokyo

AS58790’s facility trail is entirely metropolitan. PeeringDB’s individual facility pages list the testbed at AT TOKYO CC1/CC2, Equinix TY8, NTT DATA Otemachi Building and Otemachi Place West Tower. These records corroborate the four names on the network profile, but their precision stops at presence. They do not show which building in a combined campus label is used, whether the attachment is physical or remotely extended, or whether compute is installed beside the network port.

The underlying facilities are substantial. AT TOKYO’s own account says CC1 has 140,000 square metres of total floor area and describes multiple power feeds, UPS, emergency generation and round-the-clock monitoring across its facilities. Equinix’s TY8 specification gives a Tokyo address, 40,418 square feet of space, N+1 power redundancy and N+20 per cent cooling redundancy. Equinix’s operational-coverage table says TY8 has 24/7 on-site coverage.

At Otemachi Place, BroadBand Tower’s New Otemachi site description advertises a standard 6 kVA of actual rack power, dual 200-volt 30-amp lines, N+1 generators capable of running for up to 72 hours without refuelling, multiple connectivity options and remote support. Its separate network services page offers design and operation support for routers, storage networks and cloud connections. Those are facility-operator capabilities available in the building. They do not show that TEAMFELNULL buys a full rack, two circuits, remote hands or any particular service from BroadBand Tower.

This is the ownership boundary in practical terms. The facility operator controls the building shell, utility intake, generators, cooling plant, access control and the conditions under which technicians reach a rack. A colocation customer controls only what it has contracted: perhaps a cabinet, a fractional rack, a cross-connect or a remotely delivered port. The network operator controls its router configuration and address announcements. The application group controls software and user state to the extent it has access.

A facility’s resilient design cannot compensate for a single power supply in a customer server, an unpaid cross-connect, a failed disk without a replacement, or an application database with no tested restore.

The geographic claim is therefore both stronger and narrower than “global.” The services may be reachable from around the world, and internet routes are global by nature. The physical evidence reviewed here points to Tokyo, Japan. It does not establish company-operated racks in Europe, North America, other Asian metros or even Osaka. Nor do four Tokyo names necessarily create protection against a metropolitan disaster, a common upstream failure or a single administrative mistake. Data locality for the visible infrastructure should be treated as Tokyo-centred until a current asset register proves otherwise.

For users, that locality has two consequences. First, latency will depend on distance to Tokyo and on the selected upstream path; the word “global” cannot erase physics. Second, the governing arrangements for physical access, power and any stored data are likely to be Japanese in practice, even if remote users connect from elsewhere. The public bot notice does not state where its database is hosted, and the facility listings do not tie a particular application to a particular building. A user who needs residency assurance would need written placement, replication and subcontractor details rather than a city inferred from routing records.

Why four facility records do not equal four independent sites

Redundancy begins with independence, not counting. Four facility names can represent four failure domains, but they can also represent one router reached through several interconnection fabrics, one service extended between buildings, dormant cross-connects, or records maintained for planned access. PeeringDB is a valuable industry database, yet network and facility entries are contributed by entities. The AS58790 record says its facility information was updated in February 2026, which supports recency; it still does not expose the underlying circuit orders or rack occupancy.

The geography itself invites caution. Two listings are in Otemachi, one is an AT TOKYO campus label covering CC1/CC2, and one is Equinix TY8 in Shinagawa. Otemachi Place’s PeeringDB entry notes an optical interconnection to NTT DATA Otemachi Building. That link can be operationally useful, but it also means two names in a database can be reachable through one physical extension rather than two separately powered TEAMFELNULL deployments. No exact route should be inferred from that possibility. The record establishes available interconnection between the buildings, not the path or topology of AS58790.

The INIXP connection adds another layer. The exchange is present at several Tokyo and Osaka facilities, but the AS58790 listing does not publish a port location on its network profile. A 25 Gbps exchange attachment could be delivered at one site and carried across a partner network or metro circuit. Without a letter of authorisation, cross-connect record, device-level diagram and circuit diversity statement, the physical handoff remains unknown. The two exchange addresses prove a logical attachment; they do not locate the switch port precisely enough to map a cable.

True multi-site compute resilience would require more evidence. At a minimum, a current inventory would show powered servers or storage in at least two sites; replication would have a known direction and lag; DNS or routing failover would have a tested trigger; users would know which services can restart elsewhere; and the recovery design would avoid a shared management plane. Nothing in the public pages states that the Minecraft environments, Discord bot data or development services are replicated between facilities. It is possible that they are. It is not demonstrated.

The same caution applies to upstream diversity. A router can hear multiple paths while all customer traffic still depends on one transport provider, one tunnel endpoint, one metro tail or one configuration authority. SERVER-G’s public history describes multiple relationships over time and the withdrawal from some overseas community exchanges in December 2024. Its peering policy explicitly allows GRE, SIT and WireGuard tunnels as well as connections at exchanges. Tunnels are legitimate tools for a testbed, but a logically separate BGP neighbour over the same underlying access circuit is not physical diversity.

A rigorous redundancy statement would identify the layer at which independence exists. Separate BGP sessions protect against a neighbour failure only if another usable path remains. Separate facility power feeds protect a rack only if the server has dual supplies connected correctly. Separate buildings protect applications only if current data exists in both and operators can redirect users. Separate support contacts protect recovery only if more than one person has credentials and physical access.

TEAMFELNULL’s public evidence confirms none of those end-to-end combinations, so four facility labels should be read as interconnection reach, not four-site service continuity.

Capacity: the only hard number is at the exchange edge

Capacity is not one number. It is a stack of limits, and the lowest active limit governs the service. The 25 Gbps exchange port is installed logical network capacity at one interconnection. PeeringDB labels the connection operational, which is stronger than a future plan. But usable throughput could be lower because of router forwarding limits, upstream policy, congestion, transport between a rack and the exchange, packet size, attacks or application bottlenecks. Sold capacity could be lower still—or nonexistent if the testbed is not selling bandwidth.

Address space is another kind of capacity. PeeringDB lists five IPv4 prefixes and 50 IPv6 prefixes for AS58790, while Cloudflare Radar’s AS overview identifies the network in Japan and exposes traffic views when sufficient observations exist. A separate Cloudflare routing view presents announced address space, connections, RPKI status and BGP activity. Prefix counts describe routing granularity, not servers. One /24 can number 256 IPv4 addresses, but an address may sit unused, identify a router, be assigned virtually, or serve many domains behind one host.

Third-party datasets illustrate why a date and definition must travel with every number. IPinfo’s AS58790 page currently lists two /24 blocks—44.30.37.0/24 and 44.30.62.0/24—along with several observed upstreams and a handful of addresses that responded to probes. A CIDR Report view also shows two /24 advertisements and 512 originated IPv4 addresses in its collector view. Those observations support current IPv4 routing, but neither tells us how many machines exist or whether a response came from customer compute.

Other aggregators conflict. A mirrored registration page reproduces the JPNIC AS name and a 2401:d20:1020::/44 IPv6 range but reports no IPv4 range. IP2Location’s AS page shows one /24 and an IPv6 /46, while IPGeolocation’s page reports zero routes despite reproducing the AS identity. These are not equivalent snapshots; collection dates, route visibility and classification methods differ. The contradiction is evidence about the limits of aggregator data, not a reason to average the numbers.

No public source reviewed states CPU cores, memory, bare-metal nodes, virtual machines, disk capacity, storage redundancy, reserved power, average power draw or free rack units. No source separates design capacity from installed, powered, operational and customer-usable capacity. Facility-wide figures cannot fill the gap. Equinix’s 40,418 square feet at TY8 belongs to the facility, not to AS58790. BroadBand Tower’s standard 6 kVA rack specification is an available product characteristic, not proof of a TEAMFELNULL rack or entitlement.

The economically meaningful capacity is what can survive a failure while honouring commitments. If a service needs 16 cores and 64 GB of memory, a spare host counts only if it is compatible, powered, connected and not already reserved. If storage is replicated, the second copy counts only if it is recent and independently recoverable. If 25 Gbps reaches an exchange but the server has a 1 Gbps interface, the application does not have 25 Gbps. Until TEAMFELNULL publishes or privately supplies those lower-layer figures, its saleable hosting capacity remains unknown.

The upstream story is real but not cleanly documented

AS58790 is visible as an origin, and several public views see routes reaching it. That is meaningful operating evidence. IPinfo lists Hurricane Electric, SDCC Japan-West Area and SERVER-G Group as upstreams or peers, while its June 2026 probe trace to 44.30.37.1 traversed Japanese networks before reaching AS58790. CIDR Report’s collector view showed AS38074 directly adjacent to AS58790 for the two visible /24s. Cloudflare’s routing page provides another live vantage. Together, these sources support reachability, but they do not agree on one stable provider graph.

There are several benign reasons. BGP is observed from particular collectors at particular times. A relationship that looks like an upstream from one path may be a peer, a route-server path or a service carried through another network. IPv4 and IPv6 can use different providers. A session can be configured but idle, selective or visible only from some locations. PeeringDB’s exchange record shows the INIXP attachment, but it marks AS58790 as not using the route server there. That means the presence alone does not reveal which bilateral sessions actually carry production traffic.

The wider SERVER-G history is informative but cannot simply be assigned to AS58790. It records AS63800 relationships with Vultr, Hurricane Electric, SDCC and other networks at various dates, along with later withdrawals and additions. The AS63800 peering policy requires global AS numbers, minimum prefix sizes, ROAs, IRR records and PeeringDB contacts; it also says that some instability is tolerated because the network is experimental. Those are stated policies for AS63800. They suggest the culture surrounding the testbed, not a binding uptime promise for AS58790.

The ownership question sits inside the routing question. PeeringDB places AS58790 under SERVER-G Group and uses felnull.dev as its website. The public group page says AS63800 is the core network and provides TeamFelNull with resources. It is therefore reasonable to see AS58790 as a TeamFelNull testbed supported by SERVER-G. It is not reasonable to assume that TeamFelNull owns each upstream contract, each cross-connect or the address resources it originates. A customer needs to know which party can renew, cancel or reconfigure each dependency.

Route diversity also has a control-plane component. If one person, one router configuration or one credential set controls every session, multiple upstreams do not protect against an erroneous route filter or accidental withdrawal. A route leak, invalid origin, expired route authorisation or overly broad filter can make healthy servers unreachable. The public views show that routing exists; they do not publish change control, out-of-band access, configuration backups, dual routers, automatic rollback or a 24-hour network operations rota.

What would settle the issue is specific and modest: current letters or invoices establishing active transit and transport; a topology showing which connections are physical, virtual or tunnelled; collector evidence for both address families; valid route-authorisation records; and a failover test demonstrating that traffic remains usable when the primary path is withdrawn. Until then, the upstream evidence deserves a medium confidence as a snapshot and a low confidence as a redundancy guarantee.

Power, hardware and hands are the hidden control surface

Network records tend to dominate because they are public. Most hosting failures, however, are resolved at a much less visible layer: someone finds the failed power supply, disk, memory module, optic, fan or cable and replaces it. TEAMFELNULL publishes no hardware inventory, lifecycle policy or stock of spares. A 25 Gbps port can remain perfectly healthy while a single application server is offline for want of one compatible component.

Facility resilience helps only up to the customer handoff. AT TOKYO advertises multiple feeds, UPS, generators and 24-hour monitoring. Equinix advertises N+1 power at TY8 and round-the-clock operational coverage. BroadBand Tower advertises dual rack feeds, N+1 generation and remote support at New Otemachi. Those controls reduce building-level risk for customers who buy and correctly use them. They do not reveal whether AS58790 equipment has dual power supplies, whether both feeds are contracted, whether remote support is authorised, or how quickly TeamFelNull can approve work.

Support labour is itself capacity. The TeamFelNull contact page directs enquiries to Discord. That can be convenient for a community, but it does not provide a public severity scale, response-time commitment, telephone escalation, named duty rota or alternative channel if Discord is unavailable. SERVER-G’s pages provide email or Discord paths for peering, yet there is no public incident desk specifically promising restoration for hosted services. When a machine fails at 03:00, the difference between “someone may notice” and “an authorised technician must respond within 30 minutes” is the service.

Hardware-stock failure is especially important for a small testbed. Large providers spread spare parts and staff across many servers; a community operator may have unique machines bought at different times. Without a compatibility list and stocked replacements, a failed motherboard can turn a routine swap into procurement, travel and rebuilding. No public evidence says whether servers use mirrored boot drives, hot-swap storage, out-of-band management, dual network interfaces or standardised images. It would be wrong to assume either robust enterprise design or improvised hardware.

Billing and provider contracts can create the same outage without any broken equipment. A late colocation payment, expired sponsored resource, cancelled transport agreement, domain renewal problem or changed facility access list can disconnect a healthy service. SERVER-G’s statement about financial limits makes this dependency worth examining, but it does not prove any current distress. Evidence would require current contracts, renewal dates, responsible parties and a reserve or succession plan. In their absence, financial continuity is simply unknown.

Users are affected differently. A player may lose access to a seasonal world; a developer may lose a build service; a Discord community may lose voice output; a sponsored project may lose an address or route. The cost may be inconvenience rather than revenue, but data loss can still be personal and irreversible. The right resilience standard should follow the promised use. A test world can tolerate downtime if users are told; a database collecting identifiers or a long-lived community world needs backup, retention and restoration rules even when no money changes hands.

Failure begins with ambiguity before it reaches the rack

The first failure path is not necessarily technical. It is ambiguity about what was promised. If users hear “server resources” and see data-centre names, they may assume backups, spare hosts and managed recovery. If operators mean best-effort access for play and learning, both sides can behave reasonably and still collide after an outage. The fastest risk reduction is a plain service description that says what is hosted, who operates it, what is best effort, what is backed up and what users must copy themselves.

At the rack, the sequence is familiar. A power feed or power supply fails; a switch port, optic or network card drops; a disk or controller corrupts state; cooling protection shuts hardware down; or scheduled work requires a restart. Facility monitoring may identify environmental alarms, but application recovery remains with the customer unless managed services were purchased. None of the public pages ties TEAMFELNULL to a particular remote-support package, spare-parts store or maintenance window.

At the network layer, an exchange port, metro circuit, tunnel endpoint, upstream session or route announcement can fail. The four facility entries do not reveal whether those elements are diverse. A 25 Gbps INIXP port is a useful path, but the exchange describes itself as best effort with no disclosed service terms on its public listing. Bilateral peering at an exchange is not the same as full internet transit, and an exchange connection cannot reach every destination without suitable peers or an upstream. A user-facing service can therefore fail for some networks while remaining reachable from others.

At the application layer, updates create their own repair windows. TeamFelNull works with modded Minecraft and customised launchers, where server and client versions must align. A failed update can strand users even when routing and hardware are healthy. The launcher documentation shows attention to installation and migration, but there is no public schedule for server maintenance, rollback, database compatibility or retention of older worlds. Application state is often the hardest part to reconstruct because a new machine cannot recreate the lost history.

External platforms add correlated dependencies. The voice bot relies on Discord for identity, events and user access, and it may rely on one or more speech engines. An outage or policy change at those services can make the bot unavailable without any fault in AS58790. Contact also relies on Discord, so the service and its primary public support channel can fail together. A status page on an independently hosted domain, plus email escalation, would separate those paths.

The affected population is not quantified. The homepage invites a community; the bot page shows multiple bot instances; the old game listing records a public endpoint. None gives current active users, peak sessions or the number of dependent projects. That prevents a numerical impact estimate. The qualitative impact is clear: community access, stored identifiers, game state, software distribution and sponsored resources can all be interrupted. A truthful incident plan would name these classes without claiming a customer count that has not been disclosed.

Recovery and portability stop at the application boundary

Recovery has two separate questions: can the operator restore the service, and can the user leave? The public record answers neither for hosted compute. There is no published backup frequency, retention period, off-site copy, restoration test, recovery point or recovery time for TeamFelNull servers. There is also no documented export for a virtual machine, database, game world, account record or hosted volume. A user cannot tell whether a failed disk means minutes of rollback, days of reconstruction or permanent loss.

There is a narrow, useful exception on the client side. The launcher documentation provides an instance export procedure that creates a ZIP from selected local files, and a separate launcher migration guide explains how to copy local instance folders between versions. These instructions improve portability for a player’s client environment. They do not export server-side worlds, bot databases, credentials, DNS, IP addresses or virtual machines.

That boundary is easy to miss. A player may preserve mods and configuration yet still lose the shared world. A bot administrator may retain a Discord community yet lose stored preferences. A developer may keep source code but lose build artefacts or deployment secrets. A network user may keep an application image but be unable to retain addresses if resource rights belong to another party. Each layer needs its own export and restore method.

Multi-site recovery is equally unproven. The facility list offers plausible places from which resilience could be built, but no public evidence maps a service to two live sites or reports replication lag. Even if a second machine exists, successful failover requires current data, secrets, routing, DNS, capacity and authorised people. A cold spare without a tested restore may take longer than repairing the primary. A hot replica sharing the same administrative account may fail during compromise.

Support escalation should be part of the recovery design, not an afterthought. Discord-only contact may work during ordinary community use, but a severe event needs an independent path, a responsible person, facility authorisation and a decision rule for spending money on parts or transport. Succession also matters: more than one trusted operator should be able to renew domains, access routers, contact facilities and decrypt backups. No public page establishes that coverage, so it remains a question rather than an accusation.

The minimum credible portability package would be simple: a list of user-owned data; export formats; backup and retention boundaries; deletion timing; notice before planned closure; a procedure for obtaining the latest copy; and a test showing the copy can be restored elsewhere. For game services, that may be a world archive plus version manifest. For a bot, it may be a structured settings export and deletion confirmation. For a virtual server, it may be a standard disk image and configuration record. Without those commitments, users should keep their own copies wherever technically possible.

Data locality is Tokyo-centred, but application data remains unmapped.

The routing and facility evidence points to Japan, especially Tokyo. AS58790 is registered with a Japanese identity in routing datasets, the listed interconnection facilities are in Tokyo, and the observed IPv4 addresses are generally geolocated to Japan. That supports a Tokyo-centred physical assessment. It does not prove that every byte of application data stays in Tokyo, because software dependencies, backups, content delivery and third-party services can cross borders.

The bot is the clearest example. Its terms say that identifiers can be stored and messages can be processed for speech generation, but they do not name a hosting location, database provider, speech provider or backup jurisdiction. Discord itself is an external platform. The facility presence of AS58790 cannot answer where Discord stores data or where a speech request is processed. A data-residency claim would require application-level documentation, not merely an autonomous-system country code.

Game and development services have similar uncertainty. A server process may run on a Tokyo machine while mod downloads come from another platform, source code sits on a global repository and backups—if any—sit elsewhere. Conversely, an address originated by AS58790 could reach equipment delivered remotely through another network. IP geolocation is an estimate, not proof of a rack. IPinfo explicitly cautions that registered or inferred location does not always equal actual use, and the disagreement among routing aggregators shows how quickly classifications drift.

This matters even for a community service. Users may care about legal access, deletion, breach response or simply the latency of a faraway dependency. The public privacy notice gives broad categories of collected data and a necessary-retention concept, but not a fixed retention duration or location. It also allows changes without prior notice. Those terms may be proportionate to a free bot, yet they do not meet a buyer’s need for contracted sovereignty or locality.

The “Global” service-area label should therefore be read as reach, not footprint. A website, game server or Discord bot can serve people internationally from Tokyo. That does not make TEAMFELNULL a multi-region provider. The physical record supports one metropolitan cluster; the application record does not map data flows. Any organisation with residency requirements should ask for a service-specific data map naming the primary host, replicas, backups, external processors and deletion path.

There is also a resilience trade-off. Keeping all copies in Tokyo may simplify locality but expose them to a metro-wide disruption. Replicating abroad may improve disaster recovery but change jurisdiction and latency. Neither choice is inherently correct. The problem is that the current public evidence does not reveal the choice. A trustworthy answer would state where each copy resides, why, how often it is updated and who can retrieve it.

What customers should demand—and the due-diligence verdict

The first request should be an asset-and-service schedule, not a glossy network map. It should identify the contracting party, the service being offered, whether payment is involved, and the exact resource: cores, memory, storage, address space, bandwidth and support. It should distinguish dedicated from shared resources and state which quantities are installed, powered, operational, reserved and still available. A nominal 25 Gbps exchange port belongs in the schedule, but only as an interconnection component.

The second request should map responsibility. Which organisation owns or leases each server? Which one holds the facility account, transport circuit and upstream agreement? Who controls AS58790’s routers, DNS, application credentials and billing? Which facility can accept a support request from which named person? The SERVER-G and TeamFelNull affiliation is visible, but the handoffs are not. A one-page responsibility table would remove much of the current uncertainty.

The third request should be an evidence-backed topology. It should show facilities at city-level precision, avoid exposing sensitive rack details, and mark physical circuits, virtual circuits and tunnels differently. It should identify shared metro tails and management dependencies, plus the site that hosts each critical service. A failover test should then demonstrate what happens when one upstream, exchange port, router, server or site is removed. Marketing presence alone is not a test result.

The fourth request should cover power and repair. Users need to know whether servers have dual supplies, whether both facility feeds are used, whether spares are on hand, and whether remote support is contracted. The document should include maintenance notice, severity levels, response targets and an independent escalation channel. Best-effort support can be acceptable if it is stated plainly; the risk comes from leaving users to infer enterprise coverage from the facility operators’ capabilities.

The fifth request should cover data. It should state backup frequency, retention, encryption, restoration testing, user export, deletion and what is excluded. It should name external platforms and the locality of primary and backup copies. For long-lived game worlds or community databases, the operator should provide a recent export before planned closure. For experimental services, the simplest honest rule may be “no backup; keep your own copy,” provided users can actually do so.

Finally, the user should ask for current operating proof rather than historical branding. Useful items include a recent status history, dated route observations, an inventory attestation, a sample incident notice and a successful restore record. None needs to disclose secrets. Together they would show that capacity exists below the exchange port and that recovery is more than an intention. If those items are unavailable, the rational classification remains educational testbed, and workloads should be chosen accordingly.

The verdict: useful testbed, unproven hosting platform.

TEAMFELNULL SERVER-G Group has more substance than its sparse company footprint initially suggests. AS58790 has a current PeeringDB identity, an operational 25 Gbps INIXP attachment, recent facility updates and globally visible routes. TeamFelNull maintains public projects, user terms and documentation. SERVER-G describes a continuing educational network and openly acknowledges its student-led, mostly non-profit character and financial limits. These are signs of activity, not an empty registration.

The evidence still falls short at the point where a hosted service becomes dependable. Four facility listings do not prove four deployments. A 25 Gbps port does not prove server throughput or spare capacity. Address announcements do not count machines. Facility resilience does not pass automatically through an unknown rack design. Multiple observed upstreams do not prove physically diverse transport. Client-side game exports do not protect server-side data. Discord contact does not create a response guarantee.

The appropriate network evidence grade is weak, not negative. “Negative” would ignore the live exchange connection, routes and public services. “Medium” would imply that the operating chain is sufficiently described to assess capacity and recovery. It is not. The strongest evidence sits at the logical edge; the weakest sits where users bear loss: hardware inventory, power entitlement, storage durability, support labour, contracts, backups and migration.

For hobby, learning and explicitly best-effort community use, that may be a perfectly sensible bargain. Small testbeds create space to learn BGP, run specialised games and build tools without the economics of a commercial cloud. Their value should not be measured only by enterprise paperwork. The essential condition is informed consent: users should know that experimental infrastructure can change, that support may depend on a small team, and that they need their own recoverable copies.

For paid or consequential workloads, private verification is necessary before reliance. The operator would need to show the resource allocation, legal counterparty, active facility and upstream arrangements, multi-site or restore design, and data-portability terms. A buyer should test recovery, not merely connectivity. If those proofs exist, the public assessment can be upgraded. Until then, TEAMFELNULL is best understood as a Tokyo-centred educational network with real community services and an impressive exchange edge—not as a documented multi-site cloud.

That conclusion respects both sides of the evidence. It does not turn missing disclosure into a claim of failure, and it does not turn a well-connected router into a rack of resilient compute. The visible 25 Gbps port is the beginning of the capacity question. For TEAMFELNULL’s users, the decisive facts remain behind it: which machines are powered, which data can be restored, which path survives, and who will act when the repair window opens.