Summary

  • 3HCloud’s most interesting proposition is not a $1.50 virtual machine configuration. It is the promise that cloud instances, rented physical servers and customer-owned hardware can share networking, block storage, management and support without forcing the customer into a hyperscaler’s proprietary stack.
  • The legal and operational perimeter needs clarification. Florida records show an active 3HCloud LLC formed in 2020, while the autonomous system used by the service remains registered to the older Newserverlife LLC. The two companies share named managers in public filings, but public evidence does not establish their precise ownership, asset or liability relationship.
  • The provider publishes more low-level operating detail than many small hosts: shutdown does not stop VM billing, detached storage remains billable, snapshots stay on primary storage, scheduled backups are not automatically consistency-tested, and bandwidth is priced by hourly average speed. That candour is useful, but it also reveals dependencies that must be designed around.
  • The “100% Uptime Guarantee” is a contractual target backed by service credits for eligible virtual resources, not evidence of measured 100% availability. Dedicated servers, bare metal, colocation, the control panel, API, DNS, backups and several other components are outside the guarantee.
  • 3HCloud can be economically attractive for teams that understand infrastructure and value unbundled pricing, OpenStack APIs, Fibre Channel storage and engineer-led support. Buyers needing audited compliance, broad managed services, independently demonstrated multi-region resilience or tightly specified support response times have more work to do before treating it as a production standard.
  • The decisive procurement test is portability under failure: can the customer recreate compute, recover independently held data, retain or replace addressing, move physical equipment and operate when 3HCloud’s portal or support queue is unavailable?

The most revealing control in 3HCloud’s documentation is not “Create server.” It is “Shut off.”

On many clouds, a customer learns the economic meaning of that button only after the first surprising invoice. 3HCloud states it directly: a virtual server is charged from creation until deletion, and putting it into the SHUTOFF state does not stop billing. Deleting it ends the compute charge but also deletes its system volume. A network port detached beforehand can preserve its public addresses for another machine, yet the IPv4 address attached to that port continues to incur a fee. An extra block volume keeps billing when detached. These are ordinary infrastructure rules, but stating them plainly exposes the real unit of the service.

The customer is not buying “a server.” The customer is assembling persistent compute, storage, ports, addresses, bandwidth and support-assisted infrastructure, each with a different lifecycle.

That assembly is the basis of 3HCloud’s larger claim. Its company account of the platform says customers can combine their own hardware, 3HCloud bare-metal servers and cloud instances into one converged environment. The idea is more substantial than a low-cost VPS offer. A company might run bursty application nodes as virtual machines, a licensed database on dedicated hardware, a latency-sensitive appliance on its own server, and shared block storage behind all three. If networking and operations genuinely span those layers, the customer can change the placement of a workload without changing every surrounding dependency.

There is also a catch. Convergence does not remove dependency; it reorganises it. The more kinds of hardware that share one provider’s addressing, storage fabrics, control panel, billing account and support process, the larger the consequence if any of those shared systems fails or becomes commercially inaccessible. 3HCloud therefore deserves to be assessed neither as a miniature hyperscaler nor as a conventional bargain host. It is better understood as a small infrastructure operator trying to make the seams between cloud, bare metal and colocation usable.

Its case rests on whether those seams are well documented, contractible and reversible.

Two Florida companies behind one network name

The contracting identity is clear at the first layer. 3HCloud’s Terms of Use define the provider as 3HCloud LLC at 2031 Harrison Street in Hollywood, Florida. The Florida Division of Corporations record shows 3HCloud LLC as an active Florida limited-liability company, document number L20000375976, filed and effective on December 1, 2020. Its 2026 annual report was filed on January 28, 2026. The record names Konstantin Kolosovskiy as manager and Elena Kolosovskaya as authorised member.

The network identity is less simple. The service uses autonomous system AS49791 and the routing set AS49791:AS-3HCLOUD. Yet BGP.tools’ current routing view, drawing on registry and routing data, identifies the registered organisation as Newserverlife LLC while pointing to 3hcloud.com as the network website. At the time of this review it showed an active RIPE-allocated network, 43 originated IPv4 prefixes, 14 IPv6 prefixes and four named upstreams: Cogent, Kazakhtelecom, Hurricane Electric and Fiord. Those counts are a changing observation, not a fixed capacity statement.

Newserverlife is not merely a similar trading name. Its Florida corporate filing shows a separate active Florida LLC, document number L19000013202, formed in January 2019. It lists the same two people in management or membership roles and also filed a 2026 annual report on January 28. This is strong evidence of common management and an operational relationship. It is not, by itself, proof that one company owns the other, that all network assets have been transferred, or that Newserverlife guarantees 3HCloud’s obligations.

A second network directory presents the public-facing identity differently. PeeringDB lists AS49791 under the organisation name 3HCLOUD LLC, with 3hcloud.com as its website, a global scope, an open peering policy and a self-reported traffic level of 20–50 Gbps. Its organisation and facility information was last updated in August 2024. PeeringDB is valuable operational evidence, but the entries are supplied by network participants and should not be mistaken for an audit of corporate title or current capacity.

