A backend language where the worst case is known before it ships.

Write your routes, data, and rules in TypeScript. Aleph counts what every route can read, write, and compute, rejects what’s unbounded, and runs the rest on shared infrastructure.

Built for agents. Run on Rust.

aleph · app.ts

app.ts

accepted

a.route("GET /posts")
  .query({ cursor: t.cursor() })
  .handle((_, { query }) => {
    const page = Post.page({ limit: 20, after: query.cursor });
    return {
      next: page.cursor,
      posts: page.items.map((post) => ({
        post,
        comments: Comment.query({ prefix: [post.postId], limit: 5 }),
      })),
    };
  });

typical node + express

server.ts

accepted

app.get("/posts", async (req, res) => {
  const { rows: posts } = await db.query("SELECT * FROM posts");
  const out = [];
  for (const post of posts) {
    const { rows } = await db.query("SELECT * FROM comments WHERE post_id = $1", [post.id]);
    out.push({ post, comments: rows });
  }
  res.json(out);
});

two roads to production

General-purpose code steers around what can go wrong in production. Aleph rules it out and builds the rest into the road.

Why Aleph

Less flexibility, on purpose.

General-purpose languages let an app do anything. So every app needs its own isolated runtime, like a Lambda function, a Docker container, or a VPS, plus its own review and its own guardrails, and someone has to set up and maintain all of it.

Aleph makes the opposite trade. It gives up some flexibility for shared building blocks for what every backend needs, predictable behavior, and code that’s trusted by default. When agents write the code, that trade matters more than ever: a narrow language is easy to check and hard to get wrong. How Aleph programs work

Usage limits

Aleph knows what your code can use before it runs

Aleph code is declarative. A route isn’t a program that can do anything. It’s a fixed plan of queries, loops, and writes, each with a known maximum size. So Aleph can count, before a single request runs, the most work any piece of logic can ever do: the rows it reads, the rows it writes, the operations it runs, and the memory it uses.

CountedEvery route, trigger, and job gets its worst-case usage, computed from its code.
CheckedCode that could use too much, like a query that reads too many rows or a loop with no end, doesn’t build. A meter enforces the same limits while it runs.
SharedNo app can take the CPU, memory, or database that other apps need, so many apps can run safely in one process, on one database.
CheaperServers and databases aren’t set aside for each app and left idle, so each app costs far less to run.

worst case of every route

app.ts

a.route("GET /posts")
  .query({ cursor: t.cursor() })
  .handle((_, { query }) => {
    const page = Post.page({ limit: 20, after: query.cursor });
    return {
      next: page.cursor,
      posts: page.items.map((post) => ({
        post,
        comments: Comment.query({ prefix: [post.postId], limit: 5 }),
      })),
    };
  });

$ aleph check app.ts

✔ valid. The most each route and handler can use in one run:

route reads writes ops bytes read effects calls memory

limit 250 50 2,000 2 MB 50 3 8 MB

add_comment 1 <1% 1 2% 8 <1% 3.5 KB <1% 1 2% 0 – 14.2 KB <1%

create_post 1 <1% 1 2% 489 24% 3.1 KB <1% 0 – 0 – 138.0 KB 2%

get_posts 120 48% 0 – 192 10% 416.1 KB 20% 0 – 0 – 3.02 MB 38%

$ aleph check app.ts

✔ valid. The most each route and handler can use in one run:

route reads writes ops bytes read effects calls memory

limit 250 50 2,000 2 MB 50 3 8 MB

add_comment 1 <1% 1 2% 8 <1% 3.5 KB <1% 1 2% 0 – 14.2 KB <1%

create_post 1 <1% 1 2% 489 24% 3.1 KB <1% 0 – 0 – 138.0 KB 2%

get_posts 120 48% 0 – 192 10% 416.1 KB 20% 0 – 0 – 3.02 MB 38%

A page of 20 posts, 5 comments each, and a cursor for the next page: at most 120 reads. Ask for 10,000 at once and it won't build.

Guardrails

No query can read too much

Every query has a limit, and Aleph multiplies them out: a page of 20 posts with 5 comments each is at most 120 reads, before a single request runs.

So the natural way to return a long list is the right one: a page and a cursor. Ask for everything at once and it’s rejected before it ships, with the line to change. The same limits are enforced while it runs, so a limit is a guarantee, not a guess.

a loop inside a loop

app.ts

