
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.
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.

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.
The entire backend stack — database, auth, storage, realtime, jobs, mail, and observability — embedded inside your application runtime.

Built directly on Bun’s C and Zig primitives — bun:sqlite with WAL mode, Bun.password Argon2id, and native WebSockets for maximum throughput.
Relational DB, Auth with Passkeys & MFA, S3/Local Storage, Realtime WebSockets, Durable Queues, and Mail — unified in a single process.
$ 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)
No Docker orchestration or external broker services needed to get started. Boots in under 10ms with zero runtime overhead.
100% end-to-end schema autocompletion via ambient declaration merging. No Prisma CLI or slow build-step generation required.

Expressive, natural APIs like DB.users.where(), Storage.file().serve(req), and Mail.to().deliver() that read like spoken English.
Auto-instrumented observability for your yatta applications. Distributed tracing, auto-correlated logs, request and job metrics — out of the box.
Token Family replay defense, AES-256-GCM at rest, RFC 9110 HTTP 206 streaming, and non-destructive magic-byte verification.
Backend infrastructure should feel like part of your application, not an independent cloud you have to stitch together.
YATTA / 001Yatta Observe
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
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 shippedTrace every request across services, jobs and dependencies to see exactly where time is spent and where things go wrong.
Attach your subsystems once and every query, login and job execution is traced. No manual span wiring at any call site.
See every step of a request with self time and total time per span, so you know exactly where latency comes from.
Profile any region with the V8 inspector and read self time per function, down to the file and line that held the CPU.
Every response carries where its time went in a standard header your browser devtools already understand.
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
Identical failures collapse into a single defect, so you fix the bug rather than sorting through thousands of occurrences.
3 of 7 shippedAutomatically group identical failures into one issue, keyed by a normalized message and the top application frame.
See the failing file and line, the full stack, and the breadcrumbs that led there — without checking out the build yourself.
Every issue carries the users and requests it happened to, so you can tell a one-off from an outage.
See every log line exactly where it happened in the trace, automatically connected to the request or job that produced it.
Collect page timings and navigation data from the browser, joined to the server trace by trace id.
Track which release introduced a defect and automatically reopen resolved issues when the same failure comes back.
Turn any error, trace, request or job into an actionable issue with severity, ownership, due dates, comments and a complete activity history.
Jobs & runtime
The work nobody is watching is the work that fails quietly. Yatta reports on it alongside your request traffic.
5 of 6 shippedTrack queue wait time, retries and failures alongside your requests, with alerts when a backlog starts growing before it becomes an incident.
Monitor CPU, memory and event-loop delay per process, with automatic detection when one instance starts carrying the load.
See how requests move through your application and where failures happen, so you can spot the exact path that leads to a problem.
A trace waterfall, stack inspection and live refresh ship with the framework. No agent to install, no pipeline to build.
Scope issues to the users they affect, so one noisy account does not read as one widespread outage.
Compare releases by error rate, p50/p95/p99 and slow queries, plus which error fingerprints each one introduced or fixed.
Reliability
Turn raw telemetry into a signal someone can act on, rather than a dashboard nobody reads.
2 of 5 shippedAlert on error-budget burn rate instead of isolated spikes, so fast-moving incidents and slow degradation surface before they page anyone.
Define SLOs per route and method with a rolling error budget and burn rate. Too little traffic reports no-data instead of a verdict.
Adaptive baselines catch drift against each metric's own history, using median and MAD so one stall cannot hide the event.
Detect silent failures automatically — from an application that stops receiving traffic to a cron job that never runs.
Alert on errors, anomalies, SLO burn, log patterns, or things that stop happening — with notifications through email, Slack, webhooks, or issues.
Analysis
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 shippedCorrelates the failing trace, its slow queries, release proximity and rule-outs into ranked suspects with an ordered timeline.
Every claim carries the evidence behind it and the reasons it could be wrong. Gaps are reported as Unknown rather than smoothed over.
Too few samples for a baseline, a metric with no observed variance, a first release with nothing to compare — each declines instead of guessing.
Compares the running release against the previous one: signed deltas, new error fingerprints, and which failures stopped.
Per-release errors, p50/p95/p99, slow queries and affected routes, with a verdict derived from a real comparison rather than assumed.
Finds identical queries repeated under one parent — the N+1 shape specifically — and estimates the avoidable cost.
Per-query slow thresholds derived from each query's own rolling p95, so a table that normally takes 400ms is no longer all flagged.
Availability, remaining budget and burn rate per objective. A 5xx counts against availability; a 4xx does not.
Least-squares trend with fit quality. A weak fit is reported as noise rather than called a leak.
Mark a known-good run, then see exactly which step got slower, appeared or vanished in a later trace.
A call graph inferred from spans, with the limitations stated on the result rather than left to be discovered.
Destructive operations are previewed, confirmed, and need an idempotency key so a double-click cannot purge twice.
A self-contained JSON payload with evidence, caveats and timeline — designed for a model or a colleague with no access to your process.
Jump from a stack frame to the source line, with a resolver you opt into. Production bundles ship no sources, and it says so.
Cmd/Ctrl-K to jump to a view, open a trace by id, export an incident, or save a golden baseline.
Each cluster worker has its own observer. No leader aggregation yet — the dashboard shows one process.
Issues and transactions vanish on restart today. Persisting them needs retention and rotation.
Error-rate spikes, p95 thresholds, blocked event loops, heap growth, with dedupe windows and quiet hours.
Tracing inbound but not outbound is the missing half of distributed tracing. Needed before the dependency map shows external services.
Keep 100% of error and slow traces while sampling fast successes. The span tree is already there to make the decision.
Metrics & cost
The same registry serves the built-in signals and whatever you choose to measure yourself.
1 of 3 shippedTrack custom counters, gauges and histograms — from orders processed to queue depth — through the metrics registry, alongside built-in metrics.
Your registry is already served in text exposition format at /_yatta/metrics. Point a scraper at it and nothing else changes.
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↗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.
$ 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.
The backend becomes part of your application’s memory space and process boundary instead of an array of remote network hops.
Instead of stitching together multiple infrastructure products, your application operates as a coherent, self-contained system.
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.
import { DB, API } from "yatta"; export default API("/users") .get(async () => { return DB.users.where(f => f.email.endsWith("@yatta.local")).all(); });
import { auth } from "yatta"; const result = await auth.signIn({ email, password, req }); // Returns session, JWT, Argon2id & MFA tokens
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); });
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.