Blazor VPS hosting

Blazor Server hosting on UpCloud using Nginx and HTTPS

Use this guide when a small Blazor Server app requires its own Ubuntu VPS rather than a managed platform. It covers essential tasks: DNS, SSH, .NET, Nginx, TLS, service restarts, backups, and ongoing server costs.

The starting point is a basic UpCloud server at approx. £2/month. This may suffice for a modest production launch, provided you maintain simple and repeatable patching, monitoring, log rotation, and rollback routines.

View UpCloud Check prerequisites Open GhostlyHosting

UpCloud promotion: both you and we receive £21 in credits. Your monthly server cost remains unchanged by using the referral link.

Quick answer

Opt for a VPS when control outweighs platform convenience

A small UpCloud VPS suits those seeking stable costs, full Linux access, custom Nginx configurations, direct log access, and a deployment process that can be audited. It’s unsuitable if you prefer not to patch Ubuntu, monitor disk space, test backups, or troubleshoot systemd at inconvenient times.

Domain and DNS SSH key access Nginx with TLS You manage operations

Suitability check

A budget Blazor VPS is only viable if operational demands are manageable

Server cost isn’t the only factor. Consider time spent on updates, firewall rules, certificates, restores, logs, monitoring, and failed deployments before choosing self-hosting for a production app.

Suitable option

Choose this route if you want full control

  • You want full control over Nginx, systemd, SSH, logs, files, and runtime versions.
  • The app is modest enough to start on a small VPS and scale later from a snapshot or rebuild.
  • You can manage Ubuntu updates, firewall rules, certificates, backups, restores, and monitoring.
  • You need predictable monthly infrastructure costs rather than managed platform convenience.
Unsuitable

Opt for managed hosting when operational risks are a concern

  • No one is responsible for patching, backups, uptime checks, disk pressure, or incident response.
  • The app requires managed scaling, managed databases, deployment slots, and platform support from day one.
  • Non-technical colleagues must deploy and recover the app without handling Linux.
  • A brief outage would cost more than a managed hosting fee.
Contents

Before setup

Prepare domain, DNS, SSH, .NET, Nginx, and TLS settings first

Most failed VPS launches aren’t due to Blazor itself. They occur because DNS isn’t configured, SSH access is unclear, ports are blocked, the app path is improvised, or certificates are set up before the domain points to the server.

DNS prerequisite

Point DNS before TLS

Create the A or AAAA record for the final hostname before running Certbot. Certificate validation requires the public name to resolve correctly.

SSH access

Use SSH keys and a deploy user

Start with key-based access, avoid routine root uploads, and decide which user owns the app directory before the first release.

.NET runtime

Choose where publishing happens

Install the ASP.NET Core runtime on the VPS. Add the full .NET SDK only when you intentionally build or publish on the server.

Server plan

Begin with the approx. £2/month server only if the app is modest

The smallest plan provides a launch baseline, not a guarantee. It’s best for low to moderate traffic, mainly static assets served by Nginx, lightweight database use elsewhere, and a team able to scale before memory or CPU limits affect users.

Plan reference approx. £2
Use it for
Small production apps, staging apps, internal dashboards, prototypes with real users, and low-traffic content sites.
Avoid it for
Memory-heavy apps, noisy background jobs, large local databases, high traffic spikes, or teams without server maintenance time.
Upgrade signal
Scale when swap usage, CPU saturation, queue delays, or restart frequency become apparent in logs and user timings.
01

Create the server

Choose the nearest suitable region, a clean Ubuntu image, SSH keys, and the smallest plan matching your launch risk.

02

Lock the network

Allow SSH, HTTP, and HTTPS. Keep databases, dashboards, and app ports private unless there’s a specific reason.

03

Take a baseline snapshot

Snapshot the server after hardening and before the first production deploy so rebuilds are quicker and less stressful.

04

Document the rebuild

Keep the DNS, package, firewall, app path, service name, and certificate steps in a concise runbook.

Server setup

Patch Ubuntu, minimise public exposure, and install .NET carefully

Start with a clean Ubuntu image. Apply updates, keep timestamps consistent, install only necessary packages, and open only SSH, HTTP, and HTTPS ports. The SDK is optional on the server if publishing from your workstation or CI.

