The operating layer

What we would run, and what stays yours.

CloudVault is pre-launch. This is the operating model being built rather than a description of something already running — so every capability below is marked as a confirmed direction or a planned one.

Read the three layers See how onboarding works

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 ties the client to a vendor they cannot leave.

Planned mechanism

Designed for Next.js, React, Astro, and static builds — standalone output rather than platform-specific adapters.
Push-to-deploy from your production branch, with the previous build kept as a rollback target.
Per-site isolation on dedicated CloudVault infrastructure, separate from any other tooling.

Your agency supplies

A deployable build and a nominated production branch
Runtime and environment requirements
Release approval before anything reaches a client

CloudVault takes on

Provision and maintain the supported pipeline
Keep the host, orchestration, and routing layers patched
Maintain the supported runtime and isolation model

Still undecided

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

Layer 02 Planned — not yet running

Data and authentication

A Postgres database, authentication, storage, and row-level security your developers already know how to use — without anyone on your team owning database operations.

Planned mechanism

Self-hosted Supabase components rather than a proprietary data layer, so the API surface is one your developers have already learned.
Backups and retention defined per plan and written down, with restores rehearsed before they are ever needed in anger.
Tenancy model — shared versus dedicated database resources — is still being decided, and will be stated plainly rather than glossed over.

Your agency supplies

Schema, migrations, and authorization logic
Identification of which data is genuinely critical
Authorization of restore point, target, and timing

CloudVault takes on

Maintain the managed database and auth service within confirmed boundaries
Run and verify the backup services included in the approved plan
Execute authorized restores within the agreed scope

Still undecided

Whether accounts get a shared or dedicated database, plus backup retention, off-host storage, and how direct Postgres access is secured. A restore has not been rehearsed yet, and we will not describe retention as proven until one has.

Layer 03 Planned — not yet running

Managed operations

The work that starts after launch — certificates, routing, patching, monitoring, and incident response — stops being unpaid agency labour.

Planned mechanism

Traefik terminates TLS and handles routing; certificate issuance and renewal are automated so expiry stops being a calendar problem.
Infrastructure monitoring covering availability, error rate, and resource pressure, with alert thresholds agreed rather than assumed.
A coverage model written for a small operator: defined hours, defined escalation, and honest limits instead of an implied 24/7 rotation.

Your agency supplies

Correct domain authority and prompt registrar changes
Application-level monitoring not included in the service
Client communication during an incident

CloudVault takes on

Operate certificate and routing automation once implemented
Diagnose and remediate infrastructure-scope incidents
Report incident facts to you, never to your client

Still undecided

The honest coverage model for a solo operator: which hours are genuinely covered, what happens outside them, and how escalation works. This is the hardest thing on the page to get right, and we would rather publish a narrow window we can meet than a broad one we cannot.

Where the line sits

Two halves of one boundary.

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

Your agency

// Owns the client and the application

Client relationship Owns the commercial and day-to-day client relationship.
Application code Owns source, dependencies, build configuration, and application defects.
Deployment Supplies a deployable build, a production branch, and release approval.
Data and auth Owns schema, migrations, authorization logic, and data correctness.
Domains and DNS Confirms domain authority and authorizes cutovers and client-facing timing.
Backups and restores Identifies critical data and authorizes restore point, target, and timing.
Incidents Coordinates client communication and application-level remediation.
End-user support First-line support for the client and its users.
Exit and portability Coordinates the destination, validates exports, and manages client communication.

CloudVault

// Owns the infrastructure layer, invisibly

Client relationship Stays behind your agency. Does not market or upsell to your clients.
Application code Does not change code without an approved support request and repository authorization.
Deployment Provisions and maintains the supported pipeline once it is implemented.
Data and auth Maintains the managed database and auth service within confirmed boundaries.
Domains and DNS Prepares and validates infrastructure records within approved scope.
Backups and restores Runs only the backup services included in the approved plan.
Incidents Diagnoses infrastructure-scope incidents and reports facts to you.
End-user support Not included by default.
Exit and portability Provides the agreed export and infrastructure handoff after authorization.

Escalation path: 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 marked as planned.

C-02, C-03: We do not contact or upsell your clients. Not for support, not for billing, not for marketing. If we need something, we ask you.
X-06: 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-07: 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.
C-07: 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.

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.