Setting up a European cloud project the right way on OVHcloud and Scaleway

Most cloud incidents that hurt later start with a rushed first hour. Someone spins up a project under a personal login, runs everything through the root API key, picks whatever region the console defaulted to, and never sets a spending alert. It works right up until a key leaks, a bill triples overnight, or an auditor asks who has access to production and where the data lives.

This article is the foundation for the rest of this series on running scalable web apps on European infrastructure. Before we build anything – compute, databases, object storage, Kubernetes – the account itself needs to be set up so it stays clean as the team and the workload grow. We cover the same four things on both OVHcloud and Scaleway: how to structure organisations and projects, how to choose EU regions, how to set up IAM users, groups and API keys, and how to get billing alerts and EUR invoicing right. At the end there’s a starter checklist and the CLI commands to reproduce the whole setup.

Both providers are French, bill in euros, and keep your resources under EU jurisdiction, which is the reason we start the series here. The account models differ enough that it’s worth treating them separately.

Structure first: organisations and projects

The single most useful decision you make on day one is how you split resources into projects. Get this right and access control, billing separation and blast radius all fall into place. Get it wrong and you spend a year untangling one giant project where everything can reach everything.

On OVHcloud, a Public Cloud project is the boundary that separates resources from the access rights attached to them. The pattern that holds up over time is one project per application per environment, named with a consistent prefix. OVHcloud’s own guidance suggests combining domain, application and environment, for example:

pc_shop_web_prod
pc_shop_web_staging
pc_shop_web_dev
pc_billing_api_prod

The reason to separate environments into their own projects rather than folders inside one project is that IAM policies, quotas and billing all attach at the project level. A developer can have write access to pc_shop_web_dev and no access at all to pc_shop_web_prod, and a leaked dev key can’t touch production. Your monthly invoice also breaks down per project, so cost per environment and per application is visible without any tagging effort.

On Scaleway, the hierarchy has one more level. An Organization is created automatically with your account and sits at the top. Inside it you create Projects, which group resources the same way OVHcloud projects do. Billing, IAM and support all live at the Organization level; resources, Object Storage buckets and managed databases live inside Projects. So the same “one project per app per environment” pattern applies, with the Organization as the company-wide container above them:

Organization: your company
Project shop-web-prod
Project shop-web-staging
Project shop-web-dev

One caveat worth knowing early on Scaleway: IAM permission sets scope to a Project or to the whole Organization, not yet to individual resources. That makes the project split more important, not less. If two systems need different access rules, they belong in different projects from the start.

Choosing EU regions

Region choice decides three things at once: where your data physically sits, how close you are to your users, and whether you can build across isolated failure domains. For a European-first strategy you want all of that inside the EU.

OVHcloud EU regions for Public Cloud include:

GRA – Gravelines, France
SBG – Strasbourg, France
RBX – Roubaix, France
DE1 – Frankfurt, Germany (region code LIM on the availability map)
WAW – Warsaw, Poland
3-AZ Paris and 3-AZ Milan – regions split into three availability zones

The distinction that matters for resilient design is between the older single-datacentre regions (Gravelines, Strasbourg, Roubaix, Frankfurt, Warsaw) and the newer 3-AZ regions (Paris, Milan). A 3-AZ region gives you three physically separate zones inside one region, so you can run a load balancer and application tier across zones and survive the loss of a single datacentre without leaving the region. If a workload needs zone-level fault tolerance, start it in a 3-AZ region. If it needs multi-region resilience, pair two regions in different cities – a later article in this series covers those failover patterns in detail.

Scaleway organises capacity into regions and availability zones:

Paris: fr-par-1, fr-par-2, fr-par-3
Amsterdam: nl-ams-1, nl-ams-2, nl-ams-3
Warsaw: pl-waw-1, pl-waw-2, pl-waw-3
Milan: it-mil-1

Amsterdam keeps your data in the EU while giving you a second country for geographic separation from Paris. Warsaw does the same to the east. Because Paris, Amsterdam and Warsaw each expose three availability zones, you can build zone-redundant deployments in any of them and multi-region deployments across them, all without leaving EU jurisdiction. Product availability differs by region, so check that the specific service you need (managed databases, Kubernetes Kapsule, a particular instance type) exists in the region before you commit to it.

A practical rule for both providers: pick a primary region close to your users, confirm every service in your stack is available there, and pick your secondary region in a different city but the same jurisdiction. Write the choice down. Regions are hard to change once storage and data have accumulated.

IAM: users, groups and API keys

The goal here is simple to state and easy to skip: no human uses the root account for daily work, no automation uses a personal key, and every grant of access goes to a group rather than an individual. That keeps the access list readable a year from now.

On OVHcloud

OVHcloud IAM has three kinds of identity:

Local users – a person in your organisation, tied to your OVHcloud account.
Service accounts – machine-to-machine identities for automation, CI/CD and Terraform.
Federated identities – users authenticated through your own identity provider over SAML (Entra ID, Google Workspace, Okta, AD FS).

Access is granted through policies that link an identity or group to resources through a set of permitted actions. Rather than assign policies to individuals, create groups such as developers, sre and auditors and attach policies to those. OVHcloud ships permission groups like globalReadAccess and globalWriteAccess so you don’t have to enumerate every action by hand.

A worked example that maps cleanly onto the project structure above: a developer group gets globalWriteAccess on the dev project, globalReadAccess on staging, and no access to production. An SRE group gets write on staging and production. Access to the Control Panel is itself a policy, so a group can be allowed into the console while still being restricted to exactly the projects it should see.

Start protecting the account before any of this. Enable two-factor authentication on the owner login, set a recovery email that differs from the primary, and use a strong unique password. The IAM structure only matters if nobody can walk in the front door.

