Summary
- A current Brazilian company-data presentation identifies active COREVAULT DATACENTER LTDA, CNPJ
09.285.034/0001-44, at a Cuiaba address, with internet hosting and application-service provision as its principal activity. Registro.br uses the same CNPJ forAS274585and the IPv6 allocation2804:9654::/32, creating a strong legal-to-network attribution chain. - The network footprint is young but observable. Registro.br registered the ASN and IPv6 block on October 29, 2025; RIPEstat first saw the
/32originated by AS274585 on November 15 and recorded full visibility among its 322 reporting IPv6 peers on July 15, 2026. It also observed the aggregate and two/33routes throughout the July 1-15 window. - CoreVault's website advertises IaaS, on-demand virtual machines, S3 and file storage, layered backup, 24x7 monitoring, direct support and a Tier III data centre in Brazil's Centre-West. The captured page does not name the legal company or CNPJ, define the Tier III claim, publish an SLA, or give the facility and recovery details needed to test those promises.
- The reasonable buyer position is neither dismissal nor automatic trust. The public record supports a real Brazilian counterparty and active network role; operating assurance still depends on a service-specific facility schedule, data-location map, route-security plan, restore test, support escalation matrix and exit evidence.
The legal company and the network holder join on one identifier
The best public evidence for CoreVault begins with an identifier, not a slogan. Econodata's presentation of Brazilian federal company data names Corevault Datacenter Ltda, CNPJ 09.285.034/0001-44, as an active limited company headquartered on Rua Cinco in Jardim Comodoro, Cuiaba, Mato Grosso. It gives an opening date of January 4, 2008 and lists data processing, application-service provision and internet hosting as the principal activity. Its secondary activities include communications-network access, multimedia communications, software development and technical support.
That record also names Alesi Henrique da Silva and Leonardo Bellincanta Chitolina as partners from June 2025. Econodata is a commercial presentation of public company information, not a certified corporate extract, so a contracting customer should still verify current signing authority, beneficial ownership and the complete address directly. Even with that limitation, the CNPJ and legal name are specific enough to test against a stronger technical source.
Registro.br's authoritative record for AS274585 supplies the match. It names COREVAULT DATACENTER LTDA as registrant, uses 09285034000144 as the organisation handle and names Alesi Henrique da Silva for administrative and abuse responsibilities. The companion record for 2804:9654::/32 assigns the IPv6 block to the same company and CNPJ, with the same person handling technical and abuse roles. Both resources were registered on October 29, 2025.
This gives CoreVault a defensible legal-to-network identity. The organisation that a customer could put on a contract is also the named holder of an internet routing number and address block. That is useful assurance about attribution. It is not evidence that the legal company owns a particular building, employs the people shown in marketing imagery, controls every component of a service, or has delivered a workload at a promised availability level.
The 2026 LACNIC electoral roll adds a separate institutional signal by listing COREVAULT DATACENTER LTDA among Brazilian member organisations. Membership supports the company's presence in the regional internet-resource community. It should not be inflated into a quality endorsement, certification or finding about operational maturity.
The public brand page leaves an attribution step unfinished
The CoreVault website is consistent with the legal record in broad geography and activity. It places the operation in Brazil's Centre-West, publishes telephone numbers including a Cuiaba-area 65 number, and markets infrastructure and support. Yet the captured page does not display the CNPJ, the full legal name or a street address. A matching brand and region make the connection plausible; they do not close it with the precision of the Registro.br records.
There is another small but consequential loose end. The contact section asks visitors to discover how "CoreFibra" can support their operation, while the rest of the page is branded CoreVault and its footer displays a CoreFibra logo. The reviewed public records do not establish whether CoreFibra is a parent, affiliate, trading brand, connectivity supplier or simply the organisation operating the sales channel. This may have an ordinary explanation, but customers should not have to infer it when deciding who will contract, invoice, operate and answer an escalation.
The cure is simple documentary alignment. A proposal should state the CoreVault brand owner, the legal supplier and CNPJ, any CoreFibra role, the facility operator, the network operator and each subcontractor that can touch customer systems or data. The invoice entity, support entity and party liable for service credits should agree with the signed schedule. Where responsibilities are shared, the hand-off should be explicit.
That clarification matters because a cloud service is assembled from more than a website and an ASN. Power, cooling, physical access, servers, storage, network transit, monitoring, backup software and support labour may sit with different parties. The legal-to-network join is encouraging, but a buyer needs the same clarity across the rest of the operating surface.
A concise catalogue defines the promise, not its limits
CoreVault's site lists a coherent set of services: infrastructure as a service, virtual machines on demand, S3 and file storage, layered backup, 24x7 monitoring and technical support with direct attention. It describes a five-stage customer path from diagnosis and sizing through assisted implementation, operation and continuing support. Dell and Veeam are named as global partners.
This is enough to understand the proposition. CoreVault is presenting itself as a regional operator that combines infrastructure with human implementation and operating help, rather than as a self-service catalogue alone. That can be valuable for enterprises whose outages stop dispatch, cancel orders or interrupt sales, examples the company itself uses to describe the stakes.
It is not yet enough to determine the division of work. The page does not identify the virtualisation layer, the S3 compatibility boundary, storage durability design, backup retention, encryption ownership, monitoring coverage, patching duty or administration model. It does not say whether "on demand" means an automated customer action, a support request or a quoted project. Dell and Veeam references indicate technologies or commercial relationships that may be relevant, but they do not show which product, architecture, certification or support entitlement applies to a particular order.
These omissions affect both reliability and labour. If CoreVault provisions and monitors a virtual machine but the customer administers its operating system, an application outage may fall between two teams. If layered backup covers infrastructure snapshots but not application-consistent data, a successful job may still produce an unusable recovery. If file and object storage share credentials or a failure domain with production compute, the apparent extra layer may not provide independent protection.
A useful service schedule should therefore allocate each recurring action: capacity approval, account creation, privileged-access review, operating-system patching, storage expansion, alert response, backup verification, restore authorisation and incident communication. It should name the tools that create customer evidence and say how logs and configuration are exported on exit. Automation reduces effort only when its trigger, owner, failure state and manual recovery path are understood.
AS274585 is new, IPv6-only in the observed resource record, and visible
The network record contributes something marketing cannot: an externally observable operating signal. RIPEstat's announced-prefix history for AS274585 showed three IPv6 routes throughout its July 1-15, 2026 query window: the allocated 2804:9654::/32 aggregate and the two more-specific routes 2804:9654::/33 and 2804:9654:8000::/33. No IPv4 allocation was attached to CoreVault in the Registro.br evidence used here, and the BigDataCloud view of AS274585 likewise showed no IPv4 prefix.
The routing-status observation for the /32 dated its first observed origin by AS274585 to November 15, 2025, a little over two weeks after registration. At the July 15, 2026 observation point, all 322 reporting IPv6 peers saw the aggregate. Those measurements establish that the company-linked network was not merely assigned on paper: its IPv6 route was broadly visible in the public control plane.
They do not establish customer reachability end to end. Collector visibility cannot measure packet loss, latency from a customer's sites, application availability, congestion, route convergence or whether compute and storage are physically located behind the ASN. An IPv6 allocation also says nothing about how customers that still require IPv4 are served. CoreVault could use provider-assigned IPv4 space, another network, translation or a partner, but the reviewed public records do not identify that arrangement.
Public topology observations add context while requiring similar restraint. RIPEstat's neighbour data observed AS52654, AS53062 and AS262568 adjacent to CoreVault. BigDataCloud labelled the first two as networks received from and the third as a network receiving transit. These observations support more than one visible adjacency. They do not prove the commercial relationship, circuit capacity, building entrance, fibre route, failover behaviour or physical independence of any connection.
For an infrastructure buyer, the practical questions follow directly. Which ASN and addresses will carry the service? How will IPv4 and IPv6 be delivered? Which paths are active, backup or customer-facing? Do two carriers enter through independent ducts and termination equipment? What happened in the last controlled route failover? A route diagram and observed failover result would turn public topology clues into service-specific assurance.
Route authorisation is an identifiable early control
The RIPEstat RPKI check for AS274585 and 2804:9654::/32 returned unknown with no validating route-origin authorisation. Unknown does not mean invalid, and it is not evidence of a hijack. The observed origin agrees with the Registro.br holder, and the route was fully visible to reporting IPv6 collectors.
The result does mean networks using route-origin validation had no cryptographic statement in that response confirming that AS274585 was authorised to originate the /32. For a recently registered network, creating and maintaining the appropriate authorisations is a concrete way to reduce ambiguity. CoreVault should be able to say who controls the Registro.br credentials, which exact aggregate and more-specific routes are intended, how maximum lengths are chosen, and how emergency origin changes would be approved.
RPKI is only one control. It does not secure a virtual machine, authenticate support staff, prevent a storage failure or prove physical path diversity. Its value here is narrower and useful: unlike a broad reliability claim, route authorisation can be checked independently and monitored continuously. A buyer can include current route status, authorised origins and change notification in network acceptance criteria without pretending they are a complete security programme.
"Tier III" and Brazilian locality need service-specific evidence
The website's leading claim is "Data Center Tier III in the heart of Brazil." It also promises lower latency, rapid response, onsite support and proximity to customers. The Centre-West can offer a meaningful locality choice for organisations operating far from Brazil's dominant coastal infrastructure markets. A nearby team and facility may shorten a physical intervention and keep certain workloads within the country.
The captured evidence does not identify whether "Tier III" refers to a certified design, a certified constructed facility, an operational certification or the company's description of a topology. It gives no certifying organisation, certificate number, facility address, issue date or scope. The legal headquarters on Rua Cinco is not automatically the data-centre site. Buyers should request the applicable certificate or, where the phrase describes an engineering target rather than certification, the single-line diagrams and maintenance design that substantiate it.
The same discipline applies to locality. A Brazilian company, a Cuiaba address and a Centre-West marketing statement do not locate every production disk, replica, backup, monitoring record, support attachment or identity service. CoreVault's S3, file-storage and layered-backup offers make that map especially important. A primary virtual machine can remain local while a backup copy, software support channel or telemetry system crosses a region or legal boundary.
The order should name the physical site for each service, the jurisdiction of every copy, the companies that operate it, subprocessor access, encryption-key control, retention and deletion evidence. It should distinguish customer-selected external destinations from CoreVault-managed ones. Locality becomes operating assurance when it survives failover, support and recovery, not when it appears only as the location of the supplier's office.
Facility evidence should be equally concrete. Customers need the usable power design, generator autonomy, cooling redundancy, fire zones, access controls, maintenance procedure and capacity reserved for the ordered service. A site visit can verify physical conditions, but documents must still explain which components are included and which are shared. The goal is not to challenge a label for its own sake; it is to connect that label to the workload and remedy the customer is buying.
Direct support needs clocks, authority and proof of recovery
CoreVault puts people at the centre of its proposition. It advertises onsite support, 24x7 monitoring, direct technical attention, assisted implementation and an ongoing relationship. For a regional customer, access to people who understand local operations and can reach hardware may be a real alternative to a distant queue.
The page does not publish a response target, severity model, escalation path or restoration commitment. Continuous monitoring is also not the same as continuous staffed response. A monitoring system may generate an alert without identifying who can change a route, replace hardware, unlock a backup or communicate with a customer. "Direct" support can describe a useful relationship, but it needs a clock and an accountable role before it can be measured.
A production agreement should separate acknowledgement, technical engagement, workaround, restoration and final resolution. It should define when each clock starts and pauses, the authority available on every shift, the route to a duty manager, maintenance exceptions and the remedy for a missed target. For onsite work, it should cover identity checks, remote-hands scope and approval limits. For restores, it should specify who can request one, how the request is authenticated and how success is tested at the application layer.
The strongest recovery proof is an observed exercise using the proposed service. A customer should see a protected copy selected, restored into an isolated environment and validated against agreed recovery-point and recovery-time objectives. The exercise should expose dependencies on credentials, network paths, licences and particular people. A backup product name or completed-job message is not equivalent to a recoverable business service.
Support quality should remain visible after launch. Monthly evidence can include alert-to-acknowledgement time, incident-to-restoration time, backup failures, restore-test results, capacity headroom, missed commitments and post-incident actions. That record allows CoreVault's human-support claim to become a demonstrated local advantage rather than an unmeasured expectation.
Treat the name as a credible lead, then contract the controls
CoreVault's public record is stronger than a name floating free of accountable infrastructure. An active Brazilian legal entity, matching CNPJ in authoritative network records, LACNIC membership, a live ASN and globally visible IPv6 routing all support the conclusion that COREVAULT DATACENTER LTDA has a real and recent network operating footprint. The service catalogue is consistent with that role and addresses a clear regional need.
The record is also early and incomplete. The public network began appearing in late 2025. The visible site leaves the legal brand relationship implicit, labels the facility Tier III without public verification details, presents service categories without technical schedules, and promises human support without measurable clocks. The reviewed public record contains no customer performance history, public status history or restore result.
Before a critical workload moves, a buyer should close six files: legal and brand roles; facility and Tier evidence; per-copy data location; IPv4, IPv6 and route-security design; support authority and severity clocks; and a witnessed recovery plus export test. Each file should identify an owner, observable measure and remedy. Independent monitoring and customer-held configuration and data exports should remain available if the supplier relationship fails.
That is not a reason to reject a regional provider. It is how a regional provider's potential strengths become comparable: proximity becomes a named facility and intervention time; human support becomes an escalation result; infrastructure becomes a capacity schedule; backup becomes a successful restoration; and network ownership becomes an authorised, monitored route. CoreVault has enough public evidence to enter diligence as an attributable Brazilian operator. Its name should become operating assurance only after those controls work for the service actually ordered.

