Hi - my team and I are currently using the Ory Network Production Plan, where we have one project that uses the Developer Plan for our local dev environment. For this project we are using the

ory tunnel

feature from the Ory CLI. Everything works fine, but from time to time we are experiencing rate-limit issues (HTTP 429), which are not lining up with the project rate limits for the Developer Plan from the docs (see here). For example it says that it should allow 10

/sessions/whoami

calls per second (burst). I tried to debug this using the Apache Benchmark tool, where I send 10 request in parallel to this endpoint and made the following discovery: • when firing 10 parallel request against the Ory tunnel (localhost), only the 1st request will be successful, but for the other 9 I'm getting a 429 error. • when firing 10 parallel request against the Ory project URL (https://{ory-project-slug}.projects.oryapis.com), all 10 request will be successful. So it seems that the Ory tunnel is using different/lower rate-limits? I this a known limitation and is it possible to bypass this restriction?

Ya, we run into similar rate limit issues on developer projects as well from time to time

the tunnel uses the same api endpoints, so the same rate-limits get applied maybe your testing was a bit off and affected by e.g. colleagues using the same project, or you did not wait for enough time between the runs?

I just tried it once again, but the behaviour is always the same. When sending 10 requests to the tunnel, now 7 out of 10 returned 429. Afterwards I sent 10 requests to the ory-project URL directly, and all 10 worked. I'm currently the only person using this, so it should actually not be affected by colleagues.

hm interesting... what is your project slug?

suspicious-wozniak-by8qc6gqla

the tunnel really only forwards the requests to your project url, so I see no obvious reason for this behavior

No, this project is a "Development" project, so I can't even turn on edge sessions for it.

Oh, I thought the burst limit was 10 for everything. Didn't realize it is actually 5 for most requests, which matches up with the behaviour we are seeing.