The sensible conclusion is bounded. Verified fact: 3HCloud LLC is an active Florida company and is the entity named in the public customer contract. Verified fact: AS49791 is active and is registered in routing data to Newserverlife LLC. Verified fact: the two Florida entities share named managers. Reasonable inference: 3HCloud is the customer-facing cloud operation built on network resources historically or legally associated with Newserverlife.

Unresolved: which entity employs network operations staff, owns or leases specific address blocks and equipment, signs colocation contracts, receives abuse notices, and carries liability when a routing or facility problem affects a 3HCloud customer.

This is not a reason to dismiss the service. It is a reason to put entity mapping into procurement. A business buyer should require the order form, data-processing terms, SLA, abuse handling, IP assignment rights and any facility-specific schedule to name the responsible entity consistently. It should ask whether Newserverlife is a subcontractor, affiliate, licensor or asset owner; whether 3HCloud can continue operating AS49791 if that relationship changes; and whether the customer may contact the network operations function directly during a route leak, hijack allegation or abuse dispute.

The answer matters more than a logo because the network is one of the converged platform’s shared control points.

There is at least some independent evidence that 3HCloud LLC itself enters real infrastructure arrangements. A 2025 schedule filed in the Monster Worldwide bankruptcy identifies “3HCLOUD” at the Harrison Street address as a counterparty to a master services agreement and sales order. A more recent SpiceProp VPS service contract states that its VPS technology and infrastructure are provided by 3HCloud LLC. Neither document demonstrates service quality, revenue scale or capacity, but both go beyond the provider’s own marketing and show the company appearing in third-party contractual contexts.

Six marketed metros, five observed facilities, several different maps

3HCloud’s public geography cannot be reduced to one location list because its own surfaces describe the perimeter differently.

The current virtual-server creation documentation lists Warsaw, Miami, Dallas, Manila and Almaty as selectable regions or availability zones. The cloud product page instead describes Warsaw, Dallas, San Francisco, Miami and Manila. The pricing page publishes bandwidth rates for all six city names: Manila, Dallas, Miami, Warsaw, San Francisco and Almaty. Meanwhile, the site’s navigation continued in July 2026 to label dedicated servers “coming soon,” even though dedicated-server documentation describes an active ticket-based service. These differences may reflect changing capacity, product-specific availability or pages moving at different speeds. They make a live quote and portal check more authoritative than a marketing map.

Independent network evidence covers part, not all, of that footprint. PeeringDB records AS49791 at five facilities in three metros: ATMAN Warsaw-1 and Equinix WA3 in Warsaw; Digital Realty and Equinix MI1 in Miami; and Digital Realty at 365 Main Street in San Francisco. It also records a 10 Gbps port at the Equinix Warsaw internet exchange. The absence of Dallas, Manila or Almaty from that directory does not prove that 3HCloud lacks service there. A provider can reach a site through transit, a partner, a leased network, remote peering or another autonomous system.

It does mean that the publicly observable AS49791 facility map is narrower than the six-city commercial map.

Facility operators provide useful corroboration. Digital Realty’s partner directory lists 3H Cloud and names San Francisco, Dallas and Miami as partner locations, while describing bare metal among the available services. Atman’s Warsaw-1 facility page places that campus at 21a Grochowska Street and describes a carrier-neutral site with on-site engineers, multiple data-centre buildings and facility-level certifications. These sources support the existence of real facility relationships or presence. They do not establish how much space or power 3HCloud leases, which halls its equipment occupies, or whether every 3HCloud service inherits every resilience feature advertised by the building operator.

The distinction is essential. A data-centre certification applies to the assessed facility and scope. It does not automatically certify 3HCloud’s cloud control plane, employee practices, logical access, backup system or customer support process. Likewise, a partner-directory listing confirms a commercial connection but not a dedicated cage, a dual-site architecture or an ownership interest in the building.

3HCloud sometimes calls sites “our data centers,” while also referring to “partner facilities.” The more accurate public description is that it operates infrastructure across third-party data-centre environments, with the exact ownership and operational division requiring site-specific confirmation.

Routing data adds another layer. BGP.tools shows a mixed set of prefix descriptions under AS49791, including address space labelled for 3HCloud, Newserverlife and downstream or customer organisations. That is consistent with a network operator serving its own cloud and other networks. It also means an ASN-level prefix count should not be treated as the size of 3HCloud’s retail cloud. A buyer should request the origin ASN, upstream mix, DDoS path, route-object status, RPKI coverage and facility handoff for the exact region being purchased rather than extrapolating from the global AS.

There are small but useful operational traces. In June 2026 the OpenBLD filtering project reported deploying a 3HCloud-supported server in San Francisco. This is a project acknowledgement, not a controlled benchmark, but it corroborates current service activity in a city that appears in PeeringDB and Digital Realty’s partner directory. The public evidence for Manila and Almaty is more dependent on 3HCloud’s own documentation and pricing. For regulated or latency-sensitive deployments, a customer should require the facility name, physical country, data residency, support boundary and network route in the order schedule.