On Scaleway

Scaleway’s model has four building blocks:

Members / users – humans in your Organization. Note the current limitation: you invite users into an Organization rather than creating them directly.
Applications – non-human users. An application holds an API key and gives programmatic access without being tied to a person. This is where CI/CD and Terraform credentials belong.
Groups – collections of users and/or applications, so you attach policies once and cover everyone in the group.
Policies – rules that grant one or more permission sets (for example InstancesFullAccess, InstancesReadOnly, DatabaseFullAccess, BillingReadOnly) at Project or Organization scope.

An API key is now tied to a user or an application rather than directly to a project, and it consists of an access key (not sensitive) and a secret key (very sensitive, shown once). Create a dedicated application per automation use, give it its own key, and set an expiry date so credentials rotate instead of living forever. Because Object Storage uses the S3 interface, which has no concept of a Scaleway project, each API key has a preferred Project that its bucket operations run against – set that deliberately.

The pattern that works: a ci-deploy application with a policy granting exactly the permission sets it needs on the target project, an expiring API key for it, and human team members grouped into developers, sre and billing with permission sets scoped to the right projects. Reserve BillingReadOnly at Organization scope for whoever watches spend.

Billing alerts and EUR invoicing

Both providers invoice in euros to an EU legal entity and produce VAT-compliant invoices, which is one of the quiet reasons a European-first stack is easier to reconcile. Set your account country and VAT number correctly during onboarding so invoices are valid from the first month.

The part people forget is the alert. Cloud spend fails quietly – a runaway autoscaler or a forgotten load test doesn’t page anyone, it just shows up on the invoice. Set consumption alerts before you deploy anything.

On OVHcloud, Public Cloud runs on prepaid credit or post-paid billing depending on your account, and consumption is visible per project in the Control Panel. Set a budget threshold and route the notification to a shared inbox or an alias the on-call team reads, not a single person’s mailbox. Because usage is reported per project, you can see immediately which application and environment is driving a spike.

On Scaleway, billing lives at the Organization level. Configure a budget alert so you’re notified when consumption crosses a threshold you set, and give the finance or platform owner the BillingReadOnly permission set at Organization scope so they can read invoices and consumption without any resource access. Keep at least one alert well below your real ceiling as an early warning, and a second near the ceiling as a hard signal.

Starter checklist

• Owner account secured: 2FA on, recovery email set, strong unique password.
• Account country and VAT number set for correct EUR invoicing.
• Project naming convention agreed (domain / app / environment) and written down.
• One project per application per environment created; production isolated from dev and staging.
• Primary and secondary EU regions chosen, with every required service confirmed available in each.
• Groups created (developers, sre, auditors/billing); policies attached to groups, never to individuals.
• Production write access limited to the SRE group.
• Automation uses a dedicated service account (OVHcloud) or application (Scaleway), never a personal key.
• API keys have expiry dates and a rotation plan; secret keys stored in a secret manager.
• Budget alerts set below and near your ceiling, routed to a shared inbox.
• Billing read access granted to whoever owns spend, with no resource access.

Reproducing the setup from the CLI

Both setups are scriptable, which is the point – your account structure should be reproducible and reviewable like any other infrastructure.

OVHcloud

Install and configure the OVHcloud CLI, which talks to the IAM v2 API. Authenticate with a service account or application credentials rather than your personal login:

# configure credentials (application key/secret + consumer key)
ovhcloud config

# list your public cloud projects
ovhcloud cloud project

# list IAM identities, groups and policies
ovhcloud iam identity user
ovhcloud iam group
ovhcloud iam policy

# create a group and a policy granting write access to the dev project
ovhcloud iam group create --name developers
ovhcloud iam policy create \
  --name pc_shop_web_dev-RW \
  --identities "urn:group:developers" \
  --permission-group globalWriteAccess \
  --resource "pc_shop_web_dev"

For OpenStack-native work (creating instances, networks and volumes), download the OpenStack RC file for the project from the Control Panel and source it, then use the standard openstack client against the region you chose:

source openrc.sh
openstack --os-region-name GRA server list
openstack --os-region-name GRA flavor list

Scaleway

Install the Scaleway CLI and initialise it. scw init walks you through authentication and stores your access key, secret key, default Organization, project and region:

scw init

# create a project for an app environment
scw account project create name=shop-web-dev

# create an application for CI/CD, a policy, and an expiring API key
scw iam application create name=ci-deploy description="CI/CD deploy"

scw iam policy create \
  name=ci-deploy-shop-web-dev \
  application-id=$APP_ID \
  rules.0.project-ids.0=$PROJECT_ID \
  rules.0.permission-set-names.0=InstancesFullAccess

scw iam api-key create \
  application-id=$APP_ID \
  default-project-id=$PROJECT_ID \
  expires-at=2026-01-01T00:00:00Z

# create a group for humans and attach a policy
scw iam group create name=developers
scw iam policy create \
  name=developers-shop-web-dev \
  group-id=$GROUP_ID \
  rules.0.project-ids.0=$PROJECT_ID \
  rules.0.permission-set-names.0=InstancesReadOnly

Store the secret key from the API key response in a secret manager immediately – Scaleway shows it once and never again. For anything beyond a first setup, both providers have mature Terraform providers, and moving this same structure into version-controlled configuration is the natural next step.

With accounts secured, projects split by application and environment, regions chosen inside EU jurisdiction, access granted through groups, and spending alerts wired up, you have a base that stays clean while the workload grows. Everything the rest of this series builds – compute tiers, managed databases, object storage, caches, Kubernetes and the failover runbooks between regions – sits on top of exactly this structure.