Stoneware v0.2.0 — Multi-Process Serving, Caching & Developer Diagnostics

Stoneware v0.2.0

Stoneware v0.2.0 focuses on production readiness, correctness, and developer experience.

🚀 What's new

Multi-process / multi-core serving

Stoneware can now serve requests across multiple worker processes on Linux.

stoneware start --workers 4

Stoneware v0.1.8

Stoneware v0.1.8

A production deployment and reliability release.

Highlights

Fixed Vercel asset deployment

stoneware build --target vercel now carries generated CSS and island client chunks inside the server bundle so Vercel cannot omit them from the deployment.

This fixes deployments where:

• the page rendered successfully
• generated CSS returned 404
• island JavaScript returned 404
• normal public/ assets continued to work

Generated assets are still served with long-lived immutable caching.

Security hardening for generated assets

The Vercel asset lookup now uses a Map rather than a plain object.

This prevents inherited property names such as:

• toString
• constructor
• __proto__
• valueOf

from being interpreted as generated assets.

Unknown asset paths now correctly return 404 instead of producing server errors.

Improved deployment diagnostics

stoneware doctor now correctly identifies the Vercel asset fix as requiring Stoneware 0.1.8.

Documentation

• Added the 0.1.8 release documentation.
• Added framework architecture documentation.
• Expanded Vercel/static deployment guidance.
• Documented the history and limitations of the Vercel asset deployment issue.

Validation

• 519 tests passing
• Typecheck clean
• Package dry-run clean
• Vercel CSS verified with HTTP 200
• Island JavaScript verified with HTTP 200
• Binary assets verified
• Traversal and special-property edge cases tested
• Security headers and CSP verified on the new asset path

Upgrade

bun update stoneware

v0.1.7: chore(doctor): warn that 0.1.6 and earlier deploy sites whose assets 404

Stoneware v0.1.7

A reliability, security, diagnostics, and deployment-focused release.

Highlights

Better rendering errors

Stoneware now reports the component path when rendering fails.

For example:

Cannot render a plain object with keys: id, title, price.

in <span>
in <Price>
in <ProductCard>
in <Home>

Error values are described more clearly, including plain objects, Date, Map, and class instances.

Application-thrown error messages are preserved without framework prose being appended to them.

Improved 500 error handling

If a custom _500 page also fails, Stoneware now distinguishes the original application error from the error-page failure.

The original error remains available for diagnosis instead of being masked by a second rendering error.

Vercel deployment assets fixed

stoneware build --target vercel now places generated CSS and island JavaScript under:

public/_stoneware/

This allows Vercel's CDN to serve generated assets correctly.

Generated assets use long-lived immutable caching:

Cache-Control: public, max-age=31536000, immutable

Cross-copy Signals compatibility

Stoneware now recognizes compatible Signals even when multiple copies of @preact/signals-core are present.

This improves compatibility with monorepos, linked packages, and dependency-resolution scenarios without treating arbitrary { value: ... } objects as Signals.

Extensible Content Security Policy

The default CSP remains restrictive, while applications can explicitly allow trusted third-party origins.

For example:

csp: {
  scriptSrc: ["https://www.googletagmanager.com"],
  connectSrc: ["https://www.google-analytics.com"],
  imgSrc: ["https://www.google-analytics.com"],
}

Stoneware preserves its secure defaults and rejects malformed sources that could inject additional CSP directives.

Third-party integrations do not require disabling CSP or adding unsafe-inline.

Styling documentation

The documentation now explains:

• CSS discovery
• co-located CSS
• CSS ordering
• production hashing
• production minification
• island style objects
• the difference between public/ CSS and discovered CSS

Static export documentation

The documentation now covers:

• stoneware build vs stoneware export
• staticPaths()
• dynamic routes
• generated dist/ structure
• 404.html
• static-host deployment
• pages that cannot be statically exported

Deployment documentation

Deployment documentation now covers:

• pre-deployment checks
• STONEWARE_CSRF_SECRET
• stoneware doctor
• dynamic-route export checks
• Cloudflare
• Netlify
• GitHub Pages
• CDN/static deployments
• post-deployment asset verification

Validation

• 492+ tests passing
• Typecheck clean
• Documentation pages rendering successfully
• Vercel CSS and island assets verified with HTTP 200
• Generated assets verified with immutable caching

Notes

Stoneware remains an early-stage framework. The 0.1.x series continues to evolve, and some deployment and runtime capabilities may change in future releases.

Stoneware v0.1.6

Stoneware v0.1.6

A release focused on resilience, observability, performance, and a more reliable development workflow.

Highlights

