feltkit
Get started
THE APPLICATION PLATFORM FOR DEVELOPERS AND AGENTS

Build the application.FeltKit bringseverything around it.

Write your data, queries, and mutations in TypeScript. FeltKit gives you the database, a typed API with live queries, roles enforced on the server, eight built-in services, agent access over MCP, a dashboard, and a build you can deploy three ways—already wired together.

npm create feltkit@latest my-app
Get startedSee the code
Live queries Atomic mutations 8 built-in services Agents via MCP
FeltKit Studio: records, functions, capabilities, services, where FeltDB state lives, and recent activity.
Studio, included in every app: records, capabilities, services, agent actions, and every operation that ran—who ran it and what FeltDB committed.

WHAT’S IN A NEW FELTKIT APP

Everything a real application needs. Already wired.

Each piece below is in the starter you get from npm create feltkit—running, tested, and sharing one FeltDB instance. Nothing to assemble, no glue code to maintain.

Typed functions

Queries and mutations in TypeScript, validated against your schemas. A generated, typed client calls them from React.

feltkit/*.ts

Live queries

useQuery re-runs when data it read changes—whoever changed it: another person, an agent, or a background job.

useQuery · useMutation

Roles, enforced on the server

Declare roles and permissions once. Every caller—your UI, the HTTP API, AppPort, MCP, services—is checked the same way.

roles: { member: [...] }

Eight built-in services

Files, notifications, configuration, API keys, webhooks, jobs, schedules, and model selection—on your app’s own database.

services: { … }

Agents, with approvals

Agents use your app over MCP under a role, like people do. Consequential actions wait for approval—in production, from someone other than who proposed them.

/mcp · /appport

Studio

A dashboard for data, capabilities, services, models, and activity. In production, operators sign in with one-time grants.

/_feltkit/

Tests on real state

createTestApp gives every test a fresh FeltDB instance—no mocks. Act as any user and assert what the server allows.

npm test

Deploy three ways

One container, Managed FeltDB, or your own FeltDB server. The build is verified before it is packaged.

feltkit deploy

THE PROGRAMMING MODEL

Your backend is a folder of TypeScript.

Declare the application, its roles, and its data. Write queries and mutations. FeltKit serves them over HTTP, keeps React components live, and—when you add a capability—publishes them to agents and other applications.

  • Edit and it reloads. The backend reloads in place; state, sessions, and history are kept.
  • One source of truth. Functions, services, sessions, and the activity log all use the same FeltDB instance.
  • Errors with stable codes. fail(code, message) returns a structured error your UI and agents can act on.
Try it in four commands
import { feltkit, s } from "@feltdb/feltkit";

export const app = feltkit({
  name: "tasks",
  // Roles grant permissions. The server checks them on every call.
  roles: {
    member: ["tasks.*", "files.*"],
    viewer: ["tasks.read"],
    agent: ["tasks.read", "tasks.complete"],
  },
  // Built-in services, on this app's own FeltDB instance.
  services: { files: true, notifications: true, jobs: true },
});

export const tasks = app.collection("tasks", {
  title: s.string({ minLength: 1 }),
  done: s.boolean(),
  createdAt: s.number(),
});

Collections are FeltDB documents. Every write through ctx.db is validated against the schema.

BUILT FOR DEVELOPERS AND AGENTS

Agents use the front door.

Mark a function as a capability and it is published through AppPort and as an MCP tool. Agents call it with a session and a role—through the same authorization, validation, and evidence as everyone else.

Building with a coding agent? npx feltkit skills install gives it FeltKit's own instructions for writing functions, services, and deployments.

Developers remain in control. Agents do more of the work inside clear, inspectable boundaries.

AGENT SESSION · ROLE agenttasks / mcp
tasks.complete
Connect over MCP01

An agent session holds a role. Your capabilities appear to the agent as tools: feltkit session create --type agent.

Act within its role02

Every call is authorized by the same policy as a person’s: what the role does not grant, the server refuses.

Propose, then act03

Consequential actions wait for approval. In production, the proposer cannot approve their own action.

Leave evidence04

Each call is recorded with who made it, what it asked, and what FeltDB committed—visible in Studio.

Recover without repeating05

An action a crash left open is settled from evidence when the app restarts. It is never run twice.

Every call in Studio → ActivityAuthorized like a person

THE SYSTEM BENEATH FELTKIT

Three systems. Real contracts.

FeltKit uses FeltDB, AppPort, and AppPort Services through their actual package contracts. They remain distinct systems, composed into one application workflow.

BUILT ONFeltDB

You never configure them separately. Each system keeps its own responsibility while FeltKit connects them for your application—and all three packages are public on npm.

See how the pieces fit together
APPLICATION PRODUCTION AND OPERATIONSFeltKit
COORDINATES THE LIFECYCLE
The three existing systems FeltKit uses through their real package contracts
LayerPackageWhat it does in FeltKit
State@feltdb/coreThe one durable source of truth for each environment.
Capabilities@appport/sdkPublishes, authorizes, and dispatches capabilities for apps and agents.
Services@appport/servicesEight reusable services—files, notifications, configuration, API keys, webhooks, jobs, schedules, model selection—authorized and evidenced.

One FeltDB instance per environment. Your functions, AppPort capabilities, AppPort Services, sessions, and the activity log all use that same FeltDB instance—and a test proves it, rather than assuming it.

FROM GENERATED CODE TO A WORKING SYSTEM

Compilation is a milestone. Not proof.

A working application must satisfy its contracts, use dependencies correctly, preserve state, enforce access rules, and run in its intended environment.

01

Define

Data, functions, roles, and capabilities in feltkit/.

npm run dev
02

Inspect

State, capabilities, services, and recent activity.

npx feltkit inspect
03

Exercise

Real functionality, persistence, and access rules—each test on fresh state.

npm test
04

Deploy

A verified build, packaged for the target you choose.

npx feltkit deploy
05

Improve

Readiness checks and evidence from what actually ran.

npx feltkit readiness

Deploy boots the production build against throwaway state and checks it answers before it writes anything. The same application code moves through every step; deployment selects a target, not a different codebase.

CHOOSE WHERE YOUR APPLICATION RUNS

One codebase. Three ways to run it.

npx feltkit deploy builds your app, proves the build boots, and writes a ready-to-run artifact: a Dockerfile, docker-compose.yml, fly.toml, an .env.example with exactly the variables it needs, and a DEPLOY.md for the target you chose.

01

SIMPLEST

One container

The app and its FeltDB state together, state on a volume. Nothing to provision; runs anywhere Docker or Node runs.

--target container
02

LESS TO OPERATE

Managed FeltDB

A stateless app container, any number of them. Data in Managed FeltDB, created from the contract the build writes.

--target hosted
03

YOUR INFRASTRUCTURE

Your FeltDB server

A stateless app container; data on a FeltDB server you run, in the app’s own namespace, with a key scoped to it.

--target self-hosted

A deployment never silently changes where your data lives. The container target refuses a database URL. The other two refuse to start without theirs, and check that the database answers—with this key and this contract—before serving a single request. Each DEPLOY.md spells out the target's secrets, recovery, upgrades, and rollback. (The self-hosted target and these startup checks arrive in FeltKit 0.3.3.)

QUICKSTART

Four commands to a running app.

Create a project, install it, and start the development server. You get a real application—not a hello world—with every system already connected through its real contract.

  • A working appA task manager with projects, notes, and notifications. Sign in as a development user and use it.
  • Studio, signed inOpen the Dashboard link to see records, capabilities, services, and every operation that ran.
  • Roles you can feelSwitch to the viewer and the write controls disappear—the server would refuse those calls anyway.
  • Edit, and it reloadsChange feltkit/tasks.ts. The backend reloads in place; state and sessions are kept.
Quickstart
npm create feltkit@latest my-appcd my-appnpm installnpm run dev
npm run dev prints
App
http://localhost:3000
Dashboard
http://localhost:3000/_feltkit/#token=fka_…
AppPort
http://localhost:3000/appport (5 capabilities)
MCP
http://localhost:3000/mcp
State
.feltkit/development/state (FeltDB, local)
Functions
14 from feltkit/ collections: projects, tasks

Needs Node 20 or later. Then npm test runs the starter's tests against a fresh FeltDB instance, and npx feltkit deploy builds it for production.

See the code you'll edit@feltdb/feltkit on npm

FeltKit is pre-1.0 and moving quickly: read the changelog before you upgrade a minor version.