a.route("POST /posts")
  .id("create_post")
  .body({
    title: t.string().min(1).max(200),
    tags: t.array(t.string().max(32), 100),
  })
  .status(201)
  .handle((_, { body }) =>
    Post.insert({
      title: body.title,
      tags: body.tags.filter((tag) =>
        body.tags.filter((other) => other.eq(tag)).length.eq(1)),
    }));

$ aleph check app.ts

✖ over_budget at app.ts:44:4 (routes[1].plan)

route "create_post" can use up to 40809 ops in the worst case, over the limit of 2000. Lower the bounds that drive it (query limits, list sizes) or split the work.

2 problems

Comparing every tag with every other: 10 tags is 489 ops. Allow 100 and it's 40,809, over the limit of 2,000.

Guardrails

No loop can run away

There’s no unbounded while loop and no recursion. Every loop runs over a list with a known maximum size, or declares its own maximum, so even a loop inside a loop has a worst case Aleph can count.

That’s why one app can’t burn the CPU that other apps share: code that could doesn’t build.

more than routes

app.ts

import { app, t } from "@aleph-lang/sdk";
 
const a = app("blog"); // the app everything is declared on
 
const Post = a.entity("Post", {
  key: ["postId"],
  fields: {
    postId: t.id().generated(),
    title: t.string().min(1).max(200),
    tags: t.array(t.string().max(32), 10),
  },
});
 
const Comment = a.entity("Comment", {
  key: ["postId", "commentId"],
  fields: {
    postId: t.string().max(26),
    commentId: t.id().generated(),
    authorId: t.string().max(64),
    text: t.string().min(1).max(500),
  },
});
 
a.route("GET /posts")
  .query({ cursor: t.cursor() })
  .handle((_, { query }) => {
    const page = Post.page({ limit: 20, after: query.cursor });
    return {
      next: page.cursor,
      posts: page.items.map((post) => ({
        post,
        comments: Comment.query({ prefix: [post.postId], limit: 5 }),
      })),
    };
  });
 
a.route("POST /posts")
  .id("create_post")
  .body({
    title: t.string().min(1).max(200),
    tags: t.array(t.string().max(32), 10),
  })
  .status(201)
  .handle((_, { body }) =>
    Post.insert({
      title: body.title,
      tags: body.tags.filter((tag) =>
        body.tags.filter((other) => other.eq(tag)).length.eq(1)),
    }));
 
a.route("POST /posts/:postId/comments")
  .id("add_comment")
  .params({ postId: t.string().max(26) })
  .body({ text: t.string().min(1).max(500) })
  .status(201)
  .handle(($, { params, body }) =>
    Comment.insert({
      postId: params.postId,
      authorId: $.caller,
      text: body.text.trim(),
    }));
 
// An external HTTP API. "call" waits for the answer.
// Each call counts toward the limit.
const moderation = a.integration("moderation", {
  provider: "http",
  operations: {
    check: {
      mode: "call",
      input: { text: t.string().max(500) },
      output: { spam: t.bool() },
    },
  },
});
 
// Email. "effect" is sent after commit,
// exactly once.
const email = a.integration("email", {
  provider: "email",
  operations: {
    send: {
      mode: "effect",
      input: { to: t.string().max(200), subject: t.string().max(200) },
    },
  },
});
 
// A live channel that clients subscribe to, per post.
const live = a.channel("comments", {
  key: { postId: t.string().max(26) },
  message: { text: t.string().max(500) },
});
 
// A trigger: runs after each new comment commits,
// in the background. The request doesn't wait.
a.onInsert("moderate", Comment, ($, { payload }) => {
  const comment = payload.after;
  const verdict = moderation.call("check", { text: comment.text });
  // Delete spam; push everything else live.
  $.if(verdict.spam)
    .then(() => comment.delete())
    .else(() =>
      live.publish({ postId: comment.postId }, { text: comment.text }));
});
 
// A schedule: every Monday at 09:00.
a.every("weeklyDigest", "mon 09:00", ($) => {
  const posts = Post.query({ limit: 10, order: "desc" });
  email.send("send", {
    to: "readers@example.com",
    subject: $.fmt`${posts.length} new posts`,
  });
});
 
export default a;

import { app, t } from "@aleph-lang/sdk";
 
const a = app("blog"); // the app everything is declared on
 
const Post = a.entity("Post", {
  key: ["postId"],
  fields: {
    postId: t.id().generated(),
    title: t.string().min(1).max(200),
    tags: t.array(t.string().max(32), 10),
  },
});
 
const Comment = a.entity("Comment", {
  key: ["postId", "commentId"],
  fields: {
    postId: t.string().max(26),
    commentId: t.id().generated(),
    authorId: t.string().max(64),
    text: t.string().min(1).max(500),
  },
});
 