• Server-side error boundaries — isolate failures to individual server-rendered components with <Boundary>, so one failing widget doesn't take down the entire page.
• Request observability — add an observe hook with route, request kind, status, duration, and caught-error information.
• Faster request path — optimized static-path handling, route matching, and render classification. The measured /plain request path improved from roughly 300 µs to ~80 µs in the benchmark environment.
• Faster development rebuilds — template and static-file changes no longer rebuild unaffected islands.
• Reliable hot reload — fixed the development server creating multiple servers during --hot re-evaluation.
• Production build optimization — server output now uses whitespace-only minification while preserving useful function names, line information, and source maps. Browser islands and CSS remain fully minified.

Error boundaries

import { Boundary } from "stoneware";

<Boundary fallback={<p>Reviews are unavailable right now.</p>}>
  <Reviews rows={rows} />
</Boundary>

Stoneware v0.1.5 — Deployment & Runtime Fixes

What's fixed

🐛 Portable production builds

Fixed an issue where generated Stoneware bundles could contain the absolute filesystem path of the machine that built the application.

This caused deployments to environments such as Vercel to start successfully but fail to resolve routes and assets at runtime.

Stoneware now resolves its runtime root from the deployed bundle instead of relying on the original build-machine path.

🐛 Relocatable route handling

Routes are now represented in the generated build artifact instead of requiring the original routes/ source directory to be present at runtime.

This makes production artifacts portable across build and runtime environments.

🐛 Island hydration in relocated builds

Fixed an issue where interactive islands could silently lose their JavaScript when the source islands/ directory was unavailable at runtime.

The generated island registry is now preserved in the build artifact.

🐛 Development port handling

Improved development-server port detection so Stoneware detects ports already occupied on either IPv4 or IPv6 loopback addresses and automatically selects the next available port.

Production continues to use the exact assigned port and does not silently move to another port.

Verification

• 317+ tests passing
• Typecheck passing
• Relocated production artifact tested
• Route matching tested without the original source tree
• Island hydration verified
• IPv4/IPv6 port collision tested

Upgrade

npm install stoneware@0.1.5

Stoneware v0.1.4 — Production Stability & Deployment

Stoneware v0.1.4

A stability-focused release improving deployment portability, static export security, routing, and production development experience.

What's new

🚀 Deployment & Build

• Relocatable production builds — generated bundles no longer depend on the machine-specific build path.
• Improved route handling using the generated route table.
• Vercel deployment target for Bun-based Vercel functions.
• Improved static export compatibility with Cloudflare Pages, Netlify, and other static hosts.

🔒 Security

• Static exports now preserve Content Security Policy protection.
• Exported sites receive CSP through HTML metadata and _headers where supported.
• Header-only CSP directives such as frame-ancestors remain in HTTP header configuration.
• Existing server-side CSP behavior remains unchanged.

⚡ Development

• Improved development port detection.
• stoneware dev detects ports already occupied on IPv4 or IPv6 and automatically moves to the next available port.
• Production servers continue to use the exact configured platform port.

🗄️ Server & Data

• Server-side database usage documented.
• Applications can use Bun's database APIs or compatible database/ORM packages directly from server code.

📚 Documentation

• Added database documentation.
• Improved deployment documentation.
• Added static export and CSP deployment guidance.
• Updated Vercel deployment documentation.

Validation

• 367 tests passing
• Typecheck clean
• Static export verified
• Relocated build artifacts verified
• Vercel build output verified locally

Stoneware v0.1.3

Stoneware v0.1.3

Stoneware is a Bun-native, server-first web framework where HTML is the default and JavaScript is opt-in.

What's new

• Improved server-side rendering and routing
• Improved islands and hydration behavior
• Security-first defaults
• Improved build and development tooling
• Improved error handling
• Improved framework internals and stability
• Updated release and package tooling

Packages

Install the framework:

npm install stoneware

v0.1.2 — Lazy hydration, static export, error pages, SEO and images

Stoneware Releases

v0.1.2 — Lazy hydration, static export, SEO and images
Released Aug 13, 2026

What's new
──────────

✨ Lazy island hydration
✨ Static export
✨ SEO helpers
✨ Image
✨ Custom error pages
✨ Co-located CSS

🐛 Production caching fixes
🐛 Better error handling

Stoneware v0.1.1

Stoneware v0.1.1

Initial public release of Stoneware, a Bun-native server-first web framework.

Highlights

• Server-first HTML rendering
• Zero JavaScript for routes without islands
• Opt-in interactive islands
• Preact Signals for island reactivity
• No VDOM or client-side tree diffing
• File-based routing
• Automatic HTML escaping
• CSRF protection by default
• Strict CSP by default
• Bun-native build and development tooling
• bunx create-stoneware / npx create-stoneware scaffolding

Installation

bunx create-stoneware my-site
cd my-site
bun install
bun run dev