Vultr Cloud Compute Plans: Regular, High Frequency and Optimized

More plan families than the console first suggests

Vultr's create-instance page presents a row of tabs, and each one hides a different product with different economics. Teams that pick the first option without reading the others often end up either paying for dedicated cores they never saturate or squeezing a database onto shared ones.

The catalog divides cleanly. Shared vCPU instances are marketed as Cloud Compute and come in several performance tiers. Dedicated vCPU instances are marketed as Optimized Cloud Compute and come in four workload-specific flavours. Beyond those sit Bare Metal and Cloud GPU for cases where virtualisation or accelerators are the point.

This guide walks the families in that order, then covers what every plan includes, then finishes with the plan identifiers you will need when you automate any of it.

Shared vCPU: three tiers of Cloud Compute

All three tiers share one property: the physical cores are shared with other tenants, and you are buying a slice rather than a whole. What differs is the hardware underneath and, consequently, how each tier feels under load.

Regular Performance

The long-standing entry tier, built on Intel processors with SSD storage. It is the cheapest way onto the platform and remains a sensible home for low-traffic sites, bastion hosts, monitoring agents, staging environments and anything that spends most of its life idle.

High Frequency

Intel processors selected for high clock speed, paired with NVMe storage. Single-threaded work, and that includes most interpreted web applications handling one request per worker, benefits noticeably from the higher clock. This is a good default for a small production web service.

High Performance

Newer AMD and Intel processors with NVMe storage, positioned as the current-generation shared tier. It generally offers more throughput per vCPU than the Regular tier for a modest step up, which makes it a reasonable default when you are unsure.

The storage difference between the tiers is easy to underrate. Moving from SSD to NVMe changes how a database-backed application feels far more than a small change in vCPU count does, a point explored in NVMe storage on cloud VMs.

Optimized Cloud Compute: dedicated cores, four shapes

Optimized plans assign dedicated vCPU, so no other tenant competes for the same core. That removes the variability that makes shared instances unsuitable for latency-sensitive or consistently busy services. The four sub-families differ in the ratio of memory and storage to those cores.

A useful rule of thumb: if a workload regularly holds its cores above sustained heavy utilisation, the dedicated line will be both faster and better behaved than a larger shared instance. Storage Optimized plans are also worth considering for any database that currently sits on network-attached block storage and is limited by it.

Bare Metal and Cloud GPU

Bare Metal removes the hypervisor entirely and hands over a whole physical server, provisioned through the same console and API as everything else. It suits workloads that need hardware features, predictable performance without any neighbours, or licence terms tied to physical cores. The general case for it is examined in dedicated servers versus cloud VMs.

Cloud GPU offers NVIDIA accelerators, and Vultr's notable twist is fractional allocation: you can take a share of a GPU rather than the whole card, which lowers the entry point for inference and development work considerably. Full-card and multi-card configurations exist for training.

Accelerator availability varies sharply by location and by demand, so check the region before designing around a specific card. The wider landscape is covered in GPU cloud instances explained.

What every plan brings with it

Some of the platform's value sits outside the plan tiers entirely, in the things attached to any instance you create.

Bandwidth is bundled. Each plan contributes an outbound transfer allowance, and Vultr pools those allowances across the account, so a quiet instance effectively subsidises a busy one. Inbound traffic is not counted. That pooling makes month-to-month bills predictable in a way metered providers are not.

IPv6 is available without an additional address charge, and instances can be created without a public IPv4 address when they sit behind a load balancer or reach the internet through another route. Reserved IPs are separate objects that can be detached and moved, which is the basis for a simple failover swap.

Networking additions include a VPC for private communication between instances in the same location, a firewall service applied outside the guest, managed load balancers, S3-compatible object storage, managed databases, and Vultr Kubernetes Engine for teams that want a managed control plane. DDoS protection is available as an add-on in selected locations rather than universally, so confirm it where you need it.

The location list is one of the widest among developer clouds, spanning the Americas, Europe, Africa, the Middle East, South and Southeast Asia and Oceania. For applications with users spread thinly across many countries, that reach is frequently the deciding factor rather than the plan tiers.

Working out which one you need

Start from the workload rather than from the price list. Three questions usually resolve the choice without a benchmark.

Is the load sustained or bursty? A service that idles between requests, such as an internal dashboard or a marketing site, is exactly what shared vCPU was designed for. A service that keeps its cores busy for hours, such as a build fleet or a database under constant query load, should sit on dedicated cores where it cannot be starved and cannot starve anyone else.

Is the bottleneck the processor or the disk? Applications that spend their time waiting on queries improve more from NVMe storage than from extra vCPUs. If you have never measured which resource saturates first, do that before resizing; it is common to buy cores for a problem that was storage all along.

Does the work parallelise? A framework that handles one request per worker process is limited by clock speed, which favours the High Frequency tier. Workloads that spread cleanly across cores, such as container fleets or parallel batch jobs, benefit more from core count and often from the AMD-based plans.

Two mistakes recur. The first is sizing for an imagined peak and then leaving the instance oversized for a year. The second is treating the smallest shared plan as a production tier for something that genuinely matters, which works right up until a traffic spike arrives. Right-size against measurements, and revisit them after the first busy month.

Plan identifiers and the CLI

Automation needs plan identifiers, and Vultr's are readable once you know the prefixes. Shared Cloud Compute plans begin vc2, High Frequency plans begin vhf, High Performance plans begin vhp, and Optimized Cloud Compute plans begin voc, with the vCPU count and memory encoded afterwards.

The official CLI is vultr-cli. Configure it with an API key from the account settings, then enumerate what exists before creating anything:

vultr-cli plans list

vultr-cli regions list

vultr-cli os list

Creating an instance is a single call, and supplying a startup script or cloud-config keeps first-boot setup reproducible:

vultr-cli instance create --region fra --plan vhf-2c-4gb --os 2284 --label web-01 --ssh-keys $KEY_ID --vpc-enable=true

Follow up with vultr-cli instance list for an inventory and vultr-cli firewall group list to confirm which rules exist. Vultr keeps the API and product reference in its documentation portal, which is the place to check current plan codes because they change as hardware generations are refreshed.

Key takeaways

• Cloud Compute is shared vCPU in three hardware tiers; Optimized Cloud Compute is dedicated vCPU in four workload shapes.
• High Frequency suits single-threaded web applications; High Performance is the sensible modern default when you are unsure.
• Move to dedicated cores when utilisation is sustained rather than bursty, and to Storage Optimized when disk is the bottleneck.
• Bandwidth allowances pool across the account and inbound traffic is free, which keeps invoices predictable.
• Check location availability for GPUs, DDoS protection and the newest plan tiers before committing a design.

For direct comparisons against the platforms Vultr is most often weighed against, see the Hetzner and Vultr comparison and the DigitalOcean and Vultr comparison. The equivalent product orientation for DigitalOcean is Droplets explained, and the Vultr account listings describe what is available through the marketplace.