Summary

  • Chilecom's public identity is unusually well joined for a regional host. Its website address, telephone and support email match the contact attached to LACNIC's active 200.63.96.0/21 allocation, while a 2026 municipal record names the same company and Chilean tax identifier as the supplier of a transparency-site hosting renewal.
  • The network evidence is real but structurally important. RIPEstat observed all eight /24 blocks within Chilecom's /21 being announced throughout July 1-15, 2026 by AS265831. LACNIC registers that ASN to SOC. COMERCIAL WIRENET CHILE LTDA., not Chilecom, although the two records share an address and legal representative.
  • The provider publishes concrete facility claims: a Santiago site, a 40 Gbit internal network, domestic and international links, a 100 kVA UPS, a 100 kVA generator, automated and off-site backups, physical controls and a 99.5% uptime headline. These are useful specifications to test, not measured results.
  • Buyers should define the service one workload at a time. Contract schedules need to identify the responsible company, route operator, covered availability component, data and backup locations, recovery objectives, privileged access, support clock, escalation path, exit format and evidence delivered after an incident or restoration test.

A name, an address block and a customer record point to the same operator

A hosting buyer needs to know which company takes the order, which organisation controls the internet resources and which team answers when a service fails. Those identities are often blurred on regional provider websites. Chilecom supplies enough public detail to make a strong first join.

The BTW directory profile places CHILECOM DATACENTER LIMITADA in Chile and associates it with managed network, cloud, data-centre, colocation and hosting activity. Those service labels are marked as not yet assessed, so the directory is best read as the subject anchor rather than proof of delivery. The independent attribution comes from the provider and number-resource records.

Chilecom's public website gives an address at Oceano Pacifico Norte 8496 in Penalolen, Santiago, a central telephone number ending 2938 1240, and [email protected]. It markets web hosting, Linux and Windows VPSs, dedicated servers, domains, migrations and administration. The same telephone and email appear in LACNIC's operational contact for an active IPv4 allocation. This is a useful identity chain because it connects the sales surface to the people responsible for a registered network resource.

The LACNIC record for 200.63.96.0/21 names CHILECOM DATACENTER LIMITADA as registrant and Fernando Zamorano as legal representative. A /21 spans 200.63.96.0 through 200.63.103.255, or 2,048 IPv4 addresses. LACNIC registered the allocation in May 2008, marks it active and shows the registrant record as updated in September 2024. These facts establish resource responsibility. They do not reveal how many addresses are occupied, how many customers use them, where the attached servers sit, or whether the current company is in legal and financial good standing.

There is also service evidence outside Chilecom's own pages. A Municipality of San Pedro de Atacama procurement record names CHILECOM DATACENTER LIMITADA, RUT 76.653.886-K, as contractor for renewal of web hosting for the municipal transparency system. The record gives a value of CLP 269,800 and dates from February 16, 2026 to May 24, 2027. It also names Gladys Zamorano Carrasco and Fernando Zamorano Carrasco in the supplier ownership field.

That purchase is modest, but its evidentiary value is specific. It shows a named public body buying a defined hosting service from the legal company in 2026. It does not show the system's traffic, architecture, availability, security or customer satisfaction. The record describes an annual renewal even though its stated end date is more than a year after the start, a detail worth reconciling against the purchase order before using it as a template for contract duration.

Together, these records support a reasonable conclusion: Chilecom has a traceable public identity, a provider-sized address allocation and at least one recent named service engagement. That is a firmer starting point than a brand page alone. It is still a starting point, because operational assurance depends on who controls each service layer and what evidence the customer can obtain.

The route operator is closely linked, but it is not the same registrant

Chilecom's network footprint contains a distinction that should be written into any serious service review. The company holds the address space, but a separately named organisation holds the autonomous system currently originating it.

RIPEstat's announced-prefix observation for AS265831 listed all eight constituent Chilecom ranges, from 200.63.96.0/24 through 200.63.103.0/24, as announced throughout the returned July 1-15, 2026 window. Each /24 contains 256 addresses. Splitting the allocation into eight visible routes is consistent with active network use and lets routing policy treat the blocks separately. It is not a measure of occupied servers, traffic, latency, packet loss or application uptime.

The LACNIC record for AS265831 identifies the ASN registrant as SOC. COMERCIAL WIRENET CHILE LTDA. The autonomous system was registered in September 2017 and is marked active. Its record names Fernando Zamorano as legal representative and gives the same Oceano Pacifico Norte locality used in the Chilecom records. RIPEstat also shows AS265831 originating other address blocks, so it is not merely a label for Chilecom's /21.

