Some links may earn us a commission at no added cost to you. Providers do not approve our conclusions.
Vultr Cloud Compute suits teams that can manage their own OS, backups, and security. It offers flexible provisioning and hourly billing up to 672 hours per month. Downgrading plans is not supported, so size carefully. Stopped instances still incur charges; destroy them to stop billing.
Who Should Choose Vultr Cloud Compute and Who Should Look Elsewhere
Vultr Cloud Compute instances are shared CPU virtual machines designed for bursty workloads such as low-traffic websites, blogs, CMS, development/test environments, and small databases. They run general-purpose applications without specific CPU, memory, or storage performance restrictions. If your team has the skills to manage an operating system, apply security patches, and maintain backups, this product fits.
The service is self-managed: Vultr provides the infrastructure, but you are responsible for software configuration, monitoring, and data protection. Agencies and freelancers comfortable with the command line or infrastructure-as-code tools will recognize the workflow. Small ecommerce sellers who prefer a managed solution with built-in support for application-level issues should verify whether a managed alternative better matches their operational capacity.
- Good for: developers, agencies, and technical freelancers running low-traffic sites or test environments.
- Avoid if: you need managed application support, one-click downgrades, or hands-off backups.
Billing: Hourly Charges Persist Until Destruction, Not Just Shutdown
Vultr bills Cloud Compute instances on an hourly basis up to 672 hours per month. The minimum billing unit is one hour, and charges start when a server is deployed regardless of power state. Stopped instances continue to incur charges for reserved compute, storage, and IP addresses. To stop billing, you must destroy the instance via the control panel, API, CLI, or Terraform.
Invoices are generated on the 1st of each month and cover the previous period. This model works well for short-lived dev environments, but leaving unused instances in a stopped state will accumulate costs. Always check your account for orphaned resources before the billing cycle closes.
- Hourly billing cap: 672 hrs/mo for Cloud Compute.
- Minimum charge: 1 hour; starts on deployment, even if powered off.
- Stopped ≠ billing suspended. Destroy to stop charges.
- Invoices: 1st of each month for previous period.
Sources: [1] Vultr server billing guide
Resize Limitations: Upgrade Only, No Downgrade Path
You can resize a Cloud Compute instance to a larger plan without data loss. The process activates a new plan with more vCPUs, RAM, and storage, preserving the file system. However, downgrading to a smaller plan is explicitly not supported. If you start with a plan that is too large for your workload, you must migrate to a new instance to reduce resources.
Resizing can be done via the console, API, CLI, or Terraform. The upgrade is not instantaneous; the documentation mentions a job-based process that you can monitor. While the resize operation itself preserves data, you should create a snapshot or verify your latest automatic backup before initiating an upgrade.
- Upgrade only: cannot switch to a smaller plan.
- Data and file system remain intact during upgrade.
- Monitor resize via job ID with API/CLI.
- No documented rollback: snapshot before upgrading.
Backup Duties: Enable Automatic Backups on a Schedule or Create Manual Snapshots
Automatic backups are an optional feature that creates full backups of the instance’s data and file system on a schedule you define (daily, weekly, or monthly) with a chosen UTC hour. Enabling them is a manual step through the console, API, or Terraform after instance creation. Without this, your data is unprotected against failures.
Snapshots are also available for point-in-time recovery. Both auto backups and snapshots are stored in your Vultr account and can be restored to a new instance. The auto-backup schedule and retention are managed by you, not Vultr. You should test restoration yourself to ensure the backups are functional.
- Auto backups: scheduled full backups (daily/weekly/monthly) with configurable UTC hour.
- Must be explicitly enabled per instance – not on by default.
- Snapshots: manual point-in-time backups for recovery.
- Restore to a new instance; verify restoration with your own tests.
Sources: [1] Vultr Cloud Compute automatic backups documentation
Operational Responsibilities: OS Patching, Monitoring, and Security
Vultr provides the hypervisor and hardware, but you own everything inside the instance. This includes applying OS updates, securing SSH access, configuring the firewall (Vultr Firewall groups are available), and monitoring resource usage. The built-in Monitoring feature shows CPU, disk operations, and bandwidth statistics. Check the latest documentation to see if alerting or automated actions based on thresholds have been added.
You can change the OS via reinstall, which preserves the IP and hostname but wipes data. The Custom ISO feature lets you boot from your own image. SSH key management, startup scripts, and Cloud-Init user data give you control over initial configuration. Without a managed service layer, troubleshooting application errors or performance issues is your team's responsibility.
- User-managed: OS updates, SSH security, firewall rules.
- Monitoring: CPU, disk, bandwidth metrics; verify current alerting options.
- Reinstall OS keeps IP/hostname; data is lost.
- Custom ISO support for bespoke installations.
Sources: [1] Vultr Cloud Compute documentation[2] Vultr Cloud Compute provisioning guide
Primary sources
We use provider documentation for product facts and mark time-sensitive details for rechecking.