Summary

  • Registro.br identifies “Gigalink Hosting” as the administrative contact attached to Brazil’s AS28658, while naming a different legal organisation as the network registrant. The label is evidence of an operational role, not by itself of a separate hosting company.
  • AS28658 has a substantial, inspectable network footprint, including public exchange connections and role-based technical contacts. Those records establish network activity but do not establish the scope, location or contractual terms of a hosting service.
  • Gigalink’s public pages document consumer cloud storage and corporate connectivity claims. A buyer still needs a legal-identity map, service description, workload-location statement, support escalation plan and exit provisions before treating the name as operating assurance.

The name belongs first to a network contact

Infrastructure records often contain names that look more commercial than the role they perform. “Gigalink Hosting” is a good example. In the Registro.br RDAP record for AS28658, the registrant is Gigalink de Nova Friburgo Soluções em Rede Multimi, attached to Brazilian registration handle 06236865000138. A separate entity with handle GIHOS is assigned the administrative role. That entity is described as an individual, carries the display name “Gigalink Hosting” and uses the address [email protected].

The direct GIHOS record reinforces the limits of that evidence. It describes the entity as an individual, shortens the displayed name to “Gigalink”, partially redacts the email address, records a registration date of December 10, 2008 and a last change on January 18, 2024. It does not identify a corporate registration, product catalogue, office, service agreement or customer-facing support organisation for a business called Gigalink Hosting.

This does not make the label false. Administrative handles are practical identities used to maintain network-resource records, and “Hosting” may have been a convenient description for a hostmaster function. It does mean the name should not be promoted into a separate corporate identity without another source connecting the handle to a contracting entity. The strongest public conclusion is narrower: Gigalink Hosting is an administrative identity associated with Gigalink’s network resources.

That distinction matters because identity decides who owes the customer performance, confidentiality, incident response and data-return duties. A recognizable label and a functioning email domain can make a service feel accountable while leaving the actual counterparty uncertain. Before procurement, the brand, legal name, Brazilian company registration, invoice issuer and contract signatory should resolve to one documented chain.

The network is real, but it proves a different thing

The operational evidence around the label is considerably stronger than the evidence for a standalone hosting offer. Registro.br shows AS28658 registered in August 2006 and links it to multiple IPv4 and IPv6 resource records. That is direct evidence of a durable number-resource footprint under the Gigalink registrant. It is not merely a domain resolving to somebody else’s platform.

PeeringDB’s AS28658 profile identifies the network as Gigalink de Nova Friburgo Soluções em Rede Multimedia, also known as Gigalink, with a regional cable, DSL and ISP scope. The profile reports 50–100Gbps of traffic, an open peering policy, two 100G connections at IX.br Rio de Janeiro and a 20G connection at IX.br São Paulo. It also lists presence at four Rio de Janeiro facilities and exposes separate NOC, abuse, peering and technical contacts. These are operator-supplied interconnection records rather than an independent capacity audit, but they provide testable details for counterparties and network engineers.

The control surface demonstrated here is routing and interconnection: an autonomous system, resource registrations, exchange ports, facilities and technical roles. Those controls can support access services, managed connectivity, cloud access and hosted systems. They do not reveal which servers run a customer application, who owns the hardware, which software layer is managed, how backups work or what remedy applies after an outage.

For a buyer, this is the central analytical split. Network proof reduces the risk that a provider name is entirely detached from operating infrastructure. It does not eliminate product risk. A routed prefix cannot substitute for a service description, and an exchange connection cannot substitute for an availability commitment.

Public service proof stops short of enterprise hosting

Gigalink’s main website presents the company primarily as a Brazilian connectivity provider. It says the business began in 2003, serves 19 municipalities, has points of presence in 46 cities and operates a 2,500-kilometre fibre backbone. It also describes 60 of its own “data centers” or installations. These are company claims, and the page does not define whether every cited site is a customer-hosting facility, a network room, a point of presence or another type of installation.

The clearest cloud product in the reviewed material is Gigalink Cloud. The page describes a multi-platform file-storage and sharing application available through browsers and personal devices. It is bundled with Gigalink connectivity plans, with plan text showing storage allowances of 5GB, 10GB or 15GB. That is evidence of a cloud-branded storage service. It is not evidence of virtual machines, managed application hosting, dedicated servers, container orchestration or an enterprise data platform.

