Node.js on a server you actually own

Whichever one you install — the choice never leaves your hands. Each plan is a KVM VPS with the root account included, so no shared server dictates the build you get. The usual route is nvm: install it, pull the release your project wants, and you are done. That might be the current LTS branch for production work, or the specific version your build was tested against. If nvm is not your habit, grab the official Node binaries or your distribution's own packages instead. Several versions can sit on the same box at once, and an .nvmrc file in each project pins it to the right one, which is handy when a server carries more than one app. New LTS lands? You upgrade on your own timetable, not ours. Version, package manager — npm, pnpm or yarn — and update schedule are all yours to set.

Both, and neither takes any special arrangement, because you hold root. For a plain Node process, PM2 is the common pick: it keeps the app up, restarts it after a crash, forks a worker per CPU core when you want every core earning its keep, and rotates logs on its own. Run pm2 start, then pm2 startup and pm2 save, and the app comes back by itself after a reboot. If containers suit you better, install Docker and run your image, or bring up a small stack with docker-compose — the app in one container, Postgres and Redis alongside it. Mixing the two is common enough: Docker for the dependencies, PM2 for the app, or the reverse. And since the machine is yours, a plain systemd unit is equally valid if that is how you like to work. We look after the VPS, the network and the DDoS filtering; process supervision is your call.

Unmanaged, deliberately so. An unmanaged box is exactly what buys you the root account, the Node version of your choosing and your own process setup at this price. Everything above the operating system belongs to you: runtime, PM2 or Docker, reverse proxy, databases, deploy routine — set up however the project needs. Underneath that line we handle the hardware, the KVM layer, the tier-3 datacenter network and the DDoS defenses, so the parts you cannot see stay off your plate. Support is staffed around the clock for infrastructure, provisioning and network questions, and will happily resize a plan or chase down a route that is misbehaving. If running the server yourself is not what you signed up for, ask us about managed cover. Plenty of teams also keep their own developer on the application side while we keep the VPS quick, reachable and defended.

Yes, and most people do. Root lets you install Postgres, MongoDB or Redis directly on the VPS so the Node app reaches them over localhost — lower latency, one less network hop. Redis usually handles sessions, caching and job queues; Postgres or MongoDB carries the core data. Run one, run all three, sized to the RAM your tier provides. In front of the app, Nginx as a reverse proxy is the standard arrangement: it terminates TLS using a free self-renewing certificate, listens on port 443, spreads requests across your PM2 workers or Docker containers, and serves static files without waking Node. Nginx outward-facing, Node behind it, databases close by — that is the shape of a normal production deployment. Would you rather keep data on a separate managed database? Connect out to it. Nothing here insists the database share the machine.

A process manager, which is why nobody runs node server.js by hand in production — that dies the moment the shell closes or the process throws. PM2 is the usual answer. It daemonizes the app, restarts it after a crash, and paired with pm2 startup and pm2 save it brings everything back after a reboot without you logging in. Cluster mode forks one worker per core so a single app uses the whole tier, and the built-in logs make an incident easier to unpick afterwards. Working in containers instead? Docker restart policies cover the same ground, and a systemd unit is a perfectly good native alternative. Around that, guaranteed KVM cores and NVMe disks mean your app is not elbowing anyone for CPU, and network-level DDoS filtering keeps it reachable while an attack runs. Process manager plus dedicated resources: the uptime you measured in testing is the uptime your users get.

Yes. Once your order is through, raise a ticket and the team will get you moving — the server provisioned, SSH and your dedicated IPv4 confirmed working, and a sensible steer on the operating system and firewall. On the application side, a normal deploy runs like this: clone the Git repository onto the server, install dependencies, set the environment variables, build if the project needs a build, then start it under PM2 or Docker. We are glad to walk that through with you. Arriving from another host? We can help carry over the code, the environment settings and a local database so the app behaves the same on the new VPS. Stage and test on the dedicated IP first, then move DNS across, and the switch stays clean. Want a heavier hand on the application layer? Ask about managed cover — otherwise the 24/7 team stays focused on infrastructure and network.