What is Kizaki?

Kizaki is an application platform for building real products without manually stitching together a dozen separate backend tools. You define your application at the data layer in Inspire, write your server workflows in TypeScript, and let the platform generate the runtime and client surfaces that sit in between.

The key idea is simple: the risky parts of application development should not be hand-wired over and over again. Auth, authorization, billing, file access, routes, migrations, and live queries should come from one coherent model rather than a pile of disconnected services.

The Problem Kizaki Is Solving

Modern app development usually fails in two ways:

• it is slow because developers spend time composing services, SDKs, and configuration instead of building product logic
• it is unsafe because the stack allows common mistakes like missing auth checks, inconsistent data access rules, and ad hoc migration flows

Kizaki is designed to move those concerns into the platform. The goal is not to remove application expressivity. The goal is to remove the repetitive system plumbing that makes product development fragile.

The Kizaki Model

Kizaki is organized around three layers:

• Inspire defines the data model and system behavior
• server code implements app-specific workflows and business logic
• frontend code calls generated APIs and renders the product

Those layers stay aligned because the compiler sits in the middle. It reads your schema, validates your exposed server functions, generates TypeScript packages, and gives the runtime the information it needs to enforce the model you declared.

If you are starting fresh, the recommended path is:

1. create a new app with kizaki init
2. run it locally with kizaki dev
3. add server functions with /** @expose */
4. call the generated @kizaki/client from your app
5. evolve your schema with committed migrations
6. deploy with kizaki deploy

What You Build With

Kizaki gives you a few public surfaces that work together:

• Inspire for schema, auth, authorization, routes, billing, and platform features
• @kizaki/schema for typed entity objects generated from your schema
• @kizaki/client for typed RPC functions generated from your exposed server code
• @kizaki/sdk, @kizaki/sdk/browser, and @kizaki/react for server-side queries and browser live queries

Most developers end up using all of them, but not all in the same way:

• Inspire is where you make platform decisions
• server code is where you write workflows
• the generated client is what your browser code calls
• the browser query stack is what keeps UI state live

The Core Workflow

auth {
  providers: [email],
  sessionDuration: 30d,

  principal {
    displayName: string @from(Profile.displayName),
  }
}

entity Todo {
  title: string @minLength(1) @maxLength(255),
  completed: boolean = false,
  ownerId: __User.id,

  @grant read, write, delete where resource.ownerId == principal.id
}

That schema is not just documentation. It becomes:

• a real database model
• a policy-enforced runtime contract
• generated TypeScript entities and client functions
• the source of truth for future migrations and deploys

Why The Schema Matters So Much

In many stacks, your data model, auth rules, and frontend API drift apart over time because they live in different systems. Kizaki intentionally collapses those decisions into one place.

That gives you a few practical benefits:

• changing the schema updates the generated developer surfaces
• auth and authorization stay close to the data they protect
• migrations are based on source-of-truth diffs instead of hand-written SQL files
• the runtime can enforce access consistently across normal reads, routes, and live queries

What Kizaki Is Not

Kizaki is not just an ORM, not just a backend generator, and not just a deploy tool.

It is also not asking you to give up normal application code. You still write TypeScript. You still use libraries. You still build a real frontend. What changes is that the platform owns the backend plumbing that should not be reimplemented every time.

When To Use Kizaki

Kizaki is a strong fit when you want:

• auth and authorization to be built in from day one
• a typed backend without hand-writing CRUD layers
• one workflow for browser apps, APIs, and background jobs
• schema changes that stay reviewable and safe
• deploys that follow the same product model as local development

It is especially effective when you want to move quickly without letting platform complexity become the main thing you are building.

Continue with the Quickstart to build and run your first app.