Standalone Next.js. When serverless is not an option

This article is part of the in-depth series about self-hosted Next.js and the challenges around it.

Serverless architecture has many benefits, yet you should also consider its downsides when choosing an approach that works best for your specific case.

• Cold Starts: Server functions may have performance issues due to Lambda cold starts, impacting user response time. Some providers have minimal delays (like Cloudflare Workers due to V8 engine), while others may require workarounds. For example, periodically invoking the server function to keep it "warm," which adds complexity and cost.
• Execution Limits: Serverless functions are not ideal for long-running or computationally intensive tasks due to timeouts and billing based on execution time and/or memory usage.
• Less Control: Serverless architectures offer less granular control over the underlying infrastructure, making it difficult to fine-tune the environment or perform specific optimizations.
• Difficult Debugging: Testing and debugging code locally can be more tricky compared to traditional server environments. It can be difficult to perfectly replicate the serverless environment, making it hard to predict exactly how your code will behave in production.
• Feature Support: Some serverless providers may not immediately support all the latest Next.js features.

The Serverful Alternative: Gaining Control and Performance

With a serverful approach, you can avoid these drawbacks, and one of the main challenges is selecting the platform that aligns with your requirements. Options may include AWS, Render, DigitalOcean, and others. Plain VPS is also an option, but it usually comes with setup and maintenance overhead (logging, monitoring, CI/CD pipelines, etc.). However, you can make your life easier by leveraging tools like Coolify that can help manage this complexity.

Deploying Next.js on a serverful platform is straightforward and involves no changes to your application code. Essentially, you'll end up with a Node.js server. However, you may consider a minor update in your next.config.js file to significantly reduce bundle size:

/** @type {import('next').NextConfig} */
const nextConfig = {
    ...
    output: 'standalone',
    ...
};

Next.js keeps track of all the pages and their dependencies that are needed to run your application. This config creates a standalone folder inside your .next, that contains only the necessary files and dependencies and which you can deploy independently (refer to docs for more details).

In the simplest scenario, your Dockerfile might look like the following:

FROM node:20-alpine AS base

FROM base AS deps
# Check https://github.com/nodejs/docker-node/tree/b4117f9333da4138b03a546ec926ef50a31506c3#nodealpine to understand why libc6-compat might be needed.
RUN apk add --no-cache libc6-compat
WORKDIR /app

COPY package.json package-lock.json* ./
RUN npm ci

FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

RUN npm run build

# Production image, copy all the files and run next
FROM base AS runner
WORKDIR /app

ENV NODE_ENV production

COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public

EXPOSE 3000

ENV PORT 3000
ENV HOSTNAME 0.0.0.0

CMD ["node", "server.js"]

Depending on your chosen serverful platform, a Dockerfile might not always be necessary. Some platforms might use simpler bash commands for the build and deploy stages.

A serverful approach generally provides broader support for Next.js features since you control the environment. There might still be minor nuances depending on the provider, but overall, you'll likely have more flexibility compared to some serverless limitations. For example, let's have a look at the same project deployed to both serverless (Vercel, AWS Amplify) and serverful (AWS ECS) environments:

Beyond feature support, serverful deployments generally offer better performance due to the absence of cold starts and timeouts. Additionally, you may benefit from faster SSR times depending on your server hardware capabilities.

However, serverful deployments come with their own considerations:

• Deployment Complexity: The process is not as simple as the "one-click deployment" offered by serverless platforms.
• Cost Management: Servers usually have higher costs because they run all the time, unlike serverless pay-per-use models.
• Scaling: Unlike serverless approaches, serverful environments may require more manual configuration, e.g. in terms of scaling (strategies, memory / CPU limits, load balancing, and other parameters).

Conclusion

Choosing between serverless and serverful architectures depends on your project's specific needs.

Consider Serverless if:

• Your priority is fast development and easy deployment.
• Your project is a standard web app without long-running background tasks.
• Traffic is unpredictable, and you want to benefit from a pay-per-use cost model.
• You are okay with cold starts.

Consider Serverful if:

• You need full control over the environment.
• Your application includes computationally intensive or long-running tasks.
• Consistent, low-latency performance without cold starts is a critical requirement.
• You have the team or expertise to manage the infrastructure.

By understanding the advantages and limitations of both approaches, you can make an informed decision for your Next.js application.