phoenixNAP

What phoenixNAP Bare Metal Cloud actually is

phoenixNAP Bare Metal Cloud (BMC) is an API-driven dedicated server platform. You get single-tenant physical hardware — no hypervisor, no noisy neighbours — provisioned in about a minute through a REST API, CLI, Terraform, or the web portal, and billed by the hour like a cloud VM. The pitch is the standard bare metal cloud pitch: dedicated performance with cloud-like consumption, and phoenixNAP executes it competently.

The company behind it is not a startup. phoenixNAP was founded in 2009 and opened its Phoenix, Arizona data center in 2010, followed by Amsterdam in 2012; today it runs a broader colocation, dedicated server, and managed services business alongside BMC. The Bare Metal Cloud platform itself is newer — public material dates back to 2020 — and it shows in a good way: the provisioning API is clean, infrastructure-as-code integrations (Terraform, Ansible, Pulumi, Chef) are first-class, and deployment is genuinely fast (phoenixNAP quotes 60 seconds to a few minutes depending on the OS image).

The instance catalogue is broad — 50-plus pre-configured types spanning general purpose, compute-optimized, memory-optimized, database instances with a Pliops XDP accelerator, ARM boxes with 80-core Ampere Altra processors on HPE ProLiant hardware, and GPU instances with dual Intel Max 1100 GPUs. Recent additions use Intel Xeon 6 P-core CPUs with DDR5. Every instance is 100% dedicated compute, RAM, and NVMe (or SSD on the smallest types) with no overcommitment. For teams that want physical hardware but hate racking servers, this is the category's sweet spot — see /category/bare-metal-cloud for how we line it up against competitors.

Two features stand out to us. First, the network: 20 Gbps (2×10 Gbps bonded) or 50 Gbps (2×25 Gbps bonded) ports depending on instance type, 15 TB of bandwidth included per location (5 TB in Singapore), and 20 Gbps of DDoS protection included in the price. Second, the networking depth — BYO IPv4 and IPv6 blocks, BGP peering with local and global advertisement, Anycast support, and a Netris integration for VPC-like networking. That is unusual in this price class.

Pricing: what you really pay

Billing is hourly with optional 1, 12, 24, or 36-month reservations at discounts — the API exposes exactly those pricing models. On-demand general purpose instances start at $0.08/hour, and phoenixNAP advertises "as low as $38.81/mo" for the cheapest configuration. That entry machine is the s0.d1.small: a single Intel Xeon E3-1240v3 (4 cores / 8 threads at 3.4 GHz), 16 GB RAM, 2×240 GB SSD, and 2×1 Gbps network ports. Independent price trackers put the real-world monthly figure slightly higher once a public IPv4 allocation is added — IP blocks are billed separately, and per phoenixNAP's own knowledge base, public IPs cost $0.0035/hour each.

Where the catalogue gets serious: the s1.c1.small (single Intel E-2276G, 6 cores, 64 GB RAM, 1 TB NVMe) runs about $105/month in phoenixNAP's test bundle, and the dual-socket d1.c1.small (dual Intel Silver 4210R, 20 cores, 128 GB RAM, 2×1 TB NVMe, 2×25 Gbps) is listed at $295/month. Compute-optimized and GPU instances are priced correspondingly higher — dual Intel Max 1100 GPU machines and Xeon 6 boxes are the top of the range. We like that these bundles include 15 TB of bandwidth and 20 Gbps DDoS protection rather than metering them as surprises; bandwidth overages are a flat $0.01/GB, which is about as transparent as bandwidth pricing gets.

Be aware of three cost mechanics. Reserved instances are billed for the whole term even if you delete the server — phoenixNAP's master agreement is explicit that deleting a reservation mid-term does not stop billing. IPv4 addresses are an add-on. And storage extensions (S3-compatible Object Storage, all-flash Network File Storage) are separate, metered services. None of this is hidden, but a naive hourly-times-730 estimate will undershoot the invoice.

Overall we rate the pricing model well: hourly billing with published per-instance rates, no egress-style ambush on the included bandwidth, and reservation discounts for steady workloads. It is meaningfully cheaper than equivalent public cloud instances for sustained load, which is the entire argument for bare metal cloud.

Performance & infrastructure

This is where BMC earns its keep. Every instance maps to real, dedicated hardware with named CPUs — you know the processor model, the core count, the clock speed, and the disk layout before you deploy. There is no shared tenancy and no CPU credit system. For latency-sensitive or sustained-load workloads — CI runners, game servers, media encoding, databases, Kubernetes worker nodes — dedicated silicon simply behaves better than a burstable vCPU slice, and we trust the hardware profile more than an abstraction that only says "vCPU".

The footprint is six deployment locations: Phoenix, Ashburn, Chicago, and Seattle in the US, Amsterdam in the EU, and Singapore in APAC. The API confirms exactly these location codes (PHX, ASH, CHI, SEA, NLD, SGP). PhoenixNAP's wider company network adds edge and colocation presence — Atlanta, Los Angeles, Frankfurt, Madrid, Milan, Helsinki, Warsaw, Belgrade, Sofia, São Paulo, Sydney, Taipei and more — but you cannot deploy BMC instances there today. Keep that distinction straight: six BMC regions, a much larger backbone.

