Your Backend.
Inside Your App.

Build full-stack applications without provisioning a separate backend server.

Yatta gives your application a built-in backend runtime with database, authentication, mail, storage, APIs, background jobs, realtime communication, and built-in observability.

Embedded Database•Authentication•File Storage•Realtime•Background Jobs•Authorization•Embedded cache•Events•CLI•More•Backups•Queues•Huge List•
Embedded Database•Authentication•File Storage•Realtime•Background Jobs•Authorization•Embedded cache•Events•CLI•More•Backups•Queues•Huge List•
Yatta
YATTA.JS01 / 04
The Runtime

What is
Yatta.js?

A backend that lives inside your application.

Yatta handles the backend work so you can focus on building the things that matter. Less infrastructure. Less boilerplate. More application.

Philosophy

Yatta.js is designed to make backend development feel natural — giving you powerful primitives and useful features without forcing you to manage unnecessary complexity.

Built on BunJS / TS → Zig / WASM
YATTA.JS / ARCHITECTURE

Everything
inside Yatta.

The entire backend stack — database, auth, storage, realtime, jobs, mail, and observability — embedded inside your application runtime.

Yatta Performance Feature
01

Bun Native by Design

Built directly on Bun’s C and Zig primitives — bun:sqlite with WAL mode, Bun.password Argon2id, and native WebSockets for maximum throughput.

Capabilities↗
YATTAcore
DB
AUTH
STORAGE
REALTIME
JOBS
CACHE
02

Everything in One Runtime

Relational DB, Auth with Passkeys & MFA, S3/Local Storage, Realtime WebSockets, Durable Queues, and Mail — unified in a single process.

Capabilities↗
bun — yatta runtime

$ bun run src/server.ts

✓ [db] SQLite WAL initialized (app.db)

✓ [jobs] Worker pool active (concurrency: 5)

✓ [realtime] Native WebSockets & SSE ready

→ running at http://localhost:4000 (9ms)

03

Instant Startup & Zero Bloat

No Docker orchestration or external broker services needed to get started. Boots in under 10ms with zero runtime overhead.

Capabilities↗
01 import { DB, API } from "yatta";
02
03 export default API("/users/[id]")
04 .get(async (ctx) => {
05 const user = await DB.users.findById(ctx.params.id);
06 return API.json(user);
07 });
// Full autocomplete without code generation
04

Zero-Codegen Type Safety

100% end-to-end schema autocompletion via ambient declaration merging. No Prisma CLI or slow build-step generation required.

Capabilities↗
Yatta Performance Feature
05

English-Language Fluent DSL

Expressive, natural APIs like DB.users.where(), Storage.file().serve(req), and Mail.to().deliver() that read like spoken English.

Capabilities↗
YATTAcore
DB
AUTH
STORAGE
REALTIME
JOBS
CACHE
06

Zero-Config Observability

Auto-instrumented observability for your yatta applications. Distributed tracing, auto-correlated logs, request and job metrics — out of the box.

Capabilities↗
Bun Core
→
Yatta Engine
→
Your App
Argon2idSQLite WALRFC 9110
07

Hardened Enterprise Security

Token Family replay defense, AES-256-GCM at rest, RFC 9110 HTTP 206 streaming, and non-destructive magic-byte verification.

Capabilities↗

Backend infrastructure should feel like part of your application, not an independent cloud you have to stitch together.

YATTA / 001

Yatta Observe

See everything.
Instrument nothing.

Say goodbye to manual span wiring and blind spots. With Yatta Observe you get request tracing across every service, logs correlated to the request that wrote them, and errors grouped into defects with the source line that threw and the users they happened to.

Everything is instrumented by attaching your subsystems once. No sidecar, no agent, no vendor SDK, no calls to add.

Tracing

Follow every request

Every inbound request becomes a trace that follows the work it caused — through your database, your cache, your queues and your dependencies.

4 of 6 shipped

01Trace requests end to end

Shipped

Trace every request across services, jobs and dependencies to see exactly where time is spent and where things go wrong.

02Zero-touch instrumentation

Shipped

Attach your subsystems once and every query, login and job execution is traced. No manual span wiring at any call site.

03Find the real bottleneck

Shipped

See every step of a request with self time and total time per span, so you know exactly where latency comes from.

04CPU profiles with self time

Planned

Profile any region with the V8 inspector and read self time per function, down to the file and line that held the CPU.

05Server-Timing headers

Shipped

Every response carries where its time went in a standard header your browser devtools already understand.

06Turn a trace into a prompt

Planned

Turn a failing trace into a self-contained prompt — or connect your coding agent directly via MCP, with the stack, source, timings and logs it needs.

Errors

Turn errors into action

Identical failures collapse into a single defect, so you fix the bug rather than sorting through thousands of occurrences.

3 of 7 shipped

01Group errors into defects

Shipped

Automatically group identical failures into one issue, keyed by a normalized message and the top application frame.

