Recomendaciones de VPS
Recomendaciones de VPS gratis (2026): guía en profundidad de servidores en la nube gratuitos permanentes y de prueba (con lista de verificación de aceptación de 7 días y migración)
La verdadera dificultad de un VPS gratis no está en "si puedes conseguirlo", sino en "si puede funcionar de forma estable durante el periodo que necesitas". Este artículo descompone lo gratuito permanente y las pruebas por tiempo limitado en un árbol de decisión ejecutable: primero decide según el escenario, luego filtra según el presupuesto de riesgo, después verifica con un script de aceptación de 7 días y, por último, cubre con un plan de migración. Al terminar sabrás qué cargas de trabajo pueden ir en la capa gratuita y cuáles deben pasar a la capa de pago cuanto antes.
Empiezo por la conclusión:
Un VPS gratis se puede usar, pero solo como "capa de validación", nunca como "capa de entrega".
He visto a mucha gente tratar una máquina gratuita directamente como host en línea. Las dos primeras semanas van muy bien, pero a partir de la tercera empiezan a sufrir las cuotas, los controles de riesgo y las fluctuaciones de red, y al final migrar sale más caro y más desordenado que comprar desde el principio un VPS de pago de bajo coste.
Este artículo no ofrece listas esotéricas; te da directamente un marco ejecutable:
- Cómo distinguir "gratis permanente" de "prueba por tiempo limitado"
- Cómo juzgar si la capa gratuita realmente te conviene
- Cómo hacer una aceptación de 7 días para evitar el "parece que funciona"
- Cuándo migrar decididamente a un VPS de pago
Mucha gente mezcla todos los recursos gratuitos en una sola categoría. Ese es el primer error.
| Tipo | Forma habitual | Uso típico | Mayor riesgo |
|---|---|---|---|
| Cuota gratuita permanente (Always Free) | Instancias/almacenamiento/cuota de funciones de especificaciones pequeñas fijas | Aprender Linux, scripts ligeros, PoC | Especificaciones pequeñas, restricciones regionales, escasez de capacidad impredecible |
| Créditos de prueba por tiempo limitado (Trial Credits) | Crédito de 30-90 días | Pruebas de carga a corto plazo, proyectos de curso, validación técnica | Termina al vencer; interrupción si no has migrado |
| Recursos educativos/para estudiantes | Cuota o beneficios de herramientas tras verificación de estudiante | Proyectos de estudiantes, experimentos de curso | Hay umbrales de verificación y renovación; los beneficios pueden cambiar |
| Regalos de la comunidad/campañas de marketing | Crédito de prueba único | Demos temporales | Reglas que cambian rápido, poca sostenibilidad |
Si tu objetivo es "ejecutar a largo plazo un blog/API/servicio principal", asume por defecto: la capa gratuita es solo una transición, no la meta.
Este paso importa más que "qué proveedor elegir".
| Escenario de carga de trabajo | ¿Es razonable la capa gratuita? | Motivo | Recomendación |
|---|---|---|---|
| Aprender Linux, practicar comandos | Razonable | Alta tolerancia a interrupciones | La capa gratuita basta |
| Tareas de curso, demo de proyecto de fin de estudios | Razonable (con plan de migración) | Duración controlable | Primero gratis, luego de pago |
| Entorno de pruebas temporal | Razonable | Necesidad a corto plazo | Vincular copias de seguridad automáticas |
| Blog personal (poco tráfico) | Apenas viable | Requisitos de disponibilidad medios | Mejor preparar una alternativa de pago de bajo coste |
| API de producción orientada a usuarios | No recomendable | Altos requisitos de disponibilidad y estabilidad | Directamente capa de pago |
| Sitio comercial/negocio de clientes | No recomendable | El coste del riesgo supera con creces el coste de la máquina | Pago + monitorización + copias de seguridad |
Mi propia experiencia: en cuanto empiezas a preocuparte por el SLA, las ventanas de fallo y el tiempo de recuperación, la capa gratuita debe pasar a un segundo plano.
Lo que más te engaña de "gratis" es que la facturación y la estabilidad no están en la misma dimensión.
- Facturación tras superar la cuota de tráfico de salida (egress)
- Almacenamiento de snapshots/copias de seguridad facturado aparte
- Registros, monitorización, NAT e IP elásticas pueden generar cargos adicionales
- Tras vencer los créditos de prueba, los recursos que siguen en ejecución pasan a facturación por uso
- Las especificaciones gratuitas pueden tener suministro ajustado en regiones populares
- Cuando se activan los controles de riesgo de la cuenta, las instancias pueden congelarse o restringirse
- En horas punta la contención de CPU es evidente; la fluctuación es mayor de lo que imaginas
- Sin plan de migración, el día que termina la prueba te ves "obligado a caer"
- Sin copias de seguridad, la configuración se pierde al reconstruir la instancia
- Los cambios de IP pública desordenan las listas blancas y el DNS
De estos tres tipos de riesgo, el realmente fatal es el operativo, porque estalla cuando estás más ocupado.
Puedes ejecutarlo tal cual.
uname -a
nproc
free -h
df -h
ip -br a
curl -4 ifconfig.co || true
curl -6 ifconfig.co || true
Objetivo: confirmar las especificaciones de la máquina, el disco disponible y la situación de IPv4/IPv6.
# 本机 -> VPS
traceroute -n <VPS_IP> | head -n 20
mtr -rwzc 200 <VPS_IP>
Objetivo: registrar la latencia media, el percentil 99 y la pérdida de paquetes; no mires solo un resultado.
Si no sabes interpretar estos resultados, empieza por:
- Pruebas de carga en franjas fijas (día + hora punta nocturna)
- Observa si CPU, memoria y IO de disco muestran picos prolongados
- Registra la proporción de "fallos recuperables" y "fallos no recuperables"
Como mínimo haz:
- Inicio de sesión SSH con clave
- Desactivar el inicio de sesión directo de root y el inicio con contraseña
- UFW con los puertos mínimos abiertos
- Bloqueo básico con Fail2Ban
Si no lo has hecho, puedes seguir directamente esto:
Debes verificar dos cosas:
- Si las copias de seguridad se pueden restaurar
- Si puedes migrar a un nuevo host en 30-60 minutos
Si no puedes hacer estas dos cosas, la capa gratuita no te "ahorra dinero", sino que "retrasa el pago de la deuda".
Como mínimo conserva:
- Inventario de servicios (puertos, dependencias, variables de entorno)
- Scripts de despliegue (Docker Compose / Ansible / Shell)
- Scripts de copia de seguridad y de restauración de datos
- Pasos de cambio de DNS (TTL, punto de reversión)
5.2 Líneas rojas que activan la migración (recomendado pegarlas directamente en tu documentación de operaciones)
Migra si se cumple cualquiera de estas:
- Fluctuación evidente en la hora punta nocturna durante 2 días consecutivos
- Los costes de tráfico de salida empiezan a ser incontrolables
- Los controles de riesgo de la cuenta se activan con frecuencia
- Los picos de tráfico del negocio ya superan las especificaciones gratuitas
Primero busca una capa de pago estable y de bajo coste; no saltes directamente a especificaciones altas:
Si no tienes claro tu límite de presupuesto, empieza por:
- Recomendaciones de VPS baratos (2026): ¿cómo elegir por menos de $3 al mes?
- Análisis del coste real de un VPS (2026)
P1: ¿Tu negocio permite 1-2 interrupciones?
- Sí -> pasa a P2
- No -> directamente VPS de pago
P2: ¿Puedes completar la migración en 1 hora?
- Sí -> la capa gratuita es usable (a corto plazo)
- No -> primero completa el plan de migración y luego publica
P3: ¿Vas a generar tráfico público de forma continua?
- Sí -> vigila sobre todo el coste de egress
- No -> la capa gratuita puede seguir en observación
P4: ¿Tu negocio está orientado a usuarios reales?
- Sí -> pasa a la capa de pago cuanto antes
- No -> la capa gratuita sigue como capa de experimentación
Si quieres empezar hoy mismo, te sugiero este orden:
- Primero toma la capa gratuita para una validación de 7 días
- Configura la seguridad y las copias de seguridad al mismo tiempo
- Haz un ensayo de migración el día 7
- Cuando haya usuarios visitando, prioriza pasar a una capa de pago de bajo coste
Así obtienes el beneficio del "prueba y error gratis" sin entregar el destino de tu negocio a la incertidumbre.
La forma correcta de usar un VPS gratis no es "aprovecharse hasta el final", sino "validación de bajo coste + migración controlable".