Reliability terms are unusually concrete. phoenixNAP's connectivity SLA, which explicitly covers Bare Metal Cloud, sets a 100% availability target for power and network with service credits for downtime, and the object storage addendum carries a 99.9% availability commitment with a defined error-rate trigger. The hardware replacement and deployment guarantees sit under their own addenda. Compare that with providers who only say "we strive for 99.9%".

Support is 24/7 by phone, ticket, and live chat — US-based numbers are published — and the documentation is genuinely good: a developer portal with full API reference, extensive knowledge base articles on BGP, IP management, and Kubernetes, plus certified Terraform and Ansible providers. Provisioning is scriptable end to end, and product availability can be checked via API before you deploy.

Where it falls short

Six locations is the honest ceiling. If your users are in South America, Africa, or most of Asia-Pacific beyond Singapore, latency will not compete with hyperscaler regions or CDN-fronted deployments. And the region set skews US — one EU location means no EU redundancy story without going to another provider.

The entry instance is old hardware. An Intel E3-1240v3 is a Haswell-era chip; fine for a test box, not what you would pick for production. The newer Xeon 6 and 5th-gen Xeon Scalable instances fix this, but they cost several times more. On the small end, the price-performance argument against a modern shared vCPU host is weaker than it is further up the stack.

We also note the usual bare metal trade-offs: no snapshots or live resizing. A BMC instance is a physical box — you scale by redeploying or adding servers, not by dragging a slider. There is no built-in backup service; you are expected to push backups to the paid S3-compatible Object Storage (Veeam-compatible, with Object Lock immutability) or elsewhere. Management is self-managed: root on an operating system you patch yourself. phoenixNAP sells managed and colocation services, but BMC itself is a hands-on product.

Finally, the pricing pages are the weakest part of the documentation. Spec tables render client-side and the numbers are hard to pin down without an account, IP allocation costs are billed separately, and the advertised "as low as" monthly prices assume long reservations. The facts are published, but assembling a true monthly figure takes more work than it should.

Who should pick this

We would pick BMC for workloads that want dedicated hardware with cloud ergonomics: teams running CI/CD fleets, game servers, high-traffic web and SaaS backends, database nodes with predictable latency, Kubernetes clusters on bare metal (SUSE Rancher integration is offered), or compliance-minded deployments that need to know exactly which CPU and disk their workload sits on. If you are migrating off AWS specifically to stop paying hyperscaler premiums for steady-state compute, this is the kind of platform that makes the numbers work — the case study on their site claims 50% monthly cost reduction versus an equivalent AWS setup, and the unit pricing backs the direction of that claim.

We would not pick it for global low-latency delivery, for teams that want managed operations, or for very small projects where a €5 shared VM does the job. If you need EU multi-site redundancy or Asia-Pacific beyond Singapore, look at providers with deeper footprints.

Key takeaways

• Real dedicated hardware (named CPUs, no overcommit) provisioned in about a minute via API, CLI, or Terraform — hourly billing with reservation discounts.
• Entry point from $0.08/hour (s0.d1.small: 4 cores, 16 GB RAM, 2×240 GB SSD); public IPv4 blocks cost extra at $0.0035/hour each.
• 15 TB bandwidth included (5 TB in Singapore), 20 Gbps free DDoS protection, 20/50 Gbps network ports, overage at $0.01/GB.
• Six BMC locations only — Phoenix, Ashburn, Chicago, Seattle, Amsterdam, Singapore — despite a much larger company footprint.
• Concrete SLAs: 100% power/network target with service credits, 99.9% on object storage, defined hardware replacement terms.
• Self-managed by design: no snapshots or included backups; S3-compatible Object Storage and network file storage are paid add-ons.

Sources

• https://phoenixnap.com/bare-metal-cloud
• https://phoenixnap.com/bare-metal-cloud/instances
• https://phoenixnap.com/cloud-services/public
• https://phoenixnap.com/object-storage
• https://phoenixnap.com/offers/bmc-test-bundle
• https://phoenixnap.com/offers/bmc-academic-bundle
• https://phoenixnap.com/kb/public-ip-management
• https://phoenixnap.com/kb/phoenixnap-bare-metal-cloud-billing-models
• https://phoenixnap.com/cs/legal/
• https://phoenixnap.com/cs/legal/cslaa.html
• https://developers.phoenixnap.com/docs/bmc/1/routes/servers/post
• https://phoenixnap.com/bare-metal-cloud/intel-xeon-6-p-core
• https://phoenixnap.com/wp-content/uploads/2025/09/2025-PNAP-Company%20Booklet-DIGITAL-V2.pdf
• https://stackrates.ai/hosting/phoenixnap
• https://servermarket.dev/providers/phoenixnap/s0-d1-small