Cloudways Next.js Deployment 2026: Static vs Node.js SSR

This post contains affiliate links. If you purchase through our links, we may earn a commission at no extra cost to you.

Search “can Cloudways host Next.js” and you’ll find guides that either oversell it as a one-click stack or bury the real trade-offs under a wall of SSH commands. The truth about Cloudways Next.js Deployment 2026 sits in between: there’s no native Next.js application type, but the platform can run a production Next.js app once you pick the right path. Static export is close to effortless. Full Node.js server rendering is a genuine ops project — PM2, a reverse proxy, and a support ticket, not a checkbox. This guide walks through both paths, the pricing, and where Cloudways stops making sense compared to Vercel.

Does Cloudways Actually Support Next.js?

Not natively, and this is the part most comparison posts get wrong. Cloudways’ own Help Center article on supported applications lists one-click stacks for WordPress, WooCommerce, Magento, Laravel, Joomla, Drupal, and generic PHP — every single one PHP-based. There’s no Node.js or Next.js option in the server launch dropdown.

You might come across a guide claiming you can “select the Next.js stack from the Application and Stack dropdown” during server setup. That’s not accurate. It conflicts with Cloudways’ own documentation, with Cloudways’ own blog post on hosting Node apps (which tells you to start by installing a PHP Application as the container), and with the consensus on Cloudways’ community forums. If you see that claim elsewhere, treat it as wrong.

What Cloudways actually gives you is a PHP-labeled server that you turn into a Node.js host yourself. A Techzeel community thread on this exact question landed on the same conclusion: yes, you can host Next.js on Cloudways, but it “isn’t as seamless as specialized platforms like Vercel,” and it requires manual configuration for anything beyond static files. That’s the framing to hold onto for the rest of this post — Cloudways is a capable general-purpose server, not a Next.js-specific platform.

Two Deployment Paths, Two Very Different Amounts of Work

Before picking a plan or writing any config, figure out which of these two paths your app actually needs. They are not close in difficulty.

Last updated: 2026-07-14

If your app doesn’t use API routes, server components that fetch at request time, or ISR, you almost certainly want static export — it removes the entire second half of this article’s complexity. If you’re not sure, check your next.config.js: if it’s already set to output: 'export' or you could switch to it without losing features, you’re in the easy lane.

Path 1: Deploying a Next.js Static Export on Cloudways

This path is genuinely simple, and it’s the one Cloudways is well suited for without any workarounds. Build your app with output: 'export' (the modern replacement for the old next export command), and the result is a folder of static HTML, CSS, and JS files — no Node process required at runtime.

From there, deployment on Cloudways looks like deploying any static site: upload the contents of the out/ folder to public_html (or your configured app root), point your domain and SSL as normal, and you’re done. There’s no PM2, no port to configure, no reverse proxy, and no support ticket. Apache or Nginx just serves files.

One caution worth flagging: a couple of guides in this space describe setting output: 'standalone' for a static deployment. That’s actually the config for a self-contained Node server bundle — the setting you’d use for the SSR path below, not static export. If a tutorial blurs that distinction, it’s a sign the author didn’t test the setup they’re describing. Stick with output: 'export' for a true static deployment.

Static export is the right call for content sites, marketing pages, documentation, and portfolio or landing pages — anything where the content doesn’t change per-request. If your app needs a contact form with server-side handling, dynamic pricing pulled at request time, or a logged-in dashboard, static export won’t cover it, and you’re looking at Path 2.

cloudways

If you’re already running other sites on Cloudways and just need to add a static Next.js site alongside them, this is close to zero additional cost or complexity — you can run it on the same server as an existing app.

Path 2: Full Node.js SSR Deployment (PM2 + Reverse Proxy)

This is the path for API routes, server-side rendering, ISR, middleware, or anything that needs a Node process running continuously. It’s also where the “Cloudways can host Next.js” claim gets a lot more honest about the work involved. The process, consistent across Cloudways’ own blog and independent walkthroughs, looks like this:

