Nuxt SSL Monitoring: SSR, SSG, and the Split SSL Surface Agencies Miss

Nuxt is a meta-framework for Vue.js that supports server-side rendering (SSR), static site generation (SSG), and hybrid deployments that combine both. Agencies building Nuxt applications for clients deploy across a range of hosting configurations — from full SSR on Vercel or self-managed Node.js servers, to pure SSG on Netlify or Cloudflare Pages, to hybrid setups where some routes are server-rendered and others are pre-generated.

The SSL monitoring requirements for Nuxt deployments vary significantly by deployment mode. An agency that monitors only the apex domain misses the split SSL surface that hybrid and API-heavy Nuxt deployments expose.

Nuxt Deployment Modes and Their SSL Implications

SSR (Server-Side Rendering)

In SSR mode, Nuxt runs as a Node.js server. Every page request is handled by the server at request time. SSL is managed by the hosting platform — Vercel, Fly.io, a self-managed VPS with Nginx and Let's Encrypt, or Heroku.

SSL failure characteristic: Identical to a Rails server SSL failure. When the server SSL certificate expires, every page request and every API call fails immediately. There is no cached HTML layer to absorb the outage. Every visitor to the Nuxt application sees the browser's SSL error page simultaneously.

DNS and SSL requirements: Depend on the hosting platform. Vercel provisions SSL via Let's Encrypt using HTTP-01 validation; the custom domain CNAME must point at Vercel's infrastructure. Self-managed VPS deployments using Certbot require the domain to resolve to the VPS IP at renewal time.

SSG (Static Site Generation)

In SSG mode, Nuxt pre-generates all pages at build time and deploys the output as static HTML files. The static files are served from a CDN or static hosting provider — Netlify, Cloudflare Pages, Vercel, or AWS S3 with CloudFront.

SSL failure characteristic: Similar to a Gatsby or Next.js static export failure. Because CDN nodes cache static content, an SSL expiry on the origin may not immediately affect edge delivery — depending on the CDN configuration. However, browser-direct requests and CDN cache misses will fail once the SSL certificate expires.

DNS and SSL requirements: Depend on the static hosting platform. Netlify provisions Let's Encrypt via DNS-01 or HTTP-01 validation; the CNAME pointing at Netlify must remain intact. Cloudflare Pages manages SSL through Cloudflare's edge certificate infrastructure.

Hybrid (SSR + SSG)

Nuxt 3's hybrid mode allows some routes to be server-rendered at request time and others to be pre-generated. This is the most complex deployment mode from an SSL monitoring perspective.

In a hybrid deployment, the Nuxt application runs as a Node.js server (for SSR routes) and also serves pre-generated static files (for SSG routes) — all under the same domain. The SSL certificate covers the entire domain, and a failure affects both server-rendered and static-generated routes simultaneously.

However, hybrid Nuxt applications frequently also have:

A separate API subdomain for backend API calls
A staging or preview environment on a subdomain
Nitro server-side API routes under /api/ that are part of the same Nuxt server

Each of these adds an SSL surface that is independent from the main domain's certificate.

Nuxt on Vercel: CNAME Integrity and Wildcard Certificate Scoping

Vercel is the most common deployment target for Nuxt 3 SSR and hybrid applications. Vercel provisions Let's Encrypt certificates for custom domains using HTTP-01 validation. Custom domains are added in the Vercel project settings, and Vercel handles certificate provisioning automatically after the DNS CNAME is verified.

The Vercel CNAME Requirement

Vercel custom domains require either:

A CNAME record pointing at cname.vercel-dns.com (for subdomains, including www)
An A record pointing at Vercel's IP 76.76.21.21 (for apex domains)

If the CNAME is removed — during a DNS migration, a registrar transfer, or a client-managed DNS cleanup — Vercel cannot renew the Let's Encrypt certificate for that domain. The existing certificate continues serving until expiry.

Vercel Preview and Branch Deployments

Vercel automatically creates preview deployments for branches and pull requests at <hash>-<project>.vercel.app subdomains. These use Vercel's certificate, not the custom domain's certificate. However, agencies that configure custom preview domain aliases on Vercel — such as staging.clientsite.com pointing at the Vercel preview deployment — add a custom domain with its own CNAME and certificate requirement.