The corporate offer advertises personalized service, full-time technical support, network monitoring, redundancy and an SLA of up to four hours. It also gives a Nova Friburgo address and a corporate sales contact. Yet its headline counts differ from the main site: 30 points of presence, 42 data centres, 17 served cities and 21 years in operation. The pages may cover different dates, business segments or definitions. Without dated definitions, a customer cannot know which footprint applies to the service being bought.

The prudent reading is not that Gigalink lacks hosting capability. The reviewed sources cannot establish that negative. It is that the public offer does not yet bridge the gap from connectivity and bundled file storage to a defined enterprise-hosting product under the exact Gigalink Hosting name. A proposal can close that gap, but it should do so explicitly.

Brazilian routing does not settle data locality

Data sovereignty questions begin where routing evidence ends. AS28658 is registered in Brazil; its public exchange and facility entries are concentrated in Rio de Janeiro and São Paulo; the company markets a regional fibre network. None of those facts alone establishes where a particular customer’s primary data, replicas, backups, logs or support copies are stored.

The mechanism is simple. Traffic may enter a provider’s Brazilian network and then reach infrastructure operated by a partner, a public-cloud region or a separate storage platform. Backups may follow a different path from production. Support personnel may access systems from another jurisdiction. Conversely, a service can use third-party facilities while keeping processing and legal control in Brazil. Network geography is relevant evidence, but workload placement is a service-level fact.

A defensible locality statement should therefore name the primary and disaster-recovery sites, the facility operator, the contracting entity, subprocessors, backup jurisdiction, retention periods and deletion method. It should explain whether customers can select a region and whether any support or telemetry data crosses borders. Encryption, key control and incident notification belong in the same discussion because locality without operational control can provide only a thin form of assurance.

Support claims need named ownership and escalation

The public record offers useful pieces of a support model. PeeringDB separates NOC, abuse, peering and technical contacts. The corporate page promises full-time technical support and an SLA of up to four hours. The main consumer site publishes a telephone number, shop locations and customer-account access. Together they suggest a local operating presence rather than a purely anonymous web storefront.

But each channel serves a different audience. A hostmaster address maintains registration data; a peering contact negotiates interconnection; an abuse mailbox receives network complaints; a retail call centre handles subscribers. None automatically owns a failed customer workload. “Up to four hours” is also ambiguous without the event that starts the clock and the action that stops it. It could describe first response, technician dispatch or restoration.

Enterprise support becomes credible when the contract maps severity levels to response and restoration objectives, names the 24-hour escalation route, identifies the team that can change infrastructure and defines communications during an incident. Buyers should also establish whether support is delivered by Gigalink employees or another operator, which languages are staffed after hours, where the service team is based and how unresolved cases reach management. Those labour details affect recovery speed more directly than a generic support badge.

Automation deserves similar precision. A storage application or managed network may expose an account portal, but enterprise operations require clarity on APIs, identity federation, role-based access, audit logs, monitoring export, backup testing and configuration ownership. If an action remains manual, the responsible team and expected completion time should be stated. Otherwise “managed” can mean little more than “contact us”.

An evidence ladder for a consequential purchase

A buyer does not need to dismiss Gigalink Hosting because the public identity begins as an administrative handle. It should instead ask the seller to connect five layers of evidence.

First comes identity: the current legal name, company registration, trading names, address, invoice issuer and authority to contract. Second comes service: a versioned description of the hosted component, the responsibility split, included capacity, exclusions, maintenance rules and remedies. Third comes infrastructure: the ASN and prefixes used, facility and hardware operators, upstream dependencies, monitoring, resilience design and denial-of-service controls.

Fourth comes data control: exact production and backup regions, subprocessors, access model, encryption and key ownership, recovery testing, retention and verified deletion. Fifth comes accountability: named support channels, severity rules, local staffing, incident reporting, audit access, data export and an exit plan. Each layer should refer to the one above it. The support team must know the contracted service; the service must name the infrastructure; the infrastructure and subprocessors must fit the promised locality.

The public record already provides useful anchors for that exercise. It shows a Brazilian Gigalink operator, a longstanding autonomous system, concrete interconnection points, role-specific network contacts, a consumer cloud application and a corporate support claim. What it does not support is treating “Gigalink Hosting” as self-explanatory proof of a separate provider or a complete enterprise operating model.

That is the durable conclusion: the name is a lead into a real network, not a substitute for service assurance. The provider can turn it into assurance by binding legal identity, workload scope, data location and support ownership in documents a customer can test. Until then, the careful buyer should value the network evidence while keeping the hosting claim open.