DEV Community: Davron Yuldashev

Bun in 2026: Ship Your Greenfield SaaS, Skip the Migration

Davron Yuldashev — Sat, 01 Aug 2026 11:09:45 +0000

TL;DR: Bun is ready to run a greenfield SaaS backend in 2026. Start new projects on Bun 1.3+ with Elysia and Drizzle, and size containers for a bigger memory footprint than Node (oven-sh/bun #17723). Skip migrating a working Node backend: 91% of State of JS respondents still run Node, and migrations capture the least of Bun's upside.

Is Bun ready to run your SaaS backend in 2026? For a greenfield build, yes; for migrating a working Node.js backend, no. Pick Bun on day one of a new project and its advantages cost nothing; drag an existing service onto it and you pay a compatibility long-tail for gains a new codebase collects for free. That split verdict comes from ShipKit, a SaaS boilerplate whose backend runs Elysia on Bun, and it is written for solo developers and technical founders choosing a stack for a new product.

July 2026 is why the question needs re-asking: Bun announced v1.4, a complete Zig-to-Rust core rewrite executed by parallel Claude agents, still canary-only while stable Bun holds at the Zig-based 1.3.x line, and the runtime's trust debate restarted mid-year. The adoption baseline stayed put through all of it. State of JS 2024 counts 16% of respondents using Bun while 91% still use Node.js, so the decision in front of you is narrower: should a brand-new backend collect Bun's built-in advantages while the incumbent keeps carrying the legacy apps?

What actually changed for Bun in 2025 and 2026?

Three dated events reset the question inside twelve months. Bun 1.3 (October 10, 2025) made the runtime batteries-included: PostgreSQL, MySQL and SQLite through Bun.SQL, a built-in Redis client, full-stack Bun.serve() routing. The Anthropic acquisition of Bun (December 3, 2025) kept the runtime MIT-licensed. Bun announced v1.4, the Zig-to-Rust rewrite, on July 8, 2026 (canary-only at launch).

Bun's twelve decisive months: batteries-included 1.3 in October 2025, the Anthropic acquisition keeping the MIT license in December 2025, and the v1.4 Rust rewrite announced in July 2026, canary-only at launch.

The 2023–2025 objections were specific: no batteries, a single VC-backed company as bus factor, a compatibility story full of workarounds. Bun 1.3 answered the first with 98%+ of Node's N-API tests passing; the acquisition answered the second, with development continuing publicly under MIT. What stays open is trust in the process behind v1.4. One scope note: Bun as a package manager, bundler or test runner is deliberately out of scope here, because those adoption paths are settled and low-risk; the contested bet is the runtime under a production API.

Can you trust Bun after the 11-day AI rewrite?

Can you trust Bun after the rewrite? The announced Bun v1.4.0 replaces the Zig core with Rust: a +1,009,272-line diff converting 1,448 Zig files, produced in 11 days by one engineer directing up to 64 parallel Claude agents, at roughly $165,000 in API cost. The verdict hangs on which evidence you weight: the unreviewable process, or the production record since.

The case against: a million lines nobody reviewed

Start with the strongest objection, raised in the Hacker News thread where yt-dlp marked its Bun support limited and deprecated:

If the Bun maintainers are willing to completely replace their core product over the span of a week, how is anyone supposed to rely on it?

Practitioners in the same thread put the review math plainly: "It's simply not possible for a team that size to review that much code in that little time." Andrew Kelley, creator of Zig, called the result "unreviewed slop"; he is an interested party, since Bun just left his language, and his critique is pointed and personal (he has called Bun's pre-LLM code slop too), which is why the argument deserves the weight, not the tone. The objection lands because its core is true: no human team reviewed a million-line diff in eleven days, and the 19 known regressions v1.4 introduced (and later fixed) prove the test suite did not catch everything.

The case for: three weeks in production, and nobody noticed

Bun's own release numbers set the floor, labeled as self-reported: 100% of the test suite passing on all platforms before merge, 128 bugs fixed relative to v1.3.14, a binary about 20% smaller on Linux and Windows, 2–5% faster. The decisive datapoint is the production exposure: the Rust build ran inside Claude Code, a product Anthropic reports at a $1B annualized run rate, for three weeks before anyone publicly noticed. Simon Willison, reviewing the project independently, called it "an extremely sophisticated piece of agentic engineering". The shipped result, in the words of Bun's own release post (self-reported, like the numbers above):

Startup got 10% faster on Linux but otherwise, barely anyone noticed. Boring is good.

Bun v1.4's trust question weighs an unreviewable 11-day process against three weeks of unnoticed production service inside Claude Code.

Tests verify behavior; review verifies intent. A million-line diff has the first without the second, which keeps the fear legitimate while draining it of decision weight: what a founder bets on is production exposure over time, and the Rust Bun banked three weeks of it inside a heavily used product before its own announcement. Pin the runtime like any dependency: lock the Bun version in CI and in your Dockerfile, and take major upgrades as deliberate deploys after the issue tracker has spoken, never on release day.

Will Bun blow past your container's memory limit?

Documented, yes, in oven-sh/bun #17723 and #25948. A service holding ~500MB on Node spiked to its ~1.2GB container limit on Bun after a two-line Dockerfile change (#17723, open since February 2025); #25948 (closed as a duplicate in May 2026, not fixed) documented idle growth under Mongoose: RSS creeping from 50MB to 170MB over 12 hours with no traffic.

The classic first mistake is exactly that swap: FROM node becomes FROM oven/bun on an existing service, memory limits stay untouched, and the change ships because everything works. The service stays responsive, the logs stay clean, and RSS climbs to the ceiling until the platform's OOM killer restarts the container. On Cloud Run, Fly.io or GKE the symptom that surfaces first is usually a rising restart count. The question teams then search, why is my Bun server using so much memory in Docker, has issue numbers for an answer.

As of July 2026 there is no confirmed root cause and no fix: #17723 stays open, and #25948 was closed as a duplicate rather than resolved. Connection-pool tuning does not stop the idle growth either: one production report set minPoolSize: 0 and maxIdleTimeMS and the leak continued; another shows process RSS creeping while the JS heap stays flat. Load-test verdicts belong to container RSS measured over hours, never to heap snapshots taken over minutes.

Do not copy Node memory limits into a Bun deploy: in the one documented like-for-like case, the same workload hit 2.4× its Node footprint before the container ceiling cut it off, so treat that multiple as a floor, not a measured peak. The delta decides real money on memory-priced platforms, which is why it belongs in the greenfield plan instead of a postmortem. Priced in, it is a line item: pick the container size with the delta included, soak-test for a working day, and alert on RSS. A failure mode documented down to the issue number is a manageable one.

Bun 1.3 replaces the npm picks a Node stack has to maintain

A greenfield Node backend opens with four decisions: a Postgres client, a Redis client, an HTTP framework, a deploy artifact. Bun 1.3 ships all four inside the runtime: Bun.SQL speaks PostgreSQL, MySQL and SQLite, the Redis client is built in, Bun.serve() routes full-stack, and one compile step emits a standalone executable.

Bun 1.3 replaces four third-party stack picks with runtime built-ins: Bun.SQL for PostgreSQL, MySQL and SQLite, a Redis client, Bun.serve() routing and standalone-executable builds.

Every third-party pick you skip is an upgrade cadence, a CVE feed and a maintainer risk you skip with it. For a solo developer that arithmetic decides whether the week goes to product code or to the dependency tree.

Elysia is the framework question the readiness checklists skip. TechEmpower Round 22 plaintext, run in late 2023 (Round 23 followed in March 2025), puts Elysia on Bun at 2,454,631 requests per second against 113,117 for Express on Node, the origin of Elysia's 21x-faster-than-Express line. Read a benchmark that old honestly: a runtime-plus-framework number on a synthetic workload, so a real SaaS API bound by Postgres and the network will see nothing like 21x. Elysia on Bun is good enough for a production API, and the reason to pick it is fit, not the benchmark: Bun-first design with end-to-end type inference. ShipKit's backend runs on exactly this pairing, Elysia with Drizzle (the architecture overview shows how the monorepo wires them), because those are the picks that survive Bun's compatibility surface without workarounds.

Two caveats that ambush you in week two

ORM first. Drizzle runs on Bun; Prisma was the long-standing blocker, and the complaint pattern was old and consistent: "I'd use it if it weren't for my wish to use Prisma on my project" summarized the compatibility long-tail on Hacker News back in 2023, and that long-tail is why Bun still advertises N-API pass rates as a headline metric. Prisma has since closed most of that gap and ships an official Bun guide today; Drizzle stays the pick here because it is the ORM ShipKit ships and tests on this stack. Debugging second. A February 2025 write-up on Bun 1.2.x found bun --inspect ignored breakpoints unless the process held a port listener (a condition a long-running API meets), with --inspect-brk and --inspect-wait failing outright; the live breakpoint issue today is narrower, oven-sh/bun #32591, where the inspector reports a top-level breakpoint before the previous line's declaration has initialised. Both caveats are day-one decisions on a greenfield project: pick your ORM before the first migration, keep log-first debugging as the default until the inspector's remaining edges close, and neither ambushes anyone. Call the general shape the greenfield asymmetry : a constraint you choose around before the first commit costs nothing, while the same constraint discovered under a working backend becomes a migration blocker.

Should you migrate an existing Node backend to Bun?

Rarely. Node.js in 2026 is no slow-moving target: it keeps absorbing Bun's headline advantages, built-in TypeScript execution among them, and 91% of State of JS 2024 respondents still run Node.js. A migration pays Bun's compatibility long-tail to capture gains a greenfield project collects for free.

The strongest migration story of 2026 arrives with its own correction. Trigger.dev rebuilt Firestarter, its warm-start connection broker, on Bun in March 2026 ("Firebun") and reports 5x throughput; the top Hacker News comments attribute much of the gain to swapping SQLite and Zod and to optimizations applied only to the Bun version. Both halves belong in your decision: the result is real, and the runtime is only part of the cause. The pattern generalizes, because a migration always bundles a rewrite, and the rewrite is usually where the speed hides.

When staying on Node is the right call

Staying on Node is a first-class outcome of this article, and for three concrete readers the correct one: a backend with paying customers and one dependency sitting in Bun's compatibility long-tail; a deploy shaped around AWS Lambda or Vercel functions, where the managed runtimes are Node; a team whose debugging workflow lives in breakpoints and cannot absorb inspector rough edges like #32591. A working Node backend in 2026 is not a problem to fix. The greenfield asymmetry runs the other way for your next product: a new codebase collects the built-ins, the one-file deploys and Elysia's type system at zero migration cost, which is why ShipKit ships its stack greenfield-first, an Elysia-on-Bun backend you start on rather than a migration target you drag a legacy app toward.

The expensive part of a greenfield Bun stack is the plumbing

A greenfield-yes verdict answers the runtime question and leaves the costlier half. Auth, billing, an admin panel, i18n, background jobs: that plumbing eats a month between an empty repo and a first paying customer, and ShipKit exists precisely for it. Bun saves you dependency picks; it does not build your OAuth flow.

ShipKit closes that gap on the exact stack this article endorses: fourteen production subsystems pre-wired in one Turborepo monorepo, spanning Better Auth (email, OAuth, magic link, RBAC), payments, an admin panel, i18n, background jobs, a webhook worker, feature flags, file storage and observability, across 7 apps, 17 packages and 68 UI components. The greenfield asymmetry is the whole reason the math works: nothing exists yet, so adopting a pre-wired codebase costs zero migration and returns the plumbing month. The price is $149 one-time for full source, unlimited projects and lifetime updates; there is no trial, so price the decision on the source access itself. Before writing the first line of auth code, price those fourteen subsystems against your own hourly rate; that arithmetic is the entire build-vs-buy decision.

Next step: the verdict was greenfield-on-Bun, so spend the saved month on product instead of plumbing.

Get ShipKit — $149 one-time · See the architecture

FAQ

What does the Anthropic acquisition mean for Bun's roadmap?

Bun remains MIT-licensed open source, with the team continuing development publicly on GitHub, which retired the 2023–2025 bus-factor objection. The open question is priority: the December 2025 announcement paired the acquisition with Claude Code's growth, so server-runtime features now share a roadmap with agent infrastructure. Watch the release notes; intent shows up there first.

Is the Rust build already the default Bun?

Not yet. Bun v1.4.0, announced July 8, 2026, is the Rust rewrite, and it ships only on the canary channel: bun upgrade --canary installs it, while a plain bun upgrade still delivers the Zig-based 1.3.x line (v1.3.14 at the time of writing). The Rust port did run inside Claude Code for weeks before the announcement, so its production exposure predates its stable release. Pages calling the build Linux-only are outdated, since the test suite passed on all platforms before merge; canary remains the accurate label until a stable v1.4.0 ships.

Should you pick Elysia or Hono for a Bun backend?

Elysia when the backend lives on Bun, Hono when portability matters. Elysia is Bun-first with end-to-end type inference; Hono targets many runtimes, including edge platforms like Cloudflare Workers. A containerized SaaS API committed to Bun gets more from Elysia's type system; a codebase that needs to move between runtimes keeps more options with Hono.

Can you run Bun on AWS Lambda or Vercel serverless?

Not on a managed runtime: Lambda and Vercel functions provide Node.js runtimes, and running Bun there means a custom runtime layer or a container image. Bun's natural deployment targets in 2026 are container platforms such as Fly.io, Cloud Run or Railway, where the memory sizing guidance from issue #17723 applies before you set limits.

What about Deno for a greenfield backend?

Deno is the third runtime on the same State of JS chart and a legitimate greenfield option: Deno 2 runs npm packages and ships its own toolchain. It optimizes for a different bet, TypeScript-first tooling and its own hosting platform in Deno Deploy, while this article's decision is a containerized Elysia-on-Bun API. If Deno's toolchain or hosting story fits your deploy, evaluate it on the same axes used here: built-ins, npm compatibility and memory behavior in your container.

Sources

Originally published on the ShipKit blog.

Clerk vs Better Auth in 2026: The Honest Migration Math

Davron Yuldashev — Fri, 31 Jul 2026 18:00:40 +0000

TL;DR: The $24,000-a-year Clerk math still circulating is dead. Since Clerk's February 2026 repricing, 50,000 Monthly Retained Users are free and 100K MRU costs about $1,025/mo. Migrate to Better Auth when an operational trigger is live: outage coupling, the 5 req/s rate limit, or webhook-sync drift. Budget about two engineer-weeks on a live product.

The decision:

Migrate when: Clerk outages take your product down, the 5 req/s limit bites, or webhook sync drifts

Risk: bcrypt-to-scrypt hash mismatch locks migrated users out; cutover invalidates every active session

Best for: live products past 50,000 MRU that already own their user database

Migrating Clerk to Better Auth at month nine is a decision most teams price with numbers that died in February 2026. Correct the numbers and the verdict flips: below Clerk's free 50,000 MRU, stay unless an operational failure is pushing you out; past it, the migration pays back within months. Here is the corrected math, from ShipKit, a SaaS boilerplate that ships Better Auth pre-wired.

Clerk's February 2026 changelog raised the free tier from 10,000 MAU to 50,000 Monthly Retained Users, so 100K MRU now bills at about $1,025 a month, not the $2,025 the stale calculators still report. For a developer building the team's migration case, the first mistake is copying the SERP's $24k-a-year figure into the proposal: the number dies the moment anyone opens Clerk's pricing page, and the proposal's credibility dies with it.

What does Clerk actually cost in 2026?

Clerk's Pro plan is $25/mo with 50,000 Monthly Retained Users free; overage runs $0.02 per MRU from 50,001 to 100,000, then $0.018 up to one million, with lower rates past that, per Clerk's pricing page. At 100K MRU the bill is about $1,025/mo, around $12,300 a year , and the B2B organizations add-on puts another $100/mo on top.

Three worked scenarios on the current price sheet, before infrastructure or support tiers:

Scenario	Arithmetic	Monthly bill
40,000 MRU	inside the free allotment, Pro base only	$25
100,000 MRU	$25 + 50,000 × $0.02	~$1,025
100,000 MRU + organizations	$1,025 + $100 B2B add-on	~$1,125

What does Clerk cost per plan in 2026?

Four plans, and the free allowance is the same on three of them:

Plan	Base price	MRUs included	Dashboard seats
Hobby	$0	50,000 limit per app	up to 3
Pro	$25/mo ($20 billed annually)	50,000 included per app	up to 3
Business	$300/mo ($250 billed annually)	50,000 included per app	10, then $20 each
Enterprise	custom, annual only	custom	custom

Note the word that changes: Hobby's 50,000 is a limit, Pro's and Business's is an allowance. Cross it on Hobby and Clerk requires the upgrade; cross it on Pro and it meters. Overage runs $0.02 per MRU to 100,000, $0.018 to a million, $0.015 to ten million, $0.012 beyond.

Two lines people miss when they price this. Organizations are billed separately: 100 monthly retained organizations are included per app, and past that Clerk requires the B2B Authentication add-on at $100/mo ($85 annually) — that is a required add-on, not a per-org overage rate. And Clerk's "First Day Free" rule means a user who signs up and never returns is never billed: retention starts 24 hours after signup.

MRU is not MAU, and the difference lowers your bill

A Monthly Retained User is a user who comes back 24 hours or more after signing up; Clerk does not bill drive-by signups that bounce. Billable MRU therefore sits below raw MAU, so every calculator that reasons in MAU overstates the Clerk column. Clerk raised the free allotment from 10,000 to 50,000 MRU on 2026-02-05 and folded most of the Enhanced Authentication add-on into Pro. Before that change, 10,000 free users at $0.02 each put 100K MAU at $1,825–$2,025/mo, the origin of the $24,000-a-year gap the SERP still quotes. Get the unit and the date right: the whole decision is a delta between this bill and engineer time, and a 2× error in the bill propagates downstream.

One scope cut, made on purpose: what follows does not re-walk the official export tutorial; the Better Auth guide owns those mechanics. The money, the cutover, and the two lockout traps the guide leaves out are the rest of this page.

What does "upgrading Clerk" actually involve?

Two different jobs share the word, and only one of them is about money.

Upgrading the plan

Hobby is capped rather than metered: "Applications on the Hobby plan are limited to free tier usage. To use beyond the free tier limits, you must upgrade to the Pro plan." Cross 50,000 MRU and Clerk gives you a one-month grace period so the app keeps working while you move. Two other triggers force a plan change regardless of user count: a fourth dashboard seat requires Business, and enhanced dashboard roles beyond Owner and Viewer are Business-only.

Upgrading does not cost you the free allowance — 50,000 MRU is included on Pro and Business alike, so the bill starts at overage, not at zero. There is no traditional free trial; Clerk's stated substitute is the development instance, which is free and unlimited in features but capped at 100 users.

One trap worth naming, because it is the first search result for "clerk upgrade mid-cycle": Clerk's documentation that upgrades "take effect immediately, while downgrades take effect at the end of the current billing cycle" belongs to Clerk Billing, the feature for charging your users. It says nothing about your own workspace plan. Same for the proration language, which appears only in the seat-based-billing docs. Clerk publishes no proration rule for its own plans; the pricing page just carries "Upgrade to Pro plan" buttons.

Upgrading the SDK

The current major is Core 3, shipped 2026-03-03 as @clerk/nextjs v7 (7.7.1 as of 2026-08-08). Clerk runs a roughly six-month major cycle and keeps the previous major in long-term support for a year, so Core 2 is patched until January 2027 and the v6 line still gets releases.

Do not hand-edit the migration. Clerk ships a codemod that does AST-level transforms and catches re-exports, aliased imports and monorepo files:

npx @clerk/upgrade       # package-lock.json or no lockfile
bunx @clerk/upgrade      # bun.lockb / bun.lock

What Core 3 breaks in a Next.js app, in the order it will bite you: SignedIn, SignedOut and Protect collapse into a single Show component; <ClerkProvider> moves inside <body> instead of wrapping <html>; passing secretKey to clerkMiddleware() now also requires CLERK_ENCRYPTION_KEY; the Next.js floor rises to 15.2.3; and auth.protect() returns 401 rather than 404 for unauthenticated server actions. Packages were renamed too (@clerk/clerk-react to @clerk/react), and the old redirect props are gone in favour of the fallback ones.

Budget this against the migration bill above. A Core upgrade every six months is not free either — it is the recurring cost of the managed option, and it is the honest column to compare against maintaining your own auth.

What actually pushes teams off Clerk at month nine?

Under the 2026 free tier a typical month-nine product pays Clerk $0, so the real triggers are operational. Val Town left after outages that took their whole site down, a production rate limit of five requests per second across the entire account, and webhook-sync workarounds that split user data between two systems.

“Clerk went down pretty often, and went down for long periods of time... if Clerk goes down, the whole website goes down.”

Tom MacWright's Val Town writeup pairs that outage coupling with a subtler production trap: Clerk's loadUser endpoint ran fine in development, then throttled at “five requests per second. For the whole account, across all users.” If auth going down takes your product down, no free tier offsets that risk. Val Town moved sessions into their own database through a two-week dual-cookie cutover, covered below, and their verdict after the move was “so far it really has been better”: user auth no longer depends on a third party staying online.

Three operational triggers moved Val Town off Clerk: repeated outages that took the whole site down, a 5 req/s account-wide rate limit, and webhook user-sync drift.

Why can't migrated users sign in after the export?

Clerk exports password digests hashed with bcrypt; Better Auth hashes with scrypt by default. Run the export without a custom hash/verify pair and every migrated password fails verification: the user rows exist, sign-in returns invalid credentials. Configuring Better Auth to verify bcrypt digests is the fix, and the official migration guide buries it mid-tutorial.

bcrypt and scrypt are both password-hashing algorithms, and their digests are incompatible: a hash written by one cannot be verified by the other's default path. The config that prevents the lockout fits in a dozen lines:

import { betterAuth } from "better-auth";
import bcrypt from "bcrypt";

export const auth = betterAuth({
  emailAndPassword: {
    enabled: true,
    password: {
      // Clerk exports bcrypt digests; Better Auth defaults to scrypt.
      // Skip this verify pair and every migrated password fails silently:
      // the user row exists, sign-in returns "invalid credentials".
      hash: (password) => bcrypt.hash(password, 10),
      verify: ({ hash, password }) => bcrypt.compare(password, hash),
    },
  },
});

The organizations gap

Clerk organizations sit outside the automated migration script; the guide's full guidance is that moving them “should be possible with additional steps” and the Organization Plugin. The teams hit hardest are the ones paying the $100/mo B2B add-on: the users most motivated to leave face the least-documented part of leaving. Budget organization and membership mapping as its own line item rather than a footnote.

The hash mismatch says nothing about which framework is better. What it decides is whether cutover day ends with a support queue full of locked-out users. ShipKit's monorepo makes the greenfield version of that decision for you: Better Auth arrives with email, OAuth, magic link and RBAC already configured, which leaves one fewer place for a month-nine surprise to hide.

How do you migrate Clerk users from development to production?

You do not. Clerk's own migration guide opens with the sentence flat: "You cannot migrate users from your Development instance to your Production instance." The instances do not share data at all, and development is capped at 100 users, so what you are really asking is how to recreate them.

The supported path is the CreateUser Backend API endpoint. Passwords survive if you send the hash rather than the plaintext: password_digest plus password_hasher, where the hasher is one of bcrypt, argon2i, argon2id, the pbkdf2 family, scrypt_firebase, scrypt_werkzeug and a dozen others. Hashers Clerk considers insecure — md5, md5_salted, sha256, sha256_salted, sha512_symfony — are transparently re-hashed to bcrypt the first time that user signs in successfully. For bulk work Clerk publishes an open-source importer, clerk/migration-tool, which takes JSON or CSV and respects the rate limits (1,000 requests per 10 seconds on a production key, 100 on a development one).

Keep the old identifiers. Clerk's recommended pattern is to store them as external_id and surface them in the session token, which is the difference between a clean cutover and a week of reconciling foreign keys.

What else fails to carry over, in the order it breaks a deploy:

OAuth credentials. Development uses Clerk's shared credentials for most social providers. Production requires your own, per provider.
SSO connections, Integrations and Paths. Clerk names exactly these three as excluded when you clone development settings into the new instance.
Domain and DNS. Production needs a domain you own plus new DNS records, and propagation can take up to 48 hours. Plan the cutover around that, not the code freeze.
Webhooks. New endpoint URL, new signing secret, created fresh in the production instance.
Keys. pk_test_/sk_test_ become pk_live_/sk_live_.
Sessions. Development uses a __clerk_db_jwt "dev browser" object; production uses the __client cookie. A development session means nothing in production.

There is also no staging instance: Clerk offers Development and Production only, and its documented workaround is a separate Clerk application on a separate domain — which, by the same rule, cannot share production's users either.

Notice what this exercise proves before any migration is on the table. If your users only exist inside a vendor and cannot be moved between that vendor's own environments, the export question is not hypothetical; you have already met it. That is the cheapest possible moment to decide whether you want to own the user table.

How do you cut over without logging every user out?

Better Auth's guide prices session invalidation in one sentence: “This migration will invalidate all active sessions.” Val Town answered it with a dual-cookie cutover : for two weeks every auth endpoint accepted either a Clerk session cookie or a Better Auth one, so users rolled over as they signed in.

The wrong first move is running the export against production as-is. A big-bang cutover works in the tutorial because the tutorial has no live sessions; on a nine-month-old product it forces every user to re-authenticate at once, and if the bcrypt config above is missing, a share of them cannot.

The dual-cookie cutover keeps both verification paths live behind a flag: existing Clerk sessions verify against the old path while new sign-ins issue Better Auth sessions in your own database. Rollback stays one flag-flip away until the overlap window closes, and the overlap doubles as a live test of the new session shape under real traffic. When the last Clerk cookies age out, remove the old path.

Val Town's dual-cookie cutover: a two-week overlap in which every auth endpoint accepts either session cookie, so users roll over without a forced logout.

The itemized migration bill: two engineer-weeks in real currency

Plan for about two engineer-weeks on a live product — an estimate with stated assumptions, itemized below rather than asserted. At a loaded $75/hour, 80 hours is $6,000 of engineering time. The bill splits into five workstreams; two of them are the lines every estimate misses.

Assumptions for the table: one product, Postgres already in place, hours priced at a loaded $75/hour:

Workstream	What it covers	Estimate
Export and schema mapping	user export, table mapping, bcrypt digest import	12–16 h
Auth config and re-testing	bcrypt verify pair, sign-in/sign-up flows, 2FA plugin	12–16 h
Dual-cookie middleware	parallel session acceptance, feature flag, rollback path	8–12 h
UI rebuild	replacing Clerk's prebuilt sign-in, profile and org-switcher components	16–24 h
Webhook-sync teardown	removing sync endpoints, reconciling the duplicate user table	8–16 h

Two scenarios on the same $75/hour assumption: a product with no webhook sync and no organizations lands near the bottom of the ranges, about 56 hours ($4,200); a B2B product with both lands past the top, about 104 hours ($7,800), because the organization mapping is manual.

The line items nobody prices

Teams that followed Clerk's recommended pattern for using their own database keep user data in sync via webhooks, and leaving means unwinding two sources of truth: sync endpoints removed, the duplicate user table reconciled row by row. The recovered line is local dev: openstatus migrated partly because contributors needed an ngrok tunnel just to log in locally, and after the move auth runs offline like the rest of the stack. Payback math stays short: against a $0 Clerk bill this never pays back in cash; against $1,025/mo it pays back inside six months. Every row above is also a build-vs-buy datapoint: ShipKit sells the pre-wired version of this work for $149 one-time with unlimited projects, less than the cheapest single row of the table at the same hourly rate.

When staying on Clerk is the right call

Below 50,000 MRU your Clerk bill is $0, and $6,000 of engineering time cannot pay back against a free product. openstatus, a team that migrated off Clerk, still calls it “an amazing product — the documentation is clear, the setup straightforward.” Staying makes sense if none of the operational triggers are live.

The boundary is a trigger list rather than a calendar: if outage coupling has not bitten, the 5 req/s limit has not throttled you, and you resisted the webhook-sync pattern, Clerk is doing its job and the two engineer-weeks buy more elsewhere. Revisit when an incident lands or MRU crosses the paid tier, and take the export then, with openstatus's migration notes and the playbook above in hand.

What if the next project never books this migration?

The job at month nine is the same as at month one: reach paying customers without burning weeks on auth plumbing. The cheapest Clerk migration is the one the next project never books, and that choice happens at repo-init: ShipKit ships Better Auth pre-wired, with email, OAuth, magic link and RBAC, inside a monorepo of 14 production subsystems.

The full inventory runs from payments and admin panel to i18n, background jobs and a webhook worker, spread across 7 apps, 16 packages and 68 UI components; nine production apps have shipped on this codebase already. At $149 one-time with lifetime updates and unlimited projects, the license costs less than two hours of the migration priced above. The three paths, priced on this article's own numbers:

	Stay on Clerk	Migrate at month nine	Greenfield on ShipKit
Upfront cost	$0	~$4,200–$7,800 in engineer time	$149 one-time
Monthly at 100K MRU	~$1,025	your hosting only	your hosting only
Sessions live in	Clerk's cloud	your database	your database
Auth work on day one	none	two engineer-weeks	pre-wired: email, OAuth, magic link, RBAC

Before writing the first migration line, price the 14 subsystems against your own hourly rate: ShipKit's feature list reads as this article's pricing table with every row already built into the architecture.

Next step: Two engineer-weeks is the price of leaving Clerk late; $149 is the price of a stack where the job is already done. Price both against your own rate before the next repo-init.

Get ShipKit — $149 one-time · See the architecture

FAQ

Is Better Auth production-ready in 2026 now that it joined Vercel?

Better Auth joined Vercel in July 2026 with a stated commitment to staying open source and framework-agnostic, and the project sits at 29.4k GitHub stars with 2.7k forks as of July 2026. LobeHub already documents a Clerk-to-Better-Auth path for its own self-hosters. The skeptical view exists too: one Hacker News commenter argues that delegating your database schema to an auth framework suits “throwaway projects and companies with low quality technical vision.” Weigh that thread against Val Town running Better Auth in production.

What happened to Auth.js (NextAuth)?

The Better Auth team has maintained Auth.js since September 2025, and the merger announcement recommends new projects start on Better Auth. Consolidation puts the two largest open-source JavaScript auth libraries under one roof, and it makes a 2024 Clerk-to-NextAuth migration like openstatus's the direct ancestor of today's path.

Can we migrate incrementally instead of a big-bang export?

openstatus ran a lazy migration: extend the existing users table with the new adapter fields, override getUser and createUser, and re-link OAuth accounts on next login via allowDangerousEmailAccountLinking. Users migrate as they show up. The trade-off is an overlap window longer than the two-week dual-cookie cutover, with both systems live for the duration.

Does Better Auth support 2FA and multi-tenant organizations?

Both ship as plugins, and the repository describes multi-tenant support as a first-class path. Clerk organizations still need manual mapping on the way out, because the export script does not carry them across.

Do I lose the free 50,000 users when I upgrade to Pro?

No. The 50,000 MRU allowance is included on Hobby, Pro and Business alike, so a Pro bill starts at $25 plus overage above 50,000, not at $25 plus everything. What upgrading changes is the consequence of crossing the line: on Hobby it is a hard stop with a one-month grace period, on Pro it is metered at $0.02 per MRU.

Sources

Originally published on the ShipKit blog.

Four agents, 77 projects, 90 minutes: the multi-agent Claude Code pattern I run in production

Davron Yuldashev — Fri, 29 May 2026 12:03:02 +0000

Last Tuesday I sat down to audit every dev project I'd written over the past few years. 77 of them. Old courier-logistics monorepos, abandoned starters, a clinical reasoning engine, half a dozen Telegram bots, a SaaS framework I keep reusing, two startups, a Rust process manager. Different stacks, different ages, different employers, different states of git hygiene.

I gave the job to four Claude Code agents working in parallel. They were done in about 90 minutes.

Below is the pattern they used, and why a version of it now runs inside a 2,200-commit production codebase at my day job.

Why one agent isn't enough

Single-agent Claude Code is fine until you hit one of three walls.

The context window starts choking on a big codebase. The work is wider than it is deep, and serial reading wastes wall-clock. You want the orchestrator to keep judgment, not get buried in file diffs.

A swarm fixes all three. Each agent gets a slice. The lead keeps the map.

The hard part isn't spawning agents. Spawning is one tool call. The hard part is making sure four of them don't trip over each other.

The pattern

Claude Code ships with two primitives that, combined, give you a clean swarm.

TeamCreate + named teammates. Each agent has a stable name (analyst1, designer, metrics) and joins a team with a shared task list.

SendMessage to coordinate. The lead addresses any teammate by name. Teammates idle between turns and wake when messaged.

Wire those to a TaskList and you have a coordination plane. Each task carries an owner field. Setting owner = analyst3 is your atomic lock. Until that field changes, the task belongs to that agent.

For the audit I made 77 tasks, one per project. I spawned four analyst teammates with the same prompt template: read the project at code level (not commit messages), parse Claude Code session transcripts if any exist, write a per-project dossier. Then let them loose.

The race condition I shipped on day one

First attempt: each teammate, on idle, runs TaskList, finds the lowest-ID task with no owner, claims it, does it, marks it complete, repeats.

That worked for the first ten minutes. Then two analysts grabbed the same task within the same second. The TaskUpdate that set the owner went through twice. Both did the work. The second one overwrote the first dossier with a slightly different version of the same content.

Classic optimistic-concurrency mistake. The fix is boring and reliable: stop racing for low-ID tasks. The lead pre-assigns owners on the entire remaining range before spinning the swarm back up.

I partitioned the remaining work into four contiguous blocks (#33–43, #46–56, #57–67, #68–77) and set every owner in advance. Now when any agent reads the list, every task is already claimed by someone. Nothing left to race for. Each agent processes its own block in ID order and reports back when the block is empty.

Zero collisions for the rest of the run.

What came out

Sixty dossier files. Twenty-two tagged showcase, thirty-eight supporting, seventeen skip. The skips were honest: client work where my commit share was under 10%, abandoned scaffolds, empty stubs. Bad data is worse than no data when the goal is a personal-brand audit.

The interesting findings weren't in the headline projects. They were in the cross-cuts. My boilerplate had quietly become the foundation under four products. The same codebase showed up in five different clients. On one healthcare CRM my commits totalled 962 out of 2,208 (top contributor), even though the surface-level metadata I'd been relying on said only about 700. Manual git history is lossy. A swarm with shared output catches the drift.

The production version

This isn't a hobby pattern. The same multi-agent Claude Code workflow runs in our healthcare CRM at the day job, on a 2,200-commit codebase. The CLAUDE.md there defines four custom subagents:

django-backend-specialist — owns models, views, URLs.
advertiser-frontend-developer — owns the advertiser dashboard.
patient-frontend-specialist — owns the patient portal.
linting-specialist — runs last, owns the diff.

There's an explicit inter-agent contract. When the backend changes a view, it reports the new endpoint, the URL, the response shape. The frontends know to ask for that data before they start. Linting runs at the end of the chain, not the middle. The orchestrator (me) holds the architecture. The agents hold the file diffs.

On one of the products I ship with this pattern, an internal-tools rebuild, about 29% of the commits are AI-authored under my direction. The other 71% are mine. The split is visible in git shortlog. Nothing to hide, nothing to inflate.

The honest part

This doesn't replace senior engineering judgment. The orchestrator still has to know what good looks like. When an analyst returns a weak dossier, you have to recognize it and ask for a redo. Two agents disagreeing? You resolve it.

What it does give you is leverage. One engineer with a swarm covers staff-level surface area. The bottleneck shifts from typing speed to judgment quality, which is the right bottleneck to have.

If you want to see what the swarm actually produced, the 60 dossiers live at davr.dev/projects. Each one is a code-level audit, not marketing copy.

I Built 6 Free Browser-Based Tools — 50+ Utilities, No Signup, No Tracking

Davron Yuldashev — Tue, 07 Apr 2026 05:00:06 +0000

All tools are free. Processing happens in your browser or on a private server. No accounts, no ads, no tracking.

Over the past 6 weeks I built a portfolio of free online utility tools at davrapps.dev. Here's what shipped and how it's built.

The Apps

🛠️ DevTools — 28 Developer Utilities

Every tool runs 100% client-side — nothing is sent to any server. Check the Network tab if you don't believe me.

Text & Data

JSON Formatter & Validator
YAML ↔ JSON Converter
TOML ↔ JSON Converter
Diff Checker — compare two texts side-by-side
Text Statistics — word count, reading time, character frequency
String Case Converter — camelCase, snake_case, SCREAMING_SNAKE, kebab-case
Lorem Ipsum Generator

Encoding & Crypto

Base64 Encode/Decode
URL Encoder/Decoder
HTML Entity Encoder/Decoder
Hash Generator — MD5, SHA-1, SHA-256, SHA-512 (Web Crypto API)
JWT Decoder — inspect header + payload without a secret
Password Generator — cryptographically secure
Image to Base64

Dev Helpers

Regex Tester — real-time matching with group highlighting
UUID Generator — bulk v4 UUIDs
Unix Timestamp Converter — epoch ↔ human-readable with timezone
Number Base Converter — binary, octal, decimal, hex
Cron Expression Parser — plain English explanations
SQL Formatter
CSS Minifier
Markdown Preview
Color Converter — HEX ↔ RGB ↔ HSL
CSS Gradient Generator — linear/radial/conic, CSS + Tailwind output
Tailwind CSS Color Explorer

👉 devtools.davrapps.dev

🖼️ ImgTools — 7 Image Utilities

Server-side processing with Sharp/libvips on a private VPS — files are never stored.

Compress — MozJPEG, up to 80% size reduction
Resize — custom dimensions + social media presets
Crop & Rotate
Format Convert — JPEG, PNG, WebP, AVIF, GIF, TIFF
Watermark — text or image
Background Removal

👉 imgtools.davrapps.dev

📄 PDFKit — 9 PDF Tools

No file size limits. No watermarks on output. No account needed.

Merge, Split, Compress, Rotate, PDF ↔ Image, Password Protect, Watermark, Add Page Numbers.

👉 pdfkit.davrapps.dev

🔲 QRKit — 8 QR Code Tools

Generate (with logo + custom colors), Scan (file or camera), WiFi QR, vCard QR, Batch Generator, Decode, Color Picker.

👉 qrkit.davrapps.dev

📸 Picefy — Screenshot Beautifier

Turn plain screenshots into polished visuals: gradient backgrounds, rounded corners, drop shadow, device frames. Export as PNG.

👉 picefy.davrapps.dev

📦 ShipKit — Next.js + Bun SaaS Boilerplate ($49)

Full-stack starter: Next.js 16, Bun, Elysia.js, Better Auth, Polar.sh payments, PostgreSQL + Drizzle ORM, shadcn/ui, i18n, dark mode.

👉 shipkit.davrapps.dev

Monetization

App	Free limit	Pro
DevTools	Unlimited	—
ImgTools	5 ops/day	$3/mo
PDFKit	5 ops/day	$5/mo
QRKit	5 ops/day	Coming soon
Picefy	5 exports/day	$5/mo
ShipKit	—	$49 one-time

Payments via Polar.sh (Stripe under the hood, but with a much better OSS-friendly DX).

Tech Stack

All apps share the same foundation:

Next.js 16 (App Router, SSG for all tool pages)
Bun runtime + package manager
Elysia.js API layer (Bun-native, ~3x faster than Express in benchmarks)
Better Auth — email/password + OAuth, sessions in PostgreSQL
shadcn/ui + Tailwind CSS — every app has dark/light mode
PostgreSQL + Drizzle ORM
i18n via next-intl (EN/RU/UZ)

Deployed on a Hetzner CAX21 ARM (~$8/mo total for all 6 apps). Each app is a systemd service behind nginx, its own port pair.

Key Decisions

Client-side by default. For anything that doesn't need a server (formatters, converters, hash generators), everything stays in the browser. Zero upload risk, zero server cost.

SEO-first architecture. Each tool has its own URL, unique meta tags, FAQ with JSON-LD structured data. devtools.davrapps.dev/en/json-formatter and devtools.davrapps.dev/en/uuid-generator each target different search queries rather than competing as a single page.

One server, many apps. Rather than pay per-app VPS costs, everything runs on one ARM machine. Total infra cost for 6 apps + 14 services: ~$8/mo.

Current Status

6 apps live, 50+ total tools
MRR: $5 (early days)
Backlinks: 2 merged awesome-list PRs, 7 more open
Starting to appear in Brave/Bing — Google indexation in progress

What tools do you wish existed? Drop a comment — I might build it next.

I built a process manager with built-in crash detection and AI auto-fix (PM2 alternative)

Davron Yuldashev — Sat, 14 Mar 2026 10:42:06 +0000

You deploy a service, it crashes at 3 AM. You get a Sentry alert, SSH in, dig through logs, try to figure out what happened. Or you pay $26/month for Sentry plus integrate the SDK into every project.

I wanted crash detection and recovery built directly into the process manager — no extra services, no SDK, no dashboards. So I built Velos.

When a process crashes or throws an unhandled error, Velos detects it, runs AI analysis on the logs and stack trace, and sends a Telegram message with two buttons: Fix and Ignore. Tap Fix — an agent reads the logs, inspects the code, diffs recent changes, proposes a fix, and reports back. All without waking up your laptop.

How the crash flow works

Process crashes (or stderr matches panic/traceback/FATAL pattern)
  → Velos daemon detects it
  → AI analysis runs (Anthropic or any OpenAI-compatible API)
  → Telegram notification with [Fix] [Ignore] buttons
  → You tap Fix
  → Agentic loop starts: reads files, inspects git diff, runs commands
  → Result sent back to Telegram

Nothing happens without your approval. The agent has tools to read/edit files, run commands, and inspect git history — but it only acts when you tap Fix.

This also works for runtime errors before a crash. Velos watches stderr for panic/traceback/FATAL/ERROR patterns and fires an alert without waiting for the process to die. Closer to what Sentry does — but zero SDK, zero extra service.

Why Zig for the daemon?

Process management is fundamentally a systems problem: fork/exec, Unix sockets, signal handling, CPU/RAM monitoring via syscalls. Zig gives full control with zero runtime overhead — no hidden allocations, no GC, comptime metaprogramming for tight control over the binary.

The result: ~3 MB RAM idle, ~65 KB per managed process. PM2 sits at ~60 MB baseline because of V8.

Architecture:

Zig daemon (fork/exec, IPC, monitoring)
    ↓  C ABI FFI
Rust shell (CLI, REST API, MCP server, log engine, AI)

Zig core compiles to a static library (libvelos_core.a), linked into the Rust binary via C ABI FFI. Single binary, zero runtime dependencies.

IPC uses a binary protocol — 7-byte header (magic 0xVE10) + MessagePack payload over a Unix socket.

Smart Log Engine

Pattern clustering, error rate tracking, anomaly detection — runs fully local, zero LLM cost.

velos logs myapp --summary
# → "47 errors in last 10m, 3 patterns detected:
#    [1] DB connection timeout (×31)
#    [2] Rate limit exceeded (×12)
#    [3] File not found (×4)"

Instead of scrolling through thousands of raw log lines, you get a digest.

MCP server (for local AI workflows)

Velos also ships with a native MCP server — 13 tools for Claude Desktop or Claude Code to manage your local processes directly:

{
  "mcpServers": {
    "velos": {
      "command": "velos",
      "args": ["mcp", "start"]
    }
  }
}

Tools include: start_process, stop_process, restart_process, get_logs, health_check, get_metrics, search_logs, analyze_crash, and more. Useful for local dev environments where your AI agent is already running on the same machine.

Install

curl -fsSL https://releases.velospm.dev/install.sh | bash

Or Homebrew:

brew install Dave93/tap/velos

Current state

Velos is at v0.1.14, production-ready on macOS and Linux. Windows support is on the roadmap.

What's coming next:

XDG Base Directory compliance (tracking: #10)
Plugin system
Web dashboard
Benchmark suite vs PM2/supervisord/systemd

GitHub: Dave93/velos
Docs: velospm.dev

Happy to answer questions about the crash detection system, the Zig/Rust architecture, or the design decisions. What would you have done differently?