Front-end and static sites
How to deploy a Nuxt 3 app and host it online
In short
There are two ways to deploy a Nuxt 3 app. You can pre-render it with nuxt generate, which turns the site into a set of ready-made pages served as plain static files, or you can keep server mode, where Nuxt runs as a Node app that listens on the port from the PORT environment variable on 0.0.0.0. Netrun supports both: you upload the code, the platform installs the dependencies, runs the build and gives you a public HTTPS address. No server of your own, no nginx and no manual certificate, and Vercel is optional.
Normally, deploying a Nuxt 3 app means picking between two not very pleasant options. Either you rent a server, install Node.js on it, build the project, run it as a long-lived process, put nginx in front and get a certificate. Or you hand the site to a platform like Vercel, which is convenient but does not suit everyone: some people want a database running next to the site, and some do not want to be tied to one vendor.
With Netrun you upload a folder of code, and we take care of the build, the launch, the restart after a crash and the HTTPS address. We recognize Nuxt from your package.json and build the project the way it is set up. The one decision left to you is which mode to publish in: a set of pre-rendered pages, or an app with a server side. Both are covered below.
Decide whether your site needs a server#
Nuxt runs in two modes, and everything else follows from that choice. If the site only shows content, such as a landing page, a blog, a portfolio or documentation, you can turn it into ready-made pages up front with nuxt generate: that is plain static hosting, it opens instantly and nothing has to stay running. If the project has server routes (the server/api folder), database queries, form handling or content computed per visitor, you need server mode, where Nuxt runs as a Node app that stays up.
Pre-render the pages if you do not need a server#
For the static option, run npm run generate on your own machine. Nuxt writes the finished pages into the .output/public folder, and the contents of that folder are your site. Upload those files to Netrun as an archive and the platform serves them at a public HTTPS link. This is the only case where you build on your own machine: in server mode we run the build for you and you upload the source code. A static site listens to nothing and cannot crash, and to update it you generate the pages again and upload the new version. The link stays the same.
Leave the port and the address to the platform#
In server mode the site only opens if the app listens where it is expected: the port comes from the PORT environment variable, and the address has to be 0.0.0.0 rather than localhost. Nuxt does this by default, so your job is to remove any settings you added yourself. Check nuxt.config and your .env file for things like port 3000 or host localhost. A hard-coded port is the number one reason a link fails to open after publishing.
Add a start script to package.json#
After the build Nuxt puts the finished app into the .output folder, and it starts from the file .output/server/index.mjs. To leave no doubt about how the project should be launched, add a start script to your package.json with the value node .output/server/index.mjs. The build script is usually already there, and we run it for you during publishing, so you do not have to build the project on your own machine.
Split your config into server and public parts#
In Nuxt the values in runtimeConfig fall into two groups, and the difference matters. Anything inside public travels to the browser with the page and is visible to every visitor, so it should only hold harmless things such as the address of an external API. Keep API keys, tokens and database connection strings outside public, where they stay on the server. Do not write the values into the code at all: Netrun asks for them when you set the project up, passes them in as environment variables and stores them encrypted.
Upload the code and grab the link#
You can bring the project in as a ZIP archive or by importing a GitHub repository, including a private one. If you are uploading source code, leave node_modules, .nuxt and .output out of the archive. We install the dependencies and run the build, so the archive stays small. Netrun then builds the project, starts it and gives you a public HTTPS link. Logs and publishing status appear in your dashboard in real time, so a build error shows up right away instead of as a blank page.
That is it: your Nuxt site opens at an ordinary HTTPS link, with no rented server and no nginx setup. The free plan includes one project, and a site on it sleeps while nobody uses it and wakes up on its own when someone opens the link, so only the first visit after a pause is slower. If the site has to answer without delay at any moment and needs a domain of your own, the Pro plan is the right fit. Try Netrun.
Common questions
What is the difference between nuxt generate and a normal build?
The nuxt generate command works out the pages up front and writes them as finished files, so you get a static site that needs nothing running. A normal build keeps the server side, and the site becomes a Node app that listens on a port and answers every request. Server routes, database access and content computed for a specific visitor only exist in the second option.
Can I self-host a Nuxt 3 app without Vercel?
Yes. Nuxt is not tied to one platform: in server mode it is an ordinary Node app, and after nuxt generate it is an ordinary folder of finished pages. Netrun accepts both. You upload the code as an archive or from GitHub and get a public HTTPS link.
Why does the site build but the link does not open?
Most often the port or the address was set by hand: the app listens on 3000 or on localhost while the platform expects it on its own port and on 0.0.0.0. Remove those values from nuxt.config and from .env. The second common reason is that the app never started at all, and the logs in your dashboard say so in real time.
What should I do with the .env file?
Do not put the file into the archive, and it does not belong in the repository either. You enter the values when you set the project up in Netrun, they are passed in as environment variables and stored encrypted. Nuxt picks them up in runtimeConfig by its own naming rules: a server value apiSecret is read from NUXT_API_SECRET, and a public apiBase from NUXT_PUBLIC_API_BASE.
Do keys in runtimeConfig end up in the browser?
Everything under public travels to the browser with the page, and any visitor can read those values. The rest of runtimeConfig stays on the server and is never sent out. In static mode there is no server at all, so any value baked into the generated pages becomes public, which means secret keys must never go into a static build.
Do server routes from the server/api folder still work?
Yes, in server mode they work as usual: Nuxt runs as a Node app and answers requests to its own routes. In the static option there is no server side left after nuxt generate, so those routes will not respond. If you need them, publish the site in server mode.
Do I need my own server or VPS?
No. Netrun deploys your project on its own servers. There is no VPS to rent, no systemd or nginx to configure and no certificates to renew — all of that runs for you.
What about React, Vue, Next.js, Nuxt, Svelte or Astro?
Yes, all of them work. Upload the source code with your package.json — you do not need to build the project yourself or include the built output, the build happens on our side. If your framework can produce both static pages and a server build, either works: in server mode the app should listen on the port from the environment variable. One important detail: values baked into the built front-end are visible to any visitor, so keep real keys on the server side.
How do I update the code of a project that is already published?
Open the project and upload a new version or update it from GitHub. The link stays the same, and your data is kept as long as it lives in persistent storage — the /data folder or a volume from your compose file.
Why does my website sometimes sleep?
On the free plan, websites sleep after being idle and wake up in a couple of seconds on the first request. On the Pro plan your project runs without sleeping.