Documentation
Build on CloudVantage
Everything you need to provision, manage, and scale your cloud infrastructure — from signing up to running production workloads.
Start here
Register, verify your email, and access your dashboard.
Set up your workspace to organize resources.
Add credits to start provisioning resources.
Launch your first virtual machine in minutes.
Compute
Flexible VMs with monitoring, alarms, and resizing.
Point-in-time backups of your virtual machines.
Automatically grow or shrink your server fleet on demand.
Storage
Persistent block storage for your virtual machines.
Point-in-time copies of storage volumes.
Independent copies for long-term data protection.
Networking
Isolated networks for secure internal communication.
Firewall rules for inbound and outbound traffic.
Route traffic between subnets and external networks.
Public IPs you can attach to private instances.
Distribute traffic across backends for high availability.
Secure vault for SSL/TLS certificates.
Managed Services
Coming soon
Encrypted site-to-site tunnel connections.
Coming soonScalable storage for images, videos, backups, and assets.
Coming soonFull REST API documentation and interactive explorer.
Coming soonCommand-line tools for scripting and automation.
Coming soonOverview
Who is CloudVantage?
Cloudvantage is a fast, reliable, and scalable cloud provider solutions that help businesses deploy infrastructure with just a few clicks.
CloudVantage provides fast, reliable, and scalable cloud solutions that enable businesses and organisations to deploy servers and infrastructure with just a few clicks. With CloudVantage, you can easily create and manage virtual machines (Dews), networks, storage, and other cloud resources needed to run your applications efficiently.
CloudVantage allows you to scale and customise your servers easily, providing flexibility and efficient resource utilisation. Whether you are running a small web application or a large-scale enterprise system, CloudVantage gives you the tools to deploy and manage infrastructure confidently.
Key concepts
Familiarise yourself with these terms first — they are used throughout the documentation and will help you navigate it more easily.
| Term | Description |
|---|---|
| Dew | A virtual server (VM) hosted in the cloud. Functions like a traditional machine but is fully managed on the CloudVantage platform. Configurable with different CPU, memory, and storage specifications called flavors. Common uses: hosting applications and websites, running databases, processing data, file storage, and network services. |
| Wallet | Prepaid balance used to pay for all resources. Must have sufficient funds before provisioning. Charges are deducted immediately when a resource is created; deleting a resource before the billing period ends triggers a refund for the unused time, returned directly to your wallet. |
| Project | An organisational unit that groups your cloud resources together. Project names must be unique platform-wide and a description is required. You can create multiple projects to separate different workloads and switch between them using the project selector on the top bar. |
| Flavor | A server size configuration defining vCPUs, RAM, and disk. CloudVantage offers predefined flavors (e.g., Vantage Nano: 1 vCPU / 1 GB RAM / 30 GB disk) and supports custom flavors for specific workload requirements. Disk size cannot be reduced once allocated — only increased. |
| Snapshot | A point-in-time backup. Server snapshots capture the entire instance state (data, system configuration, current state). Volume snapshots capture a storage volume. Both can be used to restore or create new resources. |
| Floating IP | A publicly routable IP address that can be assigned to a private instance to make it accessible from the internet. Maximum 3 per project. Contact support if you require additional Floating IPs. |
| Security Group | A virtual firewall that controls inbound (ingress) and outbound (egress) network traffic to and from your servers. When a Dew is provisioned, two groups are automatically created: a default group (allows all outbound) and a group with port 22 (SSH) open. |
| Router | Enables communication between different networks and to external networks. Automatically connected to the external network upon creation. Interfaces connect routers to private subnets, enabling traffic to flow between subnets and out to the internet. |
| Volume | A persistent virtual storage device (like a hard drive) that can be attached to a Dew. Data persists independently of the VM's lifecycle — even if the server is restarted or terminated. Must be detached before it can be deleted. |
| Load Balancer | Distributes incoming traffic across multiple backend servers. Consists of a Listener (accepts traffic), a Pool (group of backends), Pool Members (individual servers), and a Health Monitor (checks backend health). |
| Auto Scaling Group | Automatically adjusts the number of running VMs based on demand using CPU and RAM thresholds. Integrates with a Load Balancer for traffic distribution and health monitoring. |
| Certificate Manager | Secure vault for SSL/TLS certificates. Certificates stored here are used by Load Balancers (TERMINATED HTTPS) and Auto Scaling Groups. Certificates cannot be downloaded after upload. |
Quick start path
Register at www.cloudvantage.com.ng and verify your email address before signing in.
Projects help you organise and manage your cloud resources. You'll be prompted to create one immediately after signing in for the first time. Project names must be unique platform-wide and a description is required.
CloudVantage uses a prepaid wallet model. A virtual bank account is automatically created for you at registration. You must fund your wallet before provisioning any resources. Charges are deducted from your wallet immediately when a resource is created; unused time is refunded when you delete a resource.
Create a virtual server (Dew) with your chosen operating system, size (flavor), authentication method, and network configuration.
Platform overview
The CloudVantage platform is organised into the following sections, all accessible from the sidebar navigation:
- Compute — Dews (virtual servers), Server Snapshots, Auto Scaling
- Storage — Volumes, Volume Snapshots, Volume Backups
- Networking — Private Networks, Security Groups, Routers, Floating IPs, Load Balancer
- Security — Certificate Manager
- Account — Billing, Event Logs, Settings, Support
Getting Started
Creating an Account
Register on CloudVantage to access your dashboard and begin provisioning resources.
To begin using the CloudVantage platform, you need to create an account at www.cloudvantage.com.ng.
Registration steps
- Visit the platform
Go to www.cloudvantage.com.ng.
- Click My Account
Select My Account from the top navigation menu.
- Register or sign in
Click Create an Account if you're new. Existing users sign in with their email address and password.
- Complete registration
Enter all required details on the registration page and click Create Account.
- Verify your email
A verification email will be sent to your registered address. Open it and confirm your account before signing in.
Your account won't be active until you confirm it via the verification email. Check your spam folder if the email doesn't arrive within a few minutes.
Once signed in, you'll be prompted to create a project. Continue to Projects →
Getting Started
Projects
Isolated workspaces that organise your cloud resources. Every server, volume, and network belongs to a project.
Projects are the primary organisational unit on CloudVantage. Every resource you create — Dews, volumes, networks, load balancers — belongs to a specific project. You can create multiple projects to separate different workloads or environments (e.g., development, staging, production).
Creating your first project
After signing in for the first time, you'll be automatically prompted to create a project before accessing your dashboard.
- Enter a project name
Choose a unique name. Project names must be unique across the entire platform.
- Provide a description
A description is required. Use it to identify this project's purpose or environment (e.g., "Production web infrastructure").
- Click Create Project
You'll be redirected to your dashboard where you can start provisioning resources.
If the name is already taken, you'll receive an error. Choose a different, more specific name (e.g., include your company name or environment).
Editing your current project
- Click Manage Project
Select Manage Project from the sidebar.
- Update details
Edit the project name or description as needed.
- Save changes
Click Save to apply the changes.
Creating additional projects
You can create multiple projects to separate different workloads or environments.
- Open the project selector
Click your current project name in the top bar.
- Select Create New Project
Enter a unique project name and a required description.
- Click Create Project
Switch between projects at any time using the project selector in the top bar.
Resources created in one project are not visible or accessible from other projects. This isolation makes projects ideal for separating environments like development and production.
Getting Started
Funding Your Wallet
CloudVantage uses a prepaid wallet model. You must have sufficient balance before provisioning any resource.
When you register, a virtual bank account is automatically created for you. All resource costs are deducted from your wallet balance immediately upon provisioning. If you delete a resource before the billing period ends, the unused portion is refunded directly to your wallet.
How to fund your wallet
- Click Fund Wallet
Click the Fund Wallet button in the top-right corner of your dashboard.
- View your virtual account details
Your virtual bank account number and other details will be displayed on screen.
- Copy the account details
Copy the account number and bank details for your transfer.
- Make a payment
Transfer the desired amount using the provided account details. Once payment is confirmed, the funds will reflect in your CloudVantage wallet balance.
If your balance runs low or reaches zero, resource provisioning and Auto Scaling events may be interrupted. Monitor your balance regularly from the Fund Wallet button.
When your billing period ends, you have a 15-day grace period to make payment. If payment is not received within 15 days, your server will be shut down. If payment is still not made after a further 45 days, your server will be permanently deleted and decommissioned — all data will be lost and cannot be recovered. Ensure your wallet is funded before your billing period ends to avoid any interruption or data loss.
Switching billing currency
CloudVantage allows you to switch your billing currency between Naira (₦) and US Dollars ($).
- Click Fund Wallet
In the top-right corner of your dashboard.
- Click Currency Settings
Click Currency Settings below the account information.
- Switch currency
Select Switch to Dollar to change billing from Naira to USD, or the reverse to switch back.
Currency preferences can also be changed at cloudvantage.com.ng/settings.
Compute
Dews (Servers)
Virtual servers that provide the computing resources required to run applications and services on CloudVantage.
Dews function like traditional machines but are hosted in the cloud. They can be configured with different amounts of CPU, memory, and storage depending on your workload requirements. CloudVantage allows you to scale and customise your servers easily, providing flexibility and efficient resource utilisation.
Common use cases
- Hosting applications and websites
- Running databases
- Processing and transforming data
- File storage and backup targets
- Network services (DNS, VPN endpoints, proxies)
- Continuous integration / build servers
3.1 Provisioning a Dew
When you provision a Dew, the full amount for the selected billing term is deducted from your wallet immediately. Ensure sufficient funds are available before proceeding.
When your billing period expires, you have a 15-day grace period to renew. After 15 days without payment, your server is shut down. After a further 45 days without payment, your server is permanently deleted and all data is lost with no possibility of recovery. Always ensure your wallet has sufficient funds before your billing period ends.
- Navigate to your Dashboard
Click Resources, then select Create Dew.
- Select a plan
You will see a list of available server plans (flavors) with their specifications and pricing. Example plans include:
- Vantage Nano — 1 vCPU, 1 GB RAM, 30 GB Disk
- Additional flavors with increasing CPU/RAM/disk are available
- Custom flavors can be created to match specific requirements
Select your desired plan and click Configure to proceed.
- Configure your server
Set the following options:
- Term Length — select your preferred billing period (monthly or yearly)
- Operating System — choose your OS and version: Ubuntu, CentOS, Debian, Windows, and others. Example: Ubuntu 22.04 LTS
- Instance Name — enter a name to identify this Dew within your project
- Choose an authentication method
See Authentication Methods below.
- Configure the network
Select one of the following options:
Option Accessibility When to use Public Network Accessible from the internet — server receives a public IP address Web servers, APIs, or any service that needs to be reached externally Private Network Internal only — not reachable from the internet Databases, backend services, or instances you want to keep off the public internet. A private network must already exist in your project. You can assign a Floating IP later if external access is needed. - Review and provision
Review the server configuration summary and price. Ensure your wallet has sufficient funds, then click Provision. Your new Dew will be created shortly.
Authentication methods
1. SSH Key Authentication (Recommended)
Select an existing keypair or create a new one. The keypair will be downloaded as a .pem file. Keep this file secure — it is required to access your server and cannot be retrieved from the platform again.
- Select from Existing Keypairs — click "Select from Existing Keypairs" and choose from the dropdown
- Create a New Keypair — click "Create New Keypair", enter a name, click "Create Key". The
.pemfile downloads automatically.
2. Password Authentication
Enter and confirm a password. The login username will be automatically generated for you.
When a new SSH keypair is created, the .pem file is available for download at that moment only. It is never stored on the platform and cannot be recovered if lost. Before proceeding to the next step, confirm you have downloaded and saved the file in a secure location. If you lose it, you will be unable to SSH into the server and will need to rebuild it.
3.2 Viewing Dew Information
To view details of any provisioned Dew:
- Locate the Dew on your Dashboard
- Click the Dew name
A panel will appear displaying: public or private IP address, flavor specification, operating system, keypair used for authentication, and network configuration.
3.3 Monitoring & Metrics
You can monitor the performance of each provisioned Dew through the metrics dashboard. The platform provides visual graphs for the following metrics:
You can filter metrics by selecting a start and end date to analyse usage within a specific period.
- Locate the instance on your dashboard
- Click Show Metrics
Click Show Metrics next to the instance.
- View and filter
The metrics page will display graphs for CPU, memory, disk, and egress. Use the date range selectors to analyse a specific period.
3.4 Alarms
Alarms notify you by email when resource usage exceeds defined thresholds. You can configure CPU, RAM, and disk thresholds independently and control how often notification emails are sent.
You can create only one alarm per Dew instance. Configure all thresholds within that single alarm configuration.
Creating an alarm
- Click Show Metrics
Locate the instance and click Show Metrics.
- Select Alarming
On the Metrics page, click the Alarming tab.
- Click New Alarm and configure
- CPU Threshold (%) — trigger level for CPU usage alerts
- RAM Threshold (%) — trigger level for memory usage alerts
- Disk Threshold (%) — trigger level for disk usage alerts
- Notification Frequency — how often alert emails are sent while the threshold is breached
- Maximum Emails Per Day — cap on daily alert emails to prevent inbox flooding
- Statistic Type — Average, Maximum, or Minimum measurement used for threshold evaluation
- Email Recipient — primary alert email address
- CC Emails — optional additional recipients
Updating an alarm
- Click Show Metrics next to the instance
- Select Alarming → Edit Alarm
Locate the alarm and click Edit Alarm.
- Update and save
Update the required fields and click Save.
Deleting an alarm
- Click Show Metrics next to the instance
- Select Alarming → Delete Alarm
- Confirm
The instance will no longer send alert notifications.
3.5 Resizing a Dew
Resizing a Dew allows you to adjust the resources allocated to it (vertical scaling). You can increase or decrease vCPUs and RAM, but disk size cannot be reduced once allocated — only increased.
| Option | Description |
|---|---|
| Resize to a Preconfigured Flavor | Choose from a predefined list of flavors offering different CPU/RAM/disk combinations. |
| Resize to a Custom Flavor | Manually specify vCPU count and RAM. Disk size can only be increased, not decreased. |
- Open Manage
Locate the Dew and click Manage next to the instance.
- Select Resize
Click Resize Instance to open the resize configuration page.
- Select option and configure
Select your preferred resizing option (preconfigured or custom) and set the desired resources.
- Click Initiate Resize
The platform will begin the resize operation.
- Confirm or stop
A confirmation dialog appears. Click Confirm Resize to apply or Stop Resize to revert.
Do not refresh the page until you have either confirmed or cancelled the resize operation. Refreshing prematurely may leave the Dew in an intermediate state.
3.6 Shutting Down & Restarting a Dew
You can shut down a running Dew at any time from the dashboard. A shut-down Dew becomes inactive but is not deleted — it continues to exist in your project and can be restarted whenever needed.
Shutting down a Dew
- Locate the Dew on your dashboard
- Click Manage next to the instance
- Select Shutdown Server
The server will power off and its status will change to Inactive.
Restarting a Dew
- Locate the inactive Dew on your dashboard
- Click Manage next to the instance
- Select Restart Server
The server will boot back up and its status will return to Active.
3.7 Deleting a Dew
Deleting a Dew permanently removes it from your project. Any unused time remaining in the billing period will be refunded to your wallet.
Once a Dew is deleted, it cannot be recovered. If you need to preserve its state, create a snapshot before deleting.
- Locate the Dew on your dashboard
- Click Manage next to the instance
- Select Delete Server
- Confirm the action
A confirmation prompt will appear. Confirm to permanently delete the server.
Compute
Server Snapshots
A point-in-time backup of an entire virtual machine — capturing its data, system configuration, and current state.
Snapshots allow you to restore an instance in the event of data loss, a system failure, or issues arising from an update. The snapshot captures the full state of the Dew at the moment it is taken, including all files, installed packages, configuration, and running state.
Common uses for server snapshots:
- Pre-upgrade checkpoints — take a snapshot before applying major updates or changes
- Disaster recovery — restore an instance to a known-good state after failure
- Cloning — launch multiple identical servers from a single snapshot template
- Migration — move a server configuration to a new instance with different resources
4.1 Creating a Server Snapshot
- Locate the instance
Find the Dew you want to snapshot on your dashboard.
- Open Manage
Click the Manage icon next to the instance.
- Select Create Snapshot
- Enter a name
Enter a descriptive name for the snapshot (e.g.,
prod-web-pre-upgrade-2025-01). - Choose a payment option
Select monthly or yearly billing for snapshot storage.
- Click Create Snapshot
Snapshot creation may take several minutes depending on disk size.
4.2 Viewing Snapshots
Navigate to Server Snapshots on the sidebar. This page displays a list of all snapshots created for your Dews, showing: snapshot name, OS Distro, creation date, size, and status.
4.3 Managing Snapshots
Click Manage Snapshot next to any snapshot. Available actions include:
- Create a Volume from Snapshot — extract the snapshot's data as a new volume
- Edit Snapshot — update the name or description
- Launch a New Dew from Snapshot — spin up a new server using this snapshot as its disk image
- Delete Snapshot — permanently remove the snapshot (irreversible)
Launching a Dew from a Snapshot
- Go to Server Snapshots from the sidebar
- Click Manage Snapshot → Launch
Select Launch next to the snapshot you want to use.
- Proceed through the Dew creation process
Configure the new Dew as needed (flavor, authentication, network) and provision it.
Creating a Volume from a Snapshot
- Click Server Snapshots on the sidebar
- Click Manage Snapshot → Create Volume from Server Snapshot
- Provide details
Enter Volume Name, Volume Size (cannot be smaller than the snapshot size), Payment Option, and an optional Description.
- Click Create Volume
The new volume will appear on the Volumes page, ready to attach to any instance.
Deleting a Snapshot
- Navigate to Server Snapshots
- Click Manage Snapshot → Delete Snapshot
- Confirm
Once deleted, the snapshot is permanently removed and cannot be recovered. Ensure you no longer need it before proceeding.
Compute
Auto Scaling
Automatically adjust the number of running VMs based on demand — scaling up during traffic spikes and down during quiet periods.
Auto Scaling automatically adjusts the number of virtual machines running your application based on demand. Instead of manually provisioning or removing servers, the platform continuously monitors resource usage and automatically increases or decreases instances as needed.
- High availability — maintain service during periods of increased traffic without manual intervention
- Cost efficiency — automatically scale down during low-demand periods to avoid paying for idle capacity
- Reduced operational overhead — eliminate the need to manually monitor and adjust server counts
5.1 Infrastructure & Networking
These settings form the template for every server the Auto Scaling Group launches. All instances in the group are created from the same configuration.
| Setting | Description |
|---|---|
| Image | A snapshot of an existing instance containing your fully configured application. Ensure your application is running correctly before taking the snapshot. This becomes the disk image for all instances launched by the group. |
| Flavor | VM size (CPU, memory, disk). All instances in the group use the same flavor. Choose a flavor sized for your application's peak load requirements. |
| Key Pair | SSH key pair used to access all instances created by the Auto Scaling Group. |
| VM Name | Base name for instances. The platform appends unique identifiers automatically — e.g., web-server becomes web-server-01, web-server-02. |
| Network | Private network where instances will be deployed. All instances join this network. |
| Subnet | Subnet within the private network. Ensure it has enough available IP addresses to accommodate your maximum instance count. |
| Security Groups | Security groups defining network access. Ensure required ports are open: SSH (22), HTTP (80), HTTPS (443), and any application-specific ports. |
| Application Port | Port your application listens on (e.g., 80, 443, 8080). Used by the Load Balancer when adding pool members and by Health Monitoring to check instance status. |
5.2 Scaling & Capacity Management
These settings control when and how the Auto Scaling Group adds or removes instances in response to demand.
| Setting | Description |
|---|---|
| Minimum Size | The minimum number of instances that must always remain running. The system never scales below this number. Set to at least 1 (or 2 for high availability). |
| Maximum Size | Maximum number of instances that can run simultaneously. Prevents uncontrolled scaling that could exhaust your wallet balance. |
| Desired Capacity | Initial number of instances launched when the Auto Scaling Group is first created. The group scales up or down from this starting point. |
| Cooldown Period | How long (seconds) the system waits after a scaling action before evaluating whether to scale again. Prevents rapid repeated scaling ("flapping"). Typical value: 300 seconds (5 minutes). |
Scaling policies
| Setting | Description |
|---|---|
| Scale Up Adjustment | Number of instances added when a scale-up threshold is triggered. Set to 1 for gradual scaling, higher for faster response to traffic spikes. |
| Scale Down Adjustment | Number of instances removed when a scale-down condition is met. Lower values (e.g., 1) are safer and reduce the risk of over-aggressive scale-down. |
| Scaling Cooldown | Stabilisation period between scaling actions. After adding or removing instances, the system waits this duration before re-evaluating. |
CPU-based scaling rules
| Setting | Description |
|---|---|
| CPU Scale Up Threshold (%) | Average CPU usage % that triggers adding more instances (e.g., 70%). When average CPU across all running instances exceeds this value for the configured evaluation periods, a scale-up action is triggered. |
| CPU Scale Down Threshold (%) | Average CPU usage % below which instances are removed (e.g., 30%). When usage consistently stays below this value, a scale-down action is triggered. |
| CPU Evaluation Periods | Number of consecutive monitoring intervals the threshold must be exceeded before scaling occurs. Higher values prevent premature scaling from temporary spikes — e.g., value of 3 means threshold must be exceeded in 3 consecutive checks. |
Memory (RAM) based scaling rules
| Setting | Description |
|---|---|
| RAM Scale Up Threshold (%) | Triggers a scale-up when average memory usage across instances exceeds this percentage. |
| RAM Scale Down Threshold (%) | Triggers a scale-down when average memory usage falls below this percentage. |
| RAM Evaluation Periods | Number of consecutive checks required before a memory-based scaling action is triggered. Prevents scaling due to temporary memory spikes. |
5.3 Traffic Management & Health Monitoring
The Auto Scaling Group integrates with a Load Balancer to distribute traffic across instances and verify their health.
| Setting | Description |
|---|---|
| Listener Protocol | How users connect — HTTP, HTTPS, or TCP. HTTPS requires an SSL certificate in Certificate Manager first. |
| Listener Port | Port exposed to users (e.g., 80 for HTTP, 443 for HTTPS). |
| Pool Protocol | Protocol between Load Balancer and backend instances. Default is HTTP — the LB handles SSL termination and forwards plain HTTP to backends. |
| Load Balancing Algorithm | How traffic is distributed: Round Robin (evenly in sequence) or Least Connections (to the instance with fewest active connections). |
| Health Check Type | HTTP — sends a request to a URL path and checks the response code. TCP — attempts a connection on the application port. |
| Delay (seconds) | Time between health check attempts. Lower values detect failures faster but generate more traffic. |
| Timeout (seconds) | Max time to wait for a health check response before marking the check as failed. Must be less than Delay. |
| Retries | Number of consecutive failed checks before an instance is marked unhealthy and removed from the pool. |
| Health Check URL Path | Endpoint for HTTP checks (e.g., /health, /status, /ping). Must return a successful HTTP response code. |
| Expected HTTP Codes | HTTP response codes considered healthy (e.g., 200, 200-299). |
5.4 Editing an Auto Scaling Stack
The following settings are locked after creation. If you need to change these, you must delete and recreate the Auto Scaling Group:
- Image (snapshot template)
- Flavor (VM size)
- Key Pair (SSH access)
- Network and Subnet
- Security Groups
All other parameters — scaling thresholds, capacity limits, cooldown periods, health check settings, and traffic configuration — can be modified after creation as your workload requirements change.
5.5 Pricing & Billing
Resources created within an Auto Scaling Group are billed the same way as standalone resources. Each instance and its associated load balancer pool member incur standard platform charges.
Ensure your wallet always has enough balance to cover your maximum instance count plus their pool members. For example, with maximum size 5 and 5 pool members, your wallet should cover all 10 resources at maximum scale. Insufficient funds will interrupt Auto Scaling events.
Storage
Volumes
Virtual storage devices that function like hard drives attached to a cloud VM — persisting data independently of the VM's lifecycle.
A Volume is a persistent block storage device that can be attached to a Dew. Unlike the Dew's built-in disk, a Volume exists independently — data persists even if the server is restarted or terminated. Volumes can be detached from one Dew and reattached to another.
6.1 Creating a Volume
- Click Volumes on the sidebar
Select Volumes from the dropdown menu.
- Click Create Volume
In the top-right corner of the Volumes page.
- Enter details
Enter the Name, Size (in GB), and Payment Option (Monthly or Yearly). Review the estimated cost before confirming.
- Click Create Volume
Ensure your wallet has sufficient funds before proceeding.
6.2 Attaching and Detaching Volumes
Attaching a volume to an instance
- Navigate to Volumes from the sidebar
- Locate the volume and click Manage Volume
- Select Attach to Instance
Choose the target instance from the dropdown and click Attach. The volume will appear as a new block device on the server (e.g.,
/dev/vdb).
Detaching a volume from an instance
- Navigate to Volumes from the sidebar
- Click Manage Volume for the volume
- Select Detach from Instance
Confirm the detachment. The volume will move to "Available" status and can be attached to a different instance or deleted.
6.3 Deleting a Volume
- Navigate to Volumes from the sidebar
- Locate the volume, click Manage Volume, then select Delete Volume
- Confirm the action
A volume must be detached from any instance (status must be Available) before it can be deleted. Attempting to delete an in-use volume will fail.
6.4 Volume Snapshots
A Volume Snapshot is a point-in-time copy of a storage volume. It preserves the exact state of the volume's data at the moment it is taken, and can be used to create a new volume from that saved state.
Volume snapshots can only be created when the volume status is Available. If the volume is currently In Use (attached to an instance), you must detach it first.
Creating a volume snapshot
- Navigate to Volumes → Volumes from the sidebar
- Locate the volume, click Manage Volume → Create Volume Snapshot
- Enter details
Enter a Snapshot Name, Description, and Payment Option. The size is auto-populated from the source volume.
- Click Create Volume Snapshot
The snapshot will appear on the Volume Snapshots page.
Editing a volume snapshot
- Navigate to Volumes → Volume Snapshots from the sidebar
- Click Manage Volume Snapshot → Edit Volume Snapshot
- Update Name or Description and click Update Snapshot
Creating a new volume from a snapshot
- Navigate to Volumes → Volume Snapshots
- Click Manage Volume Snapshot → Create Volume
- Fill in details
Enter Volume Name, Size (must be ≥ snapshot size), Billing Plan, and optional Description.
- Click Create Volume
The new volume will be listed on the Volumes page, ready to attach.
Deleting a volume snapshot
- Navigate to Volumes → Volume Snapshots
- Click Manage Volume Snapshot → Delete Volume Snapshot and confirm
6.5 Volume Backups
A Volume Backup is a secure, independent copy of your volume stored separately from your running system. Unlike snapshots (which are tied to the volume's lifecycle), backups exist independently — making them suitable for longer-term data protection and disaster recovery.
Unlike snapshots, volume backups can be created while the volume is attached and the server is running. You do not need to detach the volume first.
Creating a volume backup
- Navigate to Volumes → Volumes from the sidebar
- Locate the volume, click Manage Volume → Create Volume Backup
- Enter details
Enter a Backup Name, Description, and Payment Option. The size is auto-populated.
- Click Create Volume Backup
The backup will appear on the Volume Backups page.
Restoring a volume from a backup
- Navigate to Volumes → Volume Backups
- Click Manage Backup → Restore Backup
- Choose destination
- New Volume — enter a name for the new volume to be created from the backup
- Existing Volume — select a volume from the dropdown to overwrite it with the backup data
Click Restore to confirm.
Deleting a volume backup
- Navigate to Volumes → Volume Backups
- Click Manage Volume Backup → Delete Volume Backup and confirm
Networking
Private Networks
Allows your servers to communicate securely with each other within your cloud environment without exposing traffic to the public internet.
A Private Network allows your servers to communicate securely with each other within your cloud environment. Traffic between servers on the same private network stays internal — it is never exposed to the public internet. You can attach private network instances to routers and assign them Floating IPs when external access is needed.
Creating a Private Network
- Click Networks on the sidebar → Private Networks
- Click Create Network
In the top-right corner.
- Enter a Network Name and optional Description
Choose a name that identifies this network's purpose (e.g.,
prod-network,backend-db-net). - Click Create Network
Viewing Network Details
- Click Networks → Private Networks
- Click Manage Network → View Network Details
Displays the network's configuration, attached subnets, and connected resources.
Editing a Private Network
- Go to Networks → Private Networks
- Click Manage Network → Edit Network
- Update the network name and/or description and click Update Network
Managing Subnets
A subnet defines the IP address range that servers within a private network can use. Only one subnet can be created per private network. The subnet uses CIDR notation to define its IP range.
Each private network supports only one subnet. Plan your IP address range carefully before creating it, as the CIDR and IP version cannot be changed after creation.
Creating a Subnet
- Go to Networks → Private Networks
Locate the network and click Manage Network → Create Subnet.
- Configure the subnet
- Subnet Name — a descriptive label
- Network Address (CIDR) — the IP range in CIDR notation (e.g.,192.168.10.0/28). Use RFC 1918 private ranges: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. Ensure CIDRs do not overlap with other networks in your environment.
- DHCP — enable automatic IP assignment for connected instances. Enabled by default. Recommended for most use cases.
- Allocation Pools — optionally restrict which IPs within the range are auto-assigned via DHCP
- DNS Name Servers — optionally specify DNS servers (e.g.,
8.8.8.8,8.8.4.4)
- Click Create Subnet
Editing a Subnet
Only the subnet name can be modified after creation. To change the CIDR, IP version, or other core settings, delete and recreate the subnet.
- Go to Networks → Private Networks → Manage Network → View Network Details → Subnets tab
- Click Manage Subnet → Edit Subnet
Update the name and save.
Deleting a Subnet
- Navigate to Networks → Private Networks → Manage Network → View Network Details → Subnets tab
- Click Manage Subnet → Delete Subnet and confirm
Deleting a Private Network
Before deleting a network, ensure no instances or ports are connected to it. Attempting to delete a network with active connections will fail. The same applies to deleting a subnet.
- Go to Networks → Private Networks
Click Manage Network → Delete Network and confirm.
Networking
Security Groups
A virtual firewall for servers, controlling both inbound and outbound network traffic using rules you define.
A Security Group acts as a virtual firewall for your servers, controlling which network traffic is allowed to reach them (ingress) and which traffic they are allowed to send out (egress). Rules within a security group specify the protocol, port range, and source or destination of allowed traffic.
When a Dew is provisioned, two security groups are automatically created:
- The default security group — allows all outbound (egress) traffic
- A server-specific group with port 22 (SSH) open for remote access
The default security group cannot be deleted, but it can be detached from instances. You can create additional security groups and attach them as needed. A Dew can have multiple security groups attached simultaneously — rules from all attached groups are combined.
Creating a Security Group
- Click the Networks tab → Security Groups
- Click Create Security Group
- Enter a name and description, then click Create Security Group
Use descriptive names that identify the group's purpose (e.g.,
web-servers,database-access,allow-https-only).
Creating a Security Group Rule
- Click Manage Rule next to the security group → Add New Rule
- Configure the rule
- Rule Type — predefined rules (SSH, HTTP, HTTPS, etc.) auto-fill the port and protocol. Select Custom TCP or Custom UDP to specify your own values.
- Direction — Ingress controls inbound traffic; Egress controls outbound traffic.
- EtherType — select IPv4 for most use cases.
- Port Range — auto-fills based on rule type, or specify manually. Enter a single port (e.g., 8080) or a range (e.g., 8000-8999).
- Remote — source (ingress) or destination (egress). This can be specified as:
- CIDR block — e.g., 0.0.0.0/0 for anywhere, 203.0.113.0/24 for a range, 192.168.1.50/32 for a single IP
- Security Group — restrict to traffic from instances in another security group
- Description — optional label to document the rule's purpose
- Click Submit
Attaching or Detaching Security Groups
- Click Manage Rules next to the security group
- Choose Attach to Instance or Detach from Instance
Select the target instance from the dropdown and attach or detach.
Deleting Security Groups and Rules
To delete a rule, click the delete icon next to it and confirm. To delete an entire security group, first ensure it is not attached to any Dew.
Common rules reference
| Rule Type | Protocol | Port | Direction | Source | Use Case |
|---|---|---|---|---|---|
| SSH | TCP | 22 | Ingress | Your IP / 0.0.0.0/0 | Remote server access via SSH |
| HTTP | TCP | 80 | Ingress | 0.0.0.0/0 | Public web traffic |
| HTTPS | TCP | 443 | Ingress | 0.0.0.0/0 | Secure public web traffic |
| Custom TCP | TCP | 3306 | Ingress | App server CIDR | MySQL database access |
| Custom TCP | TCP | 5432 | Ingress | App server CIDR | PostgreSQL database access |
| Custom TCP | TCP | 6379 | Ingress | App server CIDR | Redis cache access |
| Custom TCP | TCP | 8080 | Ingress | 0.0.0.0/0 | Application server (alternate HTTP) |
| Custom UDP | UDP | 53 | Ingress | Specific CIDR | DNS queries |
| ICMP | ICMP | All | Ingress | Specific CIDR | Allow ping / network testing |
| All TCP | TCP | 1–65535 | Ingress | Peer network CIDR | Allow all TCP from a trusted private network |
Avoid opening SSH (port 22) to 0.0.0.0/0 in production environments. Restrict the source CIDR to your known IP address, or use a bastion/jump server pattern to reduce your attack surface.
Networking
Routers
Enable communication between different networks — connecting private subnets and allowing traffic to flow to external networks.
A router enables communication between different networks. Routers connect private networks and allow traffic to flow between subnets or to external networks such as the internet. When a router is created on CloudVantage, it is automatically connected to the external network, giving it a publicly routable external IP address.
To allow a server on a private network to communicate outside that network (e.g., to reach the internet or another subnet), the private subnet must be connected to a router via a router interface.
Creating a Router
- Click Networks → Routers
Click Create Router in the top-right corner.
- Enter a Name and Description
Choose a name that identifies this router's purpose or the networks it will connect.
- Click Create Router
The router is automatically connected to the external network upon creation.
Managing a Router
Go to Networks → Routers, locate the router, and click Manage Router. Available actions:
- View Router Details — configuration, external IP, and attached interfaces
- Edit Router — update name or description
- Delete Router — permanently remove (must be disconnected from all subnets first)
Creating a Router Interface
Interfaces allow a router to connect to a subnet, enabling communication between that subnet and other networks (including the internet via the router's external gateway). Without an interface, servers on a private subnet cannot reach resources outside that subnet.
- Go to Networks → Routers → Manage Router → View Router Details → Interfaces tab
- Select Create Interface
Choose the Subnet to connect, set a Payment Option, and add an optional description.
- Click Create Interface
The router will now route traffic between the connected subnet and the external network.
Deleting a Router Interface
- Navigate to Networks → Routers → Manage Router → View Router Details → Interfaces tab
- Click Delete Interface next to the interface and confirm
Removing an interface disconnects the subnet from the router. Servers on that subnet will lose external connectivity.
Deleting a Router
Before deleting a router, remove all router interfaces first. Attempting to delete a router with active subnet connections will fail.
- Go to Networks → Routers
Click Manage Router → Delete Router and confirm.
Networking
Floating IPs
Publicly routable IP addresses that can be attached to private instances, making them accessible from the internet.
A Floating IP is a publicly routable IP address that can be attached to a private instance or a load balancer, allowing it to be accessible from the internet. Floating IPs are separate from instances — you allocate the IP to your project first, then associate it with a specific resource. You can reassociate a Floating IP between resources at any time without releasing it. You just have to disassociate it from the current resource and associate it with another resource.
A project can have a maximum of three Floating IPs at a time. Contact support if your project requires additional Floating IPs.
Allocating a Floating IP
Allocating a Floating IP reserves it for your project. Once allocated, you can associate it with any instance or load balancer port within your project.
- Go to Networks → Floating IPs
Click Allocate IP to Project.
- Configure
Select the Pool (External — the public IP pool), choose a Payment Option, and add an optional Description.
- Click Allocate IP
The IP address is reserved for your project and appears in your Floating IPs list.
Associating a Floating IP with an Instance
- Go to Networks → Floating IPs
Click Associate Floating IP next to the IP address.
- Select the port
Choose the target port from the dropdown — a Dew port or a load balancer port. Click confirm.
Floating IPs can be attached to Load Balancers provisioned on a private network, making them internet-accessible without placing the Load Balancer directly on the external network.
Releasing a Floating IP
Releasing a Floating IP removes it from your project entirely. The IP is returned to the public pool and is no longer available to you.
- Go to Networks → Floating IPs
Click Release Floating IP next to the address and confirm.
If you have DNS records pointing to a Floating IP, update them before releasing the IP. Once released, the IP may be reassigned to another user.
Networking
Load Balancer
Distributes incoming traffic across multiple backend servers, ensuring high availability, scalability, and resilience to failures.
A Load Balancer acts as a traffic distributor that sits between your users and backend servers. It receives incoming requests and intelligently routes them to healthy backend servers based on the configured algorithm and health monitoring rules.
Common use cases
- High Availability — eliminate single points of failure by distributing traffic across multiple servers
- Scalability — handle increased traffic by adding backend servers to the pool
- SSL/TLS Termination — offload SSL/TLS encryption from backend servers to the load balancer
- Traffic Management — route requests using different protocols and ports
- Health Monitoring — automatically detect and remove unhealthy servers from rotation
Key components
| Component | Description |
|---|---|
| Load Balancer | The main component that receives traffic and distributes it |
| Listener | Defines what traffic the load balancer accepts (protocol and port) |
| Pool | A group of backend servers that handle requests |
| Pool Members | Individual backend servers within a pool |
| Health Monitor | Checks backend health and removes unhealthy members from rotation |
Prerequisites
- At least one running backend instance to receive traffic
- Network configuration: access to an external or private network
- SSL certificates uploaded to Certificate Manager (required only for TERMINATED HTTPS listeners)
Creating a Load Balancer
Navigate to Networks → Load Balancers and click Create Load Balancer. The creation wizard has five steps.
Step 1 — Load Balancer Details
Name (Required) — enter a descriptive name (e.g., production-web-lb, api-load-balancer).
IP Address (Optional) — leave blank to have an IP assigned automatically. Specifying an IP is not recommended for most deployments.
Network (Required)
- External Network — the load balancer receives a public IP directly. Use for public-facing websites and APIs.
- Private Network — accessible only within your private infrastructure. Use for internal services and backends. Attach a Floating IP to make it publicly accessible.
Step 2 — Listener Details
Protocol (Required)
| Protocol | Default Port | SSL/TLS | Use Case |
|---|---|---|---|
| HTTP | 80 | None | Unencrypted web traffic, redirects to HTTPS, internal services |
| HTTPS | 443 | Backend handles SSL | End-to-end encryption; backends need their own certificates |
| TERMINATED HTTPS | 443 | Load balancer terminates SSL | SSL offloaded to LB; backends run plain HTTP; certificate required in Certificate Manager |
| TCP | Specify manually | None | Database connections, custom applications, non-HTTP services |
| UDP | Specify manually | None | DNS, streaming media, gaming servers, VoIP |
| SCTP | Specify manually | None | Telecommunications, signalling protocols |
Upload your SSL certificate to Certificate Manager before creating the listener. Without a valid certificate, TERMINATED HTTPS listeners cannot function.
Timeout settings
| Setting | Default | Description |
|---|---|---|
| Client Data Timeout | 50,000 ms | Max time to wait for client data. Increase for file uploads or streaming; decrease for high-traffic APIs. |
| TCP Inspect Timeout | 0 (disabled) | Time to wait during TCP inspection. Leave at 0 for most use cases. |
| Member Connect Timeout | 5,000 ms | Max time to wait when connecting to a backend. Increase for slow backends or high-latency networks. |
| Member Data Timeout | 50,000 ms | Max time to wait for data from a backend. Increase for long-processing requests. |
| Connection Limit | -1 (unlimited) | Max concurrent connections. Use -1 for most deployments; set a limit to protect against traffic spikes. |
Step 3 — Pool Details
Load Balancing Algorithm (Required)
| Algorithm | How it works | Best for |
|---|---|---|
| ROUND_ROBIN | Distributes requests sequentially to each backend in order, then repeats. | Homogeneous backends; stateless applications; general-purpose load balancing. |
| LEAST_CONNECTIONS | Routes new requests to the server with the fewest active connections. | Long-lived connections; applications with variable request duration; WebSocket; database connection pooling. |
| SOURCE_IP | Uses a hash of the client IP to consistently map to a specific backend. | Applications requiring client affinity; UDP protocols. |
Session Persistence (Required)
| Option | Description | Notes |
|---|---|---|
| None | No persistence — each request can go to any available backend. | Best load distribution. Use for stateless apps or apps with shared session storage (Redis, Memcached). |
| SOURCE_IP | Routes requests from the same client IP to the same backend. | Issues with clients behind NAT. |
| HTTP_COOKIE | Load balancer inserts a cookie to maintain backend affinity. | HTTP/HTTPS only. Works well with proxies and NAT. |
| APP_COOKIE | Uses an existing cookie from your application. | HTTP/HTTPS only. Requires configuring the cookie name. |
Step 4 — Pool Members
Pool members are the backend servers that receive traffic. For each backend server:
| Field | Required | Description |
|---|---|---|
| IP Address | Yes | Must be reachable from the load balancer's network. Use private IPs for private-network load balancers. |
| Port | Yes | Port your backend listens on — can differ from the listener port (e.g., listener on 443, backend on 8080). Common values: 80, 443, 8080, 3000, 5000. |
| Weight | Yes (default: 1) | Relative traffic proportion. Range 1–256. Weight 2 receives twice the traffic of weight 1. Set equal for even distribution. |
| Name | No | A label for the member (e.g., web-server-1). Helpful for troubleshooting. |
Weight example: Server A (weight 2) + B (weight 1) + C (weight 1) → A receives 50%, B and C each receive 25%.
Step 5 — Health Monitor
Without health monitoring, the load balancer won't detect failed backends and will continue sending traffic to non-functional servers.
Health monitor types:
| Type | Compatible Listeners | How it works |
|---|---|---|
| HTTP | HTTP, HTTPS, TERMINATED HTTPS | Sends GET request to a URL path. Expects a successful HTTP response code. |
| HTTPS | HTTPS, TERMINATED HTTPS | Same as HTTP but uses an encrypted connection. |
| TCP | TCP, HTTP, HTTPS | Attempts to open a TCP connection. Healthy if connection succeeds. |
| PING | Any | Sends ICMP echo request. Note: some networks block ICMP. |
| UDP-CONNECT | UDP | Sends UDP packets and checks connectivity. |
| TLS-HELLO | HTTPS, TERMINATED HTTPS | Initiates SSL/TLS handshake. Healthy if handshake succeeds. |
| SCTP | SCTP | Checks SCTP protocol connectivity. |
Health monitor settings:
| Setting | Default | Description |
|---|---|---|
| Delay (sec) | 5 | Time between health check attempts. Must be ≥ Timeout. |
| Timeout (sec) | 5 | Max time to wait for response. Must be < Delay. |
| Max Retries | 3 | Successful checks required before marking a server healthy (1–10). |
| Max Retries Down | 3 | Failed checks before marking a server unhealthy (1–10). |
| HTTP Method | GET | HTTP method used for the health check request. |
| URL Path | / | Endpoint for HTTP checks (e.g., /health, /ping, /status). |
| Expected Codes | 200 | Codes considered healthy: single (200), list (200,201), or range (200-299). |
After creation
- Note the IP address — needed for DNS records or direct traffic routing
- Monitor health checks — ensure all pool members show as healthy in the dashboard
- Test connectivity — send test requests to verify traffic is being distributed
- Configure DNS — point your domain name to the load balancer IP address
Best practices
High availability
- Use at least 2 pool members — a single member defeats the purpose of a load balancer
- Always configure health checks to detect failures automatically
Security
- Use TERMINATED HTTPS for public services — centralises certificate management
- Monitor certificate expiration dates in Certificate Manager
- Keep backend servers accessible only through the load balancer where possible
- Use private networks for backends to reduce attack surface
Performance
- Choose the right algorithm — ROUND_ROBIN for similar-capacity servers; LEAST_CONNECTIONS for variable request durations or long-lived connections
- Tune timeout values — balance fast failure detection with tolerance for slow responses
- Avoid unnecessary session persistence — prefer stateless architectures with shared session storage (Redis, Memcached)
- Adjust member weights based on server capacity
Cost optimisation
- Start with the minimum required pool members and scale as traffic grows
- Monitor actual utilisation and remove unnecessary pool members
- Right-size your backend servers based on actual load
Troubleshooting
| Issue | Possible Causes | Solution |
|---|---|---|
| Pool members showing unhealthy | Server down; firewall blocking health checks; wrong port; app not responding on health path | Verify server is running; check security group rules; verify port; check app logs |
| Uneven traffic distribution | Session persistence enabled; SOURCE_IP with limited client diversity; different weights; some members unhealthy | Disable session persistence if not needed; switch to ROUND_ROBIN; equalise weights; check health status |
| SSL/TLS errors (TERMINATED HTTPS) | Certificate expired; domain mismatch; incomplete CA chain; wrong certificate selected | Check expiration in Certificate Manager; verify certificate matches domain; ensure CA chain was uploaded |
| Timeout errors | Member connect timeout too low; member data timeout too low; slow backends | Increase connect and data timeouts; investigate backend performance |
Before deleting: update your DNS records, migrate traffic to another load balancer if needed, and back up any configuration you may need to recreate.
Security
Certificate Manager
A secure vault for storing and managing SSL/TLS certificates and their associated private keys.
Certificate Manager allows you to upload SSL/TLS certificates once and reuse them across services such as Load Balancers and Auto Scaling Groups, without needing to store certificates directly on individual servers. All certificates are securely encrypted at rest — only you have access to your stored certificates and keys.
Common use cases
- Load Balancer SSL/TLS Termination — secure HTTPS traffic without managing certs on each backend
- Auto Scaling Groups — manage certificates for dynamically created instances
- Centralised Certificate Storage — keep all certificates in one secure, organised location
- Certificate Lifecycle Management — track expiration dates and manage renewals
This is a security feature protecting sensitive cryptographic material. Once uploaded, certificates and private keys cannot be retrieved from the platform. Always maintain your own secure backups before uploading.
Accessing Certificate Manager
- Navigate to Certificate Manager from the sidebar
- You'll see two tabs: Overview and Secrets
- Overview — total number of stored secrets
- Secrets — list of all certificates with create/delete actions
Creating a Certificate
Before uploading, ensure you have:
- Created secure backups of certificate files and private keys in an encrypted location
- Documented which certificates are used for which services
- Verified you have all required files: Private Key, Server Certificate, and CA Chain
- Click the Secrets tab → Create Secret
- Fill in certificate details
- Name — a descriptive identifier (e.g.,
production-web-cert,staging-api-cert) - Secret Type — select Certificate from the dropdown
- Expiration Date — enter in DD/MM/YYYY format
- Name — a descriptive identifier (e.g.,
- Upload the three certificate files (all must be in PEM format)
- Private Key (.pem) — your certificate's private key
- Server Certificate (.pem) — the certificate file from your CA
- CA Chain Certificate (.pem) — the certificate authority chain file
- Click Create Secret
Your certificate appears in the Secrets list showing name, type, and expiration date.
Accepted file formats
Certificate Manager accepts certificates in PEM format. To check if a file is PEM format, open it in a text editor — it should begin with -----BEGIN CERTIFICATE-----.
- .crt or .cer files in PEM format — upload directly or rename to
.pem - DER binary or PKCS#7 (.p7b) files — convert to PEM first:
# Convert .crt (DER format) to PEM
openssl x509 -inform der -in certificate.crt -out certificate.pem
# Extract certificates from PKCS#7 (.p7b)
openssl pkcs7 -print_certs -in certificate.p7b -out certificate.pemSafe certificate rotation
To replace a certificate without service disruption, always follow this order:
- Upload the new certificate
Give it a different name from the existing certificate.
- Update your Load Balancer
Attach the new certificate to your Load Balancer and any other affected services.
- Verify HTTPS is working with the new certificate
Test thoroughly before proceeding to the next step.
- Delete the old certificate
Only after confirming the new certificate is fully active and working.
If you delete a certificate attached to a Load Balancer with HTTPS termination, the Load Balancer will immediately stop terminating HTTPS connections and users will receive SSL errors. Always verify a certificate is not in use before deleting.
Recovery from accidental deletion
- Re-upload the certificate immediately using your local backup (this is why maintaining backups is critical)
- Re-attach the certificate to affected Load Balancers or services
- Monitor your services to confirm they're functioning correctly
Note: there may be downtime between deletion and re-upload.
Best practices
- Maintain secure backups — certificates cannot be downloaded after upload; always keep encrypted backups locally
- Use descriptive names — clearly identify purpose (e.g.,
production-web-cert-2026) - Monitor expiration dates — check regularly and plan renewals well in advance
- Rotate before expiry — upload and attach new certificates before old ones expire
- Never delete certificates in use — verify no services reference a certificate before deleting
- Secure your private keys — delete key files from insecure locations after uploading
Troubleshooting
| Problem | Solution |
|---|---|
| My certificate file has a .crt or .p7b extension | See the Accepted File Formats section above for OpenSSL conversion commands. |
| I don't have a private key file | The private key should be on the server where you originally generated the Certificate Signing Request (CSR). If lost, generate a new private key and request a certificate reissue from your CA. |
| My HTTPS Load Balancer stopped working after deleting a certificate | Re-upload the certificate using your local backup, then re-attach it to the Load Balancer immediately. |
| My certificate is expiring soon | Upload the new certificate with a different name, update your Load Balancers, verify everything is working, then delete the old certificate. |
Account
Billing
CloudVantage operates on a pay-as-you-go pricing model — you only pay for the resources you use.
When you provision any resource, the cost for the selected billing term is deducted immediately from your wallet balance. CloudVantage's billing model is designed to be transparent and flexible:
- Charges are deducted immediately when a resource is provisioned
- Deleting a resource before the billing period ends triggers a refund for the unused portion
- Refunds are returned directly to your CloudVantage wallet — not to your bank account
- This allows you to scale resources up or down without financial waste
Viewing your invoices
The CloudVantage Billing page allows you to view and download your monthly invoices. Visit cloudvantage.com.ng/billing or click Billing in the sidebar.
If your balance runs out, resource provisioning and Auto Scaling events may be interrupted. Maintain a buffer balance sufficient to cover your peak resource usage, especially if you use Auto Scaling Groups.
When your billing period ends, you have a 15-day grace period to make payment. If payment is not received within 15 days, your server will be shut down. If payment is still not made after a further 45 days, your server will be permanently deleted and decommissioned — all data will be lost and cannot be recovered. Ensure your wallet is funded before your billing period ends to avoid any interruption or data loss.
Billing by resource type
| Resource | Billed when | Refund on deletion |
|---|---|---|
| Dew (Server) | On provisioning | Yes — unused time refunded to wallet |
| Volume | On creation | Yes — unused time refunded to wallet |
| Floating IP | On allocation | Yes — unused time refunded on release |
| Load Balancer Pool Member | On addition | Yes — on removal |
| Router Interface | On creation | Yes — on deletion |
| Volume Snapshot | On creation | Yes — on deletion |
| Volume Backup | On creation | Yes — on deletion |
Account
Event Logs
A chronological record of important actions and activities that occur within your project.
Event logs provide an audit trail of system and user events within your project. Each log entry includes the timestamp and a description of the action performed.
Event logs are useful for:
- Auditing — track what changed, when, and by whom
- Change tracking — review configuration changes across your project over time
- Troubleshooting — identify the sequence of events leading to unexpected behaviour or failures
- Compliance — maintain a record of infrastructure operations for governance purposes
Accessing Event Logs
- Click Event Logs on the sidebar
- Browse the list of recorded events
Events are displayed in reverse chronological order. Review recent activity within your project.
Account
Settings
Manage your account preferences, including billing currency and password.
Accessing Settings
- Click the Wallet Balance in the top-right corner of your dashboard
- Select Currency Settings
This navigates to the Settings page. You can also visit cloudvantage.com.ng/settings directly.
Available settings
| Setting | Description |
|---|---|
| Billing Currency | Switch between Naira (₦) and US Dollars ($). This affects how resource costs are displayed and charged from your wallet. |
| Password | Reset your account password. You will need to verify your current password before setting a new one. |
Help
Support
Get help from the CloudVantage support team.
If you need assistance or have any questions, click the Support tab on the sidebar. From there, you can send a message to our support team via email, and we will respond to help resolve your issue.
Each resource guide includes a troubleshooting section. See Load Balancer and Certificate Manager for common issues and resolutions.
Self-service resources
Managed Services
Managed Databases
Fully managed MySQL databases — provision, migrate, and manage your database infrastructure on CloudVantage with minimal downtime.
The CloudVantage Managed Database service allows you to run production MySQL databases without managing the underlying infrastructure. You can provision a fresh database or migrate an existing database from any external environment into CloudVantage in a secure, guided, and reliable process.
Database Migration
The Database Migration Service enables you to move existing MySQL databases from any external environment into CloudVantage Managed Databases with minimal downtime and reduced operational risk.
Prerequisites
Before starting a migration, ensure you have the following ready:
- Your source database is accessible over the network
- Source database IP address
- Database username and password with sufficient privileges
- Correct database name (must match exactly)
- A database flavor with at least 4 GB RAM is recommended for faster migration
Step-by-step migration guide
Step 1 — Select a Database Flavor
- Click Managed Databases from the sidebar
- Click Migrate Database
In the top-right corner. A modal window will appear prompting you to select a database flavor.
- Select a flavor
Choose the target database configuration that matches your workload. Example flavor:
Name RAM CPU Storage Price Vantage Advanced 16 GB 6 vCPUs 200 GB ₦110,000/month RAM recommendationA minimum of 4 GB RAM is recommended for faster and more efficient migration. For large databases, select a higher RAM flavor.
- Click Next
Step 2 — Database Setup
Configure your target database on CloudVantage.
- Set the required fields
Field Description Database Engine Currently supported: MySQL Database Name Must exactly match the name of the database on your source server (e.g., employees)Target Username Username that will be created for accessing the new database (e.g., test-user)Target Password Password for the new database user. Enter and confirm. Use a strong password. Management Interface Choose how you want to manage your database: PhpMyAdmin, Adminer, or None (command-line only via mysqlclient)Payment Option Monthly or Yearly — billed according to the selected flavor Database name must match exactlyThe database name entered here must be identical to the name on your source server. A mismatch will cause the migration to fail.
- Click Next: Source DB Info
Step 3 — Source Database Information
Provide connection details for the database you want to migrate.
- Enter source database details
Field Description Source IP Address IP address of your source database server (e.g., 172.168.192.304)Source Port Default MySQL port is 3306Source Username Username with migration privileges (e.g., migration_user)Source Password Password for the source database user Use a dedicated migration userCreate a dedicated database user specifically for migration with only the required privileges. Delete this user from the source database after migration is completed.
- Click Check Database Connection
This performs a connectivity test to verify database accessibility, credentials validity, and required permissions. If the connection fails, verify your IP address, database name, username, password, and port, then retry.
- Once connection is successful, click Next: Migration Settings
Step 4 — Migration Settings
Choose how the migration will be executed.
| Migration Type | Behaviour | When to use |
|---|---|---|
| Test Migration | Source database remains read-write. No locking occurs. Simulates the migration process. | Run this first to estimate duration, test compatibility, and validate the process before going live. |
| Live Migration | Source database is placed in read-only mode. Write operations are temporarily blocked to ensure data consistency. | Use for final production migration. After completion, switch your application to use the CloudVantage database. |
Running a Test Migration before a Live Migration helps you estimate duration, identify issues, and validate compatibility — with no risk to your source data.
- Select your migration type
- Click Start Migration
The migration process begins. You can monitor both provisioning and migration progress from the dashboard.
- While the database is being provisioned: Provisioning = In Progress, Migration = Pending
- Once provisioning completes: Provisioning = Completed, Migration = In Progress
- Once migration finishes: Migration = Completed
Once migration completes, your database credentials can be viewed by clicking the eye icon next to the database status. These credentials are displayed one time only for security reasons. Save them immediately and securely — they cannot be retrieved again once the view window is closed.
Post-migration checklist
- Verify all tables and data are present in the new database
- Test application connectivity using the new CloudVantage credentials
- Update your application's database connection settings
- Remove the temporary migration user from the source database
Best practices
- Always run a Test Migration before a Live Migration
- Use a dedicated migration user with only the required privileges
- Choose a flavor with sufficient RAM — minimum 4 GB recommended
- Schedule Live Migration during low-traffic hours to minimise user impact
Troubleshooting
| Issue | Possible Cause | Solution |
|---|---|---|
| Connection test fails | Firewall blocking access; wrong port; incorrect credentials; database does not exist on source | Check firewall rules allow database access; verify port is open; confirm credentials and database name |
| Migration takes too long | Large database size; low RAM flavor selected; network latency | Upgrade to a higher RAM flavor; check network connectivity between source and CloudVantage |
| Migration fails mid-way | Network interruption; source database went offline | Ensure stable network connection; verify source database remains accessible throughout migration |
