|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: Next.js output modes — Standalone vs Default build |
| 4 | +description: Learn about different output modes in Next.js and find out which of them would be the best for you. |
| 5 | +date: 2025-12-12 |
| 6 | +cover: /images/blog/nextjs-output-modes/cover.png |
| 7 | +timeToRead: 5 |
| 8 | +author: atharva |
| 9 | +category: tutorial |
| 10 | +featured: false |
| 11 | +--- |
| 12 | + |
| 13 | +Next.js is a very popular React framework. People choose it because it blends in with the server very well, using both client-side and server-side capabilities to provide a better user experience. Next.js is packed with cutting-edge React features like RSC. However, such features also bring complexity when deploying your app. |
| 14 | + |
| 15 | +Appwrite Sites enables you to deploy your Next.js app seamlessly without any hassle of configuration. Appwrite handles all the complexity involved in deploying such apps, so that you can focus on the core logic of your app. |
| 16 | + |
| 17 | +However, we also allow you to fiddle with the behaviour of how deployments work with Appwrite Sites. Output modes allow you to decide how your Next.js app is bundled. Each mode has its own pros and cons. |
| 18 | + |
| 19 | +In this article, we will talk about the different Next.js output modes, what would be better for you, and what we have observed when using different output modes with Appwrite Sites. |
| 20 | + |
| 21 | +# The "default" mode |
| 22 | + |
| 23 | +The default mode relies on your dependencies stored in your `node_modules` and the build bundle stored in `.next` folder after running `next build`. To run your app in this output mode, you should run `next start` to serve your app in production. |
| 24 | + |
| 25 | +It's important to note that if you remove `node_modules`, which usually is the biggest chunk of your app, your app won't run anymore, as your builds also rely on `node_modules` to work properly. So, when counting the size of your app, you should also count in `node_modules` folder as well. |
| 26 | + |
| 27 | +The default mode is typically deployed by running `next start`. This is convenient, but gives you less control over the underlying server process than approaches where you own the server entrypoint (e.g., injecting custom server logic/handlers as part of your runtime). |
| 28 | + |
| 29 | +You might already think that shipping `node_modules` takes a big hit on storage, and while it's true, but not always a bad thing. We will later look at why. |
| 30 | + |
| 31 | +# The "export" mode |
| 32 | + |
| 33 | +Even though we won't be comparing this mode in our benchmarks later in the article, we will still talk about it. |
| 34 | + |
| 35 | +The "export" mode is a mode that allows you to export your app as a static site. This mode is useful if you want to deploy your app as a static site. |
| 36 | + |
| 37 | +To use this mode, configure `output: 'export'` in `next.config.js` and run `next build`. This will create an `out` folder that you can serve with any static hosting provider. |
| 38 | + |
| 39 | +# Standalone mode |
| 40 | + |
| 41 | +When building your app in standalone mode, Next.js traces all the files that are required by your app from your `node_modules`. This means that only the functionality your app uses will be bundled into your Next.js build. In this case, you can exclude `node_modules` when calculating sizes, as the build doesn't rely on `node_modules` as it already bundles all necessary code. |
| 42 | + |
| 43 | +This results in bigger `.next/standalone` folder, but we also have to factor in the fact that `node_modules` are essential for the default mode, and not the standalone mode. |
| 44 | + |
| 45 | +The `.next/standalone` folder does not contain any static assets, and Next.js recommends serving them through a CDN. For a minimal setup, you can run a few commands to copy static assets into the standalone directory. |
| 46 | + |
| 47 | +Even with all the benefits, there's a very good reason for this mode not being the default yet. |
| 48 | + |
| 49 | +# Our observations |
| 50 | + |
| 51 | +We prepared a [benchmark](https://github.com/appwrite-community/nextjs-outputs-bench) where we ran the `next build` command for four Next.js apps to check how large their build sizes were: |
| 52 | + |
| 53 | +1. Default mode, no dependencies |
| 54 | +2. Standalone mode, no dependencies |
| 55 | +3. Default mode, very heavy dependencies |
| 56 | +4. Standalone mode, very heavy dependencies |
| 57 | + |
| 58 | +Then, we compared the sizes of these builds and observed the following: |
| 59 | + |
| 60 | +``` |
| 61 | +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ |
| 62 | + 📈 Summary & Comparisons |
| 63 | +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ |
| 64 | + |
| 65 | + 🔹 No Dependencies - Default vs Standalone |
| 66 | + Default: 431.42 MB (.next + node_modules) |
| 67 | + Standalone: 57.84 MB |
| 68 | + 📉 Difference: 373.58 MB smaller |
| 69 | + |
| 70 | + 🔹 Heavy Dependencies - Default vs Standalone |
| 71 | + Default: 712.48 MB (.next + node_modules) |
| 72 | + Standalone: 57.84 MB |
| 73 | + 📉 Difference: 654.64 MB smaller |
| 74 | + |
| 75 | + 🔹 Impact of Heavy Dependencies |
| 76 | + Default mode: +281.06 MB (65.1% increase) |
| 77 | + Standalone mode: +0 KB (0.0% increase) |
| 78 | +``` |
| 79 | + |
| 80 | +The result was clear: standalone mode consistently showed lower build sizes. Interestingly, even when we installed heavy dependencies in the app, we observed that the build size for the apps with standalone mode remained unchanged. Because those dependencies were not being imported and used in the app, they were not bundled, which is ideal. Lower build sizes also result in faster cold starts for your app, which creates a better user experience. |
| 81 | + |
| 82 | +# Which is the best for me? |
| 83 | + |
| 84 | +Standalone mode seems to be the clear winner based on the results. That would make you think—why is it not the default? Because it's not the most reliable. There are some very unclear cases where your standalone build would break or cause problems in production: |
| 85 | + |
| 86 | +- If you use monorepos and import packages from it, you might need to configure Next.js to be able to trace those packages. |
| 87 | +- If you dynamically import packages in your app, standalone mode cannot help you here, as only the code that is used and can be traced is bundled. |
| 88 | +- There could be many weird edge cases here and there. |
| 89 | + |
| 90 | +**So what's the best for you?** Try out standalone. If something goes wrong, you can switch back to default mode. If you're building a very basic Next.js app, you will not go wrong with standalone mode. |
| 91 | + |
| 92 | +# Wrapping up |
| 93 | + |
| 94 | +Next.js standalone output is very powerful and could help you a lot when deploying your app. Standalone mode is fully supported on Appwrite Sites, so you can reap the benefits of it now! |
| 95 | + |
| 96 | +- [Next.js standalone builds now supported on Appwrite Sites](/blog/post/nextjs-standalone-support-in-appwrite-sites) |
| 97 | +- [Everything new in Next.js 16](/blog/post/everything-new-in-nextjs16) |
0 commit comments