Server Actions in production: three teams, three regrets, one quiet success
What the framework docs don't tell you about caching, error boundaries, and 03:00 alerts.
Server Actions promised to collapse the boundary between client and server. Three teams we spoke to shipped them to production; here is what the framework docs left out.
The first regret was caching. Actions that mutate data need their revalidation wired explicitly, and the failure mode is silent: stale reads that look fine in development.
The second was error surfacing. A thrown action error with no boundary drops users to a blank screen — the kind of thing you discover at 03:00, not in review.
The quiet success: one team treated actions as a thin transport over a well-tested service layer, and barely noticed the framework at all. That, they argue, is the point.
