Good Node.js hosting is more than a folder where you upload files. A production app needs a process that restarts after a crash, a reverse proxy in front of it, a TLS certificate, safe storage for secrets, readable logs, a way to deploy without downtime, and a database. Python apps need the same list, with a different application server.
This page explains each requirement, shows which Node.js and Python versions are still supported in November 2026, and compares shared hosting limits with a managed server. It is written for agencies, freelancers and small-business IT who run Python app hosting and Node.js apps for clients and want a clear view of what to ask a hosting provider.
What Node.js hosting needs in production
A process manager
A Node.js or Python app is a long-running process. If it crashes or the server restarts, something must start it again. For Python, the Gunicorn documentation says to supervise the server with a process monitor such as systemd, Supervisor or runit. For Node.js, PM2 is one common choice. It can start several copies of an app, one per CPU core, in what it calls cluster mode.
A reverse proxy
Your app should not face the internet directly. The Gunicorn documentation strongly recommends running it behind a proxy server such as nginx. With the default synchronous workers, the proxy must buffer slow clients, otherwise the app is exposed to denial-of-service attacks. A proxy also lets several apps share ports 80 and 443 on one server.
Two details cause many support tickets. First, nginx does not pass the original Host header to the app by default, so you must set it with proxy_set_header. Second, the app sees the proxy address as the client address unless you pass and log the X-Forwarded-For header, as the Gunicorn documentation explains.
TLS
Visitors expect HTTPS. The usual design is to end TLS at the reverse proxy and forward plain HTTP to the app on the local machine. Check how your provider issues and renews certificates. On PFHW, certificates are uploaded or bought from us; there is no automatic issuing, so renewal is a task you plan for.
Environment variables and secrets
The Twelve-Factor App method says configuration that changes between deployments, including credentials, should live in environment variables and not in code. Its test is simple: you could publish the code repository at any moment without exposing a credential. This also applies to Git deployment hosting: keep secrets out of the repository and set them on the server.
Logs
You need the application log, the proxy access log and the error log, with a retention period that fits your needs. Make sure logs are rotated so they do not fill the disk. The Gunicorn documentation, for example, describes sending a signal to the main process so it reopens its log files after rotation.
Zero-downtime deploys
A restart stops the app and starts it again, which causes a short gap. PM2 offers a separate reload command that is designed to avoid that gap, and it falls back to a normal restart if the reload cannot finish in time. Its documentation adds two conditions: the app should handle the SIGINT signal to finish pending work, and it should be stateless, with sessions kept in an external store such as a database or Redis. Gunicorn can reload its configuration and workers when it receives the HUP signal, which a systemd unit can send with a reload command.
Databases
Most apps need a database. Decide early whether it runs on the same server or elsewhere, who patches it, and how it is backed up. A restore test matters more than the backup schedule. PFHW includes MariaDB and PostgreSQL, with phpMyAdmin and Adminer for administration.
Node.js and Python support status in November 2026
Run only versions that still receive security fixes. The tables below show the status on 7 November 2026. Release schedules can change, so check the source before you plan an upgrade.
Node.js release lines
| Node.js line | Status in November 2026 | Active LTS started | Maintenance started | End of life (scheduled) |
|---|---|---|---|---|
| 26.x (Lithium) | Active LTS | 2026-10-28 | 2027-10-20 (scheduled) | 2029-04-30 |
| 24.x (Krypton) | Maintenance LTS | 2025-10-28 | 2026-10-20 | 2028-04-30 |
| 22.x (Jod) | Maintenance LTS | 2024-10-29 | 2025-10-21 | 2027-04-30 |
| 20.x (Iron) | End of life | 2023-10-24 | 2024-10-22 | 2026-04-30 |
Sources: nodejs/Release schedule for lines 22, 24 and 26; a Node.js timeline article dated 24 July 2026 for the dates of line 20. All dates are subject to change.
In short, line 26 is the Active LTS line, and lines 24 and 22 are in Maintenance LTS. Line 22 ends on 30 April 2027, so plan its replacement now. The schedule also changes from Node.js 27: according to the release team, every line from 27 is promoted to LTS and skips the Maintenance phase. Node.js 27 is in Alpha, with its LTS start scheduled for 20 October 2027.
Python branches
| Python branch | Status in November 2026 | First release | End of life |
|---|---|---|---|
| 3.15 | Bugfix | 2026-10-09 | 2031-10 (scheduled) |
| 3.14 | Bugfix | 2025-10-07 | 2030-10 (scheduled) |
| 3.13 | Security fixes only | 2024-10-07 | 2029-10 (scheduled) |
| 3.12 | Security fixes only | 2023-10-02 | 2028-10 (scheduled) |
| 3.11 | Security fixes only | 2022-10-24 | 2027-10 (scheduled) |
| 3.10 | End of life | 2021-10-04 | 2026-10-01 |
Source: Python Developer's Guide, Status of Python versions. Dates marked as scheduled can be adjusted.
Python 3.10 reached end of life on 1 October 2026, five weeks before this page was written. An app still on 3.10 no longer receives security fixes from the Python project.
Which versions PFHW offers
The panel's Web apps page creates Node.js apps (versions 22, 24 and 26), Java apps (versions 17, 21 and 25) and Tomcat apps. You can deploy code from a Git repository and branch, from a ZIP file, or from a folder that already holds the code; you also set a start file and an optional build command. The Applications page runs Python apps (WSGI and ASGI) and Ruby apps. These versions come from our function list and help text as of November 2026; versions change with releases, so check the panel for the current list and ask us before you plan around one specific version. Builds such as npm install run in a separate builder, and no compiler runs on the web server.
Python app hosting: what differs from Node.js
Python web apps normally run through a WSGI or ASGI application server, for example Gunicorn, behind the same kind of reverse proxy. Python apps usually keep their dependencies in a virtual environment per app, so two apps can use different package versions. The supervision, TLS, secrets and logging requirements above are the same. The main practical difference is the worker model: Gunicorn starts a set of worker processes, and the number of workers drives memory use, which we cover in our guide on how much server a set of websites needs.
Git deployment hosting: what to look for
Git deployment hosting means you push code to a repository and the server updates the site. For production use, check five points:
- Rollback: can you return to the previous release in one step if a deploy breaks the site?
- Build step: where do dependencies install and where does the build run, on the server or in a separate pipeline?
- Secrets: are credentials kept outside the repository, as the Twelve-Factor method advises?
- Restart behaviour: does a deploy restart the app or reload it without a gap?
- Access: which key or token pulls from your repository, and can you limit it to read-only?
PFHW includes Git deployment with rollback. Sites can also be uploaded by SFTP.
Shared hosting limits compared with a managed server
Some shared hosting plans can run Node.js and Python apps through a tool in the control panel. The public documentation of two hosting providers shows the typical limits. These are examples from those providers, not rules for all shared hosting.
| Topic | Typical shared hosting (two providers' documentation) | Managed server (PFHW) |
|---|---|---|
| Resources | The app uses the entry processes and memory of the hosting account's limits. | vCPU and RAM are dedicated to your server, not shared. |
| Port | The platform assigns the port, and the app must read it from an environment variable. | Reverse proxy sites are part of the panel. |
| Background workers | The app is meant to answer web requests, not to run as a queue worker or background service. | Not covered on this page; ask us about your workload. |
| Builds | Heavy builds can fail, so the advice is to build locally and upload the result. | Builds run in a separate builder; no compiler runs on the web server. Ask us about heavy builds. |
| Runtime versions | Limited to the list the provider installs. One provider listed Node.js 20, 22 and 24 for cPanel. | Node.js 22, 24 and 26 in our help text; Python apps (WSGI and ASGI) on the Applications page. Check the panel for the current list. |
| Number of sites | Set by the plan. | No limit on sites or accounts on any plan. |
| Deployment | Install packages and restart from the selector tool. | Git deployment with rollback. |
Sources: documentation from Domain India (queue workers and heavy builds) and Ultra Web Hosting (version lists), read on 7 November 2026. The Domain India article also notes that Node.js 20 and older have reached end of life, which matches the release schedule above.
For a hobby project, shared hosting with an app selector can be enough. For a client application with a process that must stay up, a managed server gives you more control over resources, and you do not run the server yourself.
Where PFHW fits, and where it does not
Where it fits
- Agencies and freelancers who host PHP sites and a few Node.js or Python apps for clients on one dedicated virtual server.
- Teams who want the operating system patched, the firewall maintained and nightly backups handled by engineers, while they keep control of the application code.
- Teams who want Git deployment with rollback, reverse proxy sites and per-domain PHP versions in one panel.
- Projects that need EU data residency: the data centre is Tier III in Vilnius, Lithuania.
Where it does not, or where you should check first
- There is no automatic certificate issuing. Certificates are uploaded or bought from us.
- The language versions listed above can change with releases. Check the panel for the current list, or ask us if you need one specific version.
- Managed means the server, not your app. We patch the operating system and keep the firewall; your code and its dependencies remain your responsibility.
- The panel interface is English only at present.
You can ask for a demo and then a trial server to test your own app before you commit. Contact info@cloudacropolis.com.
Frequently asked questions
What is nodejs hosting?
It is a hosting setup that can run a Node.js application as a long-running process. It normally includes a process manager, a reverse proxy, TLS and a way to deploy updates. Plain web hosting that only serves PHP files and static pages does not provide this.
Which Node.js version should I use in November 2026?
Use an LTS line. According to the Node.js release schedule, line 26 is Active LTS and lines 24 and 22 are in Maintenance LTS. Line 22 reaches end of life on 30 April 2027, so new projects should start on 24 or 26.
Is Python 3.10 still supported?
No. The Python Developer's Guide lists 3.10 as end of life on 1 October 2026. Move to 3.11 or newer; 3.11 is scheduled to reach end of life in October 2027.
Do I need a process manager if my host restarts the server?
Yes. A server restart does not cover a crash of one app, and a deploy needs a controlled restart or reload. systemd, Supervisor or PM2 handle this.
Can I deploy from Git without downtime?
It depends on the app and the setup. A reload that starts new workers before it stops the old ones can avoid a gap, but the app must be stateless and handle shutdown signals. Test this on a staging site first.
Does PFHW support Node.js and Python?
Yes. PFHW runs Node.js apps (versions 22, 24 and 26 in our help text) and Python apps (WSGI and ASGI), plus Ruby and Java with Tomcat, with reverse proxy sites and Git deployment with releases. Check the panel for the current version list.
Related resources
- Managed web hosting vs shared hosting vs unmanaged VPS
- How many websites fit on one VPS, and how much RAM do you need?
- Website backup strategy and the 3-2-1 rule
- Control panel hardening checklist
- Web hosting control panels: a guide
Sources
- Node.js release schedule, nodejs/Release on GitHub
- Node.js release and EOL timeline (status as of 24 July 2026), Hidekazu Konishi
- Status of Python versions, Python Developer's Guide
- Cluster mode, PM2 documentation
- Deploying Gunicorn, Gunicorn documentation
- proxy_set_header, nginx documentation
- III. Config, The Twelve-Factor App
- Node.js and Python apps, Ultra Web Hosting documentation
- Node.js on shared hosting, Domain India knowledge base
- Managed Web Server, CloudAcropolis