Server Actions in production: three teams, three regrets, one quiet success

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.