Summary

  • CLOUD COLIBRI S.A has a specific public identity in internet registries. LACNIC records the company in La Ceiba, Honduras as the active holder of AS269866 and 2803:6760::/32, with Julian Palacios named as legal representative and administrative, technical and abuse contact.
  • The network is not merely reserved. RIPEstat observed the IPv6 /32 originated by AS269866 throughout July 1-15, 2026, visible to all 322 reporting IPv6 peers at the captured point. Its exact origin also returned valid under RPKI, with an authorisation limited to the /32.
  • The service proof is much thinner. The provider advertises KVM and Xen virtual servers, automated resizing, managed hosting, daily backup, 24-hour support and 100% uptime, but its pages retain a 2019 footer, provide no named customer outcome or service-status history, and route the public website over a different operator's IPv4 aggregate.
  • Location and accountability need contract-level answers. A Honduran registration address does not locate customer data; the registry also publishes a New York technical contact, third-party measurements place visible IPv6 endpoints in New York, and the public billing contact returned a server error during review. Buyers need a copy-by-copy data map, a current network diagram, recovery evidence and severity-specific support obligations.

A real resource holder sits behind the name

Cloud buyers often encounter a company name before they encounter evidence that the company controls any infrastructure. CLOUD COLIBRI S.A clears that first hurdle. The LACNIC record for AS269866 identifies an active direct allocation to CLOUD COLIBRI S.A, with an address on Boulevard 15 de Septiembre next to INFOP in La Ceiba, Honduras. The autonomous system was registered on December 5, 2019. The record names Julian Palacios as legal representative and assigns the same contact administrative, technical and abuse roles through an email address on cloudcolibrisa.com.

The LACNIC record for 2803:6760::/32 makes the identity more concrete. It marks the IPv6 allocation active, dates its registration to October 24, 2019 and names the same company, address and representative. The allocation and autonomous system therefore join through more than a similar label: they share the registry organisation handle, public contact chain and legal representative.

That is useful attribution, but its scope matters. An internet registry is authoritative for the resource registration; it is not a corporate register, audited ownership statement or facility certificate. The public record does not expose incorporation details, shareholders, signing authority, accounts or the relationship between CLOUD COLIBRI S.A and every asset used to deliver service. A customer should still obtain a current Honduran company extract, verify who may bind the company and ensure the contracting name matches the resource holder it expects to operate the network.

The distinction is practical, not ceremonial. If an incident involves address reputation, route control or abuse handling, AS269866 gives the buyer an identifiable network operator and a published escalation contact. If the dispute instead involves a failed backup, an unavailable hypervisor or an unpaid refund, the registry cannot establish which company owned the server, employed the engineer or accepted the service obligation. One identity record can support a chain of accountability without completing it.

The catalogue exposes an operating model, but not its results

The Cloud Colibri home page describes virtual machines abstracted from physical hardware. It says each server receives guaranteed CPU according to size, may use spare host capacity when available, and can be resized through a click or API call. The stated resize process briefly takes the server offline, changes its RAM, disk and CPU allocation, and restarts it automatically. That is a concrete control surface: customers can infer that the provider sells mutable virtual machines rather than only static shared-hosting accounts.

The services page gives the offer a recognisable shape. It lists six KVM and Xen plans with one or two CPU cores, 10 GB to 50 GB of disk, 1 GB to 4 GB of guaranteed memory, Linux or Windows, root SSH or RDP access, managed hosting, daily backups with one free restore a month, fault tolerance and unlimited data transfer. Displayed monthly prices run from $11 to $33. The page also says workloads are distributed across a cluster, with servers assigned individual tasks so an account does not depend on one machine.

These details are better than an empty cloud label. They reveal virtualisation choices, customer privileges, a resizing mechanism and at least one backup entitlement. They also leave the responsibility boundary unusually open. Root access suggests that the customer can administer the operating system; "managed" hosting suggests that the provider may do so. The pages do not say who patches the guest, manages privileged keys, watches application health, approves an emergency reboot or owns the configuration after termination.

The backup promise has similar ambiguity. "Daily" does not identify the capture time, retention period, storage location, encryption authority, immutability or recovery-point objective. One free restore a month is a commercial allowance, not a recovery-time commitment. A buyer needs to know whether additional restores are merely chargeable or operationally limited, whether a restore can be requested around the clock, how identity is checked before overwriting data and when the provider last recovered a comparable server successfully.

The site makes substantial facility claims too. It lists uninterruptible power, supply from multiple grids, a high-capacity Caterpillar generator, dedicated circuit breakers, biometric controls, motion sensors, guard patrols, alarms, police notification and continuous access for system administrators and onsite monitoring staff. None of those statements is accompanied by a facility name, address, capacity figure, maintenance record, audit, photograph tied to the site or test result. They define diligence questions; they do not answer them.

