Summary

  • HOSTING RED SAS has a clearer public identity trail than many small infrastructure leads: its privacy policy gives the legal name, NIT 830.092.494-1, Bogotá domicile, and administrative email, while LACNIC RDAP identifies the company as registrant of the active 45.169.253.0/24 IPv4 network.
  • The network evidence is narrower than a brand claim. The 45.169.253.0/24 block is registered to HOSTING RED SAS, but public BGP views show it announced by AS13489, a UNE EPM Telecomunicaciones autonomous system, and the LACNIC RDAP record for AS13489 names UNE EPM as registrant rather than Hosting Red.
  • Hosting Red's own pages describe a cloud, VPS, private-cloud, VMware, monitoring, disaster-recovery, and certified-support offer for mission-critical workloads. The strongest procurement question is not whether those words appear, but which guarantees apply to the exact order, service tier, data location, backup plan, and escalation path.
  • The service policies place major responsibility on the customer for security, backups, server administration, risk disclosure, and continuity planning. For serious workloads, Hosting Red is best assessed through documented runbooks, restore tests, support authority, and routing evidence rather than by the mission-critical label alone.

The useful starting point is identity, not branding

Hosting Red is easy to mistake for a simple hosting brand because the name is descriptive and the public site uses familiar cloud language. The more useful starting point is the legal and resource trail. Hosting Red's privacy policy identifies the responsible company as HOSTING RED SAS, gives NIT 830.092.494-1, lists a Bogotá address at Carrera 47A #95-56, office 306, La Castellana, and provides [email protected] as a contact address for personal-data matters. The same address and Colombian phone number appear in the company's public contact footer on its policy page and older Colombian site.

That identity trail matters because Hosting Red's customer-facing promise is not a low-stakes brochure claim. The company positions itself around infrastructure and platforms for customers that need security, confidentiality, privacy, certified support, and mission-critical continuity. On its about page, Hosting Red says it provides virtual datacenter services, VPS, private clouds, and cloud-format hosting for high availability and business-continuity needs. It says the company evolved from an older mass-hosting business called Coldatec, began operating under the Hosting Red name in 2001, and has supplied services to more than 700 customers across private-sector, IT, and government segments.

Those are vendor claims, not an independent audit. But they define the offer that buyers should test. A procurement team is not merely buying a domain, a shared hosting plan, or a virtual machine. It is being asked to believe that a Colombian provider can help run important workloads across compute, storage, network, support, recovery, and compliance-adjacent concerns. That is exactly where the evidence should get more precise.

The service surface is cloud, VPS, VMware, and support

Hosting Red's public service pages make a consistent claim: the company is not only selling commodity web space, but a managed infrastructure surface for business workloads. The main Colombian site lists Cloud Datacenter - HA, elastic cloud VPS, and VMware vSphere for critical applications. The same page describes high availability, load balancing, security, certified support, clustered services, all-flash SSD storage, a 10 Gb network claim, disaster-recovery capacity, and real-time monitoring of CPU, RAM, disk, and network.

The VPS page sharpens the pitch. It presents Colombian VPS service for Windows and Linux, names high-availability clusters, disaster recovery, public gigabit speed, low-latency routing, and VMware vSphere Enterprise. It also describes automatic live migration when a physical failure is detected, an adjustable recovery-point objective over 30 days, and geographic availability of data in Colombia, the United States, and Canada, with latency figures shown for those locations.

For a buyer, this is promising and demanding at the same time. The page suggests more operational engineering than a basic virtual-server reseller. But it also creates questions that cannot be settled by product labels. Does the customer receive a managed operating system or only virtual infrastructure? Are firewall rules, patching, database administration, monitoring response, application recovery, and evidence retention included? Does the VMware HA language apply to every VPS plan or only a particular order?

Is the Colombia, U.S., and Canada location claim a selectable service design, a disaster-recovery option, or a general platform statement?

The site's "talent and certifications" material adds another useful but bounded signal. Hosting Red says it is a VMware Professional partner and Microsoft Service Provider, and that it supports those products directly for customers. That helps explain the VMware and Microsoft-heavy framing. It does not remove the need to verify which staff, queue, and service level cover a specific incident.

The network clue is real, but it is not a standalone-AS story

The strongest technical clue in the frozen evidence is not a large autonomous system. It is a small, specific IPv4 resource. LACNIC RDAP for 45.169.253.0/24 lists the network as active, allocated on February 13, 2019, with HOSTING RED SAS as registrant. The same record gives the Bogotá address, the company phone number, and an administrative, technical, and abuse contact using a hostingred.com email address. It also shows reverse delegation to nameservers under hostingred.info.

