Summary
- SIANET can be tied to an active Brazilian company, AS53101, public address space, two observed transit providers and a 10 Gbps connection at IX.br São Paulo, giving buyers more to inspect than a generic cloud-service description.
- The remaining procurement burden is substantial: SIANET's public pages state a 99.9% uptime target, redundant power and round-the-clock support, but do not publish the measurement rules, service credits, incident history, recovery objectives, restore-test evidence or response targets needed to turn those statements into operating assurance.
A visible ASN changes the starting point, not the verdict
The hardest part of assessing a small or regional infrastructure provider is often deciding whether the public name maps to an operating system at all. SIANET clears that first hurdle. Serasa Experian's company page identifies SIANET Datacenter Provedores Ltda under CNPJ 10.470.642/0001-08, records an active status and a November 2008 foundation date, and classifies its principal activity as data processing, application-service provision and internet hosting. The company's website uses the SIANET Business Hosting brand and gives a São Paulo address and telephone number.
PeeringDB connects the longer SIANET Datacenter e Provedores Ltda-ME name to the same website and to AS53101.
That identity chain matters because cloud procurement is full of soft signals: a polished domain, a broad service menu, a data-centre label and an account team. SIANET also leaves harder technical traces. At the time of review, bgp.tools showed AS53101 as an active network allocated under NIC.br, originating two IPv4 aggregates: 177.107.208.0/21 and 187.103.144.0/20. Its registry material ties the ASN and those resources to the same CNPJ. PeeringDB lists the network at IX.br São Paulo with a 10 Gbps port, a named network-operations contact, an open peering policy and regional scope.
The routing view also showed two upstreams, Claro's AS4230 and Telefônica Brasil's AS10429. This is useful evidence of a real connectivity surface and some upstream diversity. It is not proof that every hosted service is dual-homed correctly, that capacity is sufficient during an incident, or that customer traffic will fail over within an acceptable interval. A procurement team should therefore treat the ASN as a starting artefact for technical due diligence: request current route exports, transit commitments, traffic headroom, maintenance procedures and an explanation of how customer services map onto the visible network.
There is a further reason to insist on a dated network snapshot. PeeringDB's self-maintained profile lists ten IPv4 prefixes and two IPv6 prefixes, while the independent routing view observed two originated IPv4 aggregates and no originated IPv6 at review time. Those values may describe different things, including configured prefix limits versus routes then visible on the internet. The difference is not itself evidence of a fault. It is evidence that a profile field should not be mistaken for current route state.
The service boundary spans four different products
SIANET's public offer is not one uniform cloud. It spans shared and dedicated hosting, customer-owned equipment in colocation, virtual infrastructure sold as cloud computing, and managed continuity or technical services. Each shifts responsibility differently.
The hosting page says dedicated servers can be configured for customer requirements, while shared hosting targets simpler sites and applications. It advertises daily automated backup, Linux and Windows support, monitoring and plan customisation. Colocation moves the equipment boundary: the customer brings servers into SIANET's facility and relies on SIANET for physical environment, connectivity and operational access. The cloud page presents virtual capacity that can be adjusted through an automated panel, reducing the need to open support tickets for routine changes.
The site-backup offer describes replication to a secondary internet data centre and even an optional workplace from which staff could continue operations if the primary office became inaccessible.
Those are materially different services, not interchangeable labels. A shared-hosting customer is exposed to tenancy controls and platform policy. A dedicated-hosting customer needs hardware replacement and rebuild commitments. A colocation customer keeps more control over server configuration but must understand remote-hands coverage, spares, access windows and cross-connect ownership. A cloud customer depends more heavily on the control panel, provisioning state and the provider's virtualisation layer. A continuity customer needs evidence that replication and recovery actually work together.
The distinction also affects price comparison. A hyperscale cloud may provide a much larger service catalogue, granular identity controls and extensive audit material, but can impose egress, architecture and specialist-labour costs. Colocation can provide greater physical control but leaves the customer buying, maintaining and refreshing equipment. Self-run infrastructure can preserve maximum configuration freedom while creating a large burden in power, cooling, networking, security and incident coverage.
SIANET's potential advantage is narrower: local infrastructure with Portuguese-language support and a service team that can absorb some of that work. The premium is justified only if the provider's contract and evidence reduce customer supervision more than they add vendor dependence.
The physical claims are specific enough to test
The company's infrastructure page contains more detail than its broad cloud language. SIANET says the facility uses two generators in a redundant arrangement, with up to 20 hours of operation before fuel replenishment, and two scalable uninterruptible-power-supply groups that bridge roughly 15 seconds before generators take load. It describes active-active firewall appliances, two perimeter intrusion-prevention systems, fire detection and suppression, controlled cooling and several layers of physical access, including biometric authorisation for the data-centre room.
These statements create a useful inspection agenda. A buyer can ask for generator load-test dates, fuel contracts, maintenance logs, UPS battery test results, single-line electrical diagrams, cooling redundancy, fire-system inspection records and evidence that maintenance does not collapse the advertised redundancy. Without those materials, the numbers remain provider assertions. With them, the buyer can test whether the design works under normal failure modes rather than only in a sales description.
The same principle applies to connectivity. SIANET says its Cisco-based core and edge equipment are redundant and that multiple providers can propagate its address space through BGP. The observed ASN, transit relationships and exchange connection support the existence of that network role. They do not establish application availability. A hosted service can still fail because of an internal switching problem, firewall state, DNS dependency, storage outage, capacity bottleneck or an incorrect route policy. Internet-path diversity is one layer in the availability argument, not the whole argument.
This is where the public 99.9% uptime statement needs translating. If measured over a 30-day month, 99.9% permits about 43 minutes of unavailability. But that arithmetic is only illustrative because the public page does not define the measurement period, monitored endpoint, exclusions, scheduled-maintenance treatment or remedy. It also does not publish a status history from which a buyer could compare the promise with observed service. The relevant commitment is the one in the service agreement, not the percentage on the home page.
Automation reduces tickets but concentrates control
SIANET says its cloud panel gives customers control of a virtual data centre without manual support actions. That can remove repetitive provisioning labour: a customer can resize or configure resources without waiting for an operator to process each request. For a small platform team, this is a meaningful benefit. The question is what happens to the state around those actions.
A useful control plane should show who changed a resource, what changed, when it changed, whether the operation succeeded, what it will cost and how to reverse it. It should support separate roles for administrators, operators and auditors; strong authentication; durable activity logs; usage and budget reporting; and a documented exit path for virtual machines and data. SIANET's public cloud page explains the basic self-service proposition but does not set out that governance surface. Its illustrated resource values should not be read as live inventory or guaranteed capacity.
This matters during pressure, not only during setup. If a customer cannot obtain capacity, the panel should distinguish quota, physical scarcity, account status and technical failure. If a resize partially succeeds, the audit trail should preserve the old and new state. If a user credential is compromised, the customer should be able to revoke access and identify affected actions. If the panel is unavailable, there should be an alternative, authenticated operating path. Automation saves labour when it makes state legible. It creates a new concentration risk when it merely hides manual work behind a screen.
Buyers should therefore ask for a demonstration built around failure: create a resource, change it, remove a user's rights, recover from an unsuccessful operation, export the activity history and reconcile usage with the bill. The result will say more about the operating model than a list of maximum sliders.
Locality is useful only when its boundaries are explicit
SIANET's public footprint is strongly associated with São Paulo. The company site, PeeringDB organisation entry and exchange connection all point there, and the services are presented to Brazilian customers in Portuguese. For workloads serving users in or near São Paulo, that may offer latency, language and account-support advantages. For organisations that care about keeping data in Brazil, it may also be commercially relevant.
But a local office, a local ASN and a local facility claim do not by themselves answer data-residency questions. A customer needs to know where production data, replicas, snapshots, backups, logs and support artefacts are stored; whether subcontractors can access them; where control-plane services run; and whether recovery can move data outside the agreed location. Colocation, hosted servers, cloud instances and the secondary-site service may each have different answers.
The site-backup page makes the uncertainty particularly important. It describes replicated data or servers at a secondary internet data centre, but the public material does not identify a recovery-point objective, recovery-time objective, replication mode, testing frequency or the exact separation between primary and secondary locations. A continuity service should be judged by successful restore exercises and dependency mapping. A second copy that shares a power, network, credential or operator failure domain may not provide the independence the customer expects.
Before signing, a buyer should obtain a location map for every data class, a list of subprocessors, deletion and media-destruction procedures, encryption and key-ownership terms, and a tested exit process. Data sovereignty is not achieved by choosing a Brazilian name. It is achieved by keeping location and control facts attached to the workload throughout its life.
Support is part of the infrastructure
SIANET advertises Portuguese-language support 24 hours a day, seven days a week, by telephone or ticket. Its infrastructure page describes an operations team that monitors customer resources, provides first-level handling and activates second- and third-level support. This is a credible description of a local escalation surface and may be more accessible to a Brazilian customer than a distant, standardised queue.
Yet availability of a queue is different from accountability for an outcome. The public pages do not state acknowledgement or restoration targets by severity, escalation timing, incident-commander ownership, communication intervals or service credits. They also do not show whether monitoring covers only infrastructure or includes the customer's operating system and application. Those boundaries decide whether support reduces labour or starts a round of responsibility transfer during an outage.
The public record does contain one useful service-proof signal beyond the company's own pages. Nazaré Paulista's municipal contract register names SIANET as the supplier for installation, initial configuration and rental of IT infrastructure with maintenance. Contract 74/2024 ran from July 2024 to July 2025 and carried a value of R$48,999.60. This demonstrates that a public buyer contracted SIANET for a defined infrastructure service. It does not reveal uptime, resolution quality or customer satisfaction, so it should not be stretched into a performance endorsement.
A procurement exercise should turn the support promise into a table: severity definitions, response and restoration objectives, named escalation levels, after-hours authority, customer obligations, communications, evidence retention and remedies. It should then test the path before a serious incident. Open a low-risk ticket, escalate it, request the activity history and verify that both sides agree on ownership. Local support is valuable when it shortens diagnosis and decision time, not merely when someone answers in the same language.
The buyer's evidence pack should survive an outage
The practical case for SIANET rests on combining its visible technical identity with evidence that is less visible publicly. AS53101, address space and IX.br participation show that the company has operated its own network resources. The website presents distinct hosting, cloud, colocation, recovery and support surfaces. The infrastructure page supplies testable claims about power, network security and physical controls. The municipal contract adds a concrete example of infrastructure supplied with maintenance.
What remains unproven in public is the performance of that system over time. A serious buyer should ask for twelve months of availability and incident data for the relevant service, the exact SLA formula, capacity and oversubscription policy, backup and restore results, security assurance, change-management history, support performance by severity, and recent evidence for power and network failover tests. The request should match the product being bought; colocation evidence is not a substitute for cloud-control-plane evidence, and a network route is not a substitute for storage recovery.
The decision rule is straightforward. SIANET should not be dismissed as an ungrounded hosting label: the legal identity and network-resource trail are substantive. Nor should the visible ASN be promoted into a blanket reliability conclusion. Treat the company as an operating provider whose strongest public facts earn deeper diligence. The purchase becomes defensible when SIANET can connect those facts to the particular rack, host, virtual resource, backup set and support obligation on which the customer will depend.