A new OVHcloud account is at its most vulnerable in the first hour, before anything is running and before anyone has thought about who can log in or what it might cost. This guide covers the setup that is quick to do now and awkward to retrofit later, in the order that makes sense on OVHcloud specifically.
Secure the top-level login first
Whatever the platform calls its highest-privilege identity, treat it as a break-glass credential rather than a working login. On OVHcloud the access model is user accounts with per-service delegation, and an API with application keys for automation.
- Set a long, unique password and store it in a password manager.
- Turn on multi-factor authentication. This is the single highest-value action in this entire guide.
- Record the recovery details somewhere a second person can reach them.
- Create a separate working identity for daily use and leave the top-level one alone.
Compromised cloud accounts are usually mined for compute rather than data, which means the bill arrives before anyone notices the intrusion. Multi-factor authentication on the top-level identity is what stops that story from starting.
Set spending alerts before you deploy anything
Do this before the first resource exists, because afterwards you will be busy. On OVHcloud the tooling is the billing section of the control panel; most products are billed at a fixed monthly rate, so the forecast is largely the sum of what is running.
- Pick a monthly figure you would be unhappy to exceed.
- Alert at 50%, 80% and 100% of it.
- Send alerts to an address a person actually reads, not to the account’s own inbox.
Alerts do not stop spending. They turn a month-end shock into a Tuesday-afternoon question, which is the whole point. How cloud billing works covers what usually causes the spike.
Choose the region deliberately
The console will offer a default, and the default reflects where the provider is headquartered rather than where your users are. On OVHcloud you are choosing from a European core with additional locations in North America and Asia-Pacific — the European coverage, and the jurisdiction that comes with it, is the reason most people choose the platform.
Decide on three things: latency to your users, any legal requirement about where data may live, and whether the services you need exist in that region. Region is one of the few cloud decisions that is genuinely painful to reverse — see cloud regions and IP location explained.
Create the first resource
On OVHcloud, a Public Cloud instance, which is the closest analogue to a standard cloud VM. Two habits are worth forming immediately:
- Key-based authentication only. Add your SSH public key during creation rather than setting a password you will later have to rotate.
- Lock down the management ports. SSH and RDP should be reachable from your addresses, not from the whole internet. Automated scanners find a new public IP within minutes; that is the normal case, not the worst case.
What is particular to OVHcloud
Products are organised into distinct universes — public cloud, bare metal, web hosting — and they behave differently enough that it is worth knowing which one you are in.
This matters more than it sounds. Most of the friction people hit on a new platform comes from carrying habits over from a different one, and the organising concepts are exactly where those habits do not transfer.
Where to go next
- OVHcloud pricing: what actually drives the bill
- Buy OVHcloud Account — the configurations currently in stock
- Your first hour with a new cloud account — the platform-agnostic version of this checklist
- OVHcloud documentation
Questions
Frequently asked
What is the first thing to do with a new OVHcloud account?
Secure the top-level login with multi-factor authentication, then set a spending alert. Both take a few minutes and both are far harder to care about once something is already running.
Where do I set spending alerts on OVHcloud?
Through the billing section of the control panel; most products are billed at a fixed monthly rate, so the forecast is largely the sum of what is running. Configure it before you deploy, and send the alerts to an address a person reads daily.
Can I change the region later?
Moving an existing workload between regions means moving its data, which costs both transfer fees and downtime. Choosing deliberately at the start is much cheaper than correcting it later.