That record is important because it ties Hosting Red to a public internet-number resource. It is not simply a page saying "cloud" or a directory listing repeating a company name. It is registry evidence that Hosting Red is attached to a /24 IPv4 block, the kind of resource that can carry hosted services, customer applications, mail endpoints, management surfaces, or internal platform functions.

The routing view is more cautious. Hurricane Electric's BGP page for 45.169.253.0/24 shows the prefix announced by AS13489, with the origin registrant displayed as UNE EPM TELECOMUNICACIONES S.A. and the prefix registrant as HOSTING RED SAS. It also marks IRR and RPKI validity on that view. bgp.tools for AS13489 likewise includes 45.169.253.0/24 with the description HOSTING RED SAS among prefixes originated by AS13489. In LACNIC RDAP, AS13489 is registered to UNE EPM TELECOMUNICACIONES S.A., with registration dating to 1999 and a last-changed timestamp in 2024.

The most careful reading is that Hosting Red has a visible allocated prefix, while public BGP evidence in this pass did not verify a Hosting Red autonomous system. The route appears to sit under a larger Colombian operator's AS. That may be perfectly ordinary for a regional infrastructure company. It can reflect upstream routing, managed connectivity, or a service relationship. But it changes the assurance question. Buyers should not infer that Hosting Red controls all routing independence simply because it has a network block.

They should ask who originates the routes, what upstream diversity exists, who can change filters or route objects during an incident, and whether service credits or escalation rights depend on a third-party carrier.

The contract makes the customer part of the control system

Hosting Red's public policies are unusually useful because they explain where responsibility moves from the provider to the customer. The service policy page says all services are paid in advance, that server, VPS, and cloud billing cycles are set by the purchase order and service desk, and that pricing may be adjusted annually with inflation while dollar-priced services are converted using the Colombian exchange rate on the order or invoice date. That is commercial detail, but it matters for cloud governance because cost predictability is part of operational control.

The technical clauses are more important. Hosting Red says it monitors datacenter network performance, customer internal network performance, and internal hypervisors, and supplies redundant DNS without extra cost when a customer has infrastructure inside Hosting Red. It also says the customer must follow the help-desk process, keep technical contacts current, report unauthorized account use, disclose risk components and operational criticality where applicable, and respect the service policies tied to each order.

The policy does not let customers treat the provider as a blanket operations department. For dedicated servers, it says the customer's leased space, administration, program installation, implementation, and maintenance are handled directly by the customer. It says the customer is responsible for server security and security patches unless additional administration services have been contracted, and that Hosting Red will not apply a patch without a ticket and a mutually agreed maintenance window.

It also restricts penetration testing against Hosting Red infrastructure, while allowing testing on the customer's own virtual servers only after the customer gives technical details about affected public IPs, fully qualified domain names, and methodology.

That is not inherently negative. In infrastructure contracts, clarity about responsibility is valuable. But it means buyers must map their actual operating model. If they need patching, backup validation, firewall management, database tuning, incident response, or security testing support, those expectations need to be explicit in the order and visible in the service desk. Otherwise the customer may have bought infrastructure while assuming managed operations.

The uptime language is bounded by internet and liability clauses

Hosting Red's public policy says it makes its best effort to keep servers broadly available with the least interruption, expecting 99.9 percent uptime so the service can run 24 hours a day, seven days a week, except for incidents outside Hosting Red's control and subject to the purchase order. It then defines the credit path more narrowly: if an unexpected and demonstrated failure continues for 24 hours after customer notification, the customer can receive a proportional return for the hours of unavailability.

The same policy says Hosting Red is not responsible for damages to the customer or third parties from service absence or malfunction, and caps direct or immediate damages at 30 percent of the current billed period.

This is the kind of clause that separates marketing availability from recoverable assurance. A public uptime percentage can be useful, but the operating value depends on evidence: how uptime is measured, who declares the incident, when the clock starts, what exclusions apply, whether upstream congestion counts, and whether the remedy is meaningful for the workload. A revenue site, regulated database, or SaaS dependency cannot use a limited service credit as its only continuity plan.

The network wording reinforces that point. Hosting Red's policy says its IP network connects to other Colombian and global IP networks, that traffic capacity varies across available links, and that Hosting Red is not responsible for interruptions derived from other networks. That is a realistic statement about the internet. It is also a procurement signal. If an application needs predictable reachability, the buyer should ask for route diversity, upstream dependencies, maintenance communications, monitoring evidence, and a failover plan that has been tested from outside the Hosting Red environment.

Backup and data locality need documentary precision

