Is using ioredis in proxy.ts supported for rate limiting? (self-hosted, Node.js runtime, Next.js 16)

[bogdanishere]

Rate limiting in proxy.ts with ioredis (self-hosted, single instance)

Hi! With Next.js 16, proxy.ts now runs on the Node.js runtime, which means packages like ioredis are technically compatible.

I'm self-hosting on a single instance (not serverless) and want to implement rate limiting using my own Redis in proxy.ts. Something like:

// lib/redis.ts
import Redis from 'ioredis';
const redis = new Redis(process.env.REDIS_URL!);
export default redis;

// proxy.ts
import redis from '@/lib/redis';
import { NextRequest, NextResponse } from 'next/server';

export async function proxy(request: NextRequest) {
  const ip = request.headers.get('x-forwarded-for')?.split(',')[0] ?? '127.0.0.1';
  const key = `rl:${ip}:${Math.floor(Date.now() / 1000)}`;
  const count = await redis.incr(key);
  if (count === 1) await redis.expire(key, 2);
  
  if (count > 10) {
    return NextResponse.json({ error: 'Too many requests' }, { status: 429 });
  }
  return NextResponse.next();
}

However, the docs state:

"Proxy is meant to be invoked separately of your render code [...] you should not attempt relying on shared modules or globals."
"Proxy is not intended for slow data fetching."

My questions:

1. Is importing and using a Redis client (ioredis) in proxy.ts officially supported, or could this break in future versions?
2. Does the warning about "shared modules or globals" apply to a persistent Redis connection singleton?
3. For self-hosted single-instance deployments, is proxy.ts the right place for rate limiting, or should this be done in Route Handlers / reverse proxy (nginx, etc.)?

Environment:

• Next.js 16
• Self-hosted
• Own Redis instance

Thanks!

[icyJoseph]

I added that because, if you import a singleton in Proxy, it won't be the same singleton if imported in a render pass or a Route Handler.

You can however, put it in globalThis, but that's mutable share state across requests, which might be good for a redis connection but, like, if you stub user data there, that it is a big no no 🙅 ~~ I don't think we are talking about the thing. Do you mean like next time the proxy is opened, you want to reuse the connection or query the same pool for a connection?

Proxy is meant to only use nodejs AFAIK though, so that bit should be fine.

[bogdanishere]

Thanks for the clarification! That makes sense — the singleton isolation between proxy and route handlers is good to know.

To answer your question: yes, my goal is to reuse the same Redis connection across requests within proxy.ts (connection pooling), not to share state between proxy and route handlers.

My use cases for Redis would be:

• Rate limiting in proxy.ts — quick INCR calls per IP, with a matcher to exclude static assets
• Better Auth — second storage
• Cache handlers — when I scale to multiple instances/clusters, so all nodes share the same cache through Redis

Right now I'm on a single instance (self-hosted), but I'm planning to scale to multiple instances in the future, which is why I want to go with Redis from the start instead of in-memory solutions.

So basically a dedicated Redis client just for proxy.ts, using globalThis to keep the connection alive between requests. Does that sound right?

[icyJoseph]

I mean, appending things to the globalThis object is always gonna be a bit off in my book - is creating a new connection really that bad? What's the actual problem? Don't you want a pool instead anyway?

[bogdanishere]

Sorry for the confusion around globalThis — that wasn't really my point.

A simple module-level singleton like this is all I need:

import Redis from 'ioredis';
const redis = new Redis(process.env.REDIS_URL!);
export default redis;

What I'm really asking is — since proxy.ts now runs on Node.js instead of Edge, can I safely use my own self-hosted Redis with ioredis?

My use cases would be:

• Rate limiting in proxy.ts — INCR calls per IP, with a matcher to skip static assets
• Better Auth — secondary Storage
• Cache handler — so when I scale horizontally to multiple Next.js instances/clusters, all nodes share the same cache through Redis

Just want to make sure everything I mentioned above is the right approach.

[icyJoseph]

Right and that singleton is only used in proxy. I guess it is fine, the module is loaded on first request and then it persists right?

[bogdanishere]

Yes, the module loads on first request and persists.

Quick question though — can I just have a single file like this:

// lib/redis.ts
import Redis from 'ioredis';
const redis = new Redis(process.env.REDIS_URL!);
export default redis;

And import it in all three places (proxy.ts, cache handler, Better Auth)? Since proxy.ts runs in an isolated context, it would get its own instance anyway, right?

[manimovassagh]

To add to the previous answer — yes, using ioredis in proxy.ts works for self-hosted deployments. A few things to keep in mind:

Connection Singleton

The warning about shared modules means that a module imported in proxy.ts is a different instance than the same module imported in a Route Handler or page. They run in separate contexts. But within proxy.ts itself, a module-level singleton works fine:

// lib/redis.ts
import Redis from "ioredis";

const redis = new Redis(process.env.REDIS_URL!, {
  maxRetriesPerRequest: 3,
  lazyConnect: true,
});

export default redis;

The proxy.ts process persists between requests (it is not a cold-start-per-request situation on self-hosted), so the Redis connection stays alive and gets reused. This is what you want.

Rate Limiting Pattern

Your implementation is solid. One improvement — use a Lua script or MULTI/EXEC to make the increment + expire atomic:

import redis from "@/lib/redis";
import { NextRequest, NextResponse } from "next/server";

const WINDOW_SEC = 2;
const MAX_REQUESTS = 10;

export async function proxy(request: NextRequest) {
  const ip = request.headers.get("x-forwarded-for")?.split(",")[0] ?? "127.0.0.1";
  const key = `rl:${ip}:${Math.floor(Date.now() / (WINDOW_SEC * 1000))}`;

  const count = await redis
    .multi()
    .incr(key)
    .expire(key, WINDOW_SEC + 1)
    .exec();

  const current = count?.[0]?.[1] as number;

  if (current > MAX_REQUESTS) {
    return NextResponse.json({ error: "Too many requests" }, { status: 429 });
  }

  return NextResponse.next();
}

Should You Do This in proxy.ts or Nginx?

For a self-hosted single instance, either works. The advantage of proxy.ts is that your rate limiting logic lives in your codebase and you can do per-user or per-API-key limiting easily. Nginx rate limiting is simpler for basic IP-based limits but harder to customize.

Regarding future stability — proxy.ts runs on Node.js and the docs say it supports Node APIs, so ioredis is fair game. The "not intended for slow data fetching" warning is about not doing heavy DB queries that would block the proxy layer. A Redis call that takes <1ms is not what they are warning about.