Convergence is a workflow, not a product label

The platform’s three infrastructure modes begin differently.

A virtual machine is largely self-service. The customer selects a region, operating system or custom image, compute configuration, volume, network and authentication method. A first server in a region prompts the creation of an external network with IPv4 and IPv6; internal networks and previously created ports can be attached. Compute changes cause a reboot, documented as roughly one to two minutes. Custom CPU-to-memory ratios move out of self-service and into a support ticket.

A dedicated server is sales- and support-led. The dedicated-server documentation tells the buyer to submit project and technical requirements, after which the commercial team prepares an offer. The described service includes internet connectivity, IPv4 and IPv6, optional private networking, IPMI, failed-component or whole-server replacement and 24-hour technical support. Once activated, the server appears in the same control panel with IPMI sessions, SAN connection details and attached virtual volumes.

Customer-owned equipment adds logistics and a more visible physical dependency. The colocation documentation describes server or rack hosting, remote-hands assistance, IPMI access, SAN volumes and network connections. For a hosted server, 3HCloud says it uses 10 Gbps SFP+ links to two separate switches with link aggregation configured on both sides. This is a meaningful implementation description, though it remains a provider statement and needs to be matched to the ordered site and hardware.

The convergence is therefore not that all resources are provisioned identically. They are not. It is that several surrounding systems can persist across them: a private network, public addressing, block volumes, monitoring views, a customer account, billing and a support relationship. A company might begin on a VM, move a database to a dedicated HPE server, attach Fibre Channel storage, and later place its own appliance in the same facility. The value lies in avoiding a complete redesign of the network and operating process at each step.

That value is strongest for infrastructure-capable customers. 3HCloud’s API documentation says the platform follows an API-first model and points users to the OpenStack API and the OpenStack Terraform provider. An account can create up to ten API users; their generated passwords are shown once, and access can be irreversibly revoked while the historical user record remains. This gives teams a familiar automation path and makes a declarative build more plausible than a proprietary console-only service.

It does not make every part of the environment automated. The provider’s own workflow places non-standard VM shapes, dedicated-server offers, switch configuration, some IPMI credentials, port-25 removal and several network changes behind tickets. The dedicated-server navigation’s “coming soon” label also conflicts with detailed operational documentation and the third-party Digital Realty listing. The fair interpretation is that physical products are quote-led and may be available selectively rather than as an inventory-backed instant-deployment catalogue.

Procurement should ask for actual stock, replacement stock, provisioning lead time and the consequence if a matching server is unavailable after failure.

OpenStack reduces one kind of lock-in

OpenStack is the most credible element in 3HCloud’s claim to be vendor-agnostic. It gives customers widely used interfaces for compute, images, networks and volumes. Terraform configurations can be retained in a normal code repository. Custom machine images can be imported. A customer can understand many resources using upstream concepts rather than learning a wholly private API.

The provider has also published a detailed VMware-to-OpenStack migration guide. It covers VirtIO preparation, image export, VMDK-to-RAW conversion, image upload, new addressing, DNS cutover and the need to move data accumulated during migration. For Windows it describes a more involved driver and recovery process. This is company-authored guidance, not a record of a particular customer migration, but it usefully admits that moving a VM is a sequence of compatibility, image, network and data tasks—not a magic import button.

Open interfaces reduce control-plane lock-in. They do not eliminate data gravity or service-specific state. A Terraform file can recreate a virtual network, but it cannot instantly transfer a multi-terabyte Fibre Channel volume. An OpenStack image can leave the platform, but a public IPv4 address may not. A load balancer’s configuration can be documented, but its service address and health state still need a cutover plan. A colocated server can be shipped elsewhere, but only after access approval, remote-hands work, packing, carrier collection and replacement connectivity.

Even within the cloud, resource lifecycle details matter. 3HCloud says changing a VM’s configuration reboots it. It does not offer an in-place operating-system reinstall in the ordinary sense described by its workflow; the safer documented approach is to preserve what is needed, delete and recreate, or restore from an image, snapshot or backup. The system volume is tied to server deletion unless the customer has deliberately protected or exported data. These are manageable constraints, but only if automation includes data and addressing, not just compute.

The API itself is a dependency. The SLA expressly excludes the API and control panel. If the application remains online but the API cannot create a replacement instance, the contractual “availability” of the running resource may remain intact while the customer’s recovery process is blocked. A serious design should retain command-line credentials, current endpoint details, last-known infrastructure state and a support escalation route. It should also test which operations continue when the web portal is unavailable.

Storage is the hinge—and a concentration point

