Overview

Run the complete Velt platform on infrastructure you own: backend, admin console, and client SDK, with no runtime requests to Velt-owned hosts.

Full self-hosting moves Velt’s entire stack (the backend, the admin console, and the client SDK) into a cloud account you own. When it’s done, your app and console make no requests to velt.dev or any other Velt-owned host. Data, sign-in, and administration stay inside your tenancy.

​

Choose your cloud

GCP

Available. Cloud Run and Firebase in your GCP project.

AWS

Closed beta. EKS and RDS for PostgreSQL, on GovCloud or commercial.

Azure

Closed beta. AKS and PostgreSQL Flexible Server, commercial or Government.

​

How it works

You don’t run the install by hand. An AI coding agent does the work, and you handle the few steps that need a person.

1. Prepare. Check the prerequisites and decide your inputs on your cloud’s Get Started page.
2. Hand off. Copy the agent instructions from the Install page and paste them into your AI coding agent with your inputs.
3. Approve. The agent verifies every Velt artifact, builds the infrastructure, and deploys the backend, console, and SDK. It stops when it needs you: sign-in, billing or quota, the console’s sign-in provider, the image scan sign-off, DNS, and a certificate.
4. Connect your app. Add the selfHosted config the agent gives you, so the SDK loads from and talks to your deployment only.
5. Verify. Sign in to the console, create a comment in your app, see it in the console, and confirm the browser’s network log shows no Velt-owned hosts.

​

What you run

Piece	GCP	AWS and Azure
Backend	Cloud Run services and your own Firebase project	A Kubernetes cluster (EKS or AKS) and managed PostgreSQL
Console	Static files on a host you choose	Served from the deployment’s one public host
SDK	@veltdev/sdk files on your CDN	Served from the deployment’s one public host
Built with	Velt’s signed Terraform module	Velt’s signed Terraform module and Helm chart

​

Full vs partial self-hosting

Velt offers two kinds of self-hosting. They solve different problems.

	Partial self-hosting	Full self-hosting
What moves to you	User content and PII, through data providers	Backend, console, SDK hosting, and all data
Who runs the backend	Velt	You
What you set up	Data provider callbacks or endpoints in your app	Cloud infrastructure, with an AI coding agent doing the install
Requests to Velt hosts	Yes, for the collaboration backend	None
Where to start	Partial self-hosting	Choose your cloud

​

Key concepts

Concept	What it means for you
Release	One version number covers the backend, console, and SDK together. You install and upgrade releases, never individual components.
Signed manifest	Each release is a signed file that pins every component by digest. The agent verifies its signature with cosign before it pulls anything.
selfHosted config	The object in your app’s Velt config that points the SDK at your deployment. The agent generates it for you.
Strict mode	selfHosted.strict: true. Any endpoint your deployment doesn’t serve is switched off instead of falling back to Velt’s hosted service. Required for zero egress.
State file	A JSON file the agent keeps in your working directory. It records progress (never secret values), so a new session can resume an interrupted install.

​

Security

• Every artifact is verified. The agent checks each image, module, chart, and bundle against Velt’s signing identity, and stops on any failure.
• Images run from your registry. The agent copies images into your own registry by digest and scans them there. You sign off the scan (or waive it, if your policy allows) before the application deploys.
• Secrets stay with you. Keys, passwords, and tokens go into your secret store. The state file and the agent’s report record only where they are kept.
• Zero egress is tested. The last acceptance check is a network audit. Any request to a Velt-owned host fails the install.