Ramose — the database optimized for humans and agents

The database optimized for humans and agents.

Right now those are two jobs: the app you shipped, and the MCP server, auth path, and permission model you bolt on beside it for agents. Ramose makes them one. Declare schema, operations, and policy once—your UI gets offline-first writes and local queries, your agents get one discoverable MCP endpoint, and both use the same capabilities.

Start in 15 minutes →See the MCP path

◆ Nothing to keep in sync◆ Works offline◆ No SQL to inject◆ Your Cloudflare account

schema.ts

const Project = Ramose.Entity("project", {
  slug: Ramose.Field.unique(Ramose.string(), "strict"),
})

TaskList.tsx

const tasks = useQuery(
  projectDb.query
    .from(Task)
    .where({ done: false }),
)

policy.ts

ProjectSchema.applyPolicy(
  { roles: ["member"] },
  ({ policy, session }) => {
    const isMember = session.hasRole("member")
    policy.task.read.where(isMember)
    policy.task.operations.setDone.where(isMember)
  },
)

agent.ts

const openTasks = await mcp.callTool({
  name: "query",
  arguments: {
    query: openTasksDocument,
  },
})

Typed clientLive queriesPermissionsMCP endpoint

Typed client

Type-safe reads and writes

Ask for a field that does not exist, or write the wrong shape, and TypeScript stops you before production does.

You getuseQuery(projectDb.query.from(Task))

Live queries

Every open view keeps itself current

The query is the subscription. Local writes render immediately, then every connected client converges without cache keys or refetch calls.

One queryTask.setDone({ done: true })

Permissions

One policy for every caller

Field-level rules are enforced by the Ramose server for your UI and your agents, so neither path can quietly see more than the other.

Enforced ruleTask.setDone → member only

MCP endpoint

Three tools understand your app

Agents discover visible entities and operations progressively, then query or mutate through the same model your application already uses.

Fixed toolsdescribe · query · mutate

1 / 4

01 — Instant by default

That snappy, no-spinner feel? You get it on day one.

The apps people call fast never wait on a round trip. Ramose gives you that architecture by default: writes commit to the local store and render immediately, sync catches up behind them, and every other client and agent converges on its own. Pull the plug; reads and writes keep working.

app.acme.dev/board/launch Live

ProductLaunch board AJM3 online

Backlog2

Write migration guideRAM-214 A

Billing statesRAM-219 M

In progress1

Polish onboardingRAM-221 A

Done1

✓ Connect authRAM-208 J

committed locally · 0.4 ms

sync · 38 ms

9:41● ◒ ▰

ProductLaunch boardA

My workAll

Write migration guideBacklog

Polish onboardingIn progress

✓Connect authDone

Up to date

01 You drop the card input

02 Local store commits 0.4 ms · no spinner

03 Sync fans out 38 ms, in the background

04 Every client converges no refetch, no cache keys

01 You drop the card input

02 — Agents

Everything a user can do an agent can do.

Ramose projects the capabilities already in your app through three MCP tools. Agents discover the catalog progressively, query visible data, and invoke the same named operations as your UI. No shadow database, glue server, or second authorization model to keep aligned.

codex — ~/launch-app mcp

›

•

Discovering the project model and allowed operations…

✓

ramose.describe{}

↳

Visible: Task · Task.setDone · Task.delete not exposed

✓

ramose.query{ done: false, assignee: "me" }

↳

3 open tasks on the launch board

✓

ramose.mutateTask.setDone { done: true } ×3

↳

3 receipts committed · policy allowed · same operation as the UI

●

Done — your launch tasks are complete.

app.acme.dev/board/launch Live

ProductLaunch board

AAssigned to me 3Done 1

Write release notesRAM-212 rcpt 4f2a A

Verify permissionsRAM-218 rcpt 7c15 A

Connect the agentRAM-223 rcpt b930 A

✓ Connect authRAM-204 · closed by Jules

Up to date no shadow database · one policy

01 describe catalog and what this caller may call

02 query reads only the fields policy exposes

03 mutate invokes your named operations · 3 receipts

01 describe catalog and what this caller may call

03 — History

Data is never lost.

Mistakes happen. A person clicks the wrong thing, an agent runs the wrong command, or a bug reaches production. Ramose keeps every committed version, so recovery is an elegant rewind instead of a restore drill. Move back to the moment before the mistake, verify the state, and continue.

Read about time travel →

app.acme.dev/issues Live

Product / LaunchIssue board Viewing now

Backlog0

Fix empty stateISS-12 restored

Remove old flagISS-18 restored

Archive launch notesISS-23 restored

✓Backlog cleared

In progress1

Polish onboardingISS-31

Done2

Connect authISS-04

Ship schemaISS-08

Now · after deletionevery committed version is queryable

Deleted 3 issues

12:40:4812:41:08Now

01 An agent clears the backlog 12:41:04 · committed

02 Scrub the history no restore drill

03 Read the state before it 12:40:52 · queryable

01 An agent clears the backlog 12:41:04 · committed

04 — Backends

Cloudflare today, your provider tomorrow

Ramose runs on Cloudflare today, but your application is defined against Ramose — not a provider console. AWS and self-hosted backends are planned behind the same schema, policy, sync, and MCP surface, so changing infrastructure does not mean rewriting the app.

See the deployment →

CloudflareWorkers · Durable Objects · R2 · Analytics Engine

Implemented

AWSLambda · DynamoDB · S3

Planned

Self-hostedYour compute · your object store · your network

Planned

Apache-2.0 · self-hosted · pre-release

Read the source. Run it in your own account.

One npm package, one Alchemy stack, no managed service in the path between your app and your data.

Quickstart →GitHub

bun add ramosebun alchemy devbun alchemy deploy

ramose.ai — the offline-first database your agents can callDocs · Mental model · Compare