3HCloud’s architecture becomes most distinctive at storage. The provider sells block volumes in five published performance classes, from SSD Lite at 1,000 IOPS and 100 MB/s to SSD Ultra at 25,000 IOPS and 750 MB/s. Current list prices run from $0.01 to $0.10 per GiB per month. These are product specifications and price points, not independently measured sustained performance. Buyers should ask about I/O size, read/write mix, burst behaviour, latency percentiles, queue depth, noisy-neighbour controls and whether limits apply per volume or across a storage pool.

For virtual machines, 3HCloud markets external Fibre Channel storage as a way to restart an instance on another compute node after a host failure while preserving access to its data. That is a plausible architecture and a genuine advantage over a VM whose only disk is local to one host. Public documentation, however, does not expose the scheduler policy, recovery objective, quorum design, controller layout or a history of failover tests. The statement should be treated as a company claim to verify during a proof of concept, not as an independently established recovery guarantee.

The physical side is more concrete. The Fibre Channel guide describes separate storage traffic, World Wide Names, multipath operation and two fabrics labelled A and B. A dedicated server or colocated server can see volumes through multiple paths, so a switch or port failure need not remove storage access if the host is configured correctly. The VMware ESXi installation guide goes as far as describing an HPE server, iLO, a 3PAR disk, a support-assisted link-aggregation change and a multipath check. This is valuable evidence that the hybrid proposition is implemented at an operational level, although one guide cannot prove that every region uses the same hardware or redundancy.

Shared storage is simultaneously the bridge and the blast radius. It allows data to survive a compute-host failure and be presented to different kinds of server. But if virtual machines, rented bare metal and customer-owned hardware all depend on the same storage system, fabric, zoning process or operations team, a storage incident can cross the boundaries that compute separation was meant to create. Dual fabrics mitigate path failure; they do not by themselves address a controller defect, firmware error, administrative mistake, corrupted volume, facility outage or loss of the storage management plane.

3HCloud’s distinction between snapshots and backups is unusually important. Its snapshot documentation says a snapshot stays on the same hardware as the source volume and requires primary storage to be available. It explicitly says a snapshot is not a backup. That warning should be taken literally: a snapshot can be convenient for cloning or rollback but is not an independent copy against loss of the source storage system.

The backup documentation adds a second candid warning. Scheduled backups do not receive automatic performance and consistency checks, and customers are advised to restore periodically. Backups capture data written to the volume, not state that exists only in memory. They are retained according to the configured copy count and may remain after the source volume or server is deleted. The service therefore supplies a mechanism, not a complete recovery assurance.

For production use, the unanswered questions are architectural. Is the backup repository in a different failure domain from the primary array? Is it in the same facility, another 3HCloud region or a separate provider? Are backups encrypted with provider- or customer-controlled keys? Can a customer export them without restoring through 3HCloud? What are the tested restore times for one volume and an entire application? Are backup APIs and metadata available if the portal is down? A buyer should maintain at least one independently controlled copy for data whose loss would threaten the business.

Converged storage is convenient precisely because it is shared; independent recovery should be deliberately non-converged.

The network bill measures speed, not transferred bytes

3HCloud’s bandwidth model is one of its more original commercial choices. Rather than presenting only a monthly transfer allowance, it measures average incoming and outgoing speed during each hour. If the higher direction exceeds the customer’s dedicated threshold, the excess Mbps is charged at a region-specific rate. The control panel shows threshold exceedances, and a customer can impose a speed limit to avoid additional charges. Network cards aggregate resources by region, with cloud and physical infrastructure shown as separate categories.

That model can be attractive for workloads with bursts that remain below a high threshold, and it expresses network cost in the capacity language used by operators. It can also be less intuitive than a terabyte allowance. A short high-rate transfer may be inexpensive if its hourly average stays low; a sustained stream can create repeated hourly charges. Asymmetric workloads are charged on the higher direction rather than both. Teams need to model Mbps-hours, not merely monthly bytes.

The public descriptions require clarification. The pricing page says each VM includes 1 Gbps before overage and publishes per-Mbps-hour rates across six regions. The internet-access documentation gives 1,000 Mbps as the default threshold in Warsaw, Miami and San Francisco but 50 Mbps in Manila, then cautions that the dedicated threshold is not necessarily the same as free bandwidth. Dallas and Almaty are not included in that example. This may be a difference between included port speed, dedicated threshold and current regional policy, but a customer should not have to infer the billable boundary. The order should state the free bandwidth, dedicated threshold, physical port limit, overage rate and aggregation scope for each region.

Flat-rate unmetered options are also published. In Dallas, Miami, Warsaw and San Francisco, the July 2026 list price ranges from $50 a month for 100 Mbps to $2,000 for 10 Gbps; Manila and Almaty carry higher regional rates. Those numbers show why 3HCloud can advertise cheap compute while treating network capacity as its own economic layer. They also make the workload shape decisive. A lightly connected development VM and a streaming origin may use the same CPU plan but have radically different provider economics.

