Hosting VPS para Blazor
Hosting Blazor Server en UpCloud con Nginx y HTTPS
Usa esta guía cuando una pequeña app Blazor Server necesite su propio VPS Ubuntu en lugar de una plataforma gestionada. Cubre el trabajo real: DNS, SSH, .NET, Nginx, TLS, reinicios de servicio, copias de seguridad y el coste continuo de mantener el servidor.
El punto de partida es un servidor UpCloud simple desde aprox. 3 €/mes. Puede ser suficiente para un lanzamiento de producción modesto, pero solo si mantienes simples y repetibles las tareas de parcheo, monitorización, rotación de logs y restauración.
Nota promocional UpCloud: tú y nosotros recibimos 25 € en créditos. El precio mensual de tu servidor no aumenta por el enlace de referido.
Respuesta rápida
Usa un VPS cuando el control importe más que la comodidad de la plataforma
Un VPS pequeño en UpCloud es ideal si quieres costes estables, acceso completo a Linux, reglas personalizadas en Nginx, logs directos y un flujo de despliegue inspeccionable. No es adecuado si no quieres parchear Ubuntu, vigilar espacio en disco, probar backups o depurar systemd en momentos incómodos.
Comprobación de ajuste
Un VPS Blazor barato solo es útil si el trabajo operativo es aceptable
El precio del servidor no es toda la decisión. Cuenta el tiempo para actualizaciones, reglas de firewall, certificados, restauraciones, logs, monitorización y despliegues fallidos antes de elegir alojamiento propio para una app en producción.
Elige esta opción si quieres control
- Quieres control total sobre Nginx, systemd, SSH, logs, archivos y versiones en ejecución.
- La app es lo suficientemente modesta para empezar en un VPS pequeño y escalar luego desde un snapshot o reconstrucción.
- Puedes gestionar actualizaciones de Ubuntu, reglas de firewall, certificados, copias de seguridad, restauraciones y monitorización.
- Necesitas costes mensuales de infraestructura predecibles más que la comodidad de una plataforma gestionada.
Elige hosting gestionado cuando las operaciones sean un riesgo
- Nadie se encarga de parches, copias, comprobaciones de uptime, presión de disco o respuesta a incidentes.
- La app necesita escalado gestionado, bases de datos gestionadas, slots de despliegue y soporte de plataforma desde el día uno.
- Compañeros no técnicos deben poder desplegar y recuperar la app sin tocar Linux.
- Una caída breve sería más cara que la factura de un hosting gestionado.
Índice
Antes de la configuración
Prepara primero dominio, DNS, SSH, .NET, Nginx y TLS
La mayoría de lanzamientos fallidos en VPS no se deben a Blazor. Suceden porque el DNS no está listo, el acceso SSH no está claro, los puertos están bloqueados, la ruta de la app es improvisada o la configuración del certificado empieza antes de que el dominio apunte al servidor.
Apuntar DNS antes de TLS
Crea el registro A o AAAA para el nombre final antes de ejecutar Certbot. La validación del certificado necesita que el nombre público resuelva correctamente.
Usa claves SSH y un usuario de despliegue
Empieza con acceso por clave, evita subidas rutinarias como root y decide qué usuario posee el directorio de la app antes del primer lanzamiento.
Elige dónde publicar
Instala el runtime ASP.NET Core en el VPS. Añade el SDK completo de .NET solo si vas a compilar o publicar intencionadamente en el servidor.
Plan de servidor
Empieza con el servidor de aprox. 3 €/mes solo si la app es modesta
El plan más pequeño es una base para el lanzamiento, no una garantía. Funciona mejor para tráfico bajo a moderado, activos estáticos principalmente detrás de Nginx, uso ligero de base de datos en otro lugar y un equipo que pueda escalar antes de que la presión de memoria o CPU sea visible para el usuario.
- Úsalo para
- Aplicaciones de producción pequeñas, entornos de staging, paneles internos, prototipos con usuarios reales y sitios de contenido con poco tráfico.
- Evítalo para
- Aplicaciones que consumen mucha memoria, trabajos en segundo plano ruidosos, bases de datos locales grandes, picos altos de tráfico o equipos sin tiempo para mantenimiento del servidor.
- Señal de actualización
- Escala cuando el uso de swap, saturación de CPU, retrasos en la cola o frecuencia de reinicios sean visibles en los registros y tiempos de usuario.
Crear el servidor
Elige la región útil más cercana, una imagen limpia de Ubuntu, claves SSH y el plan más pequeño que se ajuste al riesgo de lanzamiento.
Bloquear la red
Permite SSH, HTTP y HTTPS. Mantén privadas las bases de datos, paneles y puertos de la app salvo que haya una razón específica.
Tomar una instantánea base
Haz una instantánea del servidor tras el endurecimiento y antes del primer despliegue en producción para que las reconstrucciones sean más rápidas y menos estresantes.
Documentar la reconstrucción
Guarda los pasos de DNS, paquetes, firewall, ruta de la app, nombre del servicio y certificados en un runbook breve.
Configuración del servidor
Parchea Ubuntu, mantén la superficie pública pequeña e instala .NET con cuidado
Empieza con una imagen limpia de Ubuntu. Aplica actualizaciones, mantén las marcas de tiempo predecibles, instala solo los paquetes necesarios y abre solo SSH, HTTP y HTTPS. El SDK es opcional en el servidor si publicas desde tu estación de trabajo o CI.
Paquetes base
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget unzip apt-transport-https ca-certificates gnupg
sudo timedatectl set-timezone UTCFirewall y fail2ban
sudo apt install -y ufw fail2ban
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw enable
sudo systemctl enable --now fail2banPaquetes .NET
wget https://packages.microsoft.com/config/ubuntu/24.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb
sudo apt update
sudo apt install -y aspnetcore-runtime-8.0Flujo de despliegue
Publica localmente, sube de forma predecible y deja que systemd gestione el proceso de la app
Para un servidor pequeño, el despliegue manual más seguro es simple: crea una salida Release, súbela a un directorio conocido, ejecuta la app como un usuario dedicado y asigna a systemd la responsabilidad del reinicio y los logs.
Publicar y subir
# Build locally
dotnet publish -c Release -o publish
# Copy to UpCloud (replace user@host)
rsync -avz --delete publish/ user@YOUR_UPCLOUD_IP:/var/www/blazor-app/releases/current/
# On the server, set ownership
sudo useradd -m -s /bin/bash blazorapp || true
sudo chown -R blazorapp:blazorapp /var/www/blazor-appServicio systemd
[Unit]
Description=Blazor Server on UpCloud
After=network.target
[Service]
User=blazorapp
WorkingDirectory=/var/www/blazor-app/releases/current
ExecStart=/usr/bin/dotnet /var/www/blazor-app/releases/current/YourApp.dll --urls http://127.0.0.1:5001
Restart=always
RestartSec=5
Environment=ASPNETCORE_URLS=http://127.0.0.1:5001
[Install]
WantedBy=multi-user.targetNginx y TLS
Coloca Kestrel detrás de Nginx y haz que HTTPS sea la única ruta pública
Kestrel debe escuchar en localhost. Nginx recibe tráfico público, redirige HTTP a HTTPS, termina TLS, reenvía el host y protocolo original y mantiene la URL estable para usuarios y rastreadores.
Proxy inverso Nginx
server {
listen 80;
listen [::]:80;
server_name app.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name app.example.com;
ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
location / {
proxy_pass http://127.0.0.1:5001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "keep-alive";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache_bypass $http_upgrade;
}
}Comandos Certbot
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect --agree-tos -m [email protected]
sudo certbot renew --dry-runOperaciones
Mantén los costes honestos planificando el mantenimiento antes de que llegue el tráfico
La factura mensual del VPS es predecible. El coste operativo no lo es, a menos que lo conviertas en rutina: ventanas de mantenimiento para aplicar parches, comprobaciones de renovación de certificados, rotación de logs, alertas de disco, snapshots, pruebas de restauración y un proceso rápido de reversión para despliegues fallidos.
Parchar según calendario
Ejecuta actualizaciones de paquetes en una ventana planificada, luego comprueba el servicio Blazor, el estado de Nginx y la ruta de renovación del certificado.
Prueba la restauración, no solo la creación de instantáneas
Las instantáneas solo son útiles cuando has restaurado una. Mantén archivos de la app, secretos y copias de seguridad de bases de datos en el plan de recuperación.
Vigila fallos silenciosos
Usa journalctl, registros de Nginx, alertas de disco y comprobaciones de uptime para que fallos en despliegues o tráfico de bots no pasen desapercibidos.
Escala antes de que los usuarios lo noten
Pasa a un plan mayor, divide servicios, añade un CDN o clona desde una instantánea antes de que la presión de memoria cause caídas.
Realidad del SEO
El hosting solo mejora el SEO si lo básico se mantiene estable
Un VPS no genera posiciones por sí solo. Ayuda cuando ofrece URLs estables, respuestas rápidas, redirecciones HTTPS correctas, metadatos limpios, JSON-LD coherente y menos caídas que la solución barata que usabas antes.
Redirecciones HTTPS
Redirige HTTP una vez, mantén la renovación de certificados y evita activos de contenido mixto que hagan que las páginas parezcan rotas.
URLs estables
Usa rutas legibles, mantén URLs canónicas consistentes y evita rutas de despliegue que cambien tras cada versión.
Rendimiento del VPS
Mide TTFB, cachea activos estáticos con Nginx, comprime respuestas y mantén la carga inicial de la página rápida y constante.
Metadatos SEO
Mantén alineados título, H1, descripción, imagen Open Graph, esquema Article, BreadcrumbList y FAQPage con el contenido visible.
Opción de automatización
Usa GhostlyHosting cuando repetir la configuración manual sea lo arriesgado
La configuración manual es útil para entender cada parte. Si ya conoces el stack y quieres un despliegue guiado y repetible, GhostlyHosting puede automatizar el flujo de trabajo de Ubuntu, Nginx, SSL, GitHub y gestión de servicios.
Sección de preguntas frecuentes
Preguntas frecuentes sobre hosting Blazor en UpCloud
Respuestas breves sobre hosting Blazor Server en UpCloud, costes VPS, .NET, Nginx, HTTPS, SEO y mantenimiento para un lanzamiento de aprox. 3 €/mes.
¿Puedo alojar Blazor Server en UpCloud por aprox. 3 €/mes?
Sí, para una app modesta con expectativas controladas. El plan básico puede manejar un lanzamiento pequeño, entorno de staging o herramienta interna, pero necesitas monitorización, copias, parches y plan de escalado.
¿Necesito el SDK completo de .NET en el VPS?
Normalmente no. Instala el runtime de ASP.NET Core al publicar desde tu estación o CI. Instala el SDK solo si el servidor construye o publica la app intencionadamente.
¿Debe exponerse Kestrel directamente a internet?
No. Vincula Kestrel a localhost y expón Nginx en los puertos 80 y 443. Nginx gestiona TLS, redirecciones, cabeceras proxy y la URL pública.
¿Cuáles son los mayores riesgos de un hosting VPS barato para Blazor?
Los riesgos comunes son paquetes sin parchear, certificados caducados, mala higiene SSH, falta de copias, presión en disco, registros ruidosos y que nadie note reinicios repetidos del servicio.
¿Mejora el hosting VPS el SEO de Blazor?
Solo si la configuración mejora los fundamentos: URLs HTTPS estables, respuestas rápidas, metadatos limpios, JSON-LD coincidente, uptime y redirecciones predecibles. El hosting por sí solo no es un atajo SEO.
¿Cuándo debería usar GhostlyHosting en vez de hacerlo manualmente?
Usa la configuración manual para aprender o auditar la pila. Usa GhostlyHosting cuando quieras un flujo repetible de Ubuntu, Nginx, SSL, GitHub y gestión de servicios tras entender las partes móviles.