Jo Petrakis

On the library question, honestly: i18next was not designed around this constraint and you feel it. Two data points rather than a recommendation.

next-intl has been publishing guidance for the Cache Components world, and there is an open issue where its Link still triggers a request-context lookup inside a cached scope even when you pass the locale explicitly, so it is not a finished story either. Compile-time approaches like paraglide sidestep the whole problem because messages become plain imports with nothing dynamic to trip over.

I have only run the compile-time route on a small app. Before migrating anything large, go and read the current open issues for whichever one you pick, because this is all moving week to week.

Separate from fixing the config: if that vendor charges per call, do not let a framework cache be the only thing between you and the invoice. Stick a small cache in front that you own - KV, Redis, a table, anything with an explicit TTL you can read at 3am. Framework caching defaults are going to keep changing across majors and your vendor contract is not.

Both. Exclude prefetches now, then move the limiter.

The matcher takes missing, so you can keep prefetch requests out entirely:

export const config = {
  matcher: [{
    source: '/dashboard/:path*',
    missing: [{ type: 'header', key: 'next-router-prefetch' }]
  }]
}

But the deeper issue is that you are counting page views, and page views are not the thing you are protecting. Nobody abuses your app by looking at the dashboard. Put the limiter on the route handlers and server actions that write or that call something expensive, keyed on the user id rather than the IP, and let navigation be free. Your office customers behind one NAT will thank you too.

There is no deprecation. They solve different problems - one is an HTTP endpoint, the other is an RPC call from your own UI. You need HTTP endpoints the moment anything that is not your React app wants to talk to you, including webhooks, which every product eventually receives.

Three things bite, in this order:

1. ISR cache is on local disk by default. One box, fine. The moment you run two containers for a zero-downtime deploy they each have their own cache and users see pages flip between two versions. You need a shared cache handler pointed at Redis, which is another service to run.
2. Image optimisation is CPU and disk. sharp will happily eat a whole vCPU resizing a 4000px phone photo, and the optimised images accumulate on disk until something fills up at 2am. Cap the sizes you allow and put a real cache in front.
3. You become the person who renews the certificate. Caddy makes that mostly automatic, which is why I use it over nginx for this exact setup.

None of it is hard. It is about two evenings up front and an hour a month afterwards. If that hour is worth more to you than $20, stay managed.

Strong agree on doing this before moving. Half the people who migrate to a VPS to escape a bill discover afterwards that one feature was 80% of it, and they now own a server for no reason.

Never seen it put that way and it is immediately obviously right. Anything with future-dated rows - bookings, invoices, renewals, scheduled sends - has to outlive its own furthest row or you are handing the customer your problem.