This evidence indicates a close operating relationship; it does not define it. The public material does not say whether Wirenet is a sister company, supplier, network operating company or asset holder, nor which legal entity employs the network staff and owns the routers. Shared representation and location reduce attribution ambiguity, but they do not make the two companies interchangeable.

Route authorisation offers one positive control-plane signal. RIPEstat's RPKI validation for AS265831 and 200.63.96.0/21 returned valid at capture. The applicable route-origin authorisation permits AS265831 to originate the /21 down to a maximum length of /24, covering the eight visible routes. This makes the intended origin cryptographically checkable by networks that perform route-origin validation.

RPKI does not prove that packets reach Chilecom's servers, that the links are diverse, or that routing changes are well governed. It validates an origin relationship, not the commercial and operational arrangement behind it. A buyer should therefore ask who controls LACNIC and RPKI credentials, who can change BGP policy, how emergency announcements are approved, which company is accountable for a routing incident, and whether the service survives loss of the AS265831 operating team.

The same distinction applies to connectivity claims. Chilecom's data-centre page names GTD Chile Teleducto and Entel Empresas and advertises redundant BGP fibre links, described as 10GB nationally and 1GB internationally. Network capacity is normally expressed in bits per second, so the published units need clarification rather than silent conversion. The page also does not show circuit identifiers, normal utilisation, committed rates, building entrances, failover policy or test results. Named carriers and visible routes support plausibility; only a current topology and a witnessed failover can establish resilience for the customer's service.

The facility description is concrete enough to challenge

Chilecom says it operates its own data centre at the Penalolen address. Its facility page describes a 40 Gbit internal network, firewalls, IDS and IPS, anti-DDoS measures, temperature and humidity sensing, remotely controlled air conditioning, controlled access, cameras and a continuous alarm. For power, it lists a 100 kVA online double-conversion UPS, batteries for up to 30 minutes and a 100 kVA generator with automatic transfer and 12 hours of supply.

Specific numbers are more useful than adjectives because they create testable questions. Yet capacity at one component does not describe the whole power path. A 100 kVA UPS and 100 kVA generator do not disclose the live IT load, cooling load, reserved headroom, bypass arrangement, maintenance condition, battery age, generator derating, fuel-replenishment plan or whether a single fault can bypass both protections. Twelve hours is a fuel claim, not an availability result.

The due-diligence request should therefore move from inventory to performance. Customers should ask for the latest loaded transfer test, UPS and battery maintenance, generator run history, alarm escalation, cooling redundancy, fire-system inspection and a diagram showing utility, transfer, UPS, distribution and rack feeds. For dedicated or virtual servers, the schedule should identify which equipment and rack are covered. For hosting, it should say whether the headline power design protects every platform component, including network, storage, authentication and backup services.

Physical security has the same boundary. Cameras and controlled access indicate sensible controls, but they do not specify visitor approval, escorting, access-log retention, former-staff removal, media handling or customer audit rights. A customer does not need the provider to publish sensitive facility detail to the world. It does need confidential evidence proportionate to the workload and a contractual right to be told when the control changes.

Chilecom's 99.5% uptime headline also needs careful treatment. If measured across a 30-day month without exclusions, 99.5% allows about three hours and 36 minutes of unavailability. The website does not state the covered component, measurement point, calculation period, exclusions, maintenance treatment, monitoring source or service credit. It therefore cannot be read as achieved availability or as a complete service-level commitment.

For a simple website, that tolerance may be commercially acceptable. For an authentication service, payment endpoint or municipal public-information system, the same figure may be too loose, especially if network, power, hardware and support interruptions are measured separately. The buyer should choose the target from the workload's consequences, then require a monthly report and a remedy tied to that exact measurement.

Backup and locality are separate promises

Chilecom's local footprint is commercially relevant. The provider identifies a Santiago facility and sells in Chilean pesos. A buyer seeking lower latency, local contracting or Chile-based infrastructure has a clearer proposition than it would from an anonymous reseller. But local company, local address allocation and local server building are three different facts, and none establishes the location of every data copy.

The data-centre page says hosting receives automated daily, weekly and monthly backups, including email, databases, passwords and website files. It also says periodic backups are kept off site. The homepage separately advertises up to 15 days of hosting backup and says a VPS customer can request an image. VPS and dedicated-server backup is described as customisable rather than inherent in the base service.

