There are hundreds of VPS providers. Most of them offer the same thing: pick a plan, get a server, log in via SSH, install your stack manually. Maybe there's a basic panel to reboot or reinstall the OS. That's it.
CubePath VPS is built for teams that think about servers differently. Servers that are created and destroyed programmatically. Infrastructure defined in Terraform and version controlled in Git. Horizontal scaling behind Load Balancers where instances spin up during traffic spikes and disappear when demand drops. Hourly billing so the invoice reflects actual usage, not reserved capacity sitting idle.
This isn't VPS hosting. This is programmable infrastructure.
Instances for Every Workload

Not every application needs the same compute. A staging environment has different requirements than a production database, and a batch processing job is nothing like a latency-sensitive API. CubePath offers multiple VPS types so each workload runs on the right hardware:
Shared CPU
The most cost-effective option. Shared CPU instances provide excellent performance for workloads that don't need guaranteed CPU time. They deliver the highest number of instances per euro, making them ideal for:
- Development and staging environments
- Personal projects and prototypes
- Internal tools and dashboards
- Lightweight web servers and blogs
- CI/CD runners for non-critical pipelines
Shared CPU is real compute on real hardware. The difference is that CPU time is shared with other instances on the same host, which means performance can vary slightly during peak periods. For most workloads, this is never noticeable.
High Frequency
High Frequency instances run on the latest generation processors with higher base clock speeds. When single-thread performance matters, this is the right choice:
- Latency-sensitive APIs and microservices
- Real-time data processing
- WebSocket servers and persistent connections
- Applications with CPU-bound hot paths
- Backends where response time directly impacts user experience
The higher clock speed translates directly to faster request processing. For an API where every millisecond of response time matters, the difference between a standard processor and a high-frequency one is measurable in production.
Dedicated CPU
Dedicated CPU instances provide guaranteed CPU cores that are never shared with other tenants on the same host. Performance is consistent and predictable, regardless of what other instances are doing:
- Production databases (PostgreSQL, MySQL, MongoDB, Redis)
- Message brokers (RabbitMQ, Kafka, NATS)
- High-traffic production APIs under SLA
- Compute-intensive batch processing and data transformation
- Applications where performance variance is unacceptable
When a service is running under an SLA that guarantees response times, Dedicated CPU removes the variable of noisy neighbors from the equation entirely.
Scaling in Any Direction
Every instance type is available in multiple configurations of vCPU, RAM, and NVMe storage. Scale vertically by resizing an instance to a larger plan. Scale horizontally by adding more instances behind a Load Balancer. Or do both: run a few large Dedicated CPU instances for the database and many smaller Shared CPU instances for stateless application servers.
Hourly Billing: Pay for What You Actually Use

CubePath VPS instances are billed by the hour. Not by the month, not by an annual commitment. By the hour.
This changes how infrastructure works in practice:
Spin up 10 servers for a load test, destroy them in 2 hours, pay for 2 hours. Testing at scale shouldn't require a month-long commitment to 10 servers. Create the instances, run the test, collect the results, destroy everything. The cost is a few hours of compute, not a month.
Scale for an event, scale back after. A product launch, a marketing campaign, Black Friday, a conference. Traffic is going to spike, and the infrastructure needs to handle it. Add instances before the event, put them behind the Load Balancer, and remove them when traffic returns to normal. The bill reflects the actual duration of the scale-up, not a permanent increase in capacity.

No contracts, no penalties. Create an instance, use it for 3 hours, destroy it. There's no minimum commitment, no early termination fee, no penalty for deleting an instance. Infrastructure becomes something that's created and destroyed as needed, not something that's purchased and maintained indefinitely.
Experimentation costs almost nothing. Want to test a new architecture? Try a different database? Benchmark an application on a larger instance? Spin it up, test it, tear it down. The cost of experimentation is measured in cents, not in monthly commitments.
This model changes how teams think about infrastructure. Servers stop being pets that live for months or years and start being cattle that exist for exactly as long as they're needed. Combined with orchestration tools, this becomes genuinely elastic infrastructure.
Multiple Global Locations
CubePath operates VPS infrastructure across strategic locations:
- Spain for Southern Europe, the Mediterranean, and North Africa
- Miami for Latin America and the Caribbean
- Houston for the central United States and Mexico
- Virginia for the US East Coast and transatlantic traffic
Deploy where the users are. An application serving customers in Latin America runs in Miami. A SaaS platform for European businesses runs in Spain. A service that needs to be close to US financial infrastructure runs in Virginia.
For applications that need geographic redundancy, deploy across multiple locations. The private network between regions (with MTU 9000) keeps inter-region communication fast and free of bandwidth charges. A primary database in Spain with a streaming replica in Miami, application servers in both locations behind their respective Load Balancers, and users are always hitting the closest deployment.
Native Load Balancers
Running a single VPS is simple. Running production workloads that need to stay available when things go wrong requires more. CubePath Load Balancers distribute traffic across multiple VPS instances and handle failure automatically.
Automatic health checks. The Load Balancer continuously monitors each backend instance. When an instance fails a health check, traffic stops being sent to it. When it recovers, traffic resumes. No manual intervention, no monitoring alerts to act on. The Load Balancer handles it.
TLS termination. Offload TLS at the Load Balancer so backend instances don't need to manage certificates. One certificate configuration, one renewal process, regardless of how many instances sit behind the balancer.
Horizontal scaling that actually works. Add more instances behind the Load Balancer during peak hours, remove them when traffic drops. Combined with hourly billing, this means paying for extra capacity only during the hours it's actually needed. Ten instances for 8 hours during the day, three instances overnight. The Load Balancer distributes traffic across whatever is running.
Multiple protocols. HTTP, HTTPS, TCP, UDP. Whether it's a web application, a TCP service, or a UDP-based protocol, the Load Balancer handles the distribution.
Orchestration Tools: Terraform, CLI, SDK