02Errors with source code

Shipped

See the failing file and line, the full stack, and the breadcrumbs that led there — without checking out the build yourself.

03Users and requests affected

Planned

Every issue carries the users and requests it happened to, so you can tell a one-off from an outage.

04Logs in context

Shipped

See every log line exactly where it happened in the trace, automatically connected to the request or job that produced it.

05Real user monitoring

Planned

Collect page timings and navigation data from the browser, joined to the server trace by trace id.

06Know when a fix fails

Planned

Track which release introduced a defect and automatically reopen resolved issues when the same failure comes back.

07Turn findings into issues

Planned

Turn any error, trace, request or job into an actionable issue with severity, ownership, due dates, comments and a complete activity history.

Jobs & runtime

Keep background work healthy

The work nobody is watching is the work that fails quietly. Yatta reports on it alongside your request traffic.

5 of 6 shipped

01Keep background jobs healthy

Shipped

Track queue wait time, retries and failures alongside your requests, with alerts when a backlog starts growing before it becomes an incident.

02See what your runtime is doing

Shipped

Monitor CPU, memory and event-loop delay per process, with automatic detection when one instance starts carrying the load.

03Understand your product flows

Shipped

See how requests move through your application and where failures happen, so you can spot the exact path that leads to a problem.

04One dashboard, no setup

Shipped

A trace waterfall, stack inspection and live refresh ship with the framework. No agent to install, no pipeline to build.

05See health per customer

Planned

Scope issues to the users they affect, so one noisy account does not read as one widespread outage.

06Measure every release

Shipped

Compare releases by error rate, p50/p95/p99 and slow queries, plus which error fingerprints each one introduced or fixed.

Reliability

Reliability, under control

Turn raw telemetry into a signal someone can act on, rather than a dashboard nobody reads.

2 of 5 shipped

01Know before customers do

Planned

Alert on error-budget burn rate instead of isolated spikes, so fast-moving incidents and slow degradation surface before they page anyone.

02Set reliability goals

Shipped

Define SLOs per route and method with a rolling error budget and burn rate. Too little traffic reports no-data instead of a verdict.

03Catch reliability drift early

Shipped

Adaptive baselines catch drift against each metric's own history, using median and MAD so one stall cannot hide the event.

04Know when things go quiet

Planned

Detect silent failures automatically — from an application that stops receiving traffic to a cron job that never runs.

05Alerts that catch silence

Planned

Alert on errors, anomalies, SLO burn, log patterns, or things that stop happening — with notifications through email, Slack, webhooks, or issues.

Analysis

Answer what changed, and why

Correlation engines over the telemetry you already record — each one reporting what it cannot see, and refusing to guess when the data runs out.

15 of 20 shipped

01Incident correlation

Shipped

Correlates the failing trace, its slow queries, release proximity and rule-outs into ranked suspects with an ordered timeline.

02Evidence, not verdicts

Shipped

Every claim carries the evidence behind it and the reasons it could be wrong. Gaps are reported as Unknown rather than smoothed over.

03It knows when it does not know

Shipped

Too few samples for a baseline, a metric with no observed variance, a first release with nothing to compare — each declines instead of guessing.

04What changed?

Shipped

Compares the running release against the previous one: signed deltas, new error fingerprints, and which failures stopped.

05Release health

Shipped

Per-release errors, p50/p95/p99, slow queries and affected routes, with a verdict derived from a real comparison rather than assumed.

06N+1 query detection

Shipped

Finds identical queries repeated under one parent — the N+1 shape specifically — and estimates the avoidable cost.

07Adaptive baselines

Shipped

Per-query slow thresholds derived from each query's own rolling p95, so a table that normally takes 400ms is no longer all flagged.

08SLOs and error budgets

Shipped

Availability, remaining budget and burn rate per objective. A 5xx counts against availability; a 4xx does not.

09Memory growth detection

Shipped

Least-squares trend with fit quality. A weak fit is reported as noise rather than called a leak.

10Golden traces

Shipped

Mark a known-good run, then see exactly which step got slower, appeared or vanished in a later trace.

11Dependency map

Shipped

A call graph inferred from spans, with the limitations stated on the result rather than left to be discovered.

12Guarded actions

Shipped

Destructive operations are previewed, confirmed, and need an idempotency key so a double-click cannot purge twice.

13Incident reports for AI

Shipped

A self-contained JSON payload with evidence, caveats and timeline — designed for a model or a colleague with no access to your process.

14Trace to code

Shipped

Jump from a stack frame to the source line, with a resolver you opt into. Production bundles ship no sources, and it says so.

15Command palette

Shipped

Cmd/Ctrl-K to jump to a view, open a trace by id, export an incident, or save a golden baseline.

16Multi-node fleet aggregation

Planned

Each cluster worker has its own observer. No leader aggregation yet — the dashboard shows one process.

17SQLite persistence for incidents

