Introduction to Vadyl

Vadyl is a product-first backend platform. You define the things your product is built around — customers, orders, invoices, teams, subscriptions, permissions, workflows, events, actions, agents, and surfaces — and Vadyl turns that product model into a running backend: data, APIs, logic, rules, migrations, integrations, observability, operations, and runtime scaling. When your product changes, the backend changes with it.

The split: above the line, below the line

Vadyl draws a hard line between two kinds of concerns. Above the line is your product model — the canonical truth about what your product is and does. Customers and orders do not change meaning when you switch from Postgres to MongoDB or from CloudFront to Cloudflare. Below the line is interchangeable infrastructure — execution substrates, providers, and configurations. Vadyl compiles the product model, including scale, ingress, and resource intent, down onto whatever substrate you bind it to.

Two independent axes of change. Product intent evolves through the canonical lifecycle (branches, commits, sandboxes, publications, rollouts). Infrastructure evolves through providers and configuration. Neither disturbs the other.

What Vadyl is not

• Not a database. Vadyl talks to seven first-class database families through its capability-surface substrate — relational, document, key-value, graph, wide-column, time-series, and vector.
• Not an ORM. Vadyl owns the entity contract; ORMs sit on top of a database you already chose. Vadyl chooses the database for you (or lets you choose), then compiles canonical operations to the right substrate.
• Not a BaaS. Backend-as-a-service products own your backend; you write code against their API. Vadyl is the platform you define your product backend on, with first-class APIs, SDKs, CLI, and a coding workspace where you author the actual logic.
• Not a code generator. Vadyl compiles APIs, SDKs, GraphQL SDL, gRPC contracts, OpenAPI, and the dashboard from the product model and canonical entity graph at runtime. There is no codegen step you maintain.

Who Vadyl is for

Vadyl is for teams building serious AI-native applications — the kind that need durable state, real authentication, observability, agent integrations, and the freedom to swap out cloud and provider choices as the product matures. It progressively discloses depth:

• Zero-concept users can describe the backend they want in natural language and never consciously model an entity.
• Product developers define entities, policies, workflows, and integrations once, then consume generated APIs and SDKs.
• Platform engineers inspect and control the deeper machinery — AST query plans, provider placement, governance envelopes, publications, compensation, cache invalidation.

These are depth levels over one canonical model — not separate product truths.

Where to go next

• Quickstart — define an entity and hit your first compiled API in under ten minutes.
• Product-first design — the deeper model behind the split.
• Architecture — the layered diagram of every plane Vadyl ships.