a.route("GET /posts")
  .query({ cursor: t.cursor() })
  .handle((_, { query }) => {
    const page = Post.page({ limit: 20, after: query.cursor });
    return {
      next: page.cursor,
      posts: page.items.map((post) => ({
        post,
        comments: Comment.query({ prefix: [post.postId], limit: 5 }),
      })),
    };
  });
 
a.route("POST /posts")
  .id("create_post")
  .body({
    title: t.string().min(1).max(200),
    tags: t.array(t.string().max(32), 10),
  })
  .status(201)
  .handle((_, { body }) =>
    Post.insert({
      title: body.title,
      tags: body.tags.filter((tag) =>
        body.tags.filter((other) => other.eq(tag)).length.eq(1)),
    }));
 
a.route("POST /posts/:postId/comments")
  .id("add_comment")
  .params({ postId: t.string().max(26) })
  .body({ text: t.string().min(1).max(500) })
  .status(201)
  .handle(($, { params, body }) =>
    Comment.insert({
      postId: params.postId,
      authorId: $.caller,
      text: body.text.trim(),
    }));
 
// An external HTTP API. "call" waits for the answer.
// Each call counts toward the limit.
const moderation = a.integration("moderation", {
  provider: "http",
  operations: {
    check: {
      mode: "call",
      input: { text: t.string().max(500) },
      output: { spam: t.bool() },
    },
  },
});
 
// Email. "effect" is sent after commit,
// exactly once.
const email = a.integration("email", {
  provider: "email",
  operations: {
    send: {
      mode: "effect",
      input: { to: t.string().max(200), subject: t.string().max(200) },
    },
  },
});
 
// A live channel that clients subscribe to, per post.
const live = a.channel("comments", {
  key: { postId: t.string().max(26) },
  message: { text: t.string().max(500) },
});
 
// A trigger: runs after each new comment commits,
// in the background. The request doesn't wait.
a.onInsert("moderate", Comment, ($, { payload }) => {
  const comment = payload.after;
  const verdict = moderation.call("check", { text: comment.text });
  // Delete spam; push everything else live.
  $.if(verdict.spam)
    .then(() => comment.delete())
    .else(() =>
      live.publish({ postId: comment.postId }, { text: comment.text }));
});
 
// A schedule: every Monday at 09:00.
a.every("weeklyDigest", "mon 09:00", ($) => {
  const posts = Post.query({ limit: 10, order: "desc" });
  email.send("send", {
    to: "readers@example.com",
    subject: $.fmt`${posts.length} new posts`,
  });
});
 
export default a;

$ aleph check app.ts

✔ valid. The most each route and handler can use in one run:

handler reads writes ops bytes read effects calls memory

limit 500 200 5,000 8 MB 200 5 32 MB

moderate 1 <1% 1 <1% 14 <1% 3.5 KB <1% 1 <1% 1 20% 13.6 KB <1%

weeklyDigest 10 2% 0 – 11 <1% 31.4 KB <1% 1 <1% 0 – 64.2 KB <1%

$ aleph check app.ts

✔ valid. The most each route and handler can use in one run:

handler reads writes ops bytes read effects calls memory

limit 500 200 5,000 8 MB 200 5 32 MB

moderate 1 <1% 1 <1% 14 <1% 3.5 KB <1% 1 <1% 1 20% 13.6 KB <1%

weeklyDigest 10 2% 0 – 11 <1% 31.4 KB <1% 1 <1% 0 – 64.2 KB <1%

An HTTP API, email, a live channel, a trigger, and a weekly schedule, all in the same app.ts, each with a worst case.

Still flexible

Bounded, not basic

The limits are on usage, not on what you can build. Beyond routes and queries, the same language calls external APIs, reacts to changes, pushes updates to clients in real time, sends email, and runs schedules, queues, webhooks, and multi-step workflows that can wait for days.

Every one of them is checked the same way: triggers and schedules get a worst-case usage, and their effects go out only after they commit.

How Aleph programs work: how state is managed, what the usage limits count, and what the language leaves out.

from app.ts to production

The manifest is the only thing that ships. Everything else is derived from it.

How it works

You write the logic. The platform runs it.

Describe your app in TypeScript. Routes, who can call them, the data, and the queries. No server, ORM, or auth library to set up.
Aleph compiles it into a manifest. Data, not code: exactly what each route can do, and the most it can ever use.
A platform runs the manifest. One small, open-source core interprets it, so your code never runs in production.

