Backend-as-a-service, for AI products
The backend-as-a-service that doesn’t stop at CRUD.
Five building blocks, one declared policy: a typed database, hybrid search, document ingestion, secure in-perimeter inference, and serverless functions. The same access policy governs all five, whether the caller is a person, an agent, or your own code.
Start lean. Scale to a compliance-grade, audited posture without re-platforming.
Vectros is in an invite-only 0.x preview. Request access and we’ll get you a key. Self-serve and a free tier are on the way as we open access.
Five building blocks, one governed system
Pick one up on its own, or use all five as one thing.
Each building block stands alone: a real, independently useful capability, not a feature bundle you have to buy whole. Together, they run under one system where each caller gets exactly the access you define for it, instead of four systems you wire up and operate separately.
Database
Declare a schema, get validation, versioning, and indexing for free.
Search
Full-text, semantic, hybrid, or none, chosen per data type, one call.
Document ingestion
Inline or upload, indexed for search the moment it lands.
Secure inference
In-perimeter LLM calls, with or without retrieval, no third-party model egress.
Functions
Your own JavaScript, run as an endpoint or a trigger, under a declared principal.
The part that isn't a commodity
One system. A different rule for every caller.
A person signing in, an external agent over MCP, and a script running inside the platform are all callers under one system, each granted exactly the role you define for it, enforced and audited the same way. Adding a new kind of caller is a role you declare, not new authorization code you write and review.
Most backend-as-a-service platforms treat agent access, function authorization, and data access as three separate concerns, each with its own credential. Here, they're one governed system.
Built to grow with you
Scales the way a managed store should.
The database and full-text search both scale independently of your data's size: steady performance from a side project to a real system of record, no re-platform, no capacity plan. Semantic search has a per-tenant capacity limit, well above what the overwhelming majority of use cases need, with room to raise it for larger ones; everything else keeps working past it (the honest boundary lives on the search building block). The underlying store is continuously backed up in production.
See the published capacity limits rather than take our word for it.
Why this matters more now
Building got cheaper. Owning it didn't keep pace.
An agent can generate a database layer, an embedding pipeline, an authorization check, and a usage meter in an afternoon. Running things got cheaper too, just not at the rate building did, so the gap between the two keeps widening instead of closing. One cost hasn't moved at all: whoever answers for it when isolation quietly fails or an audit trail comes up short still carries that, no matter how good the tooling gets. Vectros is a managed service for exactly that non-functional plumbing, so your attention goes to your product instead.
Built on the same five building blocks
Turnkey solutions, not new engineering.
Where this goes next
Three kinds of caller run under one governed system today, each with its own declared role: a person signing in, an external agent over MCP, and code you wrote executing inside the platform. The one we're building next is the obvious one: agents that work inside the boundary rather than calling into it, under a role you declare, exactly like everything above. We're running that on our own content and outreach operations first. It will arrive the way running your own code did, as a capability you grant in your blueprint file, the same one that already declares everything else.
How you reach it, and where you can start
One API. Four ways to call it. Two ways to start already built.
Ways to call the API
API
The core REST surface: data, documents, search, inference, identity, auth. Everything else is a client on top of it.
SDKs
Typed clients for TypeScript, Python, and Java. Construct one with a token and environment, then call sub-clients by area: records, schemas, documents, folders, search, inference, identity, scripts, and triggers.
CLI
The blueprint lifecycle: init, validate, plan, bootstrap, and end-to-end test, plus direct provisioning of contexts, identities, scoped keys, roles, and access bindings. See the tools page.
MCP server
Twenty-three data-plane tools that let an AI agent read and write your Vectros data natively over MCP. Vectros data-plane tools only, no web or external-search tools, by design. See the tools page.
Ways to start already built
Blueprints
An app model as one config file (schemas, access profile, a service principal, optional seed data), provisioned in one command, then driven from an agent with zero application code.
Reference apps
Forkable, production-grade front-ends with no application server of their own, including the RAVV reference app: a full customer-facing app with your own sign-in. Wire your own identity provider and host, and ship a secure, audited app for roughly the effort of building the front end alone.
The shortest path to running something
The no-code path, end to end.
Scaffold your own app from a bundled exemplar, then provision it.
# Scaffold a new "my-intake" app from the clinical-intake exemplar:
vectros blueprint init my-intake --from clinical-intake
# Check it before you provision anything (offline, no credentials):
vectros blueprint validate ./my-intake.blueprint.yaml
# Provision it, idempotently:
vectros bootstrap --blueprint ./my-intake.blueprint.yamlbootstrap sets up everything the app needs to run: the schemas, an isolated application context, a service identity (a "principal") to act as, a least-privilege set of permissions, and a narrow API key scoped to just that. It converges on re-run instead of duplicating. From there, drive it through an MCP agent or the data-plane UI. No application code.
--blueprint takes a bundled name or a path to your own blueprint file, the same command either way. That's the whole install step for a forked reference app: no separate scaffold, just your own input values.
# Or fork a full reference app and apply its own blueprint file
# directly, no scaffold step needed (needs @vectros-ai/cli 0.23.0 or later):
git clone https://github.com/vectros-ai/vectros-casework-spa
vectros blueprint apply ./vectros-casework-spa/blueprint/casework.blueprint.yaml --tenant test \
--set companyName="Acme HR" \
--set auth0Domain=acme.us.auth0.com \
--set auth0Audience=acme-hrThat's the install step for the RAVV reference app: a full case-management app with its own sign-in, forked and pointed at your own Auth0 tenant, running against the schemas and access profile its blueprint declares.
The CLI is the trust boundary, not the blueprint: a blueprint is untrusted input, and a validation step (the scope gate) mints only data-plane scopes (records · schemas · search · documents · folders · inference · entities). Control-plane scopes are hard-rejected. There is no override flag.
Start here
Three entry points.
The platform overview & docs map
The five building blocks in full context, organized so you always know where to look (explanation → how-to → reference for each area).
The blueprint walkthroughs
Getting-started, clinical-intake, agentic-sdlc, and second-brain: complete builds you can follow end to end.
The generated API reference
The authoritative, always-current request and response shapes, rendered from the OpenAPI specification.
Invite-only today. Request access and we’ll get you a key.