Imagine you maintain a Next.js site on AWS Amplify. You add a library for a new customer feature, the build completes, and deployment fails with “the size of the build output exceeds the max allowed size.” The visible change is small, but the server files shipped with it have pushed the release over the limit.
As you add features, it's easy to bring more into the server output than you expect from the page alone. If trimming those files has become part of shipping each release, try deploying the Next.js app on Forte. You can build from the same GitHub branch and test it before changing where customers go.
Why the browser bundle doesn't tell the whole story
Your browser downloads the JavaScript and assets needed to show a page. An SSR host also needs the code and files used by the server. A library used only to generate a document on the server can increase deployment size without adding much JavaScript to the browser.
Next.js traces imports and file access during a build to identify files needed in production. The resulting server output depends on what your app uses, including dependencies and files read from disk. A small source change can affect which files get deployed. Next.js output file tracing
For example, a hypothetical customer portal adds an export route that needs fonts and a document renderer. The team should check those files in the generated output. Counting React components or looking only at browser JavaScript won't show the full server package.
Recognize the limit you're hitting
An Amplify error naming 230686720 bytes points to the SSR build-output size limit. AWS's troubleshooting guide calls this 220 MB. That byte count equals 220 MiB. AWS build-output troubleshooting
Inspect the deployment artifacts to see which files take up space. If the output includes unused dependencies or files that belong only in the build environment, removing them can help. Retest the routes that load files at runtime so a smaller artifact doesn't become a broken release.
Avoid deleting a large package just because it appears in an online cleanup script. If your image route or export feature needs that package, the next request may fail after deployment. The useful question is whether the running app needs the file.
When the required server output is the problem, moving to Forte is an alternative to maintaining more Amplify-specific cleanup steps.
Let Forte build from the repository
Forte reads your repository to detect how the site builds. For Websites, that includes the framework, package manager, Node.js version, build command, and output directory. You can override those settings when detection doesn't match the project. See the Forte website deployment guide.
For the customer portal, start with a separate deployment using the branch that Amplify rejected. In the Forte console, select a Project, open Websites, and create a Website connected to that GitHub repository and branch. Grant the Forte GitHub App access to the repository first.
Copy the settings the app needs, rather than pasting the Amplify build file into the new setup. That file may include packaging or cleanup commands written for Amplify. Forte runs its own build pipeline from your source.
Pay attention to when each setting is read. Next.js can include public environment values in browser code during the build. A successful deployment can still call the wrong API if the build used the old address. Inspect a browser request to confirm the destination, and keep private keys out of public variables.
Choose how to host the app
A Website can host a static or server-rendered frontend. Website requests bypass the Forte gateway, so Forte doesn't enforce end-user sessions or provide Service request records for that traffic. An SSR Website must enforce its own authentication where needed.
If the Next.js app also holds backend logic that needs Forte's server-side API, request records, or authentication enforcement, deploy it as a Service. Services build and run containers behind Forte's managed ingress. You can also host the frontend as a Website and put privileged backend routes in a separate Service.
Choose based on what handles each request. The Website overview explains the runtime boundaries, including request duration and caching. In particular, check revalidation behavior if the site expects cached pages to update after an edit.
Prove the feature works on the new host
Use Forte's generated URL to load the portal, sign in with a test account, and run the export. Open the resulting document and check that its fonts and images are present. Then refresh a nested page and try a request the account shouldn't be allowed to make.
If the app writes data, save a test record and check it through the existing app. This helps confirm that both deployments use the intended database. Pause duplicated scheduled work while testing so two deployments don't send the same notification or process the same job.
Keep the domain on Amplify until these checks pass. Then connect it using the custom-domain setup, update callback settings that depend on the domain name, and test through the public address.
The next release should be about whether the feature works for customers. Deploy the branch on Forte and check that behavior directly, without making another round of Amplify artifact trimming the first task.