Because of those guardrails, many apps can run in the same process and share the same database, and a platform pays for capacity once instead of once per app.

Advantages

What the trade buys you

many apps, one runtime

Each request stays under its own ceiling, so no app can slow down the rest.

one database, many apps

Every key is built inside the app's own prefix. Plans never see raw keys.

Safe to share, so cheap to run

A backend usually gets its own isolated runtime (a Lambda, a container, or a VPS), its own database, and its own cache, sized for its busiest hour and idle the rest of the day. It needs them to itself because, in a shared setup, one runaway query or one bug can hurt everyone.

Aleph rules both out. It counts what every route can use and refuses any that could take more than its share, and there’s no expression that names another app’s data, so cross-app access can’t be written at all. Apps can safely share servers and a database, and you stop paying for idle capacity.

That changes the price, too. A platform doesn’t have to set aside servers and a database for every app it hosts, so it can offer apps built with Aleph much better pricing than a dedicated deployment. How sharing works

one manifest, any runtime

TypeScript is only how you write the app. What ships is a manifest, and any engine that reads it can run it.

Write TypeScript, run on Rust.

Your TypeScript never runs in production. It compiles to a manifest, and the manifest doesn’t care what executes it. Today that’s aleph-core, a small engine written in Rust.

So you get the Rust runtime’s benefits without writing Rust: no garbage-collection pauses or JIT warm-up, steady latency under load, and memory that stays small enough to pack thousands of apps into one process. A new version of your app is a manifest loaded in milliseconds, not a container booting, so there are no cold starts.

The same core runs as WebAssembly in the CLI and in aleph dev, so what you test locally is exactly what runs in production. And because the manifest is an open spec, a platform can swap in a faster engine, or a different language, without you changing a line. Running Aleph

every request is one transaction

Effects are queued inside the transaction and sent only after it commits.

Correct by default

Every request runs as one serializable transaction. Events, emails, and jobs go out exactly once, and only after it commits.

There are no half-written states to clean up, no retry logic to write, and no message that was sent for a change that never happened.

compare with what's deployed

app.ts

const Comment = a.entity("Comment", {
  key: ["postId", "commentId"],
  fields: {
    postId: t.string().max(26),
    commentId: t.id().generated(),
    authorId: t.string().max(64),
    text: t.string().min(1).max(200),
    likes: t.int().min(0).default(0),
  },
});

$ aleph check app.ts --against deployed.json

✖ entities.Comment.fields.text: string length 1-500 narrowed to 1-200; existing values may not fit

✔ entities.Comment.fields.likes: new field likes

✖ not deployable: breaking changes need a deprecation in the deployed manifest first

Narrowing a field could break stored rows, so it's blocked. Adding one is fine.

Change it without fear

Every schema change is compared with what’s deployed and classified as safe, needing a backfill, or breaking. Breaking changes are blocked until they’re deprecated properly, whoever wrote them.

Additive changes ship right away. Anything that could break data already stored waits for a proper deprecation, so stored rows always fit the schema.

an agent at work

app.ts

a.route("GET /posts")
  .query({ cursor: t.cursor() })
  .handle((_, { query }) => {
    const page = Post.page({ limit: 20, after: query.cursor });
    return {
      next: page.cursor,
      posts: page.items.map((post) => ({
        post,
        comments: Comment.query({ prefix: [post.postId], limit: 10 }),
      })),
    };
  });

you ▸ Show every comment under each post.

$ aleph check app.ts

✖ over_budget at app.ts:26:4 (routes[0].plan)

route "get_posts" can use up to 20020 reads in the worst case, over the limit of 250. Lower the bounds that drive it (query limits, list sizes) or split the work.

3 problems

agent ▸ 20 posts × 1000 comments is over the read limit of 250. Showing 10 per post; the full thread can page in on demand.

$ aleph check app.ts

✔ valid. The most each route and handler can use in one run:

route reads writes ops bytes read effects calls memory

limit 250 50 2,000 2 MB 50 3 8 MB

get_posts 220 88% 0 – 192 10% 769.6 KB 38% 0 – 0 – 5.05 MB 63%

The error names the route, the line, and the bound to lower. The agent does the rest.

Built for agents

A small, typed vocabulary means there are no architecture, infrastructure, or library choices for an agent to get wrong.

When it does slip, the checker names the route, the line, and the bound, so the agent fixes its own mistake before anyone reviews it.

Build a first app in five minutes

Write one file, check it, test it, and serve it locally.

Start the quickstart How Aleph programs work