Summary

  • RACK SPHERE HOSTING S.A. has a coherent public identity trail: LACNIC records the Panamanian company as registrant of AS64107, the IPv4 block 45.225.135.0/24, and the IPv6 block 2803:6e20::/32, while the registry and company website use the same racksphere.io contact domain.
  • The routed footprint is real but compact. Hurricane Electric observed one IPv4 and one IPv6 prefix, with different peers visible for each address family; that is useful network evidence, not proof of datacenter redundancy, spare capacity, or a particular customer's route design.
  • RackSphere advertises dedicated servers in Panama, high-availability VPS, Layer 3/4 DDoS mitigation over GRE, IP transit, BGP sessions, backups, managed options, and custom architecture work. Its public offer is consultative and quote-led, so the order and technical schedule must define what is actually included.
  • The decisive diligence questions concern mechanism and authority: where workloads and copies reside, how availability is measured, what mitigation can absorb, who controls routing changes, what restoration has been tested, and which engineer can act during an incident.

The network identity is the strongest part of the case

A small infrastructure provider should first be judged on whether its public identity joins up. In RackSphere's case, the useful trail begins outside the marketing site. LACNIC's record for AS64107 identifies RACK SPHERE HOSTING S.A. as the registrant, classifies the number as a direct allocation, and dates the registration to November 15, 2017. The same record assigns administrative, technical, and abuse roles to a contact using [email protected]. The registrant is based in Panama, and the contact details were updated in early 2026.

The address records reinforce that identity. LACNIC assigns 45.225.135.0/24, a block of 256 IPv4 addresses, and 2803:6e20::/32, an IPv6 allocation, to the same company and contact. All three resources were registered on the same day in 2017. The alignment of legal name, resource holder, contact domain, and dates makes mistaken identity less likely than it would be for a hosting brand supported only by a website.

There is also continuity between an older network footprint and a newer current domain registration. The domain registration record for racksphere.io records a January 21, 2026 registration event and names RACK SPHERE HOSTING S.A. as registrant in Panama City. The current domain record is therefore much newer than the number resources. That chronology does not prove when the website first appeared, a relaunch, or any particular company history, but it does show why the current domain registration should not be mistaken for the age of the network identity.

This distinction matters in procurement. An autonomous system is evidence that an organisation can present routing policy to other networks. Allocated address space is evidence of resource responsibility. Neither is an uptime certificate, security audit, customer reference, or facility accreditation. The records establish who is visible at the network layer; buyers must still establish what that organisation will do for their workload.

RackSphere sells a network-centred infrastructure bundle

RackSphere's public service page describes a focused portfolio: dedicated servers in Panama, high-availability VPS, Layer 3/4 anti-DDoS protection through a GRE tunnel, IP transit, BGP announcements, and custom projects. The dedicated-server offer mentions current-generation processors, NVMe storage, bandwidth, and optional network-layer attack protection. The VPS offer adds dedicated or shared resources, snapshots and backups, fast scaling, and managed options. The network offer includes dedicated BGP sessions, announcement of customer-owned prefixes, multi-upstream support, monitoring, and integration assistance.

This is a different buying proposition from a large public cloud with a long catalogue, posted unit prices, and a mature self-service control plane. RackSphere asks a prospective customer to describe traffic, volume, service-level needs, and workload type so it can prepare a tailored proposal. It also invites technical documents and architecture diagrams after the initial contact. That points to a consultative sale in which the final design may matter more than the generic service label.

For some buyers, that can be the advantage. A regional provider can assemble a bare-metal host, routed address space, mitigation tunnel, migration work, and ongoing optimisation into one engagement. A buyer may avoid stitching together a hyperscale account, a transit contract, an external DDoS service, and a local implementation partner. The trade-off is that much of the operating contract remains invisible until the quote arrives.

The words "managed options" illustrate the boundary. They do not say whether RackSphere patches the guest operating system, manages hypervisors, rotates credentials, responds to monitoring alerts, restores databases, or only advises the customer's engineers. Likewise, snapshots and backups are listed together, although a snapshot kept in the same failure domain is not equivalent to an independently retained backup. A sound order should turn each broad noun into an owner, location, retention period, response target, and test.

The same applies to automation. The site says VPS resources can scale quickly, but it does not publicly describe an API, infrastructure-as-code provider, customer portal, autoscaling policy, image catalogue, or provisioning-time target. Teams that depend on repeatable deployment should ask RackSphere to demonstrate the actual workflow: who approves a change, how a server or route is provisioned, which actions are available to customers, how configuration is versioned, and how emergency changes are recorded. Bespoke engineering can be valuable, but it creates supervision cost when every routine action requires a ticket and a particular person.

