Summary

  • NEXUSLINK DATACENTER LTDA can be joined across CNPJ 50.203.572/0001-46, a nationwide Brazilian telecom authorization, Registro.br's assignment of AS274464, the Nexus Link website and a Rio de Janeiro facility record.
  • Its network footprint is unusually legible for a young provider: public records list operational connections at five IX.br locations and DE-CIX Rio, plus interconnection presence at six Brazilian facilities. Those records demonstrate reach, not the path, capacity or resilience of any customer's service.
  • The company describes colocation, dedicated links, ISP connectivity, DDoS protection, international transit and a facility following Tier III standards. The reviewed evidence does not identify a certification, publish an SLA measurement method, or show tested power, cooling, failover and recovery outcomes.
  • Technical support and a NOC are presented as available around the clock, but public pages do not define severity, acknowledgement, restoration, update, remote-hands or escalation commitments. Those are the labour terms that must make the network usable during an incident.

The legal name and the network identity join cleanly

Infrastructure procurement often starts with a brand, a website and a list of capabilities that do not clearly resolve to the same operator. NexusLink gives buyers a stronger identity chain than that. Casa dos Dados, drawing on Brazilian federal company data, lists NEXUSLINK DATACENTER LTDA as an active limited company opened on April 4, 2023, in Rio de Janeiro. It identifies CNPJ 50.203.572/0001-46 and gives multimedia communication services as the principal activity, alongside transport-network, internet-access, software and technical-support activities.

The official check is more important. In Brazil's Federal Official Gazette, Anatel Act No. 4,925 names the same legal company and CNPJ and grants indefinite authorization to provide collective-interest and restricted-interest telecommunications services throughout Brazil. That establishes regulatory permission. It does not say that a particular circuit is installed, a facility meets a design standard, or a customer received the advertised service level.

The network identity is equally direct. Registro.br's RDAP record for AS274464 names NEXUSLINK DATACENTER LTDA as registrant, uses the CNPJ as the organisation handle and records the autonomous-system registration on July 3, 2025. The company website publishes the same Inhauma street address that appears in the company record and presents the public brand as Nexus Link Datacenter. The BTW directory entry supplies a public directory reference and classifies five service areas as not yet assessed. Together, these sources make mistaken identity unlikely while preserving the distinction between identity and service assurance.

The contract should retain that clean join. The legal entity, CNPJ, AS number, facility, circuit identifiers, billing party, incident contacts and data-processing party should all appear in the order documents. If an affiliate, carrier or facility operator performs part of the work, the responsibility split should be named rather than hidden behind the Nexus Link brand.

The public network record is substantive, but mostly operator supplied

NexusLink's PeeringDB network record identifies AS274464, the route set AS-NEXUSLINKDATACENTER-274464-ALL, IPv4 and IPv6 support, regional scope and self-reported traffic in the 200-300 Gbps band. It also links a looking glass and a NOC contact. These are useful signs of an operator prepared to be examined through internet-routing conventions rather than only through sales copy.

The same record lists six operational exchange connections: IX.br in Sao Paulo, Porto Alegre, Salvador, Curitiba and Brasilia, plus DE-CIX Rio de Janeiro. Its facility list spans Equinix RJ2 and Elea RJO1 in Rio, BR.Digital sites in Sao Paulo, Porto Alegre and Salvador, and its own NEXUS RJ01 entry. DE-CIX independently reported in October 2025 that Nexuslink Datacenter was among the first ten networks connected when its Rio exchange went live. That outside confirmation strengthens one part of the self-published footprint.

There are useful tensions inside the record. PeeringDB's structured field calls the general peering policy open, while NexusLink's notes call it selective and require prospective peers to meet capacity, NOC, public-prefix, IRR and RPKI conditions. A buyer or peer should ask which statement governs and when. The 200-300 Gbps band is also a declared traffic level, not a utilization graph or committed customer capacity. Exchange ports and facility listings may be reached directly or through transport; they do not prove that the customer receives six independent paths.

The advertised looking glass could not be exercised during this review, so it supplied no live route evidence. That may be a temporary access problem rather than an operating fault. It still illustrates why a link is not the same as an observable service. During diligence, NexusLink should demonstrate the tool, route advertisements, communities, filtering and failover from a customer-relevant path.

Exchange reach must be translated into a customer topology

NexusLink's IX.br service page says it offers direct access to major Brazilian traffic-exchange points, while its ISP offer adds high-capacity IP transit, DDoS mitigation and colocation. Its international-transit page describes multiple international backbones and optimized routes to overseas destinations. The public network records make those claims more plausible than a generic connectivity catalogue.

They do not reveal the customer topology. A connection at an exchange says that the autonomous system can exchange traffic there. It does not identify the port assigned to a customer, the transport between cities, shared chassis, upstream contracts, oversubscription, congestion thresholds, DDoS scrubbing location or the failure domain behind two nominally separate routes. Presence at a facility likewise does not prove that NexusLink stores customer equipment or data there.

For a serious link or hosting purchase, the provider should disclose a service-specific diagram. It should show the customer handoff, access fibre, building entries, routers, exchange ports, upstreams, route-security controls, DDoS path and every component whose failure can interrupt service. The diagram should distinguish owned infrastructure from leased capacity and remote peering. It should also state whether IPv4 and IPv6 receive equivalent filtering, monitoring and recovery treatment.

The test should remove one dependency at a time. Withdraw an upstream, disable an exchange session, interrupt one access path and trigger the agreed DDoS procedure. Record route convergence, loss, latency, application reachability, alarm time and operator response. A broad geographic footprint is valuable, but only a measured path shows which parts are independent for the buyer.

The facility offer is concrete enough to test, not complete enough to assume

