Recomendaciones de VPS
Recomendaciones de VPS para desarrollo y pruebas (2026): ¿cómo elegir sin caer en trampas? Configuración, regiones, facturación y lista de verificación al recibirlo
Un VPS para desarrollo y pruebas no necesita ser "el más potente", sino "el más cómodo": facturación por horas, instantáneas, escalado en cualquier momento, red estable y reinstalación cuando quieras. Este artículo lo desglosa según escenarios reales de desarrollo (CI Runner, entornos temporales, colaboración entre varias personas, depuración de API en el extranjero) y te ofrece una lista de selección + pasos de inicialización de 30 minutos al recibirlo, además de 5 enlaces internos relacionados.
En el tema de los VPS para desarrollo y pruebas, mucha gente elige la dirección equivocada desde el principio:
- Agotan el presupuesto comprando "la configuración más potente"
- Y luego descubren que solo la usan dos veces por semana
- O compran algo barato que no admite instantáneas o cuya reinstalación es engorrosa, y al final todo depende de aguantar como sea
La necesidad central del desarrollo/pruebas no es "la configuración tope", sino:
- Encender y apagar en cualquier momento (mejor con facturación por horas)
- Reinstalar y revertir en cualquier momento (instantáneas/copias de seguridad)
- Que la red no sea un desastre (sin pérdida de paquetes ni rutas indirectas constantes)
Este artículo lo desglosa según escenarios reales: si sigues la lista, básicamente no caerás en grandes trampas.
El desarrollo y las pruebas suelen caer en estas categorías:
- Ejecutar una API / demo temporal
- Levantar una base de datos/Redis para pruebas de integración
- Probar una configuración de Nginx/Caddy
Características: uso fragmentado, ciclo de vida corto.
- Runner de GitHub Actions / runner de GitLab autoalojado
- Compilar imágenes, ejecutar pruebas unitarias, ejecutar lint
Características: la CPU y el IO de disco importan más que el "ancho de banda".
- Necesitas llamar a servicios extranjeros, hacer origin pull o probar el acceso desde el extranjero
Características: elegir bien la región es más importante que la configuración.
Muchos casos de "pagué de más / compré mal" se deben a no haber mapeado el escenario a los recursos.
| Escenario | Configuración recomendada (inicial) | Trampas a tener en cuenta |
|---|---|---|
| API / demo temporal | 1-2 vCPU / 1-2GB / 20-40GB SSD | Lo que más temes es no apagarla; la facturación por horas se convierte en pago mensual |
| Docker + BD ligera | 2 vCPU / 2-4GB / 40GB+ SSD | Las imágenes/logs llenan el disco con facilidad |
| CI Runner (máquina de compilación) | 2-4 vCPU / 4GB+ / 80GB+ SSD | La caché de compilación consume mucho disco; el IO importa más que el ancho de banda |
| Programar en remoto (code-server) | 2 vCPU / 2GB+ / 40GB+ SSD | La experiencia depende mucho de la fluctuación de red (el teclado se "pega") |
| Colaboración entre varias personas / varios servicios permanentes | 4 vCPU / 8GB+ / 80GB+ SSD | Sin seguridad ni copias de seguridad, un solo incidente es muy molesto |
Puedes tomarlo como una regla:
- Sensible a la "velocidad de respuesta/interactividad": valora más la estabilidad y la fluctuación
- Sensible a la "compilación/build": valora más la CPU + el disco
Lo que más teme un entorno de desarrollo es "romper la instalación".
- Reinstalación con un clic: te atreves a experimentar
- Reversión por instantánea: no temes que una actualización falle
Los entornos temporales realmente no se usan un mes completo.
- Hoy levantas uno para probar algo
- Mañana lo eliminas
La facturación por horas reduce el costo al mínimo.
En un entorno de desarrollo, muchas veces no se trata de descargar archivos grandes, sino de la interactividad de SSH/HTTP.
Lo que debes vigilar:
- Pérdida de paquetes
- Fluctuación de latencia
Si no estás familiarizado con el diagnóstico de red, guarda primero este artículo:
Muchas trampas no son "no sabes configurar", sino "el nodo que compraste no es adecuado para ti".
Ejecuta este conjunto de comandos en el VPS y sabrás rápidamente: si los recursos están inflados, si el disco es demasiado pequeño, si la red fluctúa y si IPv6 sirve.
# 系统与资源
uname -a
uptime
free -h
df -hT
# 网卡与路由
ip a
ip r
# DNS 与基础连通
ping -c 3 1.1.1.1
# IPv4/IPv6 出站（有 IPv6 的机器建议测一下）
curl -4 -s https://api.ipify.org && echo
curl -6 -s https://api64.ipify.org && echo
Si sientes que "no entiendes estas salidas", no pasa nada: al menos guarda los resultados para poder comparar rápidamente cuando surjan problemas más adelante.
No necesitas probar todos los proveedores.
Ya hay puntos de entrada disponibles en el sitio (usa enlaces cortos de vendor según las reglas):
- Vultr: facturación por horas, encendido/apagado cómodo, adecuado para entornos temporales
- Racknerd: barato, adecuado para pruebas/creación de sitios donde "con que funcione basta"
- Contabo: orientado a la ruta de discos grandes, adecuado para quienes priorizan recursos (pero no lo tomes como solución de baja latencia)
¿Cómo elegir? En una frase:
- Entornos temporales/reconstrucción frecuente: prioriza una buena experiencia de "encendido/apagado, instantáneas, facturación"
- Quienes priorizan recursos/varios servicios permanentes: elige "más recursos al mismo precio"
- Orientado a la experiencia de usuarios en China continental: no mires solo el precio; mira primero la región/ruta
Como mínimo haz dos cosas:
- Permitir solo inicio de sesión con clave
- Instalar Fail2Ban / firewall
Sigue directamente este artículo:
Para ejecutar servicios, Docker es lo más rápido.
El entorno de desarrollo también se convierte en "semi-producción": archivos de configuración, scripts, imágenes privadas e incluso datos.
El dinero desperdiciado que más he visto es: el entorno ya no se usa, pero la máquina sigue encendida.
Puedes usar estas reglas simples para controlar costos:
- Entornos temporales: elimina la instancia al terminar (no la dejes)
- Entornos permanentes: al menos ten clara la "política de retención de disco/instantáneas"
- Usuarios intensivos de Docker: limpia periódicamente imágenes/caché de compilación (no revientes el disco)
Limpiar Docker (atención: elimina recursos no utilizados, no lo uses a la ligera en máquinas de producción):
docker system df
# 确认没问题再执行
docker system prune -af
Si cambias de computadora con frecuencia o quieres abrir el entorno en cualquier momento, Code-server es muy útil:
Si sigues dudando sobre "cuál comprar", te sugiero una estrategia muy práctica:
- Primero compra/levanta uno "lo más barato posible pero que admita instantáneas/reinstalación"
- Ejecuta tu flujo de trabajo real (Docker, compilación, SSH, pruebas de integración de API)
- Decide en una semana si actualizar la configuración o cambiar de región
El VPS para desarrollo y pruebas es, en esencia, una herramienta.
El valor de una herramienta no es "tener especificaciones bonitas", sino que te resulte cómodo usarla.