Share a Nuxt dev server with a client

nuxt dev shares through ouicu as it comes: the page, hot reload and your server routes all work through the link, with nothing to set. Nuxt can also open a tunnel itself, with --tunnel; that one is free and needs no account, and the difference is what your client gets.

Share nuxt dev with ouicu

npm run dev# in a second terminalouicu share 3000

Nuxt says Network: use --host to expose as it starts. That's about your Wi-Fi: ouicu reaches the dev server on localhost, which is all it needs. On Free, a share runs for up to 2 hours. Getting started has the install.

Hot reload runs over wss://calm-otter-4821.ouicu.app/_nuxt/, on the link's own port. We changed the heading in app.vue with the link open and it changed in place, no reload. A button calling $fetch to POST to server/api/echo.post.ts got its answer, as Nitro has no origin check of its own to trip.

nuxt dev --tunnel, and how it differs

Nuxt's own help lists a tunnel:

--tunnel Expose the server via a Cloudflare quick tunnel

It's a fair choice for a quick look, and Cloudflare's docs say of these tunnels: “You do not need a Cloudflare account or domain.” We haven't run it behind this guide; here is what each side documents, for showing a client:

If the link is for you, on your phone, --tunnel is enough. For a client, a name that stays the same and a password tend to matter more (Cloudflare Tunnel and ouicu).

Blocked request, through other tunnels

Nuxt's dev server runs on Vite, which turns away hosts it doesn't know. A tunnel that passes your public name on as Host gets 403 and:

Blocked request. This host ("calm-otter-4821.ouicu.app") is not allowed.To allow this host, add "calm-otter-4821.ouicu.app" to `server.allowedHosts` in vite.config.js.

ouicu hands Nuxt Host: localhost:3000, so you won't see it. With another tunnel, the help points at vite.config.js, but a Nuxt app sets it in nuxt.config.ts, where we tested it:

export default defineNuxtConfig({  vite: { server: { allowedHosts: ['.ouicu.app'] } },})

--public goes further. Nuxt's docs describe it as “Listen on all network interfaces and allow any host to connect”, so use it on a network you trust.

useRequestURL() and the link's address

Rendered on the server through the link, useRequestURL() gave https://localhost:3000/: the link's scheme with your laptop's name. It comes from h3, where the scheme follows the proxy by default, “If x-forwarded-proto header is set to "https", it will return "https".” while the host doesn't: “If xForwardedHost is true, it will use the x-forwarded-host header if it exists.” So ask for both:

const url = useRequestURL({ xForwardedHost: true, xForwardedProto: true })

It then rendered https://calm-otter-4821.ouicu.app/, as the browser has it, which matters for canonical links and og:url.

Upload what nuxt generate makes

From the docs on nuxt generate: “Pre-renders every route of the application and stores the result in plain HTML files.” They land in .output/public, ready to upload, and stay up with your laptop closed:

npx nuxt generateouicu deploy .output/public

Server routes don't come along: ouicu deploy serves files only (Uploading a built site). For those, build and share the server itself:

npx nuxt buildPORT=3000 node .output/server/index.mjs# in a second terminalouicu share 3000

Through the link its page loaded and its POST was answered, as in development.

Phones, and who can open it

The QR code ouicu prints opens the site on any phone (QR codes). For the same Wi-Fi without a link, start Nuxt with nuxt dev --host 0.0.0.0; see how to open localhost on your phone. Everyone with the link reaches your server routes too, so for a client add --password, on Hobby and Pro, or --allow with their email, on Pro (passwords and invited people).