Hosting, regions and deployment status
RapidValue is moving to a Scaleway-first managed SaaS for Europe. Amsterdam
(nl-ams) is the decided primary region for the European offer, on
European-owned cloud infrastructure with customer data hosted in the selected
EU region. EU hosting is the standard European offer; it is not a premium
hosting tier.
That is the decided target architecture, not a claim that the new production platform is already generally available. The current Scaleway environment is a compatibility lab. It has proved important building blocks, but it has not yet passed the production high-availability and operational exit criteria below.
Status at a glance
| Deployment model | Intended use | Status | Availability and support |
|---|---|---|---|
| RapidValue-managed SaaS on Scaleway Amsterdam | Default for European customers | Decided primary target; compatibility validation in progress | Not yet a supported production or GA environment |
| RapidValue-managed SaaS on AWS | Existing deployments, non-EU regions, or an explicit customer requirement | Supported provider target | Managed by RapidValue under the agreed service scope |
| Customer-managed cloud | Enterprise customers requiring deployment in their own cloud account | Future enterprise option | Separate pricing, implementation and support model; not a standard feature today |
| Customer-managed on-premises control plane | Enterprise customers requiring the whole platform in their own environment | Future enterprise option | Separate pricing, implementation and support model; not a standard feature today |
| Tier-3 agent in a customer network | Local connector reach and local credential custody while using managed SaaS | Supported hybrid component | This is not the same as a customer-hosted control plane; see Tier-3 Hybrid Architecture |
Customers principally choose a data region and hosting requirements. The underlying provider is an implementation choice unless a contract or technical requirement makes it material. The application architecture remains provider-neutral, with provider adapters for the services that cannot be made portable.
What the Scaleway compatibility lab has proved
The Amsterdam lab currently demonstrates:
- an application server connected over the intended network path;
- private PostgreSQL 16;
- a full replay of the database migrations;
- a private container registry;
- object-storage compatibility; and
- DNS configuration.
This is evidence of compatibility, not evidence of production availability. The lab is deliberately smaller than a production topology and does not prove high availability, disaster recovery or a supported service level.
Exit criteria before production support
The Scaleway target must not be described as production-supported until all of the following are implemented and exercised in staging:
- runtime and deployment secrets are stored and resolved without committed secret material;
- CI/CD deploys through health gates rather than manual-only steps;
- public endpoints use managed HTTPS with certificate renewal and failure alerting;
- application, database and certificate monitoring alerts the operating team;
- backup and restore are exercised with a recorded result;
- deployment rollback is exercised, not only documented;
- migrations reach the expected head and the restricted application role plus row-level-security canary pass;
- attachment, report and tenant-export flows pass against the selected object store; and
- the complete topology passes staging validation, including failure modes.
Passing one item does not imply the others. Production support is a single gate over the complete list.
Security and privacy boundaries
Hosting on Scaleway supports two concrete statements: the infrastructure provider is European-owned, and customer data can be hosted in a selected EU region. It does not by itself prove compliance with a customer's regulatory framework, create immunity from foreign law, or remove the need to review contracts, subprocessors, support access and data flows.
In every managed deployment, the synced governance model—identities, accounts, entitlements, grants, workflow and audit data—lives in the selected control-plane region. A Tier-3 agent changes connector reach and credential custody; it does not keep the synced governance model out of the control plane. See Tenant isolation for the application and database boundary.
Provider-specific operations
Generic product documentation describes outcomes: health checks, migrations, backups, restores, monitoring and rollback. Operator runbooks must name their provider explicitly because the commands and failure modes differ.
- AWS RDS, Secrets Manager, KMS, IAM and Route 53 instructions are AWS runbooks, not generic product requirements.
- Scaleway Database, Secret Manager, Object Storage, IAM and DNS instructions remain lab runbooks until the production gate above passes.
- A provider adapter is supported only when its operational path is tested; API similarity alone is not enough.
Commercial and support boundary
European managed SaaS does not carry a premium solely because it uses the European default hosting target. An explicit non-default region, customer-cloud deployment or on-premises control plane can materially change implementation, operations and support responsibilities and therefore needs a separate scope.
Do not plan a customer-cloud or on-premises rollout from this page. Those models become orderable only when RapidValue publishes a supported topology, delivery process, responsibility matrix and commercial terms for them.
Further reading:
- Tier-3 Hybrid Architecture — connector execution and credential custody
- Tenant isolation — the tenant boundary inside a shared control plane
- Environments and staged config — application configuration across dev, acceptance and production
- What we don't claim — limits that are deliberately public