Stacks: a full stack TypeScript framework that is honest about being pre-1.0

One framework for apps, APIs, cloud and CLIs

Stacks is a rapid development framework whose stated goal is to help you create and maintain frontends, backends and clouds without having to worry about the boilerplate. The description in the repository is broader still: modern, performant, optimized for DX and AX, for developing powerful apps, clouds and framework-agnostic libraries.

The list of things it claims to cover is the clearest statement of scope. Web and desktop applications including system tray apps. Serverless and traditional APIs. Cloud infrastructure creation and maintenance. Interactive CLIs. Framework-agnostic component and function libraries. And a deployment and release manager for CI and CD.

That is a very wide surface for one project, and the design choice that makes it plausible is the one CLI. The README says Stacks ships with buddy, a single CLI for everything you will do day to day, and that the handful shown covers the common workflows. The central bet is that if every task is reachable from one command with one set of conventions, the breadth stops being a liability.

The runtime diagram makes the same point from the other side. The path runs from a developer to the Buddy CLI to Stacks Cloud, and separately a web or desktop client through rpx to stx, the router, actions, the ORM and the database. That is a described runtime, not a slogan, and the README links an interactive version of the diagram with a theme toggle, node search, route tracing, a presentation mode and exports in SVG, PNG, JPEG, WebP and share-card formats. A framework that documents itself this carefully is a project that expects you to read it.

The note at the top of the README sets expectations honestly. Stacks is in active development and usable today, every section below is real, runnable functionality, and you should expect occasional breaking changes while the official 1.0 is cut. Feedback and issue reports are welcome.

The primary language is TypeScript, the licence is MIT, the homepage is stacksjs.com, and the last push to the repository was on 2026-10-20, with three releases published the same day.

Pantry and Bun: the toolchain is a contract, not a suggestion

The prerequisites section is where Stacks makes demands that other frameworks hide, and understanding them is the difference between a working first hour and a wasted afternoon.

Stacks uses Pantry to provision Bun, Git, SQLite and the project-specific tools declared by the framework. The installation of Pantry itself is a curl command, followed by a single pantry bootstrap run to configure your shell. And the platform requirement is macOS, Linux or WSL, with Windows-native support on the roadmap, because the current toolchain assumes a POSIX shell.

The pinning is explicit. Pantry installs and pins Bun 1.4.2 for this Stacks workspace, and Stacks pins Pantry v0.11.50 as an external toolchain contract. The README then explains the division of responsibility: resolution sources, lockfile and integrity rules, lifecycle trust, registry routes, authentication, storage and failure modes are documented in the source-linked whitepaper references for the package manager and the registry, and Stacks does not redefine those behaviours.

That is an unusual thing for a README to say, and it is a good sign. It means Stacks is not inventing its own package resolution. It is a consumer of a toolchain that has its own specification, and it pins a specific version of that toolchain so that the behaviour of a Stacks project is reproducible. The features that need more than the base, PostgreSQL, Redis and cloud deployment, add their requirements through the same Pantry manifest where possible, with feature-specific configuration documented alongside.

The consequence for a team is that a Stacks project is reproducible in a way that a project with a loose toolchain is not, and the cost is that your environment is shaped by Pantry rather than by you. Both sides of that trade are real, and the version numbers are the thing to keep an eye on when you pin.

The package.json in the repository reflects the same discipline. It declares type module, private true, engines with bun at 1.4.2, and a scripts section where every entry is a thin wrapper around the buddy binary.

The buddy CLI and the two ways to start a project

The daily workflow is a short list of commands:

buddy dev          # start the dev server (frontend, API, dashboard, …)
buddy build        # build for production (CLI prompts for what to build)
buddy test         # run tests
buddy migrate      # run database migrations
buddy make:action UpdateUser   # scaffold a new Action (also: model, view, job, …)
buddy --help       # show every available command

That is a legible surface, and the comments are the project's own, which is a good sign for a tool that wants to be discoverable. The full reference in the README is longer and includes project creation, dependency handling with buddy add, a fresh reinstall, a clean, setup, an optional Oh My Zsh integration, a family of upgrade commands covering the framework, the dependencies, the shell integration, the binary and Bun, and per-area dev servers such as dev:api, dev:dashboard, dev:desktop, dev:views and dev:components. Every command can be suffixed with --help.