The most important risk surface is backup responsibility. Hosting Red's older Colombian policy says backups and disaster recovery protect customer data only in specified scenarios, must be contracted and explicit in the purchase order, and do not exempt the customer from maintaining its own backups and controls. It says the customer remains responsible for backing up email, websites, databases, and virtual machines before altering data and when leaving the service.

It also says Hosting Red is not required to create, recover, or keep backups after the defined retention period, and cannot guarantee that a backup contains exactly the data the customer needs at a specific moment.

The newer policy is even more operationally specific. It advises customers to own a three-copy backup strategy, with one primary copy in the customer's possession, a second near production, and a third in an alternate datacenter. It says retention depends on the backup plan, including 30 days for one backup service, 15 days for lower-frequency backup, and weekly preventive copies. If the customer has contracted backup or disaster recovery and an unexpected event occurs, Hosting Red says it will restore the most recent and appropriate copy if available, while the customer accepts the risk of lag, data loss, or overwriting.

That makes the control question concrete. A buyer should not ask "does Hosting Red do backups?" as a yes-or-no item. The better question is which backup product is in the order, where each copy is stored, what the actual RPO and recovery-time objective are, whether databases and mailboxes are application-consistent, who can trigger restoration, and whether a restore test has been performed. Hosting Red's VPS page markets an adjustable RPO and disaster recovery; the policy text says responsibility and retention depend on the contracted plan. Both can be true, but only the order and a test prove the working design.

Data locality deserves the same discipline. Hosting Red's service pages speak to Colombian cloud hosting, Habeas Data, and geographic availability across Colombia, the United States, and Canada. Those are relevant signals for customers that care about jurisdiction, latency, and support proximity. They are not, by themselves, a service-specific data-residency guarantee. A customer with strict locality requirements should require a written statement of primary hosting location, backup location, disaster-recovery location, support access, subcontractors, and any carrier or facility dependencies.

Support accountability is the difference between a page and an operation

Hosting Red's public pages give several support signals. The company lists a Bogotá phone number, a Miami number, sales contact, customer registration links, a payment portal, a support portal, tutorials, and a customer-facing account environment. It says it helps customers solve critical problems and points to VMware, Microsoft, and cPanel support capabilities. Its about page says it accompanies customers through production go-live with trained professionals for mission-critical environments.

Those signals are valuable because local support labour is often the reason a regional cloud provider wins against a larger platform. A Bogotá team that understands the customer's language, business hours, invoices, and application stack can solve problems that a distant self-service console leaves untouched. That is especially true for small software vendors, integrators, public-sector contractors, and companies that still run Windows, cPanel, or VMware-era workloads alongside cloud-native systems.

But support is only assurance when it has authority. Can the help desk restart a VM, change a route, escalate to UNE EPM, restore a backup, apply a patch, provide incident evidence, or approve a maintenance window? Are customer contacts kept current enough for urgent work? Is the person who answers WhatsApp or a phone line authorized to act on production? Are after-hours incidents covered by a specific support plan? The public evidence shows a support front door; the operating proof is the escalation path behind it.

Hosting Red should be evaluated as a verifiable regional infrastructure provider

The right conclusion is neither dismissal nor blind trust. Hosting Red has more public substance than a name-only lead: a Colombian legal identity, long-running domain, public service pages, policy material, a LACNIC-registered IPv4 block, and visible association between that block and routed internet service. It also has a product story that fits a real market: companies that want Colombian support, VMware and Microsoft familiarity, VPS and private-cloud control, and help turning infrastructure into a production environment.

The caution is that mission-critical language can outrun the evidence if buyers do not pin it to a contract. Hosting Red's policies make clear that customers retain major duties for server administration, security, backups, continuity planning, risk disclosure, and data governance unless they have explicitly bought additional services. The routing evidence shows a Hosting Red-registered prefix announced through another operator's AS, so internet reachability questions belong in the diligence checklist.

The data-location language is useful, but should become a service-specific statement before it supports compliance or sovereignty claims.

For a low-risk website or a modest VPS, the public evidence may be enough to justify a sales conversation. For production systems, buyer diligence should be narrower and tougher: confirm HOSTING RED SAS as the contracting entity and invoice issuer; attach the exact service plan and SLA to the purchase order; document the RPO, backup retention, and restore procedure; verify where production and backup data live; ask who originates and protects the 45.169.253.0/24 route; test support escalation; and keep an exit plan outside the same account.

Hosting Red's public footprint gives customers enough evidence to ask precise questions. That is the best use of the name. Assurance starts when the identity, network record, service policy, support queue, and recovery test all tell the same story.