Compare Next.js
Stacks vs Next.js

Next.js decides how your pages render. Stacks decides the rest too.

Next.js is a rendering framework with route handlers attached. Everything behind the request, the database layer, the auth, the queue, the mail, the admin, is a decision you make and maintain. Stacks makes those decisions and ships them typed against each other.

See what ships All comparisons

What Next.js is.

In its own terms, not ours.

Next.js is the default way to build a React application in 2026. App Router, server components, streaming, and the image and font pipelines are excellent, the ecosystem is the largest in the space, and Vercel makes deploying a React app close to effortless. It is a front end framework that grew server capabilities, and it is honest about stopping where your data layer starts.

Where each one wins.

Same amount of room on both sides, on purpose.

Pick Next.js for

  • The React ecosystem

    Every component library, every hiring pool, every Stack Overflow answer. If your interface is React and your team is React, that gravity is real and it is worth something.

  • Server components and streaming

    The RSC model has the deepest production track record and tooling for partial rendering and client bundle size. STX has server components, streaming, and islands too, but React's version has far more teams and years behind it.

  • Vercel

    Preview deploys per pull request, edge rendering, and analytics with no infrastructure work at all. Stacks deploys to infrastructure you own, a Hetzner box, AWS, or any Linux server over SSH, which is more control and more responsibility.

  • Asset pipelines

    next/font self-hosts and subsets fonts with no layout shift, and next/image is heavily battle-tested. STX has an Image component with srcset and WebP/AVIF output, but fonts are still a manual link and @font-face.

Pick Stacks for

  • The backend is not an exercise

    Models, migrations, auth, roles, queues, mail, storage, search, realtime, and an admin dashboard are in the install, not in a list of packages to evaluate.

  • One type graph

    A model attribute, the action that writes it, the route that exposes it, and the view that renders it are typed against each other, so a rename is a compile error rather than a runtime surprise.

  • Infrastructure in the repository

    config/cloud.ts describes the servers, DNS, certificates, and mail records, and buddy deploy applies them to infrastructure you own. Nothing about production is configured in a console, there is no platform fee, and one small box can run several apps.

  • No build config to own

    STX compiles single-file components on the server without a bundler configuration surface, and buddy dev runs every surface at once.

  • Your own mail server

    Stacks ships an SMTP and IMAP server, so hello@ and support@ on your domain are real mailboxes on your own box, readable in Mail.app or any client. buddy mail:provision creates them and their MX, SPF, DKIM, and DMARC records. None of the frameworks compared here ships one.

Side by side.

The dimensions teams actually decide on.

Dimension Stacks Next.js
Rendering model SSR, SSG with ISR, SPA mode, streaming, islands, server components React server and client components, streaming, Cache Components (PPR)
Data layer First-party ORM, models drive migrations Choose Prisma, Drizzle, Kysely, or raw SQL
Auth Sessions, tokens, passkeys, 2FA, RBAC, gates included Better Auth, Auth.js, Clerk, or a service
Background work Queues, jobs, batches, schedules, workers included Inngest, Trigger.dev, QStash, or your own worker
Admin surface Dashboard generated from your models Build it, or buy Retool or similar
Runtime Bun today, more runtimes planned Node.js, with edge and Bun support varying by feature
Hosting Driver-based: Hetzner, AWS, or any Linux box over SSH Vercel first, with a stable adapter API for other hosts
Language surface TypeScript everywhere, including infrastructure TypeScript, plus whatever your backend services use
Mail server Built in: SMTP, IMAP, real mailboxes None; inboxes come from a hosted provider

If you did move.

What ports cleanly, what does not, and where to start.

Keep Next.js on the front, put Stacks behind it

A Stacks API with generated OpenAPI and a typed client is a normal thing for a Next.js app to consume. This is the lowest-risk way to try it.

Views are the real port

Route handlers and data access map over cleanly. STX has its own JSX runtime, so presentational JSX can come across, but anything built on React hooks or React libraries is a rewrite.

Start with the workloads

Moving queues, mail, and cron out of a Next.js app into Stacks is usually the first thing that pays for itself.

The verdict.

Both answers are real. Most teams already know which paragraph is theirs.

Choose Next.js when

Your interface is React, your team knows it, and you want the largest ecosystem and the easiest hosting story in the industry. Next.js plus a few services is a completely reasonable stack and it is the safe choice.

Choose Stacks when

You are tired of assembling and maintaining the backend half yourself, and you would rather have one typed application with the queue, the mail, the admin, and the deploy already in it, running on servers you own.

The frameworks that usually come up in the same conversation.

Stacks vs The T3 Stack

Best-in-class parts, assembled by you. Stacks is the same territory, maintained as one thing.

Stacks vs React Router (Remix)

Remix v2 lives on as React Router framework mode. Stacks shares its web-standards philosophy and ships more of the stack.

Stacks vs Nuxt

Vue meta-framework with a strong module ecosystem. Stacks brings the application layer under it.