Summary

  • Brazil's network registry ties APSYS Cloud Tecnologia e Informatica Ltda, CNPJ 28.553.357/0001-16, to AS274615, the IPv4 block 200.90.155.0/24 and the IPv6 block 2804:910c::/32. The same registry contact uses the greenfiber.net.br domain, making the join between the legal name and Green Fiber more than a resemblance of names.
  • Green Fiber's current public offer is centred on fixed internet access, whole-home Wi-Fi, Wi-Fi 6, camera installation, streaming, a speed test and address-level availability. Its subscriber portal exposes account data, finances, access items and technical support. These are meaningful operating surfaces, but they are not public proof of virtual compute, storage, backup, colocation, recovery automation or enterprise cloud controls.
  • Public routing views describe AS274615 as a small, single-homed network with one visible upstream, AS265066, while Brazil's registry records one /24 IPv4 allocation and one /32 IPv6 allocation. That evidence helps a customer ask precise resilience questions; it does not prove physical path diversity, spare capacity, route security, service availability or the topology delivered to any customer.
  • A serious assurance package should connect the contracting entity, Green Fiber brand, service address, access path, account controls, data locations, incident clocks and exit procedure. Until those joins are documented and tested, APSYS's public record supports confidence in a Brazilian connectivity operator, not a blanket cloud guarantee.

Two public names meet at one corporate identifier

The first difficulty is identity. The BTW directory entry names APSYS Cloud Tecnologia e Informatica Ltda, places it in Brazil and associates it with managed network, cloud service, data centre, colocation and hosting. Each service is marked as not yet assessed. That qualification is important: the page identifies a subject and a set of claims worth examining, but it does not say that all five services are currently sold or independently verified.

APSYS does not use its legal name prominently on the consumer site found in the public record. The storefront is Green Fiber, while a Brazilian business record gives Green Fiber Telecom as the trading name of APSYS Cloud Tecnologia e Informatica Ltda. The Serasa Experian CNPJ page identifies CNPJ 28.553.357/0001-16, a Niteroi, Rio de Janeiro address, an August 2017 founding date and multimedia communication services as the principal registered activity.

The strongest join comes from the internet number registry. The Registro.br record for AS274615 names APSYS Cloud Tecnologia e Informatica Ltda as the registrant, repeats CNPJ 28.553.357/0001-16 and lists an administrative contact at the Green Fiber domain. It also names a legal representative. This creates a coherent chain from the commissioned legal entity to a public retail brand and then to a network resource holder.

That chain proves identity, not performance. A corporate registration does not show that a promised service is available at a given address. A trading name does not reveal which entity invoices the customer or owes a remedy. An autonomous system does not establish that cloud workloads sit behind it. Before contracting, a customer should see the legal name and CNPJ on the order, invoice, privacy terms, service schedule and escalation sheet, with Green Fiber identified explicitly as the brand through which the service is delivered.

The current storefront describes an access provider

The most useful clue about product boundary is what Green Fiber asks visitors to do. Its home page promotes Super Wi-Fi 6, whole-home Wi-Fi, camera installation and a speed test. Its plans page lists household-oriented 600 Mbps, 800 Mbps and 1 Gbps offers, along with a bespoke option, and advertises Wi-Fi equipment, no installation fee and no fixed commitment. The services page gives streaming television the only substantial public service description. The availability form asks for a Brazilian postal code, street address, number, district, state and city before deciding whether service can be supplied.

This is recognisable fixed-access behaviour. The address check points to a geographically bounded last-mile network; the speed tiers and Wi-Fi equipment describe how connectivity reaches a household; camera installation and streaming extend the retail bundle. The site does include a tab inviting visitors to choose an offer for a company, but the captured page presents the same plan list rather than a separate enterprise catalogue.

The company's own history gives a broader origin story. Green Fiber says that in 2016 and 2017 its founders began developing a platform for internet-infrastructure management and the Internet of Things, that operations began in 2017 and 2018 with solutions for companies in Brazil and the United States, and that the business later expanded into a complete infrastructure provider. This is first-party chronology, not a current product specification. The present public site does not expose that management platform, its interfaces, deployment model, security controls, supported workflows or customer evidence.

