v0.0.2-alpha.71

Before you upgrade

1. Security: upgrade to pick up zod 4.6.7 and DOMPurify 3.4.17 (#2765). zod before 4.6.6 could run out of memory validating a very large array against an array schema without a length limit (GHSA-mrhx-c7xc-m3w5). DOMPurify's advisories (GHSA-cg2g-xh64-v4q7, GHSA-mrv2-3pqr-j5jr) affect modes Nextly's SVG sanitizer does not use, but the floor rises so no install resolves an affected version. Nothing to change in your project.
2. Local uploads under next start need one route file (#2756). New projects don't ship it yet. To have a production server serve files uploaded after it started, add src/app/uploads/[...path]/route.ts (or app/uploads/[...path]/route.ts without a src/ folder) exporting GET and HEAD from createUploadsHandlers({ config }) in nextly/api/uploads, as Media & Storage shows. Without it, behaviour is as before, and the server logs a warning the first time an upload would be unreachable. Cloud storage (S3, Vercel Blob, UploadThing) is unaffected.

Released 21 packages at 0.0.2-alpha.71 in lockstep. Every package below ships at this version.

What's changed

Patch Changes

• #2756 709babb Thanks @mobeenabdullah! - A production server (next build and next start) now serves a file uploaded to Nextly's default local-disk storage as soon as the upload finishes, at the same /uploads/... URL next dev gives it. Before, Next.js answered 404 for it until the server restarted, because next start serves only the files public/ held when it started. A route at src/app/uploads/[...path]/route.ts, built on the new nextly/api/uploads export, serves the rest: it streams files, answers Range requests for video and audio, sends ETag and caching headers, sets nosniff and a script-blocking policy on SVGs, and answers 404 for any path outside the storage folder and whenever cloud storage holds media. The local adapter's check that a path stays inside its folder no longer accepts a sibling folder whose name starts with the folder's own, such as public/uploads-private beside public/uploads.

  Before you upgrade: projects don't ship the uploads route yet, so an app keeps the old behaviour until it has one. Add src/app/uploads/[...path]/route.ts (or app/uploads/[...path]/route.ts without a src/ folder) exporting GET and HEAD from createUploadsHandlers({ config }) in nextly/api/uploads, as shown in Media & Storage. Until then, a production server logs a warning naming the file the first time an upload would be unreachable.

• #2765 ed1b2f1 Thanks @nextly-agent! - Security: zod moves to 4.6.7 and DOMPurify to 3.4.17.

  • zod before 4.6.6 could run out of memory validating a very large array against an array schema without a length limit (GHSA-mrhx-c7xc-m3w5). Every package that validates input with zod gets the fixed version.
  • DOMPurify before 3.4.17 had sanitizer bypasses in its SAFE_FOR_TEMPLATES, DOM-output and IN_PLACE modes (GHSA-cg2g-xh64-v4q7, GHSA-mrv2-3pqr-j5jr). Nextly's SVG upload sanitizer uses none of those modes, so it was not affected; the floor still rises, so no install can resolve an affected version.

Packages

• @nextlyhq/adapter-drizzle
• @nextlyhq/adapter-mysql
• @nextlyhq/adapter-postgres
• @nextlyhq/adapter-sqlite
• @nextlyhq/admin
• @nextlyhq/admin-css
• @nextlyhq/blocks-engine
• @nextlyhq/blocks-react
• @nextlyhq/builder
• @nextlyhq/eslint-plugin
• @nextlyhq/plugin-form-builder
• @nextlyhq/plugin-mcp
• @nextlyhq/plugin-page-builder
• @nextlyhq/plugin-sdk
• @nextlyhq/plugin-seo
• @nextlyhq/storage-s3
• @nextlyhq/storage-uploadthing
• @nextlyhq/storage-vercel-blob
• @nextlyhq/ui
• create-nextly-app
• nextly