Middleware VS Proxy

MuseMVP keeps src/middleware.ts by default to stay compatible with multiple deployment targets while keeping request-entry logic minimal.

Why use middleware.ts instead of proxy.ts

• The template needs to support multiple deployment targets (such as Vercel, Cloudflare Workers, and Node.js), so keeping middleware.ts as a unified entry is more reliable.
• The current middleware only handles request-entry responsibilities (such as locale routing, rewrite/redirect, and matcher filtering), and does not carry business auth decisions.
• A unified entry reduces maintenance costs and regression risks caused by platform differences.

If you are not deploying on Cloudflare Workers or Node.js, you can switch to proxy.ts (with sample prompt)

During migration, keep behavior unchanged and only adjust file conventions:

• Rename middleware.ts to proxy.ts
• Change the exported function name from middleware to proxy
• Keep the original matcher and rewrite/redirect order

You can directly copy the prompt below to AI (and paste your current middleware.ts code at the end):

I'm working in a Next.js (latest version) project.
All other code already follows the latest Next.js conventions.

I currently have a middleware.ts file, but in the latest version this should be implemented as proxy.ts.

Please:

Convert the following middleware.ts logic into the correct proxy.ts format.

Ensure the implementation follows the latest Next.js best practices.

Adjust any API differences if necessary.

Keep the behavior exactly the same.

Assume the project uses the App Router.

Here is my current middleware.ts:

// paste middleware.ts code here

Return:

The complete proxy.ts file

A short explanation of any necessary changes