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.
Bucket storage for files, documents, and media, with a developer API.
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.
Encrypted site-to-site IPsec tunnels to other clouds and networks.
Managed Services
Coming soon
Full 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. |
| Region | The physical location your resources run in. CloudVantage operates a Europe region and a Lagos region, the latter hosted in Nigeria. Both offer the same services, but pricing differs between them. Every project belongs to one region permanently. See Regions. |
| Project | An organisational unit that groups your cloud resources together. Every project belongs to a single region, chosen when it is created and fixed thereafter. Project names must be unique within their region and a description is required. You can create multiple projects to separate different workloads, and move between them using Switch Region 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. Every project belongs to a single region, and project names must be unique within their region. 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
Regions
Where your resources physically run — and why Nigerian financial institutions should choose Lagos.
A region is the physical location your cloud resources run in. CloudVantage operates two:
| Region | Location |
|---|---|
| Europe | CloudVantage's original region |
| Lagos | Hosted in Nigeria |
Every project belongs to exactly one region, and every resource you create — Dews, volumes, buckets, networks, load balancers — belongs to a project. Your choice of region therefore decides where your data physically lives.
Both regions offer the same services. Anything you can build in Europe you can build in Lagos.
Choosing a region
Three things separate them.
- Data residency. Resources in the Lagos region run on infrastructure located in Nigeria. For Nigerian financial institutions this is usually the deciding factor — see Data residency and the CBN directive.
- Proximity to your users. If the people and systems using your application are in Nigeria, the Lagos region puts your infrastructure closer to them.
- Pricing. Prices differ between regions. Check the Pricing page for the region you are deploying into before provisioning — the same tier does not cost the same in both.
You choose a project's region when you create it, and it cannot be changed afterwards. To run workloads in a different region, create a new project in that region. Resources cannot be moved between regions — they have to be recreated.
What is shared across regions
| Shared across regions? | |
|---|---|
| Your account and sign-in | Yes — one account covers every region |
| Wallet balance | Yes — a single wallet funds resources in both regions |
| Available services | Yes — both regions offer the same services |
| Projects | No — each project belongs to one region |
| Resources | No — servers, volumes, buckets, and networks belong to a project, and so to that project's region |
| Project names | No — names must be unique within a region, so the same name can exist in both |
| Bucket names | No — each region is a separate namespace |
| Pricing | No — each region has its own prices |
A Dew in Lagos can talk to a bucket or a database in Europe. Two things to weigh before designing across regions: traffic between regions travels further, so expect higher latency than traffic within one; and if a Lagos workload reads or writes data held in Europe, that data is leaving Nigeria. If you chose Lagos for data residency reasons, keep the regulated data and everything that touches it in Lagos.
Your first projects
New accounts start in the Europe region. When you sign in for the first time you are prompted to create a project there, and a second project is created for you automatically in Lagos, named after your email address.
That Lagos project is ready to use straight away — switch to it whenever you need it. Its name is only a placeholder, so rename it to something meaningful; see Projects.
Seeing all your projects and their regions
- Click Manage project
In the top bar, next to your project name.
- Review the project list
The Manage Projects page lists every project across every region, with its Project Name, Description, and Region.
- Filter the list
Use Region to show one region's projects only, or Project Name to search by name.
- Click Manage
Opens that project.
Switching to another region
- Click Switch Region
In the top bar, beneath your project name. The Available Regions panel opens.
- Choose a region
Select Europe or Lagos. The panel then lists the projects you have in that region.
- Choose a project
Select one to switch to it. Use ← Back to regions to return to the region list.
The top bar then shows the new project name with its region beneath it, and the dashboard shows only that project's resources.
Creating a project in a region
- Click Manage project
In the top bar.
- Click + Create New Project
In the top-right corner of the Manage Projects page.
- Select the region
Choose Europe or Lagos. This is where the project and everything in it will run, and it cannot be changed later.
- Enter a name and description
Both are required. The name must be unique within the region you selected.
- Click Create Project
Switch to it using Switch Region in the top bar.
Data residency and the CBN directive
On 15 June 2026 the Central Bank of Nigeria issued a directive requiring that payment transaction data generated in Nigeria be stored and managed on domestic servers. It takes effect on 1 January 2027 and applies across the payments ecosystem — deposit money banks, microfinance banks, mobile money operators, payment service providers, payment solution service providers, payment terminal service providers, switching and processing companies, and super agents.
The Lagos region runs on infrastructure located in Nigeria, so workloads and data placed there stay in the country.
If your organisation handles Nigerian payment transaction data, start by reviewing where that data is stored and processed today, which workloads already run in Nigeria, and which rely on infrastructure abroad. Large infrastructure moves take time to plan, validate, and roll out — beginning early keeps the work controlled rather than rushed. Contact support if you would like help with the assessment or the migration.
Hosting in the Lagos region keeps that data in Nigeria. Whether your organisation meets the directive overall depends on your full architecture — where backups are held, which third-party platforms process regulated data, and how data flows between systems. Review your own data flows end to end, and take your own regulatory advice.
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. New accounts start in the Europe region, so this first project is created there.
- Enter a project name
Choose a name that is not already in use in this region.
- 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 in that region, you'll receive an error. Choose a different, more specific name (e.g., include your company name or environment). The same name can be used again in another region.
Alongside the project you create, a second project is set up for you automatically in the Lagos region, named after your email address. It is ready to use — switch to it whenever you need it, and rename it to something meaningful. See Regions.
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 as many projects as you need to separate workloads or environments. Every new project is created in a region, so the steps live with the rest of the region documentation — see Creating a project in a region.
To move between projects, use Switch Region in the top bar: pick the region, then the project. See Switching to another region.
Every project is created in a region — Europe or Lagos — and stays there permanently. This decides where the project's resources physically run, and what they cost. See Regions.
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. If you choose Private Network, pick the network from the first dropdown, then choose the subnet to provision the Dew in from the Select Subnet dropdown beneath it. The Dew takes its private IP address from that subnet's range, so pick the subnet that fits its role. See Managing Subnets.
- 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 carries two charges: the instance itself, and its membership in the load balancer's pool. A group with a maximum size of 5 can therefore reach 5 instances and 5 pool memberships at full scale — 10 billed items, not 5.
Size your wallet balance against the group's maximum instance count, not the number of instances currently running — a quiet group can scale up suddenly under load.
If your balance cannot cover a scale-up when one is triggered, that scale-up is skipped: the group stays at its current size and is re-evaluated at the next check. Instances already running are never removed for this reason — insufficient funds blocks new capacity from being added, it does not take away capacity you already have. Fund your wallet to restore normal scaling.
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
Storage
Object Storage
Bucket-based storage for files, documents, and media — reachable over the network and independent of any server.
Object Storage lets you keep files in buckets rather than on a disk attached to a server. Where a Volume behaves like a hard drive bolted to a single Dew, a bucket is reached over the network and belongs to your project rather than to any one machine. That makes it the right choice for documents, images, backups, static website assets, and anything several servers or people need to reach.
Buckets are managed from the dashboard — upload, browse, preview, and download files without touching a command line. To read and write objects from your own application, see Developer API.
To get started, open Manage Object Storages from the Create panel on your dashboard.
A bucket lives in the region selected in the top bar. Switching regions shows a different set of buckets, and pricing differs between regions. Create the bucket in the same region as the servers that will use it.
7.1 Storage tiers and pricing
Every bucket sits on a tier, and the tier sets its capacity. Cost depends on the tier and on the region the bucket is created in — check the Pricing page for current figures before creating a bucket, rather than relying on a number written down elsewhere.
| Tier | Capacity |
|---|---|
| Basic | 150 GB |
| Standard | 300 GB |
| Advanced | 500 GB |
You pay for the tier, not for what you actually store — a Basic bucket holding 2 GB costs the same as one holding 140 GB. The bucket details page shows both figures: Size of the Bucket is the capacity your tier provides, and The local size used is what you are currently consuming.
Creating a bucket draws on your wallet balance like any other resource. If the balance will not cover the first month, creation fails. See Funding Your Wallet.
7.2 Creating a bucket
- Open Manage Object Storages
From the Create panel on your dashboard, select Manage Object Storages.
- Click New Bucket
In the top-right corner of the Bucket Storages page.
- Enter a bucket name
Between 1 and 256 characters. Names are case-sensitive and cannot contain a forward slash (
/). - Select a tier
Choose Basic, Standard, or Advanced. The tier can be changed later.
- Set the visibility
Buckets are Public by default. Tick Private if the contents should not be reachable without authentication.
- Click Create
The bucket appears as a card on the Bucket Storages page, with its visibility shown as a badge.
A bucket name must be unique across your entire account within a single region. If you already have a bucket named reports in one Europe project, no other Europe project on your account can use that name. You can create a second reports bucket in Lagos, because each region is a separate namespace.
A bucket cannot be renamed after it is created. If you need a different name, create a new bucket, move the files across, and delete the old one. Choose the name with that in mind.
A new bucket is public unless you tick Private. Visibility governs whether objects can be fetched through the API without authentication — it changes nothing in the dashboard, where you are always signed in. Set a bucket to Private before uploading anything confidential, rather than uploading first and changing it afterwards.
7.3 Finding a bucket
The Bucket Storages page lists every bucket in the current region as a card showing its name and visibility badge. Use Search buckets… at the top of the page to filter by name as the list grows.
Each card carries a ⋮ menu with three actions:
- Edit — change the tier
- Details — open the bucket and work with its contents
- Delete — remove the bucket
7.4 Changing a bucket's tier
Move a bucket up or down a tier as its storage needs change.
- Open the ⋮ menu on the bucket card and select Edit
- Select the new tier
Choose Basic, Standard, or Advanced.
- Click Save
You are charged the full price of the new tier immediately, and refunded the unused portion of the old one on a pro-rata basis, returned to your wallet. Upgrading from Basic to Standard halfway through the month, for example, charges the full Standard price and refunds roughly half of what you had already paid for Basic that month. See the Pricing page for current tier prices.
7.5 Bucket details
Select Details from the ⋮ menu to open a bucket. The panel at the top summarises it:
| Field | Meaning |
|---|---|
| Name | The bucket name |
| Tier Details | The tier the bucket is on — Basic, Standard, or Advanced |
| Visibility | Public or Private |
| Size of the Bucket | Total capacity provided by the tier |
| Objects | Number of files currently stored |
| Versioning | Not available — shows N/A for every bucket |
| The local size used | How much of the capacity is in use |
| Created | When the bucket was created |
Below the summary is the object list, showing Name, Size, Type, and Last Modified for every file, with Download and Delete on each row. Search files… filters the list by name.
Object Storage does not retain previous versions of a file. Uploading a file with the same name as an existing one in the same folder replaces it, and the earlier copy cannot be recovered. Keep your own copy of anything you cannot afford to lose.
7.6 Uploading files
- Open the bucket
From the ⋮ menu, select Details.
- Click Add File
In the top-right corner of the bucket page.
- Select a folder
Choose a destination folder from the dropdown, or leave it unset to upload to the top level of the bucket.
- Choose the files
Click Change files and select one or more files from your computer. The panel lists everything you have selected.
- Click Upload
The files appear in the object list and the Objects count increases.
Upload limits
| Type | Maximum size | Accepted formats |
|---|---|---|
| Video | 100 MB | .mp4, .mov, .avi, or any video/* content type |
| Images and PDFs | 20 MB | .jpg, .jpeg, .png, .gif, .webp, .svg, .pdf, or any image/* content type |
| All other files | 100 MB | Archives, documents, and data files such as .zip, .csv, .docx, and .sql |
Requests are limited to 70 per minute per account, which applies to the dashboard and the API together.
The 20 MB cap on images and PDFs is lower than the 100 MB allowed for everything else, so a large scanned PDF can be rejected where a bigger archive would upload without complaint. If a PDF is too large, compress it, or upload it inside a .zip.
7.7 Working with folders
Folders group objects inside a bucket, the way directories organise files on your computer.
Creating a folder
- Open the bucket
From the ⋮ menu, select Details.
- Click Add Folder
- Enter a folder name and click Create Folder
Uploading into a folder
Click Add File, then pick the folder from the Select a folder dropdown before choosing your files. Leaving the dropdown unset uploads to the top level of the bucket instead.
7.8 Previewing and downloading
Click a file name in the object list to open a preview panel — useful for checking a PDF or an image without pulling it down first. The preview panel has its own Download button, and every row in the object list has one as well. Either saves the file to your computer unchanged.
There is no copy-link action for objects yet. To pass a file to someone from the dashboard, download it and send it on. Applications can fetch objects directly through the API.
7.9 Deleting files and folders
To delete a file, click Delete on its row in the object list and confirm.
To delete a folder, first delete every file inside it, then delete the folder itself.
A folder that still contains files cannot be deleted. Remove its contents, then delete the folder.
Deleted objects cannot be recovered, and there is no versioning to fall back on. Download anything you may need again before removing it.
7.10 Deleting a bucket
- Empty the bucket
Delete every file, then every folder. See Deleting files and folders.
- Open the ⋮ menu on the bucket card and select Delete
- Confirm the action
Billing for the bucket stops as soon as it is deleted.
A bucket that still contains objects cannot be deleted. Clear its contents first.
7.11 Billing and the grace period
A bucket is billed monthly at its tier price for the region it was created in, charged to your wallet. If your wallet cannot cover the renewal, the bucket moves through four stages, all counted from the original due date:
| When | State | What you can do |
|---|---|---|
| Payment due | Grace period — day 0–7 | Upload, download, and use the bucket normally |
| Day 7 | Read-only | Download and browse existing objects. Uploads, edits, and new folders are blocked |
| Day 30 | Inaccessible | The bucket and its objects can no longer be browsed or downloaded. Nothing is deleted yet |
| Day 90 | Deleted | The bucket and its contents are permanently removed and cannot be recovered |
You have 7 days to pay before the bucket goes read-only. Read-only lasts until day 30 — while it does, your data is still yours to download. After day 30 the bucket becomes inaccessible: you can no longer reach the data at all, even though it has not yet been deleted. The bucket and everything in it are permanently removed on day 90. Once a bucket passes day 30, getting your data back means paying before day 90 and asking support to restore access — it is not something you can do yourself from the dashboard.
7.12 Developer API
Everything above describes the dashboard. To read and write objects from your own code — an application storing user uploads, a scheduled backup job, a deployment pipeline — use the Object Storage API instead.
The full API reference covers authentication, endpoints, and request formats:
buckets.cloudvantage.com.ng/bucketaas/docs
Buckets created in the dashboard are reachable through the API, and buckets created through the API appear in the dashboard. The same limit of 70 requests per minute per account applies; unauthenticated routes are additionally limited per source IP.
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 the subnets within a private network to a router's interface and assign the instances within the subnet 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
Choose a name that identifies this network's purpose (e.g.,
prod-network,backend-db-net). - Enter the network CIDR
Required. The overall IP address range for the network, in CIDR notation (e.g.,
192.168.0.0/16). Every subnet you create in this network must fall inside this range, and the CIDR cannot be changed after the network is created. Use RFC 1918 private ranges:10.0.0.0/8,172.16.0.0/12, or192.168.0.0/16. - Add a Description (optional)
- Click Create Network
The new network appears in the Private Networks list with its CIDR. It has no subnets yet. A subnet is what gives your servers their addresses, so create one next — see Managing Subnets.
Every subnet in a network must fall inside its CIDR, so choose a range large enough for all the subnets you expect to create. If you outgrow it, the only way to get a bigger range is to create a new network. If you plan to connect this network to another one — over a VPN, for example — make sure the two ranges do not overlap. See Before you start on the VPN page.
The Private Networks list
The Private Networks page lists every network in the project:
| Column | What it shows |
|---|---|
| Network name | The name you gave the network |
| CIDR | The network's overall address range |
| Subnets Associated | The subnets created in this network |
| Shared | Whether the network is shared with other projects. Always No for a private network |
| External | Whether the network is an external, internet-facing network. Always No for a private network |
| Status | The network's current state. ACTIVE means it is ready to use |
| Admin State | UP when the network is enabled |
| Actions | Manage opens the actions for that network: view details, edit, create a subnet, or delete |
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
Only the network name and description can be changed after creation. The CIDR is fixed.
- 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. A network can have several subnets, as long as each one falls inside the network's CIDR. The subnet uses CIDR notation to define its IP range.
Each subnet's range must fall within the CIDR you set when you created the network — the Create Subnet form shows that range beside the Network Address field — and subnets in the same network cannot overlap each other. For example, a network with CIDR 192.168.0.0/16 could hold 192.168.10.0/24 for application servers and 192.168.20.0/24 for databases.
A subnet's CIDR and IP version cannot be changed after creation, so plan the ranges before you create them.
Creating a Subnet
- Go to Networks → Private Networks
Locate the network and click Manage Network → Create Subnet.
- Fill in the Subnet tab
- Subnet Name (required) — a descriptive label
- Network Address (required) — the subnet's range in CIDR notation (e.g.,
192.168.10.0/24). It must fall inside the network's CIDR, which is shown beside the field label. - IP Version — IPv4 by default
- Click Next
Opens the Subnet Details tab, where the advanced settings live.
- Review the Subnet Details tab
- 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.
- Choose a Payment Method
Pay Monthly or Yearly. Monthly is selected by default. The estimated cost is shown beneath the field before you confirm.
- Click Create Router
The router is automatically connected to the external network upon creation.
Payment is taken when you create the router, according to the payment method you choose. Adding an interface to it afterwards does not ask for a separate payment. See the Pricing page for current prices.
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 one or more subnets, enabling communication between those subnets and other networks (including the internet via the router's external gateway). Without an interface, servers on a private network within a subnet cannot reach resources outside that subnet.
A single interface can connect several subnets of a private network, so a network with more than one subnet does not need an interface per subnet.
- Go to Networks → Routers → Manage Router → View Router Details → Interfaces tab
- Select Create Interface
Select the subnets to connect (required) and add an optional description.
- Click Create Interface
The router will now route traffic between the connected subnets 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 subnets it connects from the router. Servers on those subnets 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.
Networking
VPN
Site-to-site IPsec tunnels that join a CloudVantage private network to another network over the public internet, encrypted end to end.
A site-to-site VPN links the private network behind one of your routers to a network somewhere else, so machines on both sides reach each other by private address as though they shared a network. Traffic crossing the internet between the two is encrypted.
The other side does not have to be CloudVantage. A tunnel can join:
- Two projects on CloudVantage — connecting dev to production, for instance
- Two regions — a Lagos project to a Europe project
- CloudVantage and another cloud provider, such as AWS
- CloudVantage and your own on-premises network, behind a compatible IPsec device
A tunnel is two matching halves. Everything on this page describes the CloudVantage side; somebody has to build the mirror image on the other side, whether that is a second CloudVantage project, an AWS Site-to-Site VPN connection, or a firewall in your office. The tunnel stays down until both halves agree — see Matching both sides.
Pricing
A VPN is billed per IPsec site connection, per month. IKE policies, IPsec policies, VPN services, and endpoint groups cost nothing on their own — only a site connection is chargeable. For current pricing, check the Pricing page — the source of truth for prices, which can change.
The price is the same in both regions — a tunnel in Lagos costs what a tunnel in Europe costs.
If you delete a connection partway through a month, you are refunded for the unused portion, the same way Dews are handled.
Before you start
Gather these first. Most failed tunnels come from one of them being wrong rather than from a mistake in the dashboard.
- A router with an external gateway in the project, and its public IP address.
- Non-overlapping subnets. The private CIDRs on each side must not overlap —
192.168.10.0/24talking to172.16.20.0/24is fine,192.168.10.0/24on both sides cannot work. Use RFC 1918 ranges. - The peer's public IP address — the external address of the router, gateway, or firewall at the far end.
- The peer's private CIDR — the range on the other side you need to reach.
- An agreed pre-shared key, exchanged with whoever runs the other end through a secure channel.
- Agreed encryption settings — see Matching both sides.
Overlapping address ranges are the one problem no VPN setting can work around, and the fix is renumbering a network — painful once servers are running on it. If you expect to link several environments later, give each one a distinct range now: for example 192.168.10.0/24 for dev, 192.168.20.0/24 for staging, 172.16.20.0/24 for production.
The five pieces
Open VPN from the dashboard. The page has five tabs, and they are built in this order because each one depends on those before it.
| # | Tab | What it is |
|---|---|---|
| 1 | IKE Policies | How the two sides authenticate each other and negotiate keys |
| 2 | IPSec Policies | How traffic inside the tunnel is encrypted |
| 3 | VPN Services | Attaches VPN capability to one of your routers |
| 4 | Endpoint Groups | Which subnets at each end are allowed through the tunnel |
| 5 | IPSec Site Connections | The tunnel itself, tying the other four together |
1. Create an IKE policy
- Open the IKE Policies tab and click + Add IKE Policy
- Name the policy
A description is optional. The name does not need to match the other side.
- Choose the algorithms
These must be identical to the far end. Recommended: authorization
sha256, encryptionaes-256, IKE versionv2, PFSgroup14, lifetime3600seconds. - Click Create
| Setting | Options | Recommended |
|---|---|---|
| Authorization algorithm | sha1, sha256, sha384, sha512 | sha256 |
| Encryption algorithm | 3des, aes-128, aes-192, aes-256 | aes-256 |
| IKE version | v1, v2 | v2 |
| PFS | group2, group5, group14 | group14 |
| Lifetime | Seconds | 3600 |
| Phase 1 negotiation mode | main, aggressive | main |
3des is deprecated and group2 is a 1024-bit Diffie-Hellman group; neither is considered strong today. Choose them only if an older device at the far end genuinely cannot do better, and treat that as something to fix rather than live with.
2. Create an IPsec policy
- Open the IPSec Policies tab and click + Add IPSec Policy
- Name the policy
- Choose the algorithms
Again, identical to the far end.
- Click Create
| Setting | Options | Recommended |
|---|---|---|
| Authorization algorithm | sha1, sha256, sha384, sha512 | sha256 |
| Encryption algorithm | 3des, aes-128, aes-192, aes-256 | aes-256 |
| Encapsulation mode | tunnel, transport | tunnel — site-to-site requires it |
| Transform protocol | esp, ah, esp-ah | esp — encrypts as well as authenticates |
| PFS | group2, group5, group14 | group14 |
| Lifetime | Seconds | 3600 |
3. Create a VPN service
A VPN service attaches VPN capability to one router. You need one per router, and the router must already have an external gateway.
- Open the VPN Services tab and click + Add VPN Service
- Enter a name
A description is optional.
- Select the router
Choose the router whose network you want to reach through the tunnel.
- Leave Admin State Up ticked, then click Create
The VPN Services list shows the service's Local Side Public IPs — the address the far end must use as its peer address. Note it down; whoever configures the other end needs it.
A new VPN service shows PENDING_CREATE while it is being provisioned, and moves on by itself. You do not need to wait for it before creating endpoint groups.
4. Create the endpoint groups
Endpoint groups say which address ranges are allowed through the tunnel. You need two: one for your side, one for the far side.
Local endpoint group
- Open the Endpoint Groups tab and click + Add Endpoint Group
- Name it
Something that makes the side obvious, such as
local-endpoint-group. - Set Endpoint Type to "Subnet (for local systems)"
- Tick the subnets to expose
Select from your project's own subnets. Only ticked subnets are reachable over the tunnel.
- Click Create
Remote endpoint group
- Click + Add Endpoint Group again
- Name it
For example
remote-endpoint-group. - Set Endpoint Type to "CIDR (for external systems)"
- Enter the far side's CIDRs
Comma-separated, for example
192.168.100.0/24. Several ranges are allowed. - Click Create
Your own side is chosen from real subnets in your project. The far side is typed in as an address range, because CloudVantage has no visibility of it. Using the wrong type is a common cause of a tunnel that builds but carries no traffic.
5. Create the IPsec site connection
This is the tunnel itself, and the only chargeable piece.
- Open the IPSec Site Connections tab and click + Add IPSec Site Connection
- Enter a name
A description is optional.
- Select the VPN service, IKE policy, and IPsec policy
The ones you created above.
- Select the local and remote endpoint groups
Local is your Subnet group; remote is your CIDR group.
- Enter the peer gateway address
The far end's public IPv4 or IPv6 address, or an FQDN.
- Enter the peer router identity
Usually the same value as the peer gateway address.
- Enter the pre-shared key
Character for character what the other side uses. It is case-sensitive.
- Review the optional parameters
On the Optional Parameters tab: MTU (default
1500), dead peer detection action, interval, and timeout, and initiator state. The defaults suit most setups. Dead peer detection settings apply to your side only and do not have to match the far end, but the timeout must be larger than the interval. - Click Create
The connection shows
PENDING_CREATE, then becomes active once both ends agree.
Anyone holding the PSK and your gateway address can attempt to build a tunnel into your network. Send it to the far end over a secure channel — not email, not chat. Generate a long random string rather than choosing something memorable.
Matching both sides
A tunnel comes up only when both ends agree. Some values must be identical, some must be mirror images, and some can differ freely.
Must be identical
- Pre-shared key — exactly, including case. The most common reason a tunnel stays down.
- IKE policy settings — authorization algorithm, encryption algorithm, IKE version, PFS, lifetime.
- IPsec policy settings — authorization algorithm, encryption algorithm, encapsulation mode, transform protocol, PFS, lifetime.
Must be swapped
| Setting | Your side | Their side |
|---|---|---|
| Peer gateway address | Their public IP | Your public IP |
| Peer router identity | Their public IP | Your public IP |
| Local endpoint group | Your subnets | Their subnets |
| Remote endpoint group | Their CIDRs | Your CIDRs |
Can differ
Names and descriptions, which router each side uses, MTU, initiator state, and dead peer detection settings. One side may be bi-directional while the other is response-only.
Each side decides for itself how often to check the peer is alive and how long to wait before giving up, so the interval and timeout are never negotiated between the two ends and do not need to match. The action is local too — it is simply what your side does once it concludes the peer has gone. The only hard rule is that your timeout must be larger than your interval.
One combination is worth avoiding: if your side is set to clear and the far side is response-only, neither end will rebuild the tunnel after a drop, and it stays down until something forces a renegotiation. Pair clear with a peer that will initiate, or use hold or restart instead.
Allow the traffic through your security groups
A tunnel that is up does not by itself let anything through. Your security groups still apply, and by default they do not permit traffic from the peer network.
On each side, add ingress rules allowing the protocols you need from the peer's CIDR — ICMP if you want to test with ping, TCP 22 for SSH, and whatever ports your applications use.
A connection showing as active while nothing can reach anything is almost always security groups. Start permissive while testing to confirm the tunnel works, then tighten the rules to the ports you actually need. Check firewalls on the servers themselves too — ufw or iptables inside a Dew will block traffic no matter what the security group says.
Editing and deleting
To change or remove any VPN resource, click Manage on its row, then Edit or Delete.
What you can change depends on whether the resource is in use by a live tunnel.
| Resource | Before it is attached to a live connection | Once attached to a live connection |
|---|---|---|
| IKE policy | Everything — name, description, algorithms, PFS, lifetime | Locked. Cannot be edited or deleted |
| IPsec policy | Everything — name, description, algorithms, PFS, lifetime | Locked. Cannot be edited or deleted |
| VPN service | Name and description only | Name and description only |
| Endpoint group | Name and description only | Name and description only |
| IPsec site connection | Name, description, peer gateway address, peer router identity, PSK, MTU, DPD settings, initiator state | |
Once a live connection uses an IKE or IPsec policy, that policy is frozen — you cannot change so much as its name. Changing an algorithm means deleting the connection, editing the policy, and building the connection again, with the same coordination on the far end. Agree the settings with the other side before you create anything.
Endpoint groups and VPN services only ever allow their name and description to be changed. To reach a different subnet, or to move the tunnel to another router, delete the resource and create a replacement — which means tearing down the connection that uses it. Adding a subnet later is not a small change, so include everything you expect to need when you first create the endpoint group.
Deleting a connection
Deleting an IPsec site connection stops the tunnel immediately and releases the IKE and IPsec policies for editing again. Billing stops on deletion, and you are refunded for the unused part of the month.
Troubleshooting
The connection never leaves DOWN
- Check the pre-shared key on both sides, character for character. This is the single commonest cause.
- Confirm each side's peer gateway address is the other side's public IP, not its own.
- Compare the IKE and IPsec settings on both ends — one mismatched algorithm is enough.
- Confirm both routers have an external gateway and can reach each other over the internet.
The connection is active but nothing gets through
- Check security groups on both sides allow traffic from the peer CIDR.
- Check the endpoint groups: local should list your subnets, remote should list theirs, and the two must not overlap.
- Check firewalls running inside the servers themselves.
SSH works but other services fail
- Check the security group covers those ports, not just 22.
- Try lowering the MTU on the connection to
1400. Large packets can be dropped on paths that cannot carry a full 1500-byte frame.
Connecting to AWS or another provider
The CloudVantage side is identical regardless of what sits at the far end. On the other provider you will be configuring their equivalent pieces — on AWS, a customer gateway holding your public IP, a virtual private gateway, and a site-to-site VPN connection carrying the matching algorithms and PSK.
The rules on this page still decide whether it works: identical algorithms and PSK, mirrored addresses and endpoint ranges, non-overlapping CIDRs, and security groups open on both sides.
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
Password & Security
Signing in, recovering a forgotten password, and protecting your account with two-factor authentication.
Your CloudVantage account is the key to every project and every resource you own, in both regions, along with your wallet. This page covers signing in, getting back in if you forget your password, and adding a second layer of protection.
Signing in
Enter your email address and password, then click Sign in. The eye icon in the password field reveals what you have typed, which is useful for checking a long password before submitting it.
If two-factor authentication is enabled on your account, you will be asked for a verification code after your password is accepted.
Password requirements
Every password you set — at sign-up, when changing it, or when resetting a forgotten one — must contain:
- At least 12 characters
- At least 1 uppercase letter
- At least 1 lowercase letter
- At least 1 number
- At least 1 special character
A password that meets these rules and is reused from another service gives you very little protection — the commonest way accounts are taken over is a password leaked from somewhere else entirely. Generate a unique password for CloudVantage and store it in a password manager.
Resetting a forgotten password
If you cannot remember your password, reset it from the sign-in page. CloudVantage emails a one-time verification code to your registered address.
- Click "Forgot password?"
Beneath the password field on the sign-in page.
- Enter your email address
Use the address your account is registered with, then click Send verification code.
- Check your email for the code
CloudVantage sends a numeric verification code to that address.
- Enter your email and the code
On the Verify reset code page, then click Verify code.
- Create a new password
Enter the new password twice — in New password and Confirm password — meeting the requirements above, then click Reset password. You can then sign in with it.
If it expires before you use it, click Resend code on the Verify reset code page to get a fresh one.
Check your spam folder, and confirm you entered the address the account is registered with. Use Resend code if it still has not appeared. If nothing arrives at all, contact Support.
Changing your password
If you know your current password and simply want to replace it, do that from Settings rather than the reset flow. You will be asked to confirm your current password before setting a new one.
Two-factor authentication
Two-factor authentication (2FA) asks for a second piece of evidence when you sign in, on top of your password. Someone who obtains your password still cannot reach your account without it.
Every account starts with 2FA set to None. Two methods are available:
| Method | How it works | Notes |
|---|---|---|
| None | Sign in with email and password only | The default. Not recommended for accounts running production infrastructure |
| Email OTP | A one-time code is sent to your registered email each time you sign in | Nothing to install. Only as secure as your email account |
| Authenticator App | An app on your phone generates a six-digit code that changes every 30 seconds | Stronger — codes never travel over email, and are generated without a network connection |
Your account controls every project, every server, and your wallet balance. With 2FA set to None, a single leaked or reused password is enough for someone else to reach all of it. Authenticator App is the stronger of the two options, because a code sent by email is only as safe as the email account it lands in.
Enabling Email OTP
- Open Settings
Go to the Two-Factor Authentication section.
- Select Email OTP
It takes effect immediately — there is nothing further to confirm.
From then on, each sign-in sends a one-time code to your registered email address, which you enter after your password.
Enabling an Authenticator App
You will need an authenticator app on your phone — Google Authenticator, Microsoft Authenticator, Authy, or any other compatible app.
- Open Settings
Go to the Two-Factor Authentication section.
- Select Authenticator App
The Set up Authenticator App panel appears, showing a QR code.
- Scan the QR code
Open your authenticator app and scan it. If you cannot scan — on a desktop app, for instance — type the setup key shown beneath the code into your app manually instead.
- Enter the six-digit code
Your app now shows a code that changes every 30 seconds. Type the current one into Authenticator verification code and confirm.
The key beneath the QR code is the secret your codes are generated from. Anyone who has it can generate valid codes for your account indefinitely — a screenshot of it is as dangerous as your password. Do not paste it into a chat, a ticket, or a shared document.
Changing or turning off 2FA
Switch methods at any time from the Two-Factor Authentication section of Settings. What each switch asks of you depends on the method you are moving away from:
| From ↓ To → | None | Email OTP | Authenticator App |
|---|---|---|---|
| None | — | Applies immediately | Scan the QR code and enter a verification code |
| Email OTP | Applies immediately | — | Scan the QR code and enter a verification code |
| Authenticator App | Current password | Current password | — |
Moving to Authenticator App always runs the full setup again — see Enabling an Authenticator App above. Scanning the new QR code replaces any earlier CloudVantage entry in your app, so delete the old one once the new code is accepted.
Moving away from Authenticator App — to Email OTP or to None — brings up a Confirm security change panel. Enter your current password and click Confirm Change; the change does not apply until you do.
Turning off the authenticator is the change that most weakens your account, so it is the one held behind your password. Someone who reaches an already-signed-in browser cannot quietly remove it without also knowing what you typed to sign in.
Recovery codes are not available yet. Until they are, losing the phone means losing the ability to generate codes — add the CloudVantage account to an authenticator app that syncs across your devices, or set up a second device at the same time using the same QR code, so that one lost phone does not lock you out.
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 | Change your account password. You will need to verify your current password before setting a new one. If you have forgotten it, use the reset flow instead — see Resetting a forgotten password. |
| Two-Factor Authentication | Require a second verification step when signing in, using Email OTP or an Authenticator App. Set to None by default. Changing it asks for your current password. See Two-factor authentication. |
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
Run MySQL on CloudVantage without building or maintaining the server — create a new database, or migrate an existing one in.
A managed database is a MySQL server that CloudVantage provisions and runs for you. You choose how much RAM, CPU, and storage it gets, and how you want to reach it; CloudVantage builds the machine, installs and configures MySQL, opens only the ports your chosen access method needs, and gives you the credentials.
There are two ways to get one:
| Button | Use it when |
|---|---|
| Create Managed Database | You want a new, empty database |
| Migrate Database | You already have a MySQL database elsewhere and want to move it here |
Both end at the same place: a running MySQL instance listed on the Managed Databases page, with backups, version upgrades, and credential retrieval available from Manage DB.
Flavors, versions, and pricing
A flavor sets the RAM, CPU, and storage of the server your database runs on. Named flavors run from small development sizes up to large production ones, and Custom Flavor lets you specify RAM, CPU, and storage yourself.
Prices differ between the Europe and Lagos regions. Whichever flavor you pick, including a custom one, the price is shown before you confirm, and the estimated monthly cost appears beside the create button.
MySQL 8.0 and MySQL 8.4 are available.
If you are migrating an existing database, at least 4 GB of RAM makes the transfer noticeably faster. Large databases benefit from more. You are not stuck with the choice — the version can be upgraded later, and support can advise on resizing.
Creating a new database
- Open Managed Databases and click Create Managed Database
- Select a flavor
Pick a named flavor, or Custom Flavor to set RAM, CPU, and storage yourself. The price is shown alongside each option.
- Name the database
Letters, numbers, and underscores only — hyphens and spaces are rejected. CloudVantage appends a unique suffix, so a database named
employeesappears in the list as something likeemployees-1e0367c243. - Choose the MySQL version
MySQL 8.0 or MySQL 8.4. Customers are advised to use the more recent version of MySQL.
- Click Run Vulnerability Check
This scans the selected MySQL version for known critical vulnerabilities. It must pass before the database can be created.
- Set the database username and password
Enter the password twice. This is the account your application will use, unless you decide to create another database user or account.
- Choose a management interface
None, PhpMyAdmin, or Adminer. This decides how you reach the database and which ports are opened — see Choosing how to connect.
- Click Version Safe Create Database
The button at the bottom, with the estimated cost beside it. It becomes available once the vulnerability check has passed.
The database appears in the list as In progress while the server is built, briefly showing Waiting for server IP, and becomes Completed when it is ready.
The check confirms the MySQL version you picked has no known critical vulnerabilities before a server is built on it. Running it is not optional — the create button stays unavailable until it passes.
Choosing how to connect
Your choice of management interface determines which ports CloudVantage opens in the database's security group. Only what your chosen method needs is opened.
| Interface | How you reach the database | Ports opened |
|---|---|---|
| None | Directly, using the MySQL protocol — the mysql client, or your application's driver. You are given the IP address and port. | 3306 only |
| PhpMyAdmin | In a browser, at a URL supplied with your credentials | 80 and 443 |
| Adminer | In a browser, at a URL supplied with your credentials — lighter than PhpMyAdmin | 80 and 443 |
With None selected, port 3306 is open. Leaving it reachable from anywhere means your database is exposed to the whole internet, with only the password in the way. Open the database's security group and narrow the rule to the specific IP address or range your application connects from. Do this before you put real data in it.
With PhpMyAdmin or Adminer, only 80 and 443 are opened, so applications cannot connect over the MySQL protocol. If you need direct access as well as the web interface, add a rule for port 3306 to the security group yourself — and restrict it to known addresses when you do.
Migrating an existing database
The Database Migration Service moves an existing MySQL database from any external environment into CloudVantage with minimal downtime.
Before you start
- Your source database is reachable over the network
- The source database's IP address and port — MySQL's default is
3306 - A source username and password with sufficient privileges
- The exact database name, which must match on both sides
- At least 4 GB of RAM on the target flavor is recommended
Step 1 — Select a database flavor
- Open Managed Databases and click Migrate Database
- Choose the target flavor
Match it to your workload. A minimum of 4 GB RAM is recommended for a faster migration; for large databases, choose more.
- Click Next
Step 2 — Database setup
| Field | What to enter |
|---|---|
| Database Engine | MySQL |
| Database Name | Must exactly match the name on your source server, for example employees |
| Target Username | The username to create for the new database |
| Target Password | Enter and confirm. Use a strong password. |
| Management Interface | PhpMyAdmin, Adminer, or None — see Choosing how to connect |
| Payment Option | Monthly or yearly, billed according to the selected flavor |
The name entered here has to be identical to the one on your source server. A mismatch causes the migration to fail.
Click Next: Source DB Info.
Step 3 — Source database information
| Field | What to enter |
|---|---|
| Source IP Address | The address of your source database server |
| Source Port | MySQL's default is 3306 |
| Source Username | A user with migration privileges |
| Source Password | That user's password |
Create a user on the source database specifically for the migration, with only the privileges it needs, and delete it once the migration is finished. That way the credentials you type here never outlive the job they were made for.
Click Check Database Connection. This verifies that the database is reachable, the credentials are valid, and the required permissions are present. If it fails, re-check the IP address, source database name, username, password, and port. Once it succeeds, click Next: Migration Settings.
Step 4 — Migration settings
| Type | What happens | When to use it |
|---|---|---|
| Test Migration | The source stays read-write and nothing is locked. The process is simulated end to end. | First, always — to estimate how long it takes, check compatibility, and validate the process without risk |
| Live Migration | The source is placed in read-only mode. Writes are blocked for the duration to keep the data consistent. | The final production move. Afterwards, point your application at the CloudVantage database. |
A test migration tells you how long the live one will take and surfaces compatibility problems, at no risk to your source data. Use what it tells you to schedule the live migration during low-traffic hours — your application cannot write to the source database while it runs.
Select the migration type and click Start Migration. You can watch both provisioning and migration progress from the dashboard: provisioning completes first, then migration runs, and Migration Status reaches complete.
After the migration
- Verify all tables and data are present in the new database
- Test your application against the new credentials
- Update your application's connection settings
- Delete the temporary migration user from the source database
The database list
Every database in the project is listed with its name, IP address, engine, version, server type, status, and migration status. Filter DB Servers and Search Databases… narrow the list.
Migration Status reads complete for a migrated database and N/A for one created from scratch.
Retrieving your credentials
Click the eye icon beside a database's status to reveal its credentials. You get the database name, username, password, and — if you chose PhpMyAdmin or Adminer — the web interface URL and a reset URL for changing the database password later. Copy All takes the lot in one go.
Closing the modal removes them permanently — they cannot be retrieved again. Copy them into a password manager or another encrypted store before you close it, not afterwards. If you lose the password for a database with a web interface, the reset URL is your way back in; save that too.
Managing a database
Click Manage DB on any row to view its details, upgrade its MySQL version, and work with backups.
Upgrading the MySQL version
- Click Manage DB, then Upgrade Database Version
The dialog shows the current version.
- Select the target version
- Click Run Version Check
This validates that the upgrade can proceed.
- Click Upgrade Database
Available once the check passes.
Create a backup before upgrading, and test your application against the new version afterwards. A version upgrade changes the engine your data sits on, and having a restore point costs nothing next to not having one.
Backups
Click Manage DB, then Backups. The dialog has three tabs.
Available Backups lists every backup you hold, each with an ID, a timestamp, and a Restore action. Create Backup takes one immediately.
Schedule Backup controls automatic backups. Tick Enable Scheduled Backups, choose a frequency, and click Save Schedule:
| Frequency | Behaviour |
|---|---|
| Daily | A backup every day |
| Weekly | A backup every week |
| Interval | A backup every n days, where you set n |
The Current Schedule panel at the top shows whether the schedule is Active or Inactive, and what it is set to.
Restore History records past restores — the database, the backup ID used, how many tables were restored out of the total, and whether it succeeded.
Scheduled backups are disabled by default on every database, whether created new or migrated in. Until you enable them, the only backups that exist are ones you created by hand — so a database that has been running happily for months may have no recovery point at all. Turn on a schedule as soon as the database holds anything you would not want to re-enter by hand.
Deleting a database
Click Manage DB on the database's row, then Delete, and confirm. Billing stops on deletion, and you are refunded for the unused portion of the month — the same pro-rata refund applied when a Dew or a VPN connection is deleted.
Deleting a database removes it and its data immediately.