That difference matters for enterprise software and automation. A platform that provisions circuits, monitors equipment or coordinates field work could reduce manual configuration and support labour. But a buyer cannot evaluate those gains without seeing the control surface: who can create an account, request a change, approve it, observe its state, reverse it and export the resulting record. The public offer proves that there is an online sales and subscriber journey. It does not show an enterprise orchestration product or an automated cloud control plane.

AS274615 is concrete evidence with a narrow scope

APSYS's network resources are more specific than its product language. Registro.br says AS274615 was registered on August 30, 2024. The same record links the autonomous system to 200.90.155.0/24 and 2804:910c::/32. The separate IPv4 record assigns addresses from 200.90.155.0 through 200.90.155.255 to APSYS, while the IPv6 record assigns the corresponding /32. Both records carry the same CNPJ and technical contact family.

Those allocations show that APSYS holds the building blocks needed to originate public routes and number customer or infrastructure interfaces. IPv6 space is especially relevant because a current access provider should be able to explain whether customers receive native IPv6, how prefixes are delegated and retained, what filtering applies and whether the service behaves consistently through failover. The records do not say how much of either allocation is in production, which addresses serve customers, whether translation is used, or whether a particular plan includes public addressing.

Two secondary routing views add a limited topology clue. IPinfo's AS274615 page classifies the network as an ISP or hosting network, associates the /24 with it and shows one upstream, AS265066, with no visible downstreams. The CAIDA AS Rank view likewise reports a degree of one and one transit relationship in its captured view. Agreement between two observations makes the single visible dependency worth investigating.

It is not enough to declare the network physically single-path. Public BGP observations see routing relationships, not ducts, fibres, power feeds or every private interconnection. One upstream autonomous system could deliver multiple circuits over diverse entrances; conversely, two logical sessions could still share a physical failure domain. A dated routing snapshot also cannot promise tomorrow's topology.

The buyer should ask APSYS for the customer-specific path: hand-off type, access medium, aggregation point, upstreams, route policy, IPv4 and IPv6 treatment, distributed-denial-of-service response, maintenance process and restoration sequence. If resilience is sold, the provider should identify the supposedly independent components and demonstrate a failover while latency, loss and route changes are measured. AS274615 makes that test possible to frame. It does not supply the result.

Authorisation defines permission, not service quality

The regulatory record reinforces the access-provider interpretation. A July 31, 2025 federal gazette notice records Anatel act number 8,889, authorising APSYS, under the same CNPJ, to provide telecommunications services of collective and restricted interest throughout Brazil for an indefinite period.

This is substantial identity and permission evidence. It means the company can be checked against a named regulator, act number and taxpayer identifier. It does not mean the operator has physical coverage throughout Brazil, that every service is licensed in the same way, or that Anatel guarantees its speed, availability, security or support. National scope describes the authorisation, while Green Fiber's own address checker describes the practical question of whether a particular location can be served.

The distinction matters commercially. A buyer might see a national authorisation, a gigabit plan and the word cloud, then infer a broad, resilient infrastructure footprint. The public record supports a more modest reading: an authorised Brazilian telecom provider with its own autonomous system and number resources, selling location-dependent connectivity under the Green Fiber name. Anything beyond that needs service-specific evidence.

Data locality cannot be inferred from address space

All the strongest public anchors point to Brazil: the CNPJ, Niteroi registration, Anatel authorisation, Registro.br allocations and Green Fiber's postal-code availability flow. That is useful evidence of jurisdiction and of a domestic customer relationship. It is not a data-residency map.

An IP block registered in Brazil can carry traffic to systems elsewhere. A local access circuit may reach a remote software service, ticket platform, payment processor or backup site. Even a workload hosted in Brazil may produce logs, account records and support messages handled in another location. The current public pages do not identify a data-centre facility, cloud region, storage platform, backup location, subprocessor list or cross-border support path.

For a connectivity service, locality should begin with the physical installation address, aggregation and upstream path. For any cloud or hosting offer, it should extend to the primary and recovery facilities, administrative systems and every material data class. A practical schedule would list customer content, configuration, authentication records, flow or access logs, billing data, support tickets and backups. For each, it should name the controller, processor, country, retention period, support-access rule, encryption owner and deletion evidence.

The same discipline applies to cameras and IoT. Installation is not the whole service. A customer needs to know whether footage or telemetry remains on local equipment, traverses APSYS's network, or is stored by another vendor; who can view it; how long it persists; and what happens when the subscription ends. Local support can improve response, but it does not by itself make every byte local.