AS64107 gives buyers a measurable routing surface

The routing evidence is compact enough to understand. Hurricane Electric's view of AS64107 observed two originated prefixes: the company's IPv4 /24 and IPv6 /32. Its July 15, 2026 snapshot showed 256 originated IPv4 addresses, a valid route-origin authorisation for the IPv4 prefix, and no invalid originated route in either address family. It observed AS49581 for IPv4 and AS6939, Hurricane Electric, for IPv6. IPinfo's AS64107 view also associated both networks with the autonomous system and listed those two organisations as peers and upstreams, while Cloudflare Radar independently identified AS64107 as RACK SPHERE HOSTING S.A. in Panama.

That is substantive evidence. RackSphere does not merely claim to know BGP; its name is attached to an autonomous system that was visible announcing both IPv4 and IPv6 space. The valid IPv4 route-origin state is also a useful control because it lets route validators reject announcements that conflict with the authorised origin.

But the evidence needs careful reading. One observed IPv4 route and one observed IPv6 route make a small public footprint. A /32 IPv6 allocation is vast in address-count terms, yet allocation size says little about deployed servers, utilisation, customer diversity, or physical capacity. The two observed upstream relationships are encouraging, but the address-family split in Hurricane Electric's view does not show two interchangeable paths protecting the same customer service. A buyer should ask whether its exact IPv4 and IPv6 routes have independent paths, whether both are monitored, how failover is triggered, and whether maintenance or failure at one upstream can isolate one address family.

RackSphere says it has a redundant backbone, multiple upstreams, redundant datacenters, and BGP options. The public routing views support the existence of upstream connectivity; they do not verify the claimed facility redundancy or a customer's path diversity. Useful proof would include a network diagram with facility and carrier boundaries, recent route visibility from multiple collectors, maintenance procedures, failover-test results, and a clear account of which party can change announcements during an incident.

There is another worthwhile control question around IPv6. Hurricane Electric's snapshot marked the IPv4 origin as RPKI-valid but did not mark the IPv6 origin as valid or invalid. That should be treated as a point to verify, not as evidence of a fault. Customers planning dual-stack production should ask for current route-origin authorisations, route objects, prefix filters, and monitoring for both protocols rather than assuming the IPv4 posture automatically extends to IPv6.

A Panama label does not settle data locality

RackSphere explicitly markets hosting in Panama. Its site describes Panama as a strategic position between North, Central, and South America and attributes regional latency advantages to cable and carrier connectivity. The legal entity, autonomous system, and registry records are all associated with Panama. Those facts support a genuine Panamanian operating identity.

They do not, on their own, locate every machine, backup, mitigation service, or support session. IPinfo's July 2026 network view estimated that AS64107's IPv4 footprint was split almost evenly between Panama and the Netherlands. IP geolocation is an inference assembled from routing, registration, measurements, and commercial datasets; it can lag moves or misread tunnelled and reassigned infrastructure. It should not be treated as a facility inventory. Here, it is a reason to demand documentary precision.

A customer buying "dedicated servers in Panama" should obtain the named facility or at least the city, operator, and contractual location of the hardware. It should identify where snapshots and backups are stored, where DDoS traffic is scrubbed, whether a GRE endpoint leaves the country, and where support personnel can access systems from. If disaster recovery uses another jurisdiction, that may improve resilience while changing regulatory and disclosure obligations. Data sovereignty is a design property of the whole service, not a country label attached to an ASN.

Latency needs similar discipline. Panama can be attractive for applications serving Central America, the Caribbean, or traffic moving between American regions. Yet geography is not a benchmark. Route choice, peering, congestion, mitigation detours, and the customer's own access networks determine observed performance. Before migration, buyers should measure round-trip time, jitter, loss, and application response from their real user and dependency locations, then repeat the test with protection enabled.

GRE mitigation protects a particular layer, not the whole application

RackSphere describes continuous Layer 3/4 mitigation delivered through a dedicated GRE tunnel, with monitoring, alerts, custom filtering, and production-integration support. That is a plausible way to protect an address range: traffic is diverted or announced toward a scrubbing service, unwanted network and transport traffic is filtered, and clean traffic returns through the tunnel.

The architecture has limits that should be explicit. Network-layer mitigation does not automatically stop abusive login attempts, expensive API calls, cache-bypass attacks, or other application-layer behaviour that looks legitimate to a packet filter. A GRE tunnel also creates dependencies on tunnel endpoints, route propagation, maximum transmission unit settings, return-path design, and the capacity between the scrubber and origin.