The company's colocation page offers dedicated 42U racks, shared 21U and 10U allocations, and per-unit space. It describes generators and UPS, precision cooling, biometric access, continuous surveillance, fire detection and suppression, multiple connectivity providers and 24/7 technical support. Those details provide a useful acceptance-test outline. They go further than simply claiming secure racks.

The company profile page says its datacenter follows Tier III standards and has redundant power, multiple national and international backbones, environmental controls and a continuously operating network centre. The NEXUS RJ01 PeeringDB facility record places a named facility at the company's Inhauma address and associates it with AS274464 and three other networks. This is meaningful evidence that the company exposes a physical interconnection site, not proof of certified facility performance.

"Follows Tier III standards" is not the same statement as holding a current design or constructed-facility certification from a named issuer. The reviewed public pages do not identify a certificate, scope, audit date, maintenance policy, generator runtime, fuel contract, UPS topology, cooling redundancy, fire-system standard, carrier-entry diversity or incident record. Even a valid site certificate would not automatically make every customer service continuously available; rack power, cross-connects, network design and operating procedures remain part of the result.

A buyer should inspect the contracted rack and trace both power and network paths. The acceptance record should include breaker and feed identifiers, metering, power density, environmental limits, generator and UPS evidence, cross-connect routes, access procedure, visitor logs, media handling, remote-hands permissions and maintenance notice rules. A witnessed component-failure exercise is worth more than another adjective in the proposal.

Public automation evidence stops short of the customer control plane

The assigned cloud-service category raises a practical question: what can a customer observe or change without waiting for an operator? NexusLink's public pages describe monitoring, connectivity and infrastructure, but the reviewed material does not document a customer dashboard, provisioning API, role model, approval workflow, telemetry export, configuration history, billing controls or incident-status interface. The linked looking glass is an operator-observability clue, but it is not a customer management plane and was not available during the review.

This does not show that NexusLink lacks automation. It means buyers cannot infer automation from the service names. A dedicated-link customer needs visibility into utilization, loss, latency, BGP state, maintenance and tickets. A colocation customer also needs power and environment readings, access records, remote-hands requests and a durable history of who changed what. An ISP buying transit needs route-change controls, DDoS alerts and a way to export evidence into its own monitoring system.

The diligence exercise should therefore follow a real task. Add and revoke a user, request a route or cross-connect change, export telemetry, open a severity-one incident, approve emergency work and reconcile the final configuration with the ticket. If the workflow is manual, the contract should say who performs each action and within what time. If it is automated, the buyer should test authorization, auditability, rollback and degraded states rather than accept a dashboard demonstration as proof.

A Brazilian footprint does not settle data locality by itself

NexusLink's legal entity, address, facility and listed interconnection points are in Brazil. That is useful evidence of domestic operating presence. It can reduce ambiguity for a customer that wants equipment and primary connectivity in Rio de Janeiro. It does not establish where every copy of customer data, monitoring telemetry, support material or administrative record resides.

Colocation makes one locality question physically clear: the customer's hardware can be placed in a named rack at a named site. Other data paths are less visible. Configuration backups, flow logs, DDoS samples, ticket attachments, access-control records, billing data and staff collaboration tools may be processed elsewhere. International transit describes reach to overseas networks; it neither proves nor disproves domestic storage.

Locality should be written by data class. For each class, the service schedule should identify the primary and backup location, operator, legal role, retention period, encryption control, support-access route and deletion evidence. It should also say whether a failover, security incident or vendor escalation changes the location. Exchange presence in several Brazilian cities should be recorded as network reach, not silently converted into a claim that customer data is replicated across those cities.

Around-the-clock support needs clocks, authority and local hands

The contact page gives commercial hours of 8 a.m. to 6 p.m. on weekdays and describes technical support as available 24 hours a day, seven days a week. PeeringDB publishes a NOC telephone number and a network-operations email. The website and facility records also point to the same Rio base. Together, these provide a public route to local operational labour.

What remains undefined is how that labour behaves under pressure. The reviewed pages do not publish incident severities, acknowledgement and restoration targets, update cadence, escalation authority, remote-hands inclusions, spare-part coverage, language coverage, service credits or response distributions. The service catalogue advertises 99.9% uptime across services, but it does not state the measurement window, exclusions, demarcation point, calculation method or remedy. Without those definitions, the same percentage can describe very different obligations.

The buyer should stage an incident outside commercial hours. Open it through the contracted channel, verify the timestamp and severity, ask the NOC to identify the failing layer, authorize a bounded intervention and observe every handoff until restoration. The resulting timeline should reconcile with device alarms, routing evidence, facility access records and customer monitoring. The people answering the test should have the authority and tools they would have during a real outage.

Assurance comes from joining the records to one tested service

NexusLink has crossed an important threshold: its public identity can be joined to regulatory permission, an assigned autonomous system, a visible exchange footprint and a named facility. Buyers do not need to begin with the question of whether a network exists. They can begin with the more useful question of exactly what the network will do for them.

A concise acceptance sequence can answer it. First, bind CNPJ 50.203.572/0001-46, AS274464, NEXUS RJ01, the handoff, support contacts and every subcontracted dependency to the order. Second, inspect the rack and trace power, cooling, physical access and carrier paths. Third, observe routing and telemetry under normal load, then interrupt approved network and facility dependencies. Fourth, run an after-hours incident and compare every clock with the service schedule. Finally, rehearse exit: release cross-connects and addresses, export logs, remove equipment, revoke access, stop billing and obtain deletion evidence for provider-held data.

The company name is supported by more than marketing, and its routed footprint deserves serious consideration. The remaining work is not to accumulate another list of locations or services. It is to make one customer's topology, locality, control surface and support outcome observable before a failure makes the distinctions expensive.