The subscriber portal shows a support surface, not a support outcome

Green Fiber exposes a subscriber portal with areas for registered details, financial control, access items and technical support. The main site also directs prospective customers to a WhatsApp sales channel. Together, these pages show that APSYS has built public entry points for account administration and help rather than relying on an anonymous contact form alone.

What they do not disclose is the support commitment. The captured public pages do not state staffed hours, incident severities, acknowledgement or restoration targets, escalation levels, maintenance notification, service credits or an emergency route for business customers. They also do not show historical ticket response, repair distributions or outage reports. A button labelled technical support proves a route into a queue, not what happens after the ticket enters it.

This is where local labour becomes part of infrastructure assurance. A field technician may need to reach the customer premise. A network engineer may need to change a route or diagnose an optical path. An account administrator may need to restore portal access, while a separate vendor handles a camera or streaming problem. The customer needs to know which team owns each action, when it is staffed and who has authority to engage the upstream provider.

For a household plan, consumer rules and a clear repair channel may frame much of that relationship. For an enterprise circuit or a purported cloud service, the schedule should be more explicit. It should define the event that starts each clock, the difference between acknowledgement and restoration, update cadence, after-hours coverage, escalation contacts, evidence used to close an incident and the remedy for a missed objective. APSYS should be able to show anonymised response and restoration distributions by severity. Without those measures, proximity and contactability are advantages, but not quantified assurance.

A procurement test should follow the actual service

APSYS does not need an elaborate cloud narrative to prove a fixed-access service. It needs a coherent chain from order to operation. The customer should first match the sales proposal, contract, invoice and support record to CNPJ 28.553.357/0001-16 and the Green Fiber trading name. The order should define the service address, committed and advertised rates, installation boundary, supplied equipment, addressing, traffic management, maintenance, support and termination.

Next comes a technical acceptance test. Measure throughput, latency, packet loss and DNS behaviour over representative intervals rather than at one quiet moment. Record IPv4 and IPv6 assignment, customer-premises equipment control and the route seen during normal operation. Then trigger or observe a controlled loss of the primary path if resilience is part of the offer. The result should show which layer detected the failure, who acted, what changed and how long restoration took.

Account controls deserve their own exercise. Create separate roles for billing, technical support and privileged changes; verify multifactor authentication and recovery if offered; export the activity record; and test how access is revoked when a staff member leaves. If a portal action changes cost or connectivity, the approval and rollback path should be visible. Self-service is useful automation only when authority and state remain intelligible.

Any service sold as cloud, hosting, colocation or data centre needs a second evidence pack rather than an extrapolation from the access network. APSYS should name the facility and contracting chain, describe compute and storage boundaries, show tenant isolation, define backup and recovery objectives, document monitoring and incident history, identify capacity constraints, and perform a customer-selected restore. The exit test should recover data and configuration outside the service, rotate credentials, change DNS and addressing where necessary, close billing and obtain deletion evidence.

These requests are proportionate to the claim. The public record already provides enough stable identifiers to start: a legal entity, CNPJ, regulator act, autonomous system, two address allocations, brand domain and account portal. Assurance comes from joining them to the exact service and observing its failure behaviour.

The public record proves less than the name, and more than a brochure

APSYS Cloud Tecnologia e Informatica Ltda is not an empty name. The identity chain is unusually crisp once Green Fiber is recognised as the public brand. Corporate data, Registro.br records and a federal telecom authorisation converge on the same CNPJ. AS274615 and its IPv4 and IPv6 allocations establish a concrete network-resource surface. Green Fiber's sales, availability and subscriber pages show a functioning customer journey around fixed connectivity.

The remaining gap is product assurance. The public-facing service evidence does not demonstrate an enterprise cloud platform, named data-centre footprint, colocation operation, hosting stack, measured recovery capability, path diversity or contract-level support performance. It would be unfair to treat that silence as proof that those capabilities do not exist. It would be equally unsound to infer them from the legal name or an unassessed service label.

The defensible conclusion is narrower and more useful. APSYS can be treated as an identifiable, authorised Brazilian connectivity operator with its own network resources. A customer can build from that base by demanding a service map, topology, data-flow schedule, incident clock and exit test. Until APSYS supplies and demonstrates those joins, the word cloud remains a question to verify rather than an assurance to inherit.