The site says the service is designed to absorb volumetric attacks while preserving latency, but it does not publish mitigation capacity, scrubbing locations, activation times, protected protocols, traffic-cleanliness targets, or service-credit terms.

The practical diligence exercise is a controlled attack-response test. The buyer should know whether protection is always on or activated after detection; which party announces the prefix; how quickly filters can change; who sees alerts; what happens if the tunnel fails; whether IPv6 receives equivalent protection; and which traffic classes are outside scope. A post-test report should show detection, diversion, packet loss, application health, and the time taken for an authorised engineer to act. That evidence is worth more than a generic anti-DDoS badge.

Availability and recovery need workload-level definitions

RackSphere says its infrastructure is designed for high availability, with proactive monitoring and availability commitments tailored to customer needs. Tailoring can be sensible because a single dedicated server, a VPS cluster, and a routed transit service fail in different ways. It also means there is no single public percentage that buyers can safely apply to every offer.

For dedicated hardware, the order should distinguish power, network, host, disk, and replacement commitments. For VPS, it should define whether high availability covers automatic restart after a host failure, storage continuity, live migration, or application-level health. For transit, it should specify port availability, packet loss, latency, route visibility, maintenance, and the boundary between RackSphere and upstream networks. Measurement source, exclusion rules, notification duties, remedy, and reporting access matter as much as the headline number.

Recovery is a separate promise. Snapshots help reverse a bad change; backups help recover from deletion, corruption, ransomware, or platform loss only when they are isolated, retained, and restorable. A buyer should request recovery-point and recovery-time objectives, encryption and key ownership, immutability where needed, geographic separation, retention, deletion procedures, and evidence from a recent restore. It should also keep an exit copy outside the same account and failure domain.

Cost comparison should include this operating work. A tailored regional service may beat hyperscale pricing for bandwidth-heavy or steady workloads, especially when it bundles addresses, support, and engineering. It may cost more than self-run colocation while removing hardware procurement and carrier coordination. The honest comparison adds the customer's continuing labour for monitoring, security configuration, restore testing, capacity planning, spend review, and vendor escalation. Low monthly infrastructure cost is not a saving if incident authority is unclear.

Human support is the final control plane

The public identity trail provides a direct technical contact, and the website invites architecture discussions rather than routing every buyer through an anonymous catalogue. That can be a meaningful advantage for a smaller provider. During a real outage, however, support quality is determined by authority and coverage, not friendliness at the sales stage.

LACNIC lists the same individual contact for administrative, technical, and abuse roles. This proves that a responsible contact is publicly attached to the resources; it does not reveal team size, duty rotation, response times, or separation of responsibilities. The website provides a contact email and quote form but does not publish a support portal, status page, escalation matrix, or incident-response schedule in the material reviewed here.

Before placing a critical workload, a customer should run a support drill. Open a technical ticket, escalate it after hours, verify identity checks, ask for a route or firewall change, and measure the time to reach someone authorised to act. Record who can power-cycle hardware, move a VPS, alter BGP policy, engage an upstream, activate mitigation, restore data, and communicate an incident. The exercise should also expose language coverage, handoff quality, and whether knowledge lives in runbooks or with one person.

The buying decision should follow the evidence boundary

RackSphere deserves to be assessed as a real network operator and infrastructure provider, not dismissed as a name-only lead. Its LACNIC resources, live autonomous system, routed IPv4 and IPv6 prefixes, route-origin control for IPv4, Panamanian identity, and detailed service surface create a credible basis for technical discussion. The company may be especially relevant to buyers seeking regional hosting, custom routing, network-layer attack protection, or engineering attention that a larger cloud does not readily provide.

The remaining gap is operating proof at customer level. The public evidence does not establish a particular facility configuration, workload uptime, mitigation ceiling, recovery outcome, automation interface, or support response. Those are not reasons to reject the supplier; they are the items a serious order must settle.

A disciplined evaluation can therefore be short and specific: verify the contracting company against the LACNIC identity; map every workload, copy, tunnel, and support-access location; review the exact IPv4 and IPv6 route design; define availability and recovery by service layer; demonstrate provisioning and change control; conduct a mitigation and restore test; exercise the escalation path; and preserve an independent exit copy. If RackSphere can produce that evidence, its compact footprint and consultative model may be strengths. Until then, AS64107 proves a network exists.

The contract and the drills must prove that it can carry the buyer's risk.