The smallest VM illustrates unbundling. The cloud product calculator shows a 1 vCPU, 1 GB shared instance at $1.50 per month, then adds a minimum 16 GB SSD Lite system disk for $0.16 and IPv4 for $1, producing a displayed total of $2.66 per month. IPv6 is free. The price is genuinely low, but the $1.50 headline is not a bootable, publicly reachable configuration by itself. Storage performance, backup storage, Windows licensing, load balancing and sustained bandwidth are separate decisions.

Billing continues until resources are deleted, not merely idle. The billing documentation says usage is hourly and the default card is usually charged when the cycle closes—normally on the first and sixteenth of the month—or when the credit limit is reached. This is reasonably transparent, but it places discipline on account hygiene. Orphaned ports, detached volumes, retained backups and forgotten resources can all survive after the application owner thinks a project has ended.

The Terms add workload constraints. Public relays, bandwidth resale, public tunnels and proxy software can become prohibited when traffic is highly symmetrical and sustained above stated consumption conditions, unless separately agreed or used under qualifying unmetered options. Outbound TCP port 25 is blocked by default and can be opened through a ticket. A buyer planning VPN, proxy, mail, CDN, gaming or data-distribution workloads should obtain written confirmation that the intended pattern is allowed and correctly priced.

What “100%” buys

3HCloud’s Service Level Agreement sets a target of 100% availability for covered virtual resources. The phrase is prominent on the website, but the contract defines its meaning more narrowly than the marketing shorthand.

The guarantee applies to paid virtual servers, cloud instances, cloud storage and other resources expressly included in the agreement. It does not apply to dedicated physical servers, bare metal or colocation. It also excludes the 3HCloud website, DNS servers, API, control panel, payment integrations, beta services and customer backups. GPU operation and performance are outside the general guarantee, with confirmed GPU-server downtime compensated minute for minute. The covered “infrastructure” is defined around availability of the host node and network port connected to the provider backbone.

This is not evidence that 3HCloud has achieved 100% historical uptime. No public incident archive or independently audited availability series was identified in this review. The SLA is a promise about eligibility for credits after qualifying unavailability. The Terms separately disclaim uninterrupted, completely secure or error-free operation and exclude consequential losses such as downtime and lost data, subject to applicable law.

The credit schedule is finite. Less than nine minutes of resource unavailability earns two hours of credit; 10–59 minutes earns six hours; 60–119 earns 12 hours; 120–239 earns 24 hours; 240–419 earns 48 hours; and 420 minutes or more earns 168 hours. The published table appears to leave exactly nine minutes unassigned, a drafting point worth clarifying. Credits are calculated on the affected resource, capped at that resource’s monthly cost, carried forward rather than paid in cash, and described as the exclusive remedy.

The claim process is customer-driven. A ticket explicitly requesting compensation must be submitted within 60 days. Even if 3HCloud knows about an outage, a credit does not start without that request. The company independently determines whether a failure occurred and how long it lasted; customer logs are reference evidence. 3HCloud recommends MTR or traceroute output, screenshots and application logs.

There is a practical tension with the Terms of Use, which prohibit using the service to monitor its availability, security, performance or functionality, or for benchmarking, without express written permission. The likely intention is to restrict competitive testing or abusive benchmarking rather than stop a customer monitoring its own production system, but the clause is broad on its face. Since the SLA asks customers to preserve technical evidence, buyers should obtain written permission for ordinary synthetic availability tests, latency monitoring, security scanning and benchmark activity used for acceptance or capacity planning.

Numerous exclusions can be commercially reasonable but architecturally consequential. Scheduled maintenance can be excluded with advance notice under defined conditions; emergency remediation of critical vulnerabilities can be excluded without notice. Customer software, overload, configuration reboots, backup restoration, delinquent payment, DDoS attacks and third-party technology outside 3HCloud’s control may also fall outside credits. A massive DDoS attack above 100 Gbps or lasting more than four hours is treated as force majeure.

Packet loss above 0.5% between an instance and the first provider hop triggers investigation, but not automatically a credit unless 3HCloud verifies an infrastructure failure.

The remedy is therefore much smaller than the business impact for most serious applications. The Terms cap aggregate liability for relevant claims at fees for the applicable products during the preceding two months and exclude many forms of indirect or consequential loss. A week of resource credit after a long outage may be symbolically accountable, but it will not fund lost transactions, emergency migration or data reconstruction. The correct use of the SLA is as a procurement baseline and escalation process, not as a substitute for redundancy.

Support is part of the architecture

Small infrastructure providers often compete with humans rather than product breadth. 3HCloud says customers reach engineers rather than chatbots, and its support documentation describes 24/7 technical support through a ticket system. Tickets display an assigned engineer, status, history and attachments; closed tickets can be reopened by commenting. Sales operates on weekday US Eastern hours.

The public material does not specify severity levels, first-response targets, restoration targets, telephone escalation for critical incidents or named service-management roles. That absence matters because support is embedded in several technical paths. Dedicated server provisioning begins with a ticket. Custom VM ratios require a ticket. Some network threshold changes and port-25 removal require a ticket. An ESXi deployment requires support to configure link aggregation. IPMI credentials arrive through support after installation. If a Fibre Channel zoning or physical component issue occurs, the customer cannot resolve every layer alone.