The age and condition of the sales surface also matter. Both public pages were live during review, yet each retained a 2019 copyright footer. The linked customer contact endpoint returned an HTTP 500 server error at capture. A stale footer does not prove stale infrastructure, and a transient application fault does not prove that support is unavailable. Together, however, they make it unsafe to treat published plans, prices or ordering paths as current without confirmation from an accountable person.

AS269866 is small, visible and cryptographically authorised

The strongest present-tense evidence is the route itself. RIPEstat's announced-prefix observation showed 2803:6760::/32 originated by AS269866 for the full July 1-15, 2026 observation window. The routing-status record dated the first observed origin to January 6, 2022 and the latest to July 15, 2026. At the captured point, 322 of 322 reporting IPv6 peers saw the route.

That visibility establishes a durable, globally propagated control-plane presence. It does not establish how many customers use the prefix, how much traffic it carries or whether applications respond reliably. A /32 is a large IPv6 allocation in address terms, but address count is especially misleading in IPv6: it should never be converted into server count, utilisation or commercial scale.

The route also has a positive security signal. RIPEstat's RPKI validation returned valid, backed by a route-origin authorisation naming AS269866 for the exact /32 with a maximum length of 32. Networks that enforce route-origin validation can therefore verify that this aggregate is authorised to originate from the company's ASN.

The maximum-length setting is conservative: it authorises the aggregate, not arbitrary more-specific routes. That can reduce accidental exposure, although it also means an emergency or traffic-engineering announcement longer than /32 would need a changed authorisation to validate. RPKI does not protect a hypervisor, encrypt data, measure latency or prevent every route leak. It answers one narrow and valuable question: whether the observed origin is cryptographically consistent with the resource holder's published intent.

The network has a narrow visible dependency. RIPEstat's neighbour observation found one adjacent network on July 15, AS265680. IPinfo identifies that network as HNTELCO S.A and classifies AS269866 as a single-homed autonomous system. Public collectors do not see every private interconnection or dormant backup, so this is not proof that only one physical circuit exists. It does show that the source set contains no independently visible second path.

For a cloud workload, the next questions are straightforward. Does AS269866 have a second transit provider, and if so is that path normally visible or only activated during failure? Do circuits enter the building through independent ducts? Is the valid RPKI authorisation updated as part of failover? Has the company tested losing AS265680 without losing management access, DNS or customer routes? A visible upstream is service evidence; a tested, independent alternative is resilience evidence.

The public website uses a different IPv4 operating path

AS269866's own visible resource footprint is IPv6-only. IPinfo's AS269866 profile reports no IPv4 prefixes for the ASN and one IPv6 upstream, AS265680. Meanwhile, cloudcolibrisa.com and its billing subdomain resolved during review to 45.186.152.254, an IPv4 address outside AS269866.

The registry trail does not make that address unrelated. The LACNIC record for the containing 45.186.152.0/23 says the range was reallocated to Julian Palacios and publishes the same New York address, telephone number and cloudcolibrisa.com NOC contact that appear in the AS269866 contact chain. But RIPEstat's route view sees the address only through the less-specific 45.186.152.0/22, originated by AS266842. LACNIC identifies AS266842 as HNHOSTING.NET S.A., another organisation registered in La Ceiba with a different legal representative.

The fairest conclusion is limited. There is an observable contact relationship between Cloud Colibri's public website address and its named representative, while the route is operated under HNHOSTING.NET's ASN. The sources do not establish common ownership, a reseller agreement, a hosting contract or the division of operational responsibility between the two companies.

This separation matters because the website cannot serve as a demonstration that AS269866 delivers Cloud Colibri's advertised virtual servers. It proves that a company-branded service page is reachable over an IPv4 resource associated with its representative. The live IPv6 route separately proves that the company controls an active autonomous-system presence. A buyer should ask which ASN and prefixes its own server will actually use, who handles an IPv4 abuse or route incident, and whether the management portal depends on a network outside the service's advertised resilience boundary.

The split can be perfectly ordinary. Small providers often combine owned addresses, reallocated space, upstream transit and hosted control systems. Assurance comes from documenting that combination: resource holder, route origin, upstream, DNS operator, portal host, mitigation provider and escalation owner. Without that map, a customer cannot tell whether a fault in one company affects only the marketing site or the path to its production server as well.

Honduras is an identity anchor, not a data-location answer

Cloud Colibri's resource registration is Honduran. Both the company and AS269866 are associated with La Ceiba in LACNIC, and the company also appeared among the Honduran organisations in LACNIC's 2024 electoral register. Those facts support a Honduran institutional identity. They do not locate a rack, disk, backup or support session.