There are two ways to get a project. In the browser, a GitHub Codespace provisions Pantry, installs dependencies, runs buddy setup and forwards the dev ports, so ./buddy dev works on first open with nothing to install locally. On your machine, after Pantry is installed, the fastest path is:

panx buddy new my-project

Pantry executes Buddy in an isolated environment and provisions the generated project's declared toolchain during setup. For frontend experiments there is also a live stx starter on StackBlitz, forked straight from the repository.

Two details stand out. The first is that the agent skills are treated as a first-class part of the onboarding: the documentation links skills that teach Claude Code, Codex and Cursor how each subsystem works, which is an unusual and pragmatic way to make an unfamiliar codebase legible to a tool that reads it.

The second is the wording of the CLI comments themselves. Build for production prompts for what to build, and make:action scaffolds a new Action alongside model, view and job. The framework is describing itself in terms of actions, views and models, and the vocabulary of the commands tells you what the mental model is before you read a page of prose.

Environment configuration with encrypted values

The .env.example in the repository is unusually well annotated, and it is the best short description of what a Stacks application looks like on disk.

The first block is application identity and state:

APP_NAME=Stacks
APP_ENV=development
APP_KEY=
APP_URL=stacks.localhost
APP_MAINTENANCE=false
APP_MAINTENANCE_SECRET=
APP_COMING_SOON=false
APP_COMING_SOON_SECRET=

The comment on APP_URL explains that pretty HTTPS URLs are the default development experience and that ./buddy dev routes this hostname through rpx, which uses tlsx for local certificates. That is a small design decision with a large convenience payoff: your local environment gets real HTTPS without you generating certificates.

The maintenance and coming-soon flags with their secrets are a staging feature rather than a general one. Being able to put a deployment into maintenance mode behind a secret is the sort of thing a framework gives you for free.

The database block is where the abstraction shows:

DB_CONNECTION=sqlite
DB_VITESS_SHARDED=false
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=stacks
DB_USERNAME=root
DB_PASSWORD=

The default connection is sqlite, with a comment explaining the Turso option as libsql for a hosted database or http://127.0.0.1:8080 for turso dev. There is also a DB_VITESS_SHARDED flag, which tells you the framework can talk to a sharded Vitess deployment, and a PREDICTHQ_DB_PASSWORD entry, so multiple database backends are anticipated rather than hypothetical.

The part worth reading twice is the encryption section. There is a DOTENV_PUBLIC_KEY and a DOTENV_PRIVATE_KEY, generated by buddy key:generate. The public key encrypts new values set through buddy env:set and buddy env:encrypt, the private key decrypts at runtime and must be kept out of source control in production. Encrypted values look like encrypted:... or enc:... in the file, and they are decrypted automatically at boot by the env plugin in the bunfig.toml preload. Leave both blank in development and run buddy key:generate to create them.

That is a specific, workable answer to the problem of secrets in a .env file, which most frameworks leave to the deployment platform.

The runtime: rpx, stx, a router, actions and an ORM

The runtime diagram in the README is the closest thing to an architecture document, and its components can be read as the layers of a Stacks request.

rpx sits at the edge. It is the piece that routes a hostname through to the application, and the .env comment about APP_URL being routed through rpx with tlsx for local certificates places it in front of the web server. A web or desktop client talks to rpx.

stx comes next, and the StackBlitz live starter is described as the stx starter, so stx is the front end layer of a Stacks project. The .env comment about the dev server starting the frontend, API and dashboard, and the buddy commands dev:views, dev:components and dev:dashboard, confirm that a Stacks project has separable front ends rather than one monolithic web tier.

Behind that come the router, the actions, the ORM and the database. Actions are the unit of work: buddy make:action UpdateUser scaffolds one, and the same generator handles model, view, job, migration, notification, factory and lang, with make:stack available for pulling in a whole registered project-shaped stack, which is what buddy add calendar does.

The Cloud side is separate again, with a cloud/ directory in the repository and Stacks Cloud in the diagram as the destination of the Buddy CLI. The claim is cloud infrastructure creation and maintenance, plus a deployment and release manager for CI and CD, and there is a deploy script in package.json and a release script.