Planned

Issues and transactions vanish on restart today. Persisting them needs retention and rotation.

18Alerting rules

Planned

Error-rate spikes, p95 thresholds, blocked event loops, heap growth, with dedupe windows and quiet hours.

19Outbound HTTP instrumentation

Planned

Tracing inbound but not outbound is the missing half of distributed tracing. Needed before the dependency map shows external services.

20Tail sampling

Planned

Keep 100% of error and slow traces while sampling fast successes. The span tree is already there to make the decision.

Metrics & cost

Metrics that fit your business

The same registry serves the built-in signals and whatever you choose to measure yourself.

1 of 3 shipped

01Measure what matters to you

Shipped

Track custom counters, gauges and histograms — from orders processed to queue depth — through the metrics registry, alongside built-in metrics.

02Prometheus exposition, built in

Planned

Your registry is already served in text exposition format at /_yatta/metrics. Point a scraper at it and nothing else changes.

03Keep observability costs under control

Planned

Sampling is the honest gap: tracesSampleRate is accepted and validated, but no head-sampling decision is made yet, so every span is recorded. Everything is in-process and nothing is ingested anywhere.

Observability that starts itself, so you can spend the time on the failures instead of on the wiring.

Read the docs↗
YATTA.JS / PHILOSOPHY

Why
Yatta?

Modern application development often means assembling and paying for six independent cloud services before writing a single line of business logic.

Yatta takes a radically different approach: engineered natively on Bun, the database, auth, storage, realtime, and queues compile directly into your application process with zero external brokers.

01SQLite WAL Engine
02Passkeys & MFA Auth
03RFC 9110 Storage
04Typed File Routing
05Native WebSockets
06Durable Job Queues
07Multi-Tier SWR Cache
08Transactional Mailer
THE DIFFERENCE

Install the backend
instead of provisioning it.

terminalTS
$ bun add yatta

# boots SQLite WAL, Passkeys, S3 storage, and queues
✓ [yatta-db] SQLite WAL initialized
✓ [yatta-jobs] Worker pool active
✓ [realtime] Native WebSockets & SSE ready
→ Server ready in 9ms

Your application gets all required production infrastructure embedded directly inside the native Bun runtime.

No external Redis, Postgres, or Kafka broker instances required.
Zero cold-start delay — initializes in under 10ms.
Full data ownership on local NVMe or edge disks.
Seamless S3/R2 switch when you need object scale.
ARCHITECTURE

Where the
backend lives.

Traditional (Microservice Cloud)
Application
Network Hop / RPC
CLOUD DB
EXT AUTH
S3 BUCKET
WS GATEWAY
Yatta (In-Process Runtime)
Your Application
Bun Process · Zero Network Latency
DB (WAL)0
AUTH1
STORAGE2
REALTIME3
THE FUNDAMENTAL DIFFERENCE

The backend becomes part of your application’s memory space and process boundary instead of an array of remote network hops.

ONE RUNTIME

One installation.
One runtime.

Instead of stitching together multiple infrastructure products, your application operates as a coherent, self-contained system.

Unified Subsystem Stack
API (File Router)07
Realtime (WS & SSE)06
Jobs & Queue05
Multi-Tier Cache04
Storage (S3/Local)03
Auth & Passkeys02
Database (SQLite WAL)01
Single Process
Self-Hosting
Local Dev First
Data Ownership
Offline Ready
Bun Native
COHESIVE PLATFORM

The database is
only the beginning.

single bun process
Embedded Yatta Corelocal runtime
DB (WAL)
AUTH
STORAGE
REALTIME
JOBS
CACHE
MAIL
ROUTER

Yatta is not simply an embedded database with an API wrapper around it.

The database, authentication tokens, file storage, realtime WebSockets, and background queues share the same memory space, same lifecycle, and same TypeScript declaration registry.

DEVELOPER EXPERIENCE

The infrastructure
should disappear.

database & apiTS
import { DB, API } from "yatta";

export default API("/users")
  .get(async () => {
    return DB.users.where(f => f.email.endsWith("@yatta.local")).all();
  });
authentication & passkeysTS
import { auth } from "yatta";

const result = await auth.signIn({
  email,
  password,
  req
});

// Returns session, JWT, Argon2id & MFA tokens
storage & rfc 9110 partial streamingTS
import { Storage, API } from "yatta";

export default API("/media/[name]")
  .get((ctx) => {
    // Smart HTTP 206 Partial Content & 304 caching
    return Storage.file(ctx.params.name).serve(ctx.req);
  });
durable background jobs & eventsTS
import { Jobs, events } from "yatta";

await Jobs.job("send-email")
  .with({ to: user.email, subject: "Welcome" })
  .delay("10m")
  .priority("high")
  .save();

The goal is not to hide complexity forever.

It is to provide a sensible default so developers can focus on building their application instead of assembling infrastructure.

YATTA / 002