The public record points across jurisdictions. LACNIC gives the organisation a La Ceiba address but gives its named technical, administrative and abuse contact an address at 25 Broadway in New York. IPinfo says the network is registered in Honduras while the IPv6 endpoints it could measure were in the United States; its recent pingable samples were observed in New York. The IPv4 space serving the official site is also reallocated to the named representative at the New York address.

IP geolocation is an inference, not a facility deed. Addresses can be registered in one country, announced elsewhere, tunnelled, anycast or labelled incorrectly by a database. A one-millisecond probe observation from New York is consistent with nearby infrastructure but does not identify the building or who owns the hardware. The correct takeaway is not that Cloud Colibri's service is definitively in New York. It is that the public record does not justify an assumption that customer data remains in Honduras.

A customer with residency, sovereignty or latency requirements needs a data map for the purchased plan. It should locate primary disks, replicas, daily backups, control panels, authentication records, monitoring data, ticket attachments and provider logs. It should identify subprocessors and remote administrators, distinguish data at rest from data accessed during support, and explain what moves during failover. The contract should also say whether a customer may choose a location and what evidence proves deletion after exit.

The website's facility language makes this request more important. Claims about multiple power grids, generators, biometric controls and onsite personnel imply a physical site, but the page does not name it. The La Ceiba registration address may be an office, network contact or facility; the source set cannot decide which. Buyers should request the service address under confidentiality if necessary, then reconcile it with network latency, the backup location and the legal schedule.

Round-the-clock support needs a working route and a defined clock

The provider promises 24-by-7 customer support, access for system administrators and onsite monitoring personnel. LACNIC adds a public NOC email and telephone contact for routing and abuse matters. This is more accountable than an anonymous brand with no named person or network contact.

It is still not evidence of support performance. The site does not publish severity levels, response times, restoration targets, escalation steps or service credits. "24x7" may describe when a queue accepts messages, when a first-line agent responds or when an engineer with hypervisor and network authority is available. Those are materially different commitments during an outage.

The failed customer contact page sharpens the issue. A broken web form may be temporary, and existing customers may have a separate portal, email or telephone channel. But the public route offered for contact was not usable at the review point. Before purchase, a customer should test each channel, record the incident number, verify after-hours escalation and learn who can authorise network changes, restore data and approve a service remedy.

Local support also needs a labour model. The company says personnel monitor onsite continuously, but the source set does not establish headcount, shift depth, language coverage, employment location or dependency on one named contact. A credible schedule should identify role coverage rather than exposing private staff details: network operations, virtualisation, storage, security, billing and an incident commander. It should set handover rules and ensure that a serious event does not wait for one person to wake or travel.

Measured evidence can replace a large amount of sales language. Buyers should ask for response and restoration distributions by severity, recent maintenance notices, a redacted incident report and a witnessed restore. They should call the escalation route during onboarding and include portal failure in a tabletop exercise. Support becomes an operating control when its clock, authority and fallback channels survive the same failure that generated the ticket.

What buyers should require before production use

Cloud Colibri has more substance than a name alone. Its registry identity is specific, its IPv6 allocation is active, its route has been visible for years and its RPKI state is valid. The website describes a plausible small-provider offer with virtual machines, root access, automated scaling, backup and physical controls. These facts justify further diligence.

They do not validate the provider's strongest promises. The services page says customers can enjoy 100% uptime, yet publishes no measurement window, exclusions, maintenance treatment, dependency map or remedy. "Fault tolerance" is a feature label without a failure-domain design. "Unlimited" transfer has no fair-use or port-capacity definition. A daily backup without retention and restore results cannot be priced as recovery assurance.

A production order should therefore attach evidence to each claim. The legal schedule should name the contracting company and its signing authority. The network schedule should list customer prefixes, route origins, IPv4 provider, upstreams, RPKI responsibility and tested failover. The infrastructure schedule should name the facility, power paths, hardware ownership and maintenance boundaries. The data schedule should locate every copy and administrator. The support schedule should define severities, clocks, escalation and service credits. The exit schedule should guarantee machine-image and data export in a usable format.

Customers should also seek proof that reaches beyond the provider's own pages: a reference for a comparable workload, an invoice or service record tying the proposed facility and network to the contracting entity, uptime data from an independent monitor, and a restore observed against the ordered plan. The absence of a named customer in the available public record is not proof that customers do not exist. It means prospective buyers should not borrow confidence from testimonials they have not seen.

The central judgement is balanced. CLOUD COLIBRI S.A is an attributable network resource holder with a small but genuine and well-authorised IPv6 presence. Its public service case is older, broader and less testable than that network evidence. The name can identify who should answer the first question. Operating assurance begins only when the company can answer the next ones with a current contract, a location map, working support and measured recovery.