Node.js & Git
node.js on shared
hosting. actually.
Multiple Node versions, Phusion Passenger, npm and environment variables from the panel — and Git deployment that pulls when you push. Deploy Next.js, an API, or a site an AI built you. No VPS required.
two kinds of people land on this page.
Both want the same thing — a Node app, live on the internet, without renting and babysitting a whole server. Where you started just changes which words on this page are unfamiliar.
you write the code
the developer
You already know what Node, npm and a build step are. What wears thin is being told a rendered site or a small API needs a whole VPS — an operating system to patch, a firewall to configure, a box to keep alive at 3am. You want Node and Git without inheriting a server to run.
you described it to an ai
the builder
You asked Claude, Cursor, v0 or Lovable for a website and it wrote you a real one — a proper Next.js or Astro project, sitting in a folder you are not quite sure what to do with. It runs on your laptop. Now it needs to run somewhere the rest of the world can reach. That somewhere is here.
From here the path is identical. The code lives in a Git repository, you point the panel at it once, and every push after that goes live on its own. The rest of this page explains that in plain terms — and stays honest about the handful of things that genuinely want a server of their own.
plans that run node
Node.js hosting on our Plesk platform — Phusion Passenger, your choice of Node version, npm and environment variables from the panel, and Git deployment that pulls on push. Everything a Node app needs, managed for you rather than assembled on a VPS.
Showing monthly pricing.
Node.js Starter
£9.99/mo
- Daily Backups
- UK Data Centre
- 512MB RAM Allocation
- 25% CPU Allocation
- DDoS Protection
- Friendly UK Support
Perfect For
Express.js Applications · Fastify APIs · Discord Bots · Personal Projects · Small Next.js Applications · REST APIs
Need more performance? Upgrade at any time as your application grows with no downtime.
Choose Node.js StarterNode.js Business
£19.99/mo
- Daily Backups
- UK Data Centre
- 1GB RAM Allocation
- 50% CPU Allocation
- DDoS Protection
- Friendly UK Support
Perfect For
Business Websites · Express.js Applications · NestJS Applications · Production APIs · Customer Portals · Growing Projects
Scale your application effortlessly by upgrading your hosting plan whenever you need additional resources.
Choose Node.js BusinessNode.js Professional
£39.99/mo
- Daily Backups
- Priority Support
- UK Data Centre
- 2GB RAM Allocation
- 100% CPU Allocation
- DDoS Protection
Perfect For
SaaS Platforms · Next.js Applications · Nuxt.js Applications · NestJS APIs · GraphQL Services · High-Traffic Websites
Designed for developers who need reliable performance and the flexibility to scale production applications.
Choose Node.js ProfessionalNode.js Enterprise
£79.99/mo
- UK Data Centre
- 4GB RAM Allocation
- 200% CPU Allocation
- DDoS Protection
Perfect For
Digital Agencies · Enterprise Applications · Multiple Node.js Projects · High-Traffic APIs · Large SaaS Platforms · Mission-Critical Workloads · Unlimited bandwidth is subject to our Fair Usage Policy.
When reliability and performance matter most, Enterprise provides the resources and support to keep your applications running at their best.
Choose Node.js EnterpriseThe new workflow
let an ai build it. let git deploy it.
AI tools now produce a complete, working Next.js or Astro project in an afternoon. The part nobody solves for you is where it lives afterwards — and push-to-Git turns out to be the whole answer.
Describe what you want built
Claude Code, Cursor, v0 or Lovable will generate a working Next.js or Astro project — pages, styling, components, the lot. What used to be a week of scaffolding is now an afternoon of iterating.
Push it to GitHub
The AI writes to a repository like any developer would. That repository becomes the single source of truth, with a full history of every change and a way back from any of them.
Point Plesk at the repo
Add the remote, pick the branch, choose automatic deployment. Plesk pulls the code down whenever you push.
Install, build, enable — once
Set the Node version and startup file, install dependencies, run the build, start the application. This is the only part done by hand, and only the first time.
Iterate by pushing
Ask for a change, review the diff, push. The site updates. Re-run install and build when dependencies or built output change; otherwise pushing is the whole deploy.
Why this suits shared hosting
- An AI-built site is a normal Node application. It needs a process and a domain, not a platform-specific runtime.
- No cold starts. The process stays warm, so the first visitor after a quiet hour gets the same speed as the last.
- Predictable cost — a fixed monthly price rather than per-invocation billing that spikes with a traffic surge.
- It sits alongside your WordPress site, mail and domains on one account and one invoice.
This site is built and deployed exactly this way — Next.js, written with AI assistance, pushed to GitHub, pulled by Plesk.
what actually happens when you push.
“Push to Git and it is live” reads like a slogan. It is really just four steps, and only the first one is yours to do.
- git push
you push a change
You, or the AI you are working with, save a change to the Git repository. In an editor that is one button; on the command line it is one command.
- plesk pulls
the panel pulls it
Plesk is watching the branch you told it to track. It sees the new commit and pulls the code straight onto your hosting — no FTP client, no dragging a build folder across.
- passenger restarts
your app restarts
Passenger brings up the new version of your app and takes the old one down. For a typical site that is a second or two, and visitors keep being served while it happens.
- live
it is on the internet
The change is public. The part of shipping that used to mean a held breath and a checklist becomes the part you stop thinking about.
Two steps sit outside this loop: installing dependencies and running the build. You repeat those only when your dependencies change or your framework needs recompiling — the rest of the time, pushing is the entire deploy.
most shared hosting is php and nothing else.
Which is why the standard advice for anything JavaScript is “get a VPS”. That advice is right when you need root or background workers — and unnecessary for a rendered site or an API, where it just hands you an operating system to maintain.
Multiple Node versions
Pick the Node version per application and change it later. A legacy app on an older runtime and a current one can sit on the same account without arguing.
Phusion Passenger
Passenger runs your app as a long-lived process behind nginx and restarts it on demand — so you get a real Node server rather than a CGI-style shim.
npm install from the panel
Install dependencies and run package scripts from the control panel. No SSH required, though SSH is there when you would rather use it.
Environment variables
Set secrets and configuration in the panel rather than committing a .env file — which is how API keys end up in a public repository.
Git deployment
Connect a GitHub, GitLab or Bitbucket repository and Plesk pulls on push. No FTP, no dragging a build folder around.
Restart on demand
Restart the application from the panel after a deploy or a config change, without touching the rest of the account.
why node behaves differently.
Not faster by decree — structurally different. PHP rebuilds the world on every request; Node builds it once and keeps it.
PHP, per request
Every request starts the application from nothing: boot the interpreter, load the framework, read config, open a database connection, render, then throw all of it away. That work repeats on the next request, and on every request after it.
Node, persistent
The process starts once and stays running. The framework is already loaded, database connections are already open, and anything cached in memory is still there. A request arrives and the app is ready for it.
No per-request bootstrap
Startup cost is paid once at boot rather than on every hit. What that is worth depends entirely on how heavy your application is to start, which is why a number quoted without your code attached is meaningless.
In-memory caching actually works
A value cached in a variable survives between requests, so you can hold a parsed config, a compiled template or an API response without reaching for Redis. In PHP that memory disappears when the request ends.
Long-lived connections
Database pools and open sockets persist instead of being re-established constantly. WebSockets are possible at all, which they are not under a per-request model.
The trade: state persists too
A memory leak accumulates rather than being cleared by the request ending, and a crash takes out every in-flight request rather than one. Persistent processes reward care and punish sloppiness — PHP is more forgiving precisely because it forgets everything.
On benchmarks: we have not published any, because a hosting benchmark without your application attached tells you very little. The gap between a well-built site and a badly-built one dwarfs the gap between stacks. If you want numbers for your specific app, run them on a plan and we will help you read the results honestly — including when they say you do not need us.
the words that trip people up, in plain english.
None of this is as opaque as it first sounds. Five terms cover almost everything you meet setting up a Node app — here they are with the jargon taken out.
- Phusion Passenger
- The thing that keeps your app switched on. On ordinary hosting a web server hands each request to PHP, which runs and then vanishes. Passenger instead starts your Node app once and keeps it alive as a real, long-running process, feeding it requests as they arrive. You never configure it by hand — you just tell the panel which file to start.
- The startup file
- The one file Passenger runs to boot your app — its front door. For a plain Express app that is your server file; for a framework like Next.js it is usually a small file that starts the framework's own server. You point the panel at it once and forget it is there.
- The build step
- Some frameworks compile your code ahead of time, turning your source into the optimised files a browser actually receives. That compilation is the build. It runs once per change to the code — not on every visit — and it has to finish before the app starts. On your laptop it is the npm run build command; here it is a button.
- node_modules
- The folder of downloaded libraries your app depends on. It is deliberately kept out of Git — large and machine-specific — and rebuilt on the server by running install. That is why the first thing you do after the code arrives is install: the code is there, but the things it leans on are not yet.
- Environment variables
- Settings and secrets — API keys, database passwords — that you set in the panel rather than writing into your code. It keeps them out of your Git repository, which is precisely where secrets should never live, because a repository is one careless click from being public.
push to git. that is the deploy.
Plesk tracks a branch and pulls when you push. No workflow files, no deploy keys to manage by hand. Here is the one-time setup, in order.
Point Plesk at your repository
Add the Git remote in the panel and choose the branch to track. Plesk clones it into the application root.
Set the Node application up
Application root, startup file and application mode. The startup file is the entry point Passenger runs — for a framework build that is usually a small server file rather than the framework's own CLI.
Install dependencies
Run NPM install from the panel. Do this with the application STOPPED — installing over a running app leaves node_modules half-written, and the failure looks like a mysterious build error later.
Run your build
Run the build script from the panel. For frameworks that compile ahead of time, this is the step that produces what the server actually serves.
Enable and push
Start the application. From then on, pushing to the tracked branch pulls automatically — you only repeat install and build when dependencies or built output change.
The one that catches everybody: stop the application before running NPM install. Installing over a running app leaves node_modules half-written, and the symptom appears later as a build error that looks like something else entirely. Disable, install, build, enable — in that order.
the startup file, demystified.
It is the one artefact that stumps people, and it is genuinely small. The startup file is simply the file Passenger runs to switch your app on. For a plain Express app it is your server file; for Next.js it is a short file that boots the framework’s server.
Set once in the panel
- Application root
- where your repo was cloned
- Startup file
- server.js
- Application mode
- production
- Node.js version
- match what you build with
You point the panel at these once and never touch them again. From then on, deployment is a push.
const { createServer } = require("http");const next = require("next"); // dev:false runs the built app, not the dev serverconst app = next({ dev: false });const handle = app.getRequestHandler(); app.prepare().then(() => { // Passenger tells us which port to listen on createServer((req, res) => handle(req, res)) .listen(process.env.PORT || 3000);});Illustrative — the deployment guide has the full version, plus the equivalents for Express, Nuxt and Astro, and the panel settings screen by screen.
what fits here, and what wants a server.
Shared hosting Node is real, but it is not a cloud server with a nicer panel. Here is the honest split.
| Shared hosting | Cloud server | |
|---|---|---|
| Next.js / Nuxt / Astro site | Included | Included |
| Express or Fastify API | Included | Included |
| Static site build step | Included | Included |
| AI-built site (Claude, Cursor, v0) | Included | Included |
| Headless CMS (Strapi, Payload) | Small instances | Included |
| Long-running background workers | Not included | Included |
| WebSockets at scale | Not included | Included |
| Your own system packages | Not included | Included |
| Root access | Not included | Included |
| You maintain the OS | No — we do | Yes |
the usual suspects all run.
Anything that boots a Node HTTP server works, which is most of the ecosystem. Frameworks that build ahead of time need their build step run before the app starts — that is the only real difference from a local machine.
We can say this one with confidence: sparkz.network itself is a Next.js application running on this stack, deployed from GitHub.
Known to run
- Next.js
- Express
- Nuxt
- Fastify
- Astro
- SvelteKit
- Remix
- NestJS
- Strapi
- Payload CMS
Running something not listed? Ask — if it boots a Node server and does not need root, it almost certainly works.
Domain search
need a domain for it?
Search every extension we sell, with renewal prices shown next to registration prices.
node.js questions
Can you really run Node.js on shared hosting?
Yes. Plesk runs Node applications through Phusion Passenger, which keeps your app running as a real long-lived process behind nginx. It is not a workaround or a CGI shim. Most budget shared hosting is PHP-only, which is why people assume Node needs a VPS — it does not, unless you need what a VPS specifically gives you.
I used an AI tool to build my site and I am not a developer — can I still deploy it here?
Yes, and it is increasingly why people arrive here. The AI writes your site into a Git repository just like a developer would; you connect that repository in the panel once, choose the Node version and startup file, then install and build with a button each. After that, every change goes live when it is pushed. You do not have to write code to follow the setup — and if a step is unclear, the team who run the platform will walk you through the one-time part.
Which Node versions are available?
Several, and you choose per application rather than per account. That matters when you are running an older app that has not been updated alongside something current — they can coexist without one dictating the other's runtime.
How does Git deployment work?
Connect a GitHub, GitLab or Bitbucket repository in the panel and choose a branch. Plesk pulls when you push. There are no workflow files to write and no deploy keys to manage by hand — though you still run install and build yourself when dependencies or built output change.
What is a startup file, and how do I know what mine is?
It is the single file Passenger runs to start your app — think of it as the front door. For a plain Express or Fastify app it is your main server file. For a framework like Next.js it is usually a small file that boots the framework's server; our deployment guide includes one you can copy almost verbatim. You set it once in the panel and never touch it again.
Can I run Next.js?
Yes, and it is one of the most common things people run here. Next needs a small startup file that boots the server for Passenger, and the build has to be run before the app starts. Our guide walks through both, including the mistakes that cost people an afternoon.
Do I need to use a terminal or know Linux?
For most things, no. Installing dependencies, running the build, restarting the app and editing environment variables are all buttons in the Plesk panel. SSH is available if you prefer a command line or need to do something fiddly, but it is optional rather than the main way in.
Do I get SSH access?
SSH is available, and useful for anything fiddly. Most day-to-day work — installing dependencies, running scripts, restarting the app, editing environment variables — can be done from the panel without it.
Can I use a database with my Node app?
Yes. Create MySQL or MariaDB databases in the panel and connect to them from Node exactly as you would anywhere else. Because a Node app is a long-lived process, a connection pool stays open between requests instead of being torn down and rebuilt on every one — one of the practical upsides of the persistent model.
What are the limits compared with a cloud server?
You do not get root, you cannot install system packages, and long-running background workers or heavy WebSocket use are not a good fit — those want a server of your own. For a rendered site, an API, or a small app, shared hosting handles it and you are not responsible for patching the operating system.
Can I run Node.js and WordPress on the same account?
Yes. They are separate applications under the same Plesk account, with their own domains or subdomains. A marketing site on WordPress, a Node API alongside it, and a legacy PHP app on anything from PHP 5 to 8.5+ can all coexist on one account.
What happens on a deploy — does the site go down?
Passenger restarts the application, so there is a brief moment while the new process starts. For most sites that is a second or two. If you need genuinely zero-downtime deploys, that is a cloud server conversation.
deploy it from git this afternoon.
Tell us what you are running and we will tell you honestly whether shared hosting fits it — or whether you want a server.