This can be a strength when the team is skilled and reachable. A small operator may diagnose across compute, switch, SAN and facility boundaries faster than a large provider whose support queues are segmented by product. It can also be a concentration risk. Public sources do not establish the size of the network operations and support teams, their geographic coverage, on-call staffing, language coverage, employee turnover or dependency on particular individuals. There is no basis to claim a support failure; there is equally no basis to assume hyperscaler-like staffing depth.

Physical services add another party. Atman and Digital Realty operate buildings and remote-hands capabilities, while 3HCloud presents the customer-facing service. A failed power supply might involve the server vendor, 3HCloud support and facility technicians. A network incident could involve 3HCloud, Newserverlife’s registered network resources, an upstream carrier and the data-centre operator. The customer needs one accountable escalation path, but it should also understand the handoffs behind it.

A proof of concept should test support, not only throughput. Open tickets at ordinary and inconvenient hours. Ask for a non-destructive IPMI session, a mock failed-disk procedure, a route-change escalation and a backup restore. Record acknowledgement and resolution time without turning the exercise into an abusive load test. Request a severity matrix, incident communications policy, root-cause-analysis policy, maintenance channel and named emergency contact in the commercial agreement. If physical replacement is critical, ask for region-specific spare policy rather than a general promise to replace failed components.

Security controls are unevenly documented

3HCloud’s security story is strongest where the documentation becomes specific. Virtual machines use security groups with ingress and egress rules; default egress rules can be deleted. Dedicated or physical infrastructure has a separate data-centre firewall service that is explicitly marked beta. That firewall is stateful and blocks unsolicited incoming traffic when enabled with no allow rules, but its documentation warns that outgoing traffic is not filtered. Marketing that broadly describes a firewall as protection from attacks should therefore be translated into product-specific controls: the virtual firewall and physical perimeter firewall do not have identical behaviour.

IPMI access is another example. The IPMI guide says the management interface uses an isolated network, is not connected to the main infrastructure, and is exposed through source-IP firewall sessions that can be temporary or permanent. A quick session lasts three hours. This is a sensible control design, though the assertion of isolation remains provider-supplied. Buyers should ask how credentials are generated, rotated and logged; whether multi-factor authentication covers the portal action that opens IPMI; whether permanent allow rules expire; and whether support personnel access is recorded.

The network perimeter blocks outbound port 25 by default, a common anti-abuse measure. Routing records publish abuse and network contacts. What is not public is a detailed security assurance package: no 3HCloud-specific SOC report, ISO certificate, penetration-test summary, subprocessor register, vulnerability disclosure policy or detailed incident-response commitment was identified in the reviewed material. Such documents may be available under non-disclosure, but facility certificates should not be substituted for them.

The privacy policy, effective July 29, 2024, describes broad categories of personal information, service-provider sharing, retention criteria and “reasonable” physical, technical and organisational safeguards. It refers to website and account information more than to a full enterprise data-processing framework. A customer handling regulated data should request a data-processing agreement, subprocessor and location list, deletion and return procedures, breach-notification timing, law-enforcement request policy, encryption responsibilities and audit rights.

The Terms assign substantial responsibility to the customer for network, server, application and access-code security. They permit suspension where 3HCloud suspects prohibited use or believes traffic threatens the hosted environment. They also allow the provider to identify a customer in marketing and disclose products or features used, subject to stated guidelines. Organisations with confidentiality requirements should negotiate publicity consent rather than assume silence.

There is very little independent review volume from which to infer operational quality. Trustpilot displayed only two reviews during this research, both invited, which is far too small and selection-prone to establish reliability. One reviewer described a positive colocation experience; another described needing support to obtain enough temporary storage for a bare-metal recovery at an inconvenient hour. The anecdote is not independently verifiable and should not be generalised, but it illustrates the procurement question: what recovery resources are self-service, and what capacity requires a human at the moment of crisis?

Cheap compute is the entry point, not the whole model

3HCloud’s price structure appears designed to make each infrastructure input legible. Compute, storage, public IPv4, backup retention, load balancing and network capacity are separate. Private L2/L3 networks and IPv6 are listed as free. This allows an experienced team to pay narrowly for what it needs, but it transfers the work of assembling and forecasting the bill to that team.

The market comparison is not one-dimensional. DigitalOcean’s Droplet pricing starts at $4 per month, and its 1 GB product page shows a $6 configuration including storage and a transfer allowance. DigitalOcean moved Droplets to per-second billing in 2026. Amazon Lightsail sells predictable bundles that combine compute, SSD storage and transfer, with low-end IPv6-only plans beginning at $3.50. Their headline prices are higher than 3HCloud’s $1.50 compute line but include different components, ecosystems and support assumptions. Comparing only RAM and vCPU would conceal the real trade.

