Hosting a Next.js project from v0 on shared hosting: static export or Node runtime

You can host Next.js projects generated by v0 on Flashcloud shared hosting using two methods: a static export or the Node.js application runner. The choice depends entirely on whether your application requires server-side execution.

If your project is a front-end interface that talks to external APIs directly from the browser, build it as a static export. LiteSpeed serves static files from disk immediately with minimal resource usage. If your project uses Server Components, dynamic server-side rendering (SSR), Server Actions, or internal Next.js API routes, deploy it as a Node application using cPanel's Setup Node.js App tool.

Choosing between static export and the Node runtime

Most v0 prototypes start as pure client-side interfaces. They render UI components, handle state in the browser, and communicate with external services like Supabase or third-party REST endpoints. For these applications, running a persistent Node process adds unnecessary overhead.

Choose static export when:

• Your pages do not rely on server-side functions like getServerSideProps or dynamic request headers.
• You do not use Next.js API routes located in pages/api or app/api.
• You want the fastest possible page load times through direct LiteSpeed file delivery and edge caching. See our guide on setting up a CDN with Cloudflare to pair static assets with edge performance.

Choose the Node runtime when:

• Your application processes backend secrets or database credentials inside Next.js route handlers.
• You need on-demand server rendering for pages that change per request.
• You rely on dynamic server features that cannot be pre-rendered during a build step.

Option A: Static export for pure front-end apps

A static export compiles your Next.js application into standard HTML, JavaScript, CSS, and asset files. This removes the Node runtime dependency on the server.

First, configure Next.js for export. Add the output flag to your next.config.js or next.config.mjs file:

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

module.exports = nextConfig;

Run the build command locally on your machine:

npm run build

Next.js generates an out directory containing your compiled assets. Upload the contents of this out directory to your website's document root on the server:

1. Log in to the Flashcloud portal at portal.flashcloud.com and open your hosting service.
2. Click the File Manager tile.
3. Navigate to your document root. For your primary domain, this is public_html. For a subdomain, the folder sits alongside public_html at ~/subdomain_name.
4. Upload the files from your local out folder directly into the document root. If you maintain your project in Git, you can also deploy commits using the Git Version Control tool, similar to the deployment workflow outlined in our guide on installing CodeIgniter.

A fresh document root already contains default files, including a cPanel .htaccess file. Never replace or delete that file; append any custom rules to the bottom if needed. If your export relies on client-side routing, add the standard rewrite rules to .htaccess so direct visits to subpages do not throw 404 errors, similar to the front-controller fixes discussed in our guide on Laravel routes not working on shared hosting.

Option B: Node runtime with Setup Node.js App

When server-side logic is required, configure LiteSpeed's Node runner (lsnode) via cPanel.

Note on themes: If you are using the opt-in Meridian cPanel theme, click Classic cPanel Theme at the top to switch back to Jupiter. The Setup Node.js App interface is located under the Software section in the Classic theme and is not indexed in the Meridian search bar.

1. Create the application in cPanel

1. Open cPanel via one-click login from your service page.
2. Navigate to Software → Setup Node.js App and click Create Application.
3. Select your Node version. We provide Node 22.23.2 (recommended) and Node 24.21.0.
4. Set Application mode to Production.
5. Specify the Application root (for example, next-app, which creates a directory in your home folder).
6. Choose your Application URL from the domain dropdown.
7. Set the Application startup file (typically server.js).
8. Click Create. The installer generates placeholder files, including app.js, public/, and tmp/. A warning about domain availability may appear; this is harmless while configuration is underway.

2. Prepare and upload the project

Shared hosting plans are optimized for serving traffic, not compiling resource-intensive JavaScript bundles. Build your Next.js project on your local machine or in CI before uploading. We recommend using Next.js standalone output by setting output: 'standalone' in next.config.js.

Upload your application files into your defined Application root folder. The standalone output produces a minimal server.js along with required dependencies. Ensure your server code listens on the port provided by the environment variable:

const port = process.env.PORT || 3000;

The LiteSpeed runner manages ports automatically and routes web traffic to your process through process.env.PORT.

3. Install packages and configure environment variables

If you uploaded a standard project with a package.json file instead of a pre-bundled standalone build:

1. Reload the Setup Node.js App page completely. The Run NPM Install button will appear once the panel detects package.json.
2. Click Run NPM Install to install production dependencies.
3. Under the Environment variables section, add any configuration values required by your app. Click Add Variable, save your changes, and click Restart.

If your application crashes on boot, check stderr.log inside your application root directory for the error trace.

Shared hosting boundaries and performance

Shared hosting provides fixed CPU and memory allocations. On the Start plan, for instance, your account has 2 GB of physical memory and a maximum of 60 concurrent processes. Keep these practical boundaries in mind:

• Never run builds on the server: Executing npm run build or next build on shared hosting will trigger memory limits and kill your process. Always build locally or in a deployment pipeline, then upload the production artifacts.
• Avoid long-running daemons: Next.js should handle incoming web requests and exit cleanly. Do not run heavy background tasks or persistent queue workers inside your web application. The principles detailed in Laravel queues and cron on shared hosting apply here: shared servers prioritize short-lived requests, not background compute.
• Path handling: If your Node application is mounted on a subpath (such as example.com/api), the application receives the full path in the request. Make sure your route handlers account for the path prefix.

When to contact support

If your application fails to start and stderr.log remains empty, or if your domain continues to display a server error after restarting the Node manager, open a ticket. Go to Support → New ticket in the Flashcloud portal. Our support team consists of real humans who can check origin error logs and verify your server mappings.