Repository navigation
chore(vercel): run functions in fra1, next to Upstash - #261
Conversation
Functions ran in Vercel's default iad1 while the Upstash database is in eu-central-1, so every Redis call crossed the Atlantic (~85 ms, measured on production). Redis is on the hot path of every signed-in request: the session cookie lookup, the OAuth request lock (TECH-807, which takes the lock twice per proxied call and serialises one user's parallel requests), the session store and the rate limits. On production a burst of 12 parallel same-session reads took up to 6.3 s; the same burst of public reads, which skip the session, took 0.5 s. Pin all functions to fra1 (Frankfurt), the same region as the database and the rest of our infrastructure. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Configure and document the function region vercel.json, AGENTS.md |
vercel.json sets the function region to fra1. AGENTS.md documents the region, Redis placement, and the preferredRegion guidance. |
Priority:
Estimated code review effort: 1 (Trivial) | ~5 minutes
Change: Other
Suggested reviewers: holkeb
Merge Risk: 
Minimal · up to 70d26
-
No actionable merge-blocking risk was found in this configuration-only change.
Pre-merge checks: 
5
-
Full details: Docstring Coverage
-
Explanation
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.)
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
…he EU Review follow-up to 3430f27. The project's dashboard default function region was still iad1 (vercel.json overrides it per deployment); it is now fra1 too, so AGENTS.md says to keep both in step. Also records that staging's Upstash database is in eu-central-1 as well, and which upstreams are EU-hosted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…p data runs (TECH-813) Upstash, Inc. hosts certified.app's Redis database (production and staging, AWS eu-central-1 / Frankfurt). It holds personal data: sign-in sessions (cookie -> DID mapping, OAuth tokens and DPoP keys), short-lived OAuth state and unlocked app-password sessions, and rate-limit counters keyed by IP address or DID. The policy's processor list (section 8) didn't name it. - Section 8: add Upstash, Inc. (sign-in session, authentication and rate-limiting data, hosted in Frankfurt, Germany). - Section 6: say that certified.app's server functions (fra1 since #261) and its session data are in Frankfurt; the section only described the certified.one PDS infrastructure. - Last updated: October 29, 2026. Transfers outside the EU stay covered by section 6's SCC paragraph. The wording needs legal review before it ships. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Hotfix to
main: run Vercel functions infra1(Frankfurt), next to the Upstash database (eu-central-1). Already onstaging(3430f27). After merge, main and staging hold identical files.Why
Functions ran in Vercel's default
iad1(Washington DC), so every Redis call crossed the Atlantic. Measured on production after #260:/api/auth/session(four Redis calls in a row) has a median of 542 ms; an endpoint without Redis takes 185 ms.x-vercel-id: fra1::iad1::…: requests enter Vercel in Frankfurt, run in Washington DC, and call Redis back in Frankfurt.Our infrastructure is in Europe; only Bluesky services (plc.directory, the Bluesky AppView and bsky.network PDSes) are in the US, and calls to those get slower from Frankfurt.
Change
vercel.json:"regions": ["fra1"]. No region was set anywhere before (novercel.json, nopreferredRegion).Review (three subagents: Vercel config, outbound latency, region-bound side effects)
regionsinvercel.jsoncovers every function, includingsrc/proxy.ts, which runs as a Node lambda in the function region. The deployment API showsregions: ["fra1"]on staging (the previous staging deployment showediad1). Nothing else about the deployment changed. The project's dashboard default was stilliad1; it is nowfra1too, so both agree.*.host.bsky.networkPDSes, Resend). The noticeable case is profile resolution for many Bluesky-hosted identities on a cold cache (/api/resolve-dids, up to about +0.6 to 1.3 s), plus uncached handle lookups in page metadata. Caching is the follow-up; don't give those routes apreferredRegion, because they also use Redis.Testing
x-vercel-id: fra1::fra1::…on/api/auth/session. Pages, public xrpc reads and the well-known endpoints all answer normally.🤖 Generated with Claude Code
Summary by CodeRabbit


Confidence Score: 5/5
This PR appears safe to merge.Summary
Sets Vercel functions to
fra1and documents why they should stay near Redis.Reviews (1) · Last reviewed commit: "docs(agents): record the dashboard regio..." · Reviewed by Greptile