A VPS that can only be managed through a web panel is a VPS that can't be automated. CubePath provides the tools to manage infrastructure programmatically, the same way modern teams manage everything else.
Terraform Provider
Define CubePath infrastructure as code. VPS instances, Load Balancers, private networks, DNS records, firewalls. All of it declared in Terraform files, version controlled in Git, applied with terraform apply, and destroyed with terraform destroy.
terraform {
required_providers {
cubepath = {
source = "cubepath/cubepath"
version = "~> 1.0"
}
}
}
provider "cubepath" {
# API token via CUBE_API_TOKEN environment variable
}
resource "cubepath_project" "app" {
name = "production"
description = "Production infrastructure"
}
resource "cubepath_network" "private" {
name = "app-network"
project_id = cubepath_project.app.id
location = "us-mia-1"
ip_range = "10.0.1.0"
prefix = 24
}
resource "cubepath_vps" "web" {
count = 3
name = "web-${count.index}"
project_id = cubepath_project.app.id
location = "us-mia-1"
plan_name = "gp.pro"
template_name = "ubuntu-24-04"
network_id = cubepath_network.private.id
ssh_key_names = ["my-key"]
}
Projects, networks, instances, SSH keys, all defined as code. Infrastructure changes go through pull requests. Peer review before anything is created or destroyed. Full audit trail in Git history. Roll back by reverting a commit.
CLI
Manage instances, networks, Load Balancers, and every other CubePath resource from the terminal. Script operations, integrate into shell workflows, or use it for quick ad-hoc management.
# Configure your API token
cubecli config setup
# List VPS instances
cubecli vps list
# Create a VPS instance
cubecli vps create
# Show details of a specific VPS
cubecli vps show <id>
# Destroy a VPS instance
cubecli vps destroy <id>
# Manage Load Balancers
cubecli lb list
cubecli lb create
# Manage private networks
cubecli network list
cubecli network create
# JSON output for scripting
cubecli vps list --json | jq '.[].vps[].name'
SDK
For teams building custom tooling, deployment systems, or internal platforms, the SDK provides programmatic access to everything CubePath offers. Build auto-scaling logic, custom deployment workflows, or integrate CubePath into an existing internal developer platform.
Everything Through the API
The Terraform provider, CLI, and SDK all consume the same API. The web panel consumes the same API. There's no feature that exists in one place but not another. If it can be done in the panel, it can be automated.
Cloud Alerts: Monitoring and Notifications
Knowing what's happening in the infrastructure without staring at dashboards all day is essential for teams operating production services. CubePath includes Cloud Alerts to create alerts on instance resource consumption and receive notifications wherever the team is already working.
Resource alerts. Configure alerts when CPU usage exceeds a threshold, when memory is running low, when disk is filling up, or when network traffic spikes. The system monitors instance metrics and fires the alert when the condition is met.
Notifications to Slack, Email, and more. Alerts arrive where the team needs them. A Slack channel for the infrastructure team, an email to the on-call engineer, or both. No installing monitoring agents on instances, no setting up Prometheus from scratch, no building alerting infrastructure from the ground up.
React before it becomes a problem. A CPU alert at 90% allows scaling before the service degrades. A disk alert at 85% gives time to clean up or expand before the database stops. Alerts turn monitoring into proactive action instead of reactive firefighting.
The Full Ecosystem: Not Just a Server

A VPS in isolation is just a server. What makes CubePath VPS useful for production infrastructure is everything that connects to it:
Private networking. Connect VPS instances on an isolated private network. Traffic between instances stays on the private network and never touches the public internet. No bandwidth charges for private traffic. Available within a region and across regions with MTU 9000.
Managed firewalls. Define firewall rules from the panel or the API. Allow SSH from specific IPs, open ports for the application, block everything else. Rules apply at the network level before traffic reaches the instance. No need to configure iptables or nftables on every server manually.
DNS management. Host DNS zones on CubePath and manage records alongside the rest of the infrastructure. Point domains at Load Balancers, create records for internal services, manage everything from the same API.
Floating IPs. Assign a public IP that can be moved between instances instantly. If the primary instance fails, reassign the Floating IP to a standby. DNS doesn't change, clients don't reconnect. The IP moves to a healthy instance in seconds.
Backups and snapshots. Schedule automatic backups or create manual snapshots before making changes. Restore from a snapshot to get back to a known good state.
DDoS protection included. Every VPS instance is protected by CubePath's FlowSpec-based DDoS mitigation on the edge routers. No extra configuration, no additional cost. The network protects itself.
VPS Built for Building
CubePath VPS isn't designed for people who want to rent a server and forget about it. It's designed for teams that treat infrastructure as code, that scale horizontally behind Load Balancers, that create and destroy instances based on demand, and that automate everything through APIs and orchestration tools.
Hourly billing means paying for actual usage. Multiple instance types mean each workload runs on the right hardware. Terraform, CLI, and SDK mean infrastructure is programmable. Load Balancers, private networks, firewalls, DNS, and Floating IPs mean every piece needed for production architecture is already there.
The VPS is the building block. What gets built with it is up to the team.