Agencies often configure staging aliases and then forget them. When the main domain's DNS is migrated, the staging CNAME may not be migrated, or it may be migrated to the wrong target. The staging environment's SSL fails independently from production.

Nuxt on Netlify: DNS-01 Validation and the Zone Apex Problem

Netlify provisions Let's Encrypt certificates using DNS-01 validation for apex domains. The DNS-01 method requires a _acme-challenge.<domain> TXT record — or a delegation CNAME from _acme-challenge.<domain> to a Netlify-controlled hostname — to be present in the DNS zone.

Netlify-managed DNS (when the domain's nameservers are pointed at Netlify) handles the acme-challenge delegation automatically. But agencies that use Netlify for hosting while keeping DNS management at another provider (Cloudflare, Route53, or the registrar) must manage the acme-challenge record manually.

The External DNS Netlify SSL Failure Mode

When Nuxt is deployed to Netlify with a custom domain using external DNS (not Netlify DNS), the agency adds the CNAME pointing at Netlify's infrastructure and Netlify provisions the certificate. If the agency does not also set up the _acme-challenge delegation correctly, Let's Encrypt renewal uses HTTP-01 instead.

If the domain's A record or CNAME is later changed — pointing the domain at a different host for any reason — the HTTP-01 challenge fails and the certificate is not renewed. The failure happens silently, at the 60-day renewal mark, and is not visible in Netlify's dashboard until the renewal system logs the failure.

The Nuxt API and Nitro Server Routes SSL Blind Spot

Nuxt 3 applications use the Nitro server engine, which enables server-side API routes under /api/ in the same application. In a Nuxt SSR or hybrid deployment, these API routes are served by the same Node.js server as the HTML pages — they share the same SSL certificate.

However, agencies building Nuxt applications for clients with separate backend APIs frequently configure:

A api.clientsite.com subdomain pointing at a separate backend (a dedicated Node.js API, a Fastify server, a Laravel API, or a third-party API gateway)
The Nuxt frontend calling api.clientsite.com for data

The api.clientsite.com subdomain has its own SSL certificate, independent from the main Nuxt frontend domain. This certificate is provisioned by whatever hosting platform the API backend uses — which may be different from the platform hosting the Nuxt frontend.

The failure mode: The Nuxt frontend SSL is monitored (it is the main site). The API subdomain SSL is not. The API certificate expires. The Nuxt application loads and renders normally — because the frontend SSL is valid — but data loading fails silently as the browser blocks HTTPS requests to api.clientsite.com. Users see empty pages, infinite loading states, or application-level error messages. The agency is not alerted because the main site domain SSL is still valid.

Monitoring Setup for Nuxt Deployments in Merlonix

SSR Nuxt (Vercel, Fly.io, self-managed Node.js)

Add the apex domain as an asset with SSL expiry monitoring (30-day alert)
Add the www subdomain as a separate asset — CNAME integrity check on the target pointing at the hosting platform
Add the staging subdomain if a custom alias is configured
Add API subdomains as separate assets with independent SSL expiry alerts
Add the hosting platform as a vendor status feed

SSG Nuxt (Netlify, Cloudflare Pages)

Add the apex domain as an asset with SSL expiry monitoring
DNS change monitoring on the CNAME pointing at the static hosting platform — catches DNS migrations that redirect traffic before SSL fails
Add preview or staging subdomains if configured with custom domains
Add Netlify or Cloudflare Pages as a vendor status feed

Hybrid Nuxt

All of the above: apex domain, www subdomain, staging subdomain, API subdomains — each as a separate asset with independent SSL expiry and DNS integrity monitoring. Hybrid deployments have the largest SSL surface of the three modes because they combine server-side and static routes, often with a separate API backend.

Merlonix monitors SSL and DNS across Nuxt SSR, SSG, and hybrid deployments — with per-subdomain expiry alerts, DNS change detection, and vendor status tracking. Start a free trial and add your first Nuxt client domain.