What the diagram does not tell you, and what you will have to read in the docs, is where the boundaries between those layers actually enforce anything. In particular, the repository has separate app/, routes/, resources/, database/, config/ and storage/ directories, and the storage/framework/core/buddy/src/cli.ts path in the package.json scripts shows that the CLI itself lives inside the framework's own storage tree, with a bootstrap script at the root. The framework is unusually willing to show you its own plumbing, which is a good sign for a project still finding its shape.

Where Stacks is the wrong tool

The first limitation is stated by the project itself. Windows-native support is on the roadmap, and the current toolchain assumes a POSIX shell, so a Windows developer without WSL is out of luck today.

The second is the toolchain requirement. A Stacks project needs Pantry, and Pantry provisions Bun, Git, SQLite and the project-specific tools. That is a coherent and reproducible setup, and it is also a commitment. If your organisation standardises on Node with a different package manager, or your CI images are not allowed to install a package manager, Stacks does not fit, and the reason is not the framework code but the provisioning layer under it.

The third is the pre-1.0 churn. The README says to expect occasional breaking changes while the official 1.0 is cut, and the release numbers show how fast this is moving: v0.75.239, v0.75.240 and v0.75.242 were all published on 2026-10-20, the same day as the last push. For a team with a long-lived application, that rate of change is a genuine cost, and the project is candid about it rather than hiding it.

The fourth is the scope mismatch. If you only need a web frontend, or only a CLI, adopting a framework whose stated purpose is to cover frontends, backends, clouds, CLIs, libraries and deployment is a lot of machinery for a small job. The framework-agnostic library claim is the escape hatch, but the documentation and the tooling assume a full Stacks project.

The fifth is the version mismatch inside the repository itself. The package.json in the repository carries version 0.70.52 while the published releases are in the 0.75 line, which is a sign that the version in the working tree lags or is set differently from the release line. If you read the docs for 0.75 and clone a tree that says 0.70, you may hit differences that have nothing to do with your code.

The last point is about ownership. Stacks is a single project with a single commercial-looking home at stacksjs.com, funded through GitHub Sponsors and with a named main contributor. That is a legitimate way to build a framework, and it also means the roadmap is one person's roadmap.

Licence, release rhythm and the shape of the project

The licence is MIT, recorded in the package.json metadata and in the LICENSE.md file at the root of the repository, and this article does not interpret it. For a framework whose output is application code you own, a permissive licence is what you would want, and the README's emphasis on staying in control and ownership of your and your users' data is consistent with that choice.

The release rhythm is the most striking fact about the project. Three releases on a single day, v0.75.239 in the early morning, v0.75.240 a couple of hours later and v0.75.242 later still, with the last push at midday. That is a continuous delivery cadence in the literal sense, and it is what an ambitious pre-1.0 framework looks like from the outside.

The repository layout supports the same impression. There is a CHANGELOG.md and an AGENTS.md, a devcontainer configuration, a bootstrap script and a buddy entry point at the root, a bench/ directory, a logsmith.config.ts, a deps.yml and a pantry.lock, bun.lock and bunfig.toml for the JavaScript side, and separate directories for app, cloud, config, content, database, docs, locales, public, resources, routes, storage and tests. The locales directory and the make:lang command suggest localisation is part of the framework rather than an afterthought, and the resources and content directories suggest a distinction between static content and other resources that you will need to understand.

The open questions for an adopter are all about stability rather than capability. Every capability the README describes is described as real and runnable, and the code is MIT licensed, so nothing prevents you from building on it today. What changes is how you absorb upgrades. With releases arriving several times a week, a team that wants a stable application should pin a version and treat the framework as vendored, and a team that wants to move with the project should be prepared to read changelogs before every dependency bump.

My reading is that Stacks is at the point where the ideas are ahead of the stability, and the honest thing for an engineering team to do is to pick one of those two postures deliberately rather than drift into the second one by accident.

Editorial conclusion

Adopt Stacks if you want a single TypeScript stack that covers the web app, the API, the database migrations, the deployment and the scaffolding, and you are prepared to track a fast-moving pre-1.0 framework with the toolchain it pins. Do not adopt it if you need Windows-native support, if you cannot accept a POSIX-only toolchain, or if a project that changes shape every few weeks is a problem for your team. Verify first that the version you install matches the docs you read, that your environment meets the Bun and Pantry pins, and that the licence and the deployment story are acceptable, since the licence is MIT, the newest release is v0.75.242 from 2026-10-20, and the last push was on 2026-10-20.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. stacksjs/stacks on GitHub