3HCloud’s dedicated-CPU shapes can also be inexpensive: a published 2 vCPU, 8 GB general-purpose VM is $16 a month before storage and addressing. The economic question is whether dedicated means a consistently allocated physical-core resource under the customer’s expected workload, and whether storage and network behaviour remain predictable. A buyer should benchmark its own application with written permission, across time and failure events, rather than rely on plan labels.

The converged model creates opportunities for cross-selling and retention. A customer may enter through a cheap VM, add higher-performance storage, reserve bandwidth, buy a load balancer, rent a physical server, and eventually colocate hardware. The customer benefits if these layers genuinely reduce migration effort. 3HCloud benefits because the account’s value grows while shared network, storage and support dependencies make departure more involved. This is not an improper lock-in mechanism; it is the ordinary economics of integrated infrastructure. It becomes problematic only if exit costs are hidden or interfaces are not portable.

Smaller providers also face unforgiving input costs. Transit, facility power, remote hands, public IPv4, spare parts, server memory and storage arrays do not become cheap because the customer-facing brand is small. In May 2026, larger low-cost competitor Hetzner announced another server price and product adjustment, citing hardware procurement pressure and standardising configurations to make provisioning and maintenance more efficient. The lesson is broader than Hetzner: transparent low prices are sustainable only if the provider can keep purchasing, utilisation and support costs under control.

3HCloud’s own answer appears to be granular billing, selective physical provisioning, open-source software and a narrower managed-service catalogue. It does not need to reproduce hundreds of hyperscaler services if its target customer brings operating skill. But the margin for error is thin. Generous network thresholds, human support, spare hardware and enterprise storage all cost money. Buyers should examine whether a quoted price is promotional or durable, how renewal and price changes work, whether hardware setup fees apply, and what happens to the price when a server is replaced or resized.

The Terms permit pricing changes with notice under their stated process, so long-term predictability ultimately comes from the order, not the public calculator.

The competitors are three different categories

For pure virtual infrastructure, 3HCloud competes with developer clouds and regional OpenStack providers. DigitalOcean, Akamai Connected Cloud, Vultr, OVHcloud, Hetzner and numerous local operators offer quick VM creation, APIs and relatively legible pricing. Their advantages may include more regions, broader managed services, larger support organisations, richer status histories and bigger communities. 3HCloud counters with low unbundled prices, dedicated-CPU options, Fibre Channel storage and a path into physical infrastructure.

For bare metal, it competes with inventory-rich dedicated-server companies and with hyperscaler bare-metal instances. The key tests shift to component specification, stock, setup time, remote management, replacement inventory and contract length. Here the “coming soon” label is a commercial warning: even if bespoke dedicated servers are operational, a buyer should not assume instant or standardised availability.

For colocation, the substitutes include buying directly from a facility or a larger managed-colocation provider. 3HCloud’s potential advantage is aggregation. A customer with one or a few servers may prefer a provider that supplies internet, IP space, switch configuration, SAN volumes, remote hands and cloud adjacency under one relationship. The disadvantage is an extra commercial and operational layer between the customer and the building. The buyer should know which rights survive if it wants to move service, change carriers or collect its equipment.

The most powerful substitute is architectural, not a named vendor: split the stack. Keep portable VMs at one cloud, backups at another, physical equipment under a direct colocation contract and DNS with an independent provider. That approach reduces correlated provider risk but increases integration and support burden. 3HCloud is effectively betting that many customers will prefer one technically coherent operating perimeter. The buyer’s task is to decide which dependencies are worth converging and which should remain deliberately separate.

An exit is a design, not a cancellation email

3HCloud’s use of OpenStack creates a credible route out for VM definitions and images, but an orderly exit must be built while the service is healthy.

For compute, retain Terraform or equivalent declarations, cloud-init, configuration management, image-building instructions and an inventory of external dependencies. Periodically create and test an image outside the platform. Confirm the format, export method, time and egress cost for every important volume. Do not assume a snapshot is portable; 3HCloud says it resides on the same primary storage.

For data, maintain a second copy in another administrative and failure domain. Test application-consistent recovery, not only volume restoration. Record RPO and RTO achieved in practice. If using Fibre Channel for bare metal or colocation, document filesystem, multipath, boot-LUN and zoning configuration so the system can be attached to different storage. Know how long it would take to copy the full dataset over the available network.

For networking, distinguish portable configuration from non-portable identity. Private subnets and security rules can be recreated. Provider-assigned public addresses normally require DNS or routing cutover. A detached port may preserve an address inside 3HCloud, but that does not make it portable to another operator. Lower DNS time-to-live values before migration, maintain an alternate ingress path and ask whether any address space can be customer-owned or announced under a written arrangement.

For physical equipment, the contract should define access, remote hands, de-racking, packing, shipment, outstanding balances and the customer’s right to retrieve hardware. The public Terms say 3HCloud has no obligation to retain customer data after termination and place retrieval responsibility on the customer. They also allow 3HCloud to assign its rights and obligations without customer consent while restricting customer assignment. A negotiated physical-service schedule should be more specific than the general cloud terms.