Essential packages

Shell
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget unzip apt-transport-https ca-certificates gnupg
sudo timedatectl set-timezone UTC

Firewall and fail2ban

Shell
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 fail2ban

.NET packages

Shell
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.0

Deployment process

Publish locally, upload reliably, and let systemd manage the app process

For a small server, the safest manual deployment is straightforward: build a Release output, upload it to a designated directory, run the app as a dedicated user, and delegate restart behaviour and logging to systemd.

Publish and upload

Shell
# 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-app

systemd service

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.target

Nginx and TLS

Place Kestrel behind Nginx and enforce HTTPS as the sole public access point

Kestrel should listen on localhost. Nginx handles public traffic, redirects HTTP to HTTPS, terminates TLS, forwards the original host and protocol, and maintains a consistent URL for users and search engines.

Nginx reverse proxy

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;
    }
}

Certbot commands

Shell
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-run

Operations

Manage costs responsibly by scheduling maintenance before traffic arrives

The monthly VPS fee is predictable. Operational costs are not, unless you establish routines for patching, certificate renewal checks, log rotation, disk alerts, snapshots, restore tests, and a swift rollback process for failed releases.

Ubuntu updates

Scheduled patching

Perform package updates during a planned period, then verify the Blazor service, Nginx status, and certificate renewal process.

Backup restorations

Test restores, not just snapshot creation

Snapshots are only useful once restored. Include app files, secrets, and database backups in your recovery plan.

Server logs

Monitor for silent failures

Use journalctl, Nginx logs, disk alerts, and uptime checks to ensure failed deployments or bot traffic don’t go unnoticed.

VPS scaling

Scale up before users notice

Upgrade to a larger plan, separate services, add a CDN, or clone from a snapshot before memory pressure causes downtime.

SEO reality

Hosting supports SEO only when fundamentals remain stable

A VPS alone doesn’t generate rankings. It helps when it provides stable URLs, quick initial responses, correct HTTPS redirects, clean metadata, matching JSON-LD, and fewer outages than cheaper alternatives previously used.

01

HTTPS redirects

Redirect HTTP once, maintain certificate renewals, and avoid mixed-content assets that break page appearance.

02

Stable URLs

Use human-readable routes, keep canonical URLs consistent, and avoid deployment paths that change after each release.

03

VPS performance

Measure TTFB, cache static assets via Nginx, compress responses, and ensure the first page load remains reliably fast.

04

SEO metadata

Keep title, H1, description, Open Graph image, Article schema, BreadcrumbList, and FAQPage schema consistent with visible content.

Automation option

Use GhostlyHosting when repeating manual setup poses a risk

Manual setup is valuable for understanding every component. If you know the stack and want a guided, repeatable deployment, GhostlyHosting can automate the Ubuntu, Nginx, SSL, GitHub, and service management workflow.

Review GhostlyHosting View UpCloud

FAQs

Can I host Blazor Server on UpCloud for approx. £2/month?

Yes, for a modest app with realistic expectations. The entry-level plan supports a small launch, staging environment, or internal tool, but monitoring, backups, patching, and scaling plans are still necessary.

Do I need the full .NET SDK on the VPS?

Usually not. Install the ASP.NET Core runtime when publishing from your workstation or CI. Only install the SDK if the server builds or publishes the app intentionally.

Should Kestrel be exposed directly to the internet?

No. Bind Kestrel to localhost and expose Nginx on ports 80 and 443. Nginx manages TLS, redirects, proxy headers, and the public URL.

What are the biggest risks of cheap Blazor VPS hosting?

Common risks include unpatched packages, expired certificates, poor SSH practices, missing backups, disk pressure, noisy logs, and unnoticed repeated service restarts.

Does VPS hosting improve Blazor SEO?

Only if the setup enhances fundamentals: stable HTTPS URLs, fast responses, clean metadata, matching JSON-LD, uptime, and predictable redirects. Hosting alone isn’t an SEO shortcut.

When should I use GhostlyHosting instead of manual setup?

Use manual setup to learn or audit the stack. Choose GhostlyHosting for a repeatable Ubuntu, Nginx, SSL, GitHub, and service-management workflow once you understand the components.