HttpRouter.serve: two servers in one layer graph share the same router

[florianbepunkt]

Not sure whether this is a bug or by design. For us it created a security issue. If you run two HttpRouter.serve layers on different ports in the same app, each server also answers the other one's routes.

As far as I can tell, serve provides the module-level HttpRouter.layer, and since layers are memoized by reference, every serve in the same Effect.provide / Layer.launch ends up with the same router instance.

Repro:

import { Effect, Layer } from "effect"
import { HttpRouter, HttpServerResponse } from "effect/unstable/http"
import { BunHttpServer } from "@effect/platform-bun"

const internal = HttpRouter.add("GET", "/internal", HttpServerResponse.text("internal"))
const pub = HttpRouter.add("GET", "/public", HttpServerResponse.text("public"))

const Servers = Layer.mergeAll(
  HttpRouter.serve(pub).pipe(Layer.provide(BunHttpServer.layer({ port: 3000 }))),
  HttpRouter.serve(internal).pipe(Layer.provide(BunHttpServer.layer({ port: 3001 })))
)

const status = (url: string) => Effect.promise(() => fetch(url).then((r) => r.status))

Effect.gen(function*() {
  console.log("GET :3000/internal ->", yield* status("http://localhost:3000/internal"))
  console.log("GET :3001/public   ->", yield* status("http://localhost:3001/public"))
}).pipe(Effect.provide(Servers), Effect.runPromise)

GET :3000/internal -> 200
GET :3001/public   -> 200

I'd expect 404 for both.

Passing routerConfig doesn't change anything, since it still wraps the same layer. What works for us is giving each app layer its own router:

HttpRouter.serve(Layer.provideMerge(app, Layer.fresh(HttpRouter.layer)))

We hit this in production: a route that was only meant for an internal port was reachable on our public one, and nothing in the code hinted at it, since the two servers look completely independent. Would it make sense for serve to use Layer.fresh(layer) internally? If the sharing is intended, a short note in the serve docs would already help.

[84dnnvbdvp-debug]

There’s a second memoization regression worth pinning alongside the two-server leak.

Current HttpRouter.serve() builds RouterLayer from the module-level HttpRouter.layer, then provides that layer to appLayer. In v4 the MemoMap is shared across provides, and Layer.fresh is the explicit opt-out for a layer that must be rebuilt independently.

So I’d make the acceptance test two-sided rather than only asserting that routes stop leaking between server roots:

1. Distinct server roots are isolated. Server A registers /a1 + /a2; server B registers /b. A must serve both A routes and 404 /b; B must serve /b and 404 both A routes.
2. Intentional registration reuse still works. Reuse the same route-registration layer in two separate serve calls. Both servers should receive those routes.

The second case matters because freshening only the singleton router provider can fix the original cross-server sharing while exposing the inverse failure: a reused appLayer is itself a Layer value, so shared v4 memoization can cause its registration side effect to run against one fresh router and then be reused instead of registering against the other.

I’d keep the implementation open, but the invariant seems to be: router-dependent registration gets a per-serve memoization boundary, while route layers composed inside one server still share that server’s router. That catches both accidental cross-server union and accidental under-registration after the isolation fix.