For operations, preserve contact routes outside the portal. The SLA excludes the portal and API, so a customer should know how to open a severity-one incident if login or ticket creation is unavailable. Maintain a current asset list, serial numbers, rack or facility references, IP allocations, support contacts and copies of invoices and orders. A converged interface is convenient in normal operation; exit planning requires an independent record of what sits behind it.

The procurement test should recreate a bad day

A conventional feature comparison will flatter 3HCloud because the platform covers many useful primitives. A better evaluation reproduces the moments when convergence is supposed to matter.

First, establish the legal and network map. Obtain a signed explanation of the relationship between 3HCloud LLC and Newserverlife LLC, including ownership or licence of AS49791 resources, abuse handling and continuity rights. Match the contracting entity across the order, SLA, data-processing agreement, invoice and facility schedule.

Second, pin down the region. Ask for the physical facility, country, origin ASN, upstream design, DDoS handling, free bandwidth, dedicated threshold, port speed and current capacity for the exact service. Resolve why public lists differ over San Francisco and Almaty. Do not accept a generic “global” answer for a workload with residency or latency requirements.

Third, test the VM lifecycle. Create through Terraform, rebuild from a customer image, resize, preserve a network port, delete safely and recreate in another region. Verify which resources and charges survive each action. Confirm that account quotas, API-user limits and portal dependencies fit the automation plan.

Fourth, test storage failure and recovery. Measure the published volume classes with agreed benchmarks. Restore a scheduled backup to a new volume and boot a service from it. Ask where that backup physically resides. For Fibre Channel, test loss of one path and confirm multipath behaviour. Ask for evidence of controller and fabric failover testing without assuming the answer from a diagram.

Fifth, test the boundary between self-service and support. Request a custom VM shape, a dedicated-server quote, a firewall change, an IPMI session and a network escalation. Record response quality and the points where an engineer must act. Negotiate severity and response commitments if the workflow depends on them.

Sixth, model the whole bill. Include system and data volumes, retained backups, IPv4, Windows licensing where relevant, load balancers, hourly bandwidth exceedance, flat-rate capacity, remote hands and physical setup. Model an idle month, a traffic spike, a restore and a migration. The headline VM price is useful only after the persistent components are included.

Seventh, test contract language against operations. Clarify the nine-minute gap in the SLA credit table. Obtain permission for production monitoring and acceptance benchmarks. Confirm which products are covered by credits, how credits are requested, and whether an enterprise order changes liability, data return or publicity rights.

Finally, execute a partial exit. Export one image and one meaningful dataset, recreate them elsewhere, change DNS, and document the elapsed time. For customer-owned hardware, obtain the de-installation and collection procedure even if no move is planned. A provider that genuinely competes on transparency should be willing to make the departure path understandable.

What to watch

The most important near-term watchpoint is whether 3HCloud regularises the public boundary of its physical products. Detailed dedicated-server, IPMI, SAN and colocation documentation suggests a functioning service, while primary navigation still says dedicated servers are coming soon. A standard inventory, explicit regional availability and published provisioning terms would turn an interesting bespoke capability into a more assessable product.

The second is identity clarity. AS49791’s Newserverlife registration and 3HCloud’s customer contract can coexist for legitimate historical and group-structure reasons. Publicly explaining that relationship would reduce avoidable diligence friction and make network accountability easier to understand.

The third is operational evidence. A public status history, incident communications standard, region-level architecture descriptions, security assurance material and tested recovery metrics would be more valuable than broad reliability adjectives. So would a clear mapping of facility certifications to 3HCloud’s own control scope.

The fourth is whether the low-price model remains durable as hardware, memory, power and transit costs move. 3HCloud’s granular prices are a strength because customers can see what they are buying. They also expose the company to scrutiny when regional thresholds, product pages or contract terms diverge. Keeping those surfaces synchronised is part of the product.

3HCloud’s proposition is not implausible. The legal company is active; the network is visible; third-party facility directories corroborate part of the footprint; the documentation contains enough operational detail to show more than a landing-page concept; and outside documents show the company participating in customer and vendor contracts. The evidence supports treating it as a real, technically ambitious smaller provider.

It does not support treating every marketing claim as settled fact. The public record is thin on audited service performance, security controls, staff depth, incident history, exact intercompany responsibilities and the physical basis of every advertised region. The 100% language is a credit mechanism, not a measurement. The converged architecture can reduce the friction between virtual and physical infrastructure, but it can also concentrate storage, networking and support risk.

That leaves a useful, company-specific conclusion. 3HCloud is most compelling for an engineering team that wants to see the parts: OpenStack APIs, ports, address charges, bandwidth thresholds, block-volume tiers, Fibre Channel paths and physical-server controls. Its transparency is strongest at that mechanical level. A buyer should reward it by testing those mechanics rigorously—and require the commercial and organisational perimeter to become just as visible. The shutdown button still bills, but at least the documentation says so.

The larger question is whether every dependency that remains on after shutdown can also be named, measured and moved.