Learn Nuxt - Edge & Serverless Runtime

#Introduction

After successfully deploying, the next question is: where should the application run? Episode 21 covers two main models — edge runtime and serverless — and how Nuxt and Nitro bridge both.

The difference matters because it determines latency, pricing, and limits on the execution environment. Applications that need super-fast responses worldwide fit the edge; applications with heavy workloads or full Node.js feature needs are more comfortable on traditional serverless. Nuxt makes switching between the two a matter of changing a preset.

#Deploying Nuxt on an Edge Runtime

#What Is an Edge Runtime

An edge network places servers in many locations around the world. Code runs at the location closest to the user, so latency is extremely low — ideal for pages that need fast responses from anywhere.

Nuxt supports the edge through Nitro presets, for example Cloudflare:

Preset edge Cloudflare

export default defineNuxtConfig({
  nitro: {
    preset: "cloudflare_pages",
  },
})

The cloudflare_pages preset translates the Nuxt application into a form that runs on Cloudflare's edge network. The build is then deployed through their dashboard or CLI.

#Edge Runtime Limits

The edge runtime doesn't run Node.js fully. A few things to keep in mind:

• Limited Node.js features: some core modules aren't available.
• Storage: use KV or edge storage, not the local filesystem.
• Execution duration: there's a time limit for each request.

Test the application on an edge preset from the start, not at the end. You can write environment-aware code that doesn't depend on specific Node.js features.

#Serverless Functions and the Nitro Server

#Serverless Functions from the Same Code

With a serverless preset like vercel or netlify, the whole Nuxt server is translated into serverless functions. Every server route becomes a function endpoint:

server/api/pesanan/index.ts

export default defineEventHandler(async (event) => {
  const body = await readBody(event)
  return { status: "diterima", id: buatId() }
})

This server route automatically becomes a serverless function on the target platform. No code changes — you keep writing defineEventHandler as usual.

#Serverless Scalability

Serverless handles scale well: the platform adds instances automatically when traffic rises, and scales to zero when quiet. You pay per execution, not per server hour. This makes serverless a good fit for workloads with unpredictable traffic.

#Runtime Differences and Environment Considerations

#Node vs Edge vs Serverless

The three runtimes differ in important ways:

• Node server: full features, good for self-hosting or a VPS.
• Serverless: near-complete Node features, executed per-request with duration limits.
• Edge: limited features, but the lowest latency.

Code must consider its environment. Don't write code that only runs on Node if the target is the edge:

Kode yang sadar lingkungan

if (process.env.NODE_ENV === "production") {
  console.log("mode produksi aktif")
}

process.env.NODE_ENV is available on most runtimes. However, to access storage at the edge, use the APIs the preset provides — for example useStorage with a supported KV backend.

#Environment Considerations

Also note: deployment size, execution duration, and environment variables differ across platforms. Document environmental assumptions in the README so the team understands the limits to respect.

#Use Cases for Edge vs Serverless

#When to Use Edge

The edge is best for:

• Public pages with global traffic, like blogs and landing pages.
• Applications requiring extremely low latency worldwide.
• Light dynamic content that is read often and written rarely.

If most pages can be cached, the edge delivers maximum speed at minimal cost.

#When to Use Serverless

Serverless is more comfortable for:

• Applications with user data and complex business logic.
• Workloads requiring full Node.js features.
• Write-heavy operations like payments and checkout.

Combinations are also common: public pages at the edge, while transactional API endpoints run on serverless. Nuxt enables this granularity through per-route configuration on several platforms.

#Conclusion

Episode 21 explains your runtime options: edge for the lowest latency with environment limits, serverless for near-complete Node.js flexibility with automatic scaling, and a Node server for full control. With Nitro, moving between runtimes is just a matter of changing a preset.

Key takeaways:

• The edge executes code at the location closest to the user for low latency.
• Nitro translates applications into edge or serverless form via presets.
• The edge has Node.js feature limits; test early, not late.
• Serverless handles automatic scaling and per-execution pricing.
• Choose a runtime based on latency, feature, and cost needs.
• Public pages fit the edge; heavy transactional logic fits serverless.

In the next episode, episode 22, we will discuss observability and monitoring — monitoring frontend and server performance, error tracking with Sentry, real user monitoring and analytics, and production support and incident handling.