Un allotjament Node.js amb marge per a aplicacions de veritat

Sí, la decisió és del tot vostra. Com que tots els plans són un VPS KVM amb root complet, no depeneu de la versió que un allotjament compartit tingui a bé oferir. La majoria de gent instal·la nvm i baixa la versió exacta que necessita la seva aplicació (la línia LTS actual per tenir estabilitat en producció, o una versió concreta contra la qual s'ha provat el projecte) i canvia de versió per projecte al mateix servidor. Si ho preferiu, podeu instal·lar els binaris oficials de Node o els paquets de la vostra distribució. També podeu mantenir diverses versions en paral·lel i fixar cada aplicació a la seva amb un fitxer .nvmrc, cosa molt pràctica quan hi allotgeu més d'un projecte. Quan surt una LTS nova, actualitzeu quan us convingui a vosaltres i no quan ho decidim nosaltres. Res de l'entorn d'execució no està bloquejat: decidiu la versió, si feu servir npm, pnpm o yarn com a gestor de paquets, i quan actualitzar.

Tots dos funcionen bé perquè teniu root. Per a un procés Node normal, PM2 és l'opció habitual: manté l'aplicació en marxa, la reinicia si peta, pot bifurcar diverses instàncies per aprofitar tots els nuclis de CPU i us rota els registres. Normalment n'hi ha prou amb un `pm2 start` més `pm2 startup` i `pm2 save` perquè l'aplicació sobrevisqui a un reinici. Si preferiu els contenidors, instal·leu Docker i executeu la vostra imatge directament, o aixequeu una pila petita amb un fitxer docker-compose: per exemple, un contenidor d'aplicació al costat de Postgres i Redis. Hi ha qui combina les dues coses, amb Docker per a les dependències i PM2 per a l'aplicació, o a l'inrevés. Com que el servidor és vostre, també podeu fer servir unitats de systemd si us encaixa millor amb el vostre flux de treball. Nosaltres mantenim sans el VPS de sota, la xarxa i la protecció DDoS; com superviseu els vostres processos ho decidiu vosaltres.

Són plans de VPS autogestionats, i és una decisió deliberada: mantenir el servidor no gestionat és justament el que fa possibles l'accés root, les versions de Node a mida i la vostra pròpia configuració de processos a aquest preu. Vosaltres sou els amos de tot el que hi ha per damunt del sistema operatiu: l'entorn d'execució de Node, PM2 o Docker, el vostre proxy invers, les bases de dades i els desplegaments són vostres per configurar-los com demani la vostra aplicació. El que gestionem nosaltres és la base de sota (el maquinari físic, la virtualització KVM, la xarxa del centre de dades tier-3 i la protecció DDoS) perquè no us hàgiu de preocupar mai de les peces que no es veuen. El nostre equip de suport és disponible 24/7 per a qüestions d'infraestructura, aprovisionament i xarxa, i us pot ajudar a redimensionar un pla o a resoldre problemes de connectivitat. Si preferiu no administrar el servidor vosaltres mateixos, tenim opcions gestionades a petició, i molts equips confien la capa d'aplicació a un desenvolupador mentre nosaltres mantenim el VPS ràpid, en línia i protegit.

Sí. Amb root complet podeu instal·lar Postgres, MongoDB o Redis directament al VPS i fer que la vostra aplicació Node hi parli per localhost, cosa que manté la latència baixa i evita un salt de xarxa addicional. Redis és un company habitual per a sessions, memòria cau i cues de tasques, mentre que Postgres o MongoDB guarden les dades principals: feu servir-ne un, o tots tres, dimensionats segons la RAM que us doni el vostre nivell. Al davant de l'aplicació és habitual posar-hi Nginx com a proxy invers: acaba el TLS amb un certificat SSL gratuït de renovació automàtica, serveix el punt públic del 443, reparteix la càrrega entre les vostres instàncies de PM2 o de Docker i pot guardar a la memòria cau els recursos estàtics. Aquesta és la distribució clàssica de producció: Nginx a la vora, Node al darrere i les bases de dades al costat. Si preferiu tenir les dades en una base de dades gestionada a part, simplement us hi connecteu; res no obliga a posar la base de dades a la mateixa màquina.

Un `node server.js` pelat s'atura en el moment que tanqueu el terminal o el procés peta, així que en un servidor de veritat l'executeu sota un gestor de processos. PM2 és la resposta habitual: converteix l'aplicació en dimoni, la reinicia automàticament després d'una caiguda i, amb `pm2 startup` i `pm2 save`, ho torna a aixecar tot després d'un reinici. El seu mode clúster pot bifurcar un treballador per nucli de CPU perquè una sola aplicació faci servir tots els recursos que li dona el vostre nivell, i la gestió de registres integrada facilita seguir el rastre dels problemes. Si opteu pels contenidors, les polítiques de reinici de Docker fan la mateixa feina, i systemd és una opció nativa molt sòlida si la preferiu. A més, els recursos KVM garantits i l'emmagatzematge NVMe fan que l'aplicació no hagi de competir per la CPU amb veïns sorollosos, i la protecció DDoS a escala de xarxa la manté accessible sota atac. Entre un gestor de processos i uns recursos dedicats, la mateixa disponibilitat que veieu a les proves és la que reben els vostres usuaris.

Sí. Després de donar-vos d'alta, obriu un tiquet i el nostre equip us ajuda a posar-ho tot a punt: aprovisionar el servidor, confirmar l'SSH i la vostra IPv4 dedicada i orientar-vos amb el sistema operatiu i el tallafoc. Per a l'aplicació, un desplegament típic consisteix a clonar el vostre repositori Git al servidor, instal·lar dependències, definir les variables d'entorn, compilar si cal i arrencar el procés sota PM2 o Docker, i us assessorem de bon grat sobre aquest flux. Si veniu d'un altre proveïdor, us podem ajudar a portar-hi el codi, la configuració d'entorn i qualsevol base de dades local perquè l'aplicació funcioni igual al VPS nou. Podeu preparar-la i provar-la a la IP dedicada abans de canviar el DNS, així el canvi és net. Tenim assistència gestionada per a la capa d'aplicació a petició si voleu una mà més ferma; si no, el nostre equip 24/7 es queda a la banda de la infraestructura i la xarxa.

Yes. Since you have full root and outbound access, you can authenticate npm, pnpm or yarn against a private registry using a token in your package manager's config, exactly as you would on your own machine. There's no proxy or firewall rule blocking package installs, so private dependencies resolve the same way they do in local development.

Every plan includes daily backups of the server, covering your application code, installed dependencies, configuration and any co-located database data. If a deploy goes wrong, a dependency upgrade breaks something, or a config change needs undoing, you can restore to a previous day rather than rebuilding by hand.

Yes — root access means the server's own cron is available for anything you'd rather run outside your application process, such as nightly database dumps or report generation. Just as commonly, people schedule jobs from within Node itself using a scheduling library, keeping that logic in the same codebase as the rest of the app. Both approaches run fine side by side on the same VPS.

Yes, every Node.js VPS plan carries a 30-day money-back guarantee, so you can put a real workload on the server, benchmark it against wherever you're hosting now, and request a refund within that window if it isn't the right fit. It's the same guarantee across our hosting lineup, not a scaled-down version for VPS.

Yes. A single VPS can run several Node processes at once — each on its own port, managed as a separate PM2 process or container, with a reverse proxy routing incoming requests to the right one based on subdomain or path. It's a common way to run an API, an internal dashboard and a webhook handler on one server instead of three, or to keep a staging copy running next to production.

Yes. Pricing across our plans, including the Node.js VPS tiers, is displayed and billed in your local currency automatically based on where you're signing up from, so international teams don't have to work out conversions before checkout.