Those statements reveal meaningful product boundaries. A hosting account appears to receive a managed retention service; a VPS or dedicated server may require an option and a customer request. What remains unclear is the actual schedule for each plan, retention generations, off-site region, storage operator, encryption, key control, immutability, tenant separation, failure alerting and restoration process. Keeping a copy away from the primary room is useful, but it can still share credentials, administrators, network dependencies or a metropolitan hazard.

A locality schedule should list primary data, replicas, backups, logs, support attachments, monitoring telemetry, identity records and billing data separately. For each, it should name the country, facility or cloud region, responsible company, subprocessors, access roles, retention and deletion evidence. It should also say what happens during an emergency restore. Without that map, the phrase "data centre in Chile" is a facility claim, not a complete data-residency commitment.

Restoration is the proof point. Buyers should agree recovery-point and recovery-time objectives for each dataset, run representative restores and retain the result. A screenshot that a job completed is weaker than evidence that an isolated environment booted, the database opened, application credentials worked and the customer could resume service. The schedule should also distinguish provider backup from the customer's independent copy so that an account dispute or provider-wide incident does not remove both recovery paths.

Automation changes who can act during failure

Chilecom's catalogue offers cPanel or Plesk for hosting, Linux and Windows VPSs, dedicated systems, migration help and an administration service. These tools can replace manual ticket work for routine account, domain, email and server tasks. They also create several control planes: the customer panel, server operating system, virtualisation layer, backup system, network edge and provider support console.

Public product descriptions do not set out API access, provisioning time, role separation, multifactor authentication, audit-log export, configuration rollback, image portability or approval rules for privileged intervention. That absence is not evidence that the controls do not exist. It means the buyer cannot infer them from the catalogue.

The practical question is who can complete each recovery step without waiting for another party. Can the customer reboot or rebuild a VPS, rotate a compromised credential, export an image, change reverse DNS, restore a mailbox or retrieve logs? Which actions require Chilecom, and which require the Wirenet network team? If an automated backup fails, who sees the alert and by when? If a migration is included, what validates completeness before the old service is retired?

An operating schedule should answer those questions as a responsibility matrix. It should name routine changes, emergency changes, approval authority, evidence retained and rollback ownership. It should also define the exit path: standard image and database formats, DNS handover, address changes, data-export window, deletion confirmation and assistance pricing. Local service can reduce distance to an operator, but it does not reduce lock-in unless the customer can leave with working data and configuration.

Support needs one clock, not several impressions

Chilecom presents a substantial contact surface. The website offers a central telephone line, email, ticketing, online support, tutorials and a knowledge base. It says assistance is available every day. The data-centre page also publishes office contact hours of Monday to Friday, 08:00 to 19:00. Those statements can both be true if channels or staffing differ, but the public pages do not explain the distinction.

For production service, "available" must be separated into acknowledgement, qualified response, workaround and restoration. A ticket queue may operate continuously while network authority, physical access or senior systems staff follow a narrower rota. The public material does not define severities, response targets, escalation contacts, after-hours coverage, remote-hands tasks, language coverage or service credits.

The municipal hosting engagement shows why this matters. A public transparency site can fail outside office hours and still need a named owner, even if the monthly service is inexpensive. A platform team with a database or customer-facing application needs stronger cover again. Buyers should test the published telephone and ticket routes before migration, run a tabletop incident, and require named escalation roles for network, power, server, backup and billing failures.

Support labour is also part of concentration risk. The close public relationship between Chilecom's allocation and Wirenet's ASN may produce efficient local coordination. It may also mean that a small group holds authority across customer service and routing. The customer should ask how on-call coverage, succession, credential recovery and supplier escalation work when the usual contact is unavailable.

The right conclusion is verified presence, conditional assurance

Chilecom's public record is stronger than its name alone. The company can be connected to a current website, an active LACNIC allocation, all eight visibly announced portions of that allocation, a valid route-origin authorisation and a recent municipal hosting purchase. Its facility page publishes enough engineering detail to support a serious diligence conversation.

None of that should be discounted. Nor should it be stretched. Registry records do not measure uptime; routes do not prove application health; a municipal purchase does not certify performance; carrier names do not prove physical diversity; a Santiago building does not locate every backup; and support channels do not establish restoration time.

The buying decision therefore turns on conversion. Chilecom and its customer need to convert public claims into a service map, current evidence and enforceable duties for the exact product ordered. If the provider can document the Chilecom-Wirenet responsibility boundary, show power and route tests, locate every data copy, demonstrate restoration, define the support clock and support an orderly exit, its local footprint can become operating assurance. Until then, the evidence proves a real provider and a real network presence, not the outcome of the next failure.