VPS para Desarrolladores: Stack Ideal y Herramientas 2026
Si desarrollas software, un VPS es diferente a lo que necesita un blogger o una tienda online. Necesitas root total, tu runtime de preferencia, Docker sin restricciones y un pipeline de CI/CD que funcione sin fricciones. Esta guía va al grano.
Por qué los developers prefieren VPS
El hosting compartido está diseñado para usuarios finales, no para developers. Las restricciones no son un accidente — son una decisión de negocio para proteger la estabilidad del servidor frente a cientos de clientes. Pero si sabes lo que haces, esas restricciones solo estorban.
- →Root access completo: instala lo que quieras, configura el kernel, ajusta límites del sistema. Sin ticket de soporte pidiendo permiso.
- →Sin restricciones de runtime: nada de PHP version fija, nada de
exec()bloqueado. Node.js, Python, Go, Rust, Bun — lo que necesites. - →Docker nativo: en hosting compartido, Docker es imposible. En un VPS KVM con root, es trivial instalar y correr contenedores.
- →Portabilidad total: tu app vive en tu servidor. Cambias de proveedor en horas con una imagen de disco o un backup. Sin vendor lock-in.
- →CI/CD propio: GitHub Actions desplegando a tu VPS por SSH es suficiente para la mayoría de proyectos. Sin pagar Vercel, Railway o Render.
Features que busca un developer en un VPS
No todos los VPS son iguales para developers. Hay diferencias técnicas importantes que el marketing suele enterrar en la letra pequeña.
| Feature | Qué buscar | Por qué importa |
|---|---|---|
| Virtualización | KVM (no OpenVZ) | Kernel propio, Docker funciona, módulos del kernel disponibles |
| Storage | NVMe > SSD SATA | Builds más rápidos, base de datos más ágil, I/O intensiva sin cuellos de botella |
| Snapshots/Backups | API o programables | Snapshot antes de un deploy arriesgado. Rollback en minutos si algo explota |
| API de gestión | REST API disponible | Automatizar arranque/parada, crear instancias desde scripts, integrar con IaC |
| Distribuciones | Ubuntu, Debian, Rocky | Elige la distro que ya conoces, no la que impone el proveedor |
| IPv6 nativo | IPv6 incluido de serie | Para servicios modernos, APIs y futura compatibilidad de red |
| Ancho de banda | 1 TB+ o ilimitado | Transferencias de imágenes Docker, pulls de paquetes y logs consumen más de lo que parece |
Proveedores más dev-friendly en España
Filtrado por lo que importa a un developer: API disponible, soporte real de Docker, SSH root sin restricciones, y snapshots utilizables.
| Proveedor | API | Docker | SSH root | Snapshots | IPv6 | Precio base |
|---|---|---|---|---|---|---|
| Hostinger | Sí | Sí | Sí | Sí | Sí | €6.99/mo |
| IONOS | Sí | Sí | Sí | Sí | Sí | €8/mo |
| Raiola Networks | Limitada | Sí | Sí | Sí | Sí | €15/mo |
| SiteGround Cloud | Sí | Sí | Sí | Sí | Sí | €80/mo |
Raiola destaca por su soporte técnico en español genuinamente dev-amigable y sus discos NVMe. Para proyectos de agencia o cuando necesitas que alguien entienda tu stack cuando algo falla a las 10 PM, vale la diferencia de precio frente a Hostinger.
Stacks recomendados por lenguaje
Node.js / Bun (APIs, SSR)
Ubuntu 22.04 LTS + Nginx como reverse proxy + PM2 para process management es el stack más probado. Para proyectos nuevos, Bun como runtime ahorra RAM y mejora el tiempo de arranque.
Instalar Node.js 20 LTS vía nvm y arrancar con PM2:
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
nvm install 20
npm install -g pm2
pm2 start app.js --name mi-app
pm2 startup # auto-arranque al reiniciar
pm2 save Configuración Nginx para proxy reverso a Node en puerto 3000:
server {
listen 80;
server_name mi-dominio.com;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
} Python (FastAPI, Django)
Ubuntu 22.04 + Nginx + Gunicorn como servidor WSGI/ASGI es el combo estándar para producción. Virtualenv (o uv) para aislar dependencias por proyecto.
python3 -m venv /var/www/mi-app/venv
source /var/www/mi-app/venv/bin/activate
pip install fastapi gunicorn uvicorn
# Servicio systemd para auto-restart
cat <<EOF > /etc/systemd/system/mi-app.service
[Unit]
Description=Mi App FastAPI
After=network.target
[Service]
User=www-data
WorkingDirectory=/var/www/mi-app
ExecStart=/var/www/mi-app/venv/bin/gunicorn main:app -w 4 -k uvicorn.workers.UvicornWorker
Restart=always
[Install]
WantedBy=multi-user.target
EOF
systemctl enable mi-app
systemctl start mi-app Go / Rust (servicios de alto rendimiento)
La ventaja de Go y Rust es que el binario compilado no necesita runtime instalado en el servidor. Sin Node.js, sin Python, sin dependencias de sistema. Ideal para VPS con poca RAM (1-2 GB).
# Compilar en local, subir binario al VPS
go build -o mi-servicio ./cmd/server
scp mi-servicio usuario@tu-vps:/usr/local/bin/
# Systemd service (igual de simple)
[Service]
ExecStart=/usr/local/bin/mi-servicio --port 8080
Restart=on-failure
RestartSec=5 Docker y Docker Compose en VPS
Docker en un VPS KVM es trivial. El script oficial instala todo lo necesario en Ubuntu/Debian:
curl -fsSL https://get.docker.com | bash
usermod -aG docker $USER
newgrp docker # aplicar sin cerrar sesión
docker run hello-world # verificar instalación Para apps multi-servicio (web + base de datos + cache), Docker Compose es lo más práctico. Un ejemplo con Node.js + PostgreSQL:
version: '3.8'
services:
web:
image: node:20-alpine
working_dir: /app
volumes:
- .:/app
ports:
- "3000:3000"
environment:
DATABASE_URL: postgres://user:***@db:5432/mydb
depends_on:
- db
db:
image: postgres:16
environment:
POSTGRES_DB: mydb
POSTGRES_USER: user
POSTGRES_PASSWORD: pass
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata: Con docker compose up -d tienes todo corriendo en segundo plano. Los datos de PostgreSQL persisten en el volumen pgdata aunque reinicies los contenedores.
CI/CD desde GitHub Actions a tu VPS
No necesitas Jenkins, ni CircleCI, ni ningún SaaS de CI/CD. GitHub Actions + SSH al VPS es suficiente para la mayoría de proyectos indie y de agencia.
Workflow básico de deploy con SSH y git pull:
name: Deploy to VPS
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Deploy to VPS
uses: appleboy/ssh-action@v1
with:
host: ${{ secrets.VPS_HOST }}
username: deploy
key: ${{ secrets.VPS_SSH_KEY }}
script: |
cd /var/www/mi-app
git pull origin main
npm ci --production
pm2 restart app El secreto VPS_SSH_KEY es la clave privada SSH del usuario deploy (un usuario sin privilegios de root). Lo añades en Settings → Secrets de tu repo de GitHub.
Si quieres algo más parecido a Heroku pero self-hosted, Caprover es un PaaS open source que se instala en cualquier VPS y permite hacer deploy con git push o desde el dashboard web. Soporta Docker, múltiples apps y SSL automático.
Monitorización para developers
Antes de necesitar un stack de observabilidad completo, empieza con herramientas simples que ya vienen con Linux o son gratuitas:
- →btop / htop: visualización en tiempo real de CPU, RAM, disco y red.
btoptiene una UI más moderna. Imprescindible para diagnosticar picos de carga. - →UptimeRobot (free tier): monitoriza tu VPS desde fuera cada 5 minutos. Te avisa por email o Telegram si cae. Gratuito para hasta 50 monitores.
- →Grafana + Prometheus: stack completo de métricas open source. Node Exporter exporta métricas del sistema, Prometheus las recoge y Grafana las visualiza. Consume ~200 MB de RAM extra.
- →Loki + Promtail: logs centralizados de todos tus servicios en un solo lugar, consultables desde Grafana. Alternativa ligera a ELK para VPS.
Para la mayoría de proyectos, htop + UptimeRobot cubre el 90% de los casos. El stack Grafana/Prometheus/Loki vale la pena cuando tienes varios servicios y quieres alertas por umbral de CPU/RAM. Lee cómo configurar un VPS desde cero en Configurar VPS con Ubuntu.
¿Qué VPS encaja con tu stack?
Responde 7 preguntas sobre tu proyecto y te decimos qué proveedor y plan se adapta mejor a lo que construyes. Sin tecnicismos innecesarios.
Encontrar mi hosting ideal →Preguntas frecuentes sobre VPS para developers
¿Qué VPS es mejor para un proyecto Node.js con tráfico moderado? +
Para tráfico moderado (hasta 50K visitas/mes), el Hostinger VPS KVM 1 (4 GB RAM, 2 vCPU, €6.99/mes) es suficiente con Nginx + PM2. Si la app crece, el KVM 2 (8 GB RAM, €12.99/mes) aguanta sin problemas. Lo importante es KVM (no OpenVZ) para tener control total del sistema.
¿Puedo usar Docker en cualquier VPS? +
Solo en VPS con virtualización KVM. En OpenVZ, el kernel es compartido con el host y Docker no funciona (o funciona de forma degradada). Todos los proveedores listados en esta guía usan KVM, así que Docker es completamente funcional en todos ellos.
¿Cuánta RAM necesito para correr Docker + base de datos + API? +
El sistema Ubuntu base consume ~300-400 MB. Docker daemon ~200 MB. PostgreSQL en idle ~50-150 MB. Una API Node.js sencilla ~100-200 MB. En total, 2 GB es el mínimo real, pero 4 GB te da margen para picos y para el build de imágenes Docker sin swap. Con 1 GB te quedarás sin memoria en cuanto hagas un docker build.
¿Es seguro hacer CI/CD directamente al VPS de producción? +
Sí, con las precauciones correctas. Usa un usuario deploy sin sudo (o con sudo muy limitado), clave SSH dedicada para el CI/CD, y firewall que solo permita SSH desde IPs conocidas. Nunca uses la clave root para GitHub Actions. Considera también hacer snapshot antes del deploy si los cambios son arriesgados.
¿Merece la pena Caprover frente a un deploy manual por SSH? +
Depende del número de apps. Para 1-2 proyectos, el deploy manual por SSH es más simple y con menos capas que pueden fallar. Para 5+ proyectos en el mismo VPS o si trabajas en equipo, Caprover ahorra mucho tiempo: SSL automático, apps con un click, logs centralizados y deploy por webhook sin tocar el servidor. Consume ~512 MB de RAM adicional para su propio stack.