Founding-partner waitlist is open for small web and design agencies.
The operating layer

What we would run, and what stays yours.

CloudVault is pre-launch. This is the operating model being built, not a description of something already running — so every capability below is marked confirmed or planned.

Explore the three layers See how onboarding works
Designed for the tools agencies already use
Three layers, one clear view

Choose a layer. See what belongs there.

Select an aspect of the planned platform to see how it would work, what your agency supplies, and what still needs a decision.

A CloudVault guardian presents the three planned platform layers: sites and applications, data and authentication, and managed operations.

Pick a layer below

Layer 01 Planned — not yet running

Sites and applications

Your builds deploy to an environment you never have to administer — and nothing about the setup locks the client into a vendor they cannot leave.

Planned approach

  • Built for Next.js, React, Astro, and static output — standalone builds, not platform-specific adapters.
  • Push-to-deploy from your production branch, with the previous build kept as a rollback target.

Your part

  • A deployable build on a nominated production branch
  • Release approval before anything reaches a client
Open decision

Which runtime versions we commit to supporting, and for how long after one goes end-of-life. Nothing is provisioned yet, so this is a promise about the model, not a description of a running system.

Where the line sits

Pick a responsibility. See both sides.

White-label only works when ownership is unambiguous. This is the provisional operating model — a product control rather than a contract, and a commercial agreement will refine it.

01 Client relationship See the split
Your agency keeps

Owns the commercial and day-to-day client relationship.

CloudVault handles

Stays behind your agency. Does not market or upsell to your clients.

02 Application code See the split
Your agency keeps

Owns source, dependencies, build configuration, and application defects.

CloudVault handles

Does not change code without an approved support request and repository authorization.

03 Deployment See the split
Your agency keeps

Supplies a deployable build, a production branch, and release approval.

CloudVault handles

Provisions and maintains the supported pipeline once it is implemented.

04 Data and auth See the split
Your agency keeps

Owns schema, migrations, authorization logic, and data correctness.

CloudVault handles

Maintains the managed database and auth service within confirmed boundaries.

05 Domains and DNS See the split
Your agency keeps

Confirms domain authority and authorizes cutovers and client-facing timing.

CloudVault handles

Prepares and validates infrastructure records within approved scope.

06 Backups and restores See the split
Your agency keeps

Identifies critical data and authorizes restore point, target, and timing.

CloudVault handles

Runs only the backup services included in the approved plan.

07 Incidents See the split
Your agency keeps

Coordinates client communication and application-level remediation.

CloudVault handles

Diagnoses infrastructure-scope incidents and reports facts to you.

08 End-user support See the split
Your agency keeps

First-line support for the client and its users.

CloudVault handles

Not included by default.

09 Exit and portability See the split
Your agency keeps

Coordinates the destination, validates exports, and manages client communication.

CloudVault handles

Provides the agreed export and infrastructure handoff after authorization.

Escalation stays simple End client → Agency → CloudVault

Exceptions must be explicit, narrow, and documented. A client emergency contact does not become a general support channel, and never becomes a route for us to sell around you.

Product principles

What we will not do.

These are policy positions rather than capabilities — which is why they can be stated plainly today while everything above is still planned.

  1. 01

    We do not contact or upsell your clients.

    Not for support, not for billing, not for marketing. If we need something, we ask you.

    C-02, C-03
  2. 02

    We do not publish numbers we cannot measure.

    No uptime percentage, no incident statistics, and no customer counts until there is a platform behind them and wording that has had legal review.

    X-06
  3. 03

    We do not claim to own the hardware.

    The planned model is dedicated rented infrastructure kept separate from any other workload — not owned metal in facilities we selected.

    X-07
  4. 04

    We do not automate before it is earned.

    Founding partners are onboarded by hand on purpose. Provisioning gets automated after the process is proven, not before.

    C-07

Hold us to the model.

If this is the operating layer you would want behind your client sites, join the founding-partner list. We would rather hear where it is wrong now than after it is built.

Join the founding-partner list Read the scenarios

// Pre-launch. Founding partners are onboarded personally, one site at a time.