Introduction
I changed the Next.js build configuration after sst deploy failed in a monorepo. The build hadn't produced the output artifacts deployment expected, so the deployment attempt reported missing files. The repair combined two settings: standalone output and an explicit file-tracing root pointing to the application directory. After both changes, I ran a clean build. It produced the expected output without errors and resolved the missing-files issue that had blocked deployment.
That result is narrower than a successful deployment. I haven't verified an end-to-end deployment or the deployed application's runtime behavior from the available evidence. I also can't attribute the original failure to either setting alone, because both changed together. The useful distinction is between the output packaging requires and the tracing boundary used to assemble it. Verifying those artifacts matters, but a successful build doesn't prove that everything downstream works.
The Rule That Shipped
In next.config.ts, I set output to 'standalone' and explicitly set outputFileTracingRoot to the app's own directory rather than the monorepo root. Those are the two parts of the shipped configuration. The prior effective tracing-root value isn't recorded, so this describes the chosen configuration, not a confirmed change from a known previous value.
Standalone output produces a server directory containing the server output and traced dependencies. It is intended to provide a self-contained server bundle within the limits of that tracing, not to guarantee that every application file or deployment asset is included. In particular, public and .next/static aren't copied into standalone output by default. Deployment tooling or the packaging process must handle them separately. The evidence doesn't establish how those assets were handled here.
outputFileTracingRoot sets the boundary within which tracing can include files; it isn't simply the directory where dependency traversal starts. Next.js normally uses the project directory as that boundary. This configuration explicitly used the application directory, but an app that depends on sibling workspace files may need a broader root. The setting worked for this case. It isn't a universal monorepo rule.
Worked Example
The input was an SST deployment of a Next.js app inside a monorepo, before standalone output and the explicit application-directory tracing root were configured. Running sst deploy failed because expected build output was absent, and deployment reported missing files. The literal error text and specific missing filenames or paths aren't recorded, so I can't reconstruct which artifact lookup failed.
I then set output to 'standalone' and outputFileTracingRoot to the app directory in next.config.ts. A clean build after that combined change produced the expected output without errors. This resolved the missing-files issue blocking deployment and allowed deployment to proceed. It doesn't establish that deployment subsequently completed.
The before-and-after supports the combined configuration as the successful repair in this case. It doesn't show whether standalone output alone would have been enough, whether the tracing-root setting was independently necessary, or how the previous effective configuration contributed to the failure. Without the original paths and configuration, a more specific diagnosis would go beyond the evidence.
Challenges and Tradeoffs
The main tradeoff is between producing the server output packaging expects and making sure tracing includes the files the app needs. Standalone output moves dependency selection into the build, but it doesn't remove monorepo dependency concerns. Shared workspace files still need to fall within an appropriate tracing boundary and be captured by tracing.
An application-directory root can exclude sibling packages outside that directory. An app that uses those files may need a broader monorepo root, though broadening the boundary doesn't prove that every required file has been included. Likewise, the successful build here isn't a reason to replace an application-directory root with a broader one without examining the app's dependencies. The right boundary depends on the required files, not just on whether the repository is a monorepo.
Another possible approach is to package the server and dependencies without relying on standalone output. That would require a packaging process suited to that output structure, and it wasn't verified in this case. Either way, server dependencies and static assets remain separate concerns. Missing build artifacts, omitted runtime dependencies, and absent static assets can all cause failures, but the recorded failure here establishes only missing build artifacts.
Verification Process
My completed verification was a clean build after both configuration changes. It produced the expected output without errors and resolved the previously observed missing-files blocker. That's the strongest supported comparison: the earlier deployment attempt lacked required build output, while the subsequent clean build generated the expected output.
The record doesn't include an artifact inventory, the original error message, or a complete deployment log. I therefore can't name the repaired files, claim that I inspected a particular directory, or say that SST's full packaging and deployment sequence passed. I also haven't verified runtime dependency completeness, static-asset delivery, or behavior after deployment.
Further checks would address those gaps separately. Comparing the generated output with the deployment tool's requirements would make the required artifacts explicit. Confirming how public and .next/static are handled would cover assets that standalone output doesn't copy by default. Completing deployment and exercising server behavior, including any shared workspace dependencies, would test beyond build success. These checks remain undone; their outcomes can't be inferred from the clean build.
Conclusion
I resolved the recorded build-output blocker with two settings in next.config.ts: output set to 'standalone' and outputFileTracingRoot explicitly set to the application directory rather than the monorepo root. The clean build afterward produced the expected output without errors, allowing deployment to proceed past the missing-files issue.
The limits still matter. The original error text and missing filenames are unavailable. The prior effective tracing-root value, and exactly how it differed from the application directory, are unspecified. Because both settings changed together, the result doesn't isolate either one as the cause or sole repair. Whether this fix generalizes to other monorepo layouts or deployment targets is also unverified. This is a supported build repair for the recorded SST setup, not proof of completed deployment, runtime correctness, or a tracing-root rule for every monorepo.