1. Launch a PHP Application server. There’s no separate Node.js application type — the PHP container is the environment you build on top of.
2. Connect via SSH, navigate to public_html, and install Node.js and your app’s dependencies (npm init, npm install), or connect a Git repo and configure npm run build / npm run start.
3. Set your app to listen on a non-privileged port — commonly 3000, via process.env.PORT || 3000.
4. Install PM2 globally (npm install pm2@latest -g) and start your app through it. Without PM2, the Node process dies the moment your SSH session closes — this isn’t optional for anything you want to stay up. A dedicated SSR deployment guide from prateeksha.com recommends an ecosystem.config.js file with pm2 reload ecosystem.config.js --env production for zero-downtime restarts, plus max_memory_restart so PM2 auto-recovers from memory leaks instead of quietly degrading.
5. Reroute traffic from port 80/443 to your Node port. Cloudways blocks inbound traffic on every port except 80 and 443 by default, so you need a reverse proxy rule — either an Apache mod_proxy .htaccess rewrite (RewriteRule ^(.*)?$ http://127.0.0.1:3000/$1 [P,L]) or an Nginx proxy_pass block. mod_proxy is disabled by default on Cloudways servers, which means step one of this is actually opening a support ticket and waiting for Cloudways to enable it for you.

You can generate a clean starting point for that reverse proxy block with our free Nginx config generator rather than hand-writing the proxy_pass and header directives from scratch.

Server sizing matters more here than it does for a typical WordPress site. The prateeksha.com SSR guide recommends starting at 2 vCPU / 4GB RAM minimum for a small production SSR app, and stepping up to 4 vCPU / 8GB+ for medium traffic, running Node 18+. It also recommends layering CDN edge caching on top of ISR with explicit Cache-Control headers (their example: Cache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=30), and setting up centralized logging (Papertrail or an ELK stack) plus error tracking through Sentry before you put real traffic on it. None of that is automatic — you’re building and monitoring it yourself.

That same source frames Cloudways as sitting “between Vercel’s simplicity and full DIY infrastructure” for SSR Next.js. That’s a fair summary: it’s more control and lower flat cost than Vercel, but scaling, monitoring, and process management are entirely your responsibility, not something the platform handles for you. If you’ve already deployed a Node app on Vultr with PM2 and Nginx, the shape of this workflow will feel familiar — see our Next.js on Vultr deployment guide for the same pattern on a different provider, or read our full hands-on writeup of the Cloudways Node.js deployment process for more detail on where this setup tends to go wrong in practice.

Cloudways Pricing for Next.js Hosting

Cloudways’ relevant product for either deployment path is Cloudways Flexible, its managed VPS line — not Cloudways Autonomous, which is WordPress-only and doesn’t apply here. On DigitalOcean-backed Standard servers, the published tiers run:

Prices last checked: 2026-07-14

A static export site can run comfortably on the entry $11/mo tier — 1 vCPU and 2GB is plenty for serving pre-built files. A real SSR Next.js app is a different story: the SSR guide’s “2 vCPU / 4GB minimum” recommendation doesn’t land cleanly on any single published tier — Cloudways’ pricing table jumps from the $11/mo entry plan straight to $88/mo for 4 vCPU / 8GB, with nothing shown in between at the time of writing. In practice, that means budgeting closer to the $88/mo tier for a small-to-medium SSR app rather than assuming you’ll land right at $11/mo, unless you confirm an intermediate size is available when you configure the server. Cloudways offers a 3-day free trial with no credit card required, plus 30% off your first three months on all plans — worth using that trial window to actually load-test your SSR app before committing to a tier.

Other providers (Vultr, Linode, AWS, GCP) are available on Cloudways with their own regional pricing, all through the same flat-fee Flexible model — see our Cloudways vs Vultr comparison if you’re weighing the underlying infrastructure choice separately from the Next.js question.

Cloudways vs Vercel for Next.js

Vercel is the platform Next.js is built by and for, and it shows in the deployment experience: push to Git, and builds, scaling, caching, and cold-start handling are automatic. The Hobby tier is free but non-commercial only — any revenue-generating site needs to upgrade — and caps out at 100GB bandwidth, 100,000 function invocations, and 100 deployment builds per month, with hard feature locks once you hit those limits rather than silent overage charges.

The Pro plan runs $20 per user per month, includes 1TB of bandwidth (Vercel states that’s enough for over a million monthly users on a typical app) and a $20 usage credit, and unlocks commercial use. As of Vercel’s 2025 pricing shift, both Hobby and Pro run on “Active CPU” usage-based pricing by default: $0.128 per Active CPU-hour plus $0.0106 per GB-hour of provisioned memory. That means Vercel’s real cost scales with your traffic and compute usage — it’s not a flat number the way Cloudways’ server pricing is.

That’s the actual trade-off, and it’s worth stating plainly: Vercel gives you zero-config scaling and caching but a bill that can grow with success. Cloudways gives you flat, predictable server pricing and full control, but you’re the one building the process management, reverse proxying, and caching layer that Vercel hands you for free. For a budget-conscious indie hacker with steady, predictable traffic, that flat fee is attractive. For anyone building an SSR-heavy app where usage is unpredictable or scaling matters more than shaving a monthly bill, Vercel’s automation is worth paying for.

Who Should Use Cloudways for Next.js (and Who Shouldn’t)

Cloudways makes sense if you’re already running other sites there and want to add a Next.js project to the same account, if your app is a static export or leans ISR-light rather than SSR-heavy, or if you’re cost-conscious and comfortable doing your own PM2 and reverse-proxy setup in exchange for flat server pricing instead of usage-based billing. It’s also a reasonable fit if you specifically want server-level control — custom Nginx rules, non-standard caching layers, or co-locating a Next.js frontend with a PHP backend on the same box.

It’s the wrong choice if you need SSR at real scale with zero ops overhead, if API routes and middleware are core to your app and you don’t want to own PM2 restarts and reverse-proxy config yourself, or if you’d rather your hosting bill track your actual usage automatically instead of managing server sizing manually. In those cases, Vercel is the more honest recommendation, even though it’s not an affiliate product for us — sending you to the platform that actually fits builds more trust than steering you toward the one that pays a commission.

cloudways If your use case lands in the “makes sense” column above, Cloudways’ 3-day free trial is enough time to actually test a static export deploy or a small PM2 setup before you commit a card number to it.

FAQ

Does Cloudways have a native Next.js stack?

No. Cloudways’ officially supported one-click stacks are all PHP-based — WordPress, Laravel, Magento, Joomla, Drupal, and generic PHP. Next.js and Node.js run inside a PHP Application container that you configure manually, not as a dedicated application type.

Can you run Next.js SSR on Cloudways?

Yes, but it takes manual setup: installing Node.js and PM2 yourself, configuring your app to listen on a non-standard port, and setting up an Apache or Nginx reverse proxy to route traffic to it. You’ll also need to file a support ticket to enable mod_proxy if you use the Apache route, since it’s off by default.

Is static export easier than SSR on Cloudways?

Considerably. Static export deploys like any static site — upload the built files, no Node process, no PM2, no reverse proxy, no support ticket. SSR requires all of that plus ongoing process monitoring.

What server size do I need for Next.js SSR on Cloudways?

Guides recommend at least 2 vCPU / 4GB RAM for a small production SSR app, moving up to 4 vCPU / 8GB+ for medium traffic. Cloudways’ published pricing tiers jump from $11/mo (1 vCPU/2GB) to $88/mo (4 vCPU/8GB) with no exact match for the 2 vCPU/4GB recommendation, so budget toward the $88/mo tier for anything beyond a light SSR workload.

Should I use Cloudways or Vercel for Next.js?

Use Vercel if your app is SSR-heavy, traffic is unpredictable, or you want zero-ops scaling and caching. Use Cloudways if you’re already on the platform, your app is static export or ISR-light, or you’d rather pay a flat server fee and handle the ops work yourself.

Final Verdict: Cloudways Next.js Deployment 2026

Cloudways Next.js Deployment 2026 comes down to which path your app actually needs — and being honest about that before you launch a server saves real time. Static export is a genuinely good fit: it’s simple, cheap, and works the same way any static site does on Cloudways. Full Node.js SSR is possible and documented, but it’s real infrastructure work — PM2, a reverse proxy, a support ticket, and ongoing monitoring that Vercel would otherwise hand you for free.

If you’re a static or ISR-light site, or you’re already running other projects on Cloudways and want to consolidate, Cloudways is a reasonable, budget-predictable choice. If you’re building an SSR-heavy app and don’t want to own process management and reverse-proxy config yourself, spend the extra per-user dollars on Vercel instead — it’s built for exactly that job, and this is one case where the specialized platform earns its premium.