.NET 8 and 9 End of Life — Upgrade Your VPS to .NET 10

A VPS upgrade has several separate parts. The build tools, application target, runtime image and database must work together. Start by identifying the deployed application, prepare a recovery copy, then test the new release on an isolated service.

The example below is a minimal ASP.NET Core HTTP service. Use it to understand the deployment layout, then adapt the project name, configuration and tests for your application. Commands are intended for a Linux VPS with Docker Engine and the Compose plugin already installed.

.NET 8 and 9 support dates and the .NET 10 upgrade target

Microsoft's servicing policy requires supported installations to stay current on patches. Record the runtime version you actually deploy and make patching part of the maintenance schedule. Check the current support policy.

A suitable migration target also depends on package support, native libraries and application behaviour. Here, .NET 10 LTS gives an existing .NET 8 or 9 deployment a defined support window while you test those dependencies.

1. Find which application and runtime are running

For an application installed directly on Linux, run these commands under the account and installation path used by the service.

dotnet --info
dotnet --list-sdks
dotnet --list-runtimes

dotnet --version reports the selected SDK. The runtime list shows shared runtimes in that installation. Check the application's .runtimeconfig.json, its project file and any service definition to connect those versions to the process receiving traffic. Read Microsoft's runtime inventory guidance.

For Docker deployments, inspect the actual service image and its runtime. Replace app with your Compose service name and run from its project directory.

sudo docker compose ps
sudo docker compose images
sudo docker compose exec app dotnet --list-runtimes

Some self-contained or Native AOT images have no dotnet executable. Use the release's build records, target framework and image metadata to identify the bundled runtime. A self-contained release carries its own runtime and needs rebuilding and redeployment when that runtime changes. Review .NET publishing modes.

2. Prepare backups and a rollback boundary

Before changing a live service, keep the existing release and the information required to start it. Include the deployment configuration, protected environment values, database backup, uploads and any persistent application keys.

• Store a database-aware backup and verify that it restores into an isolated database.
• Retain the current application image by digest or preserve the published release directory.
• Record which database schema versions the old and new applications support.
• Plan how to pause writes or reconcile data if a rollback becomes necessary.

Give staging its own database, storage and credentials. Disable real payment actions, outbound customer messages and scheduled jobs while testing a copied environment. Keep a written record of the backup time and the last point at which the old release can safely resume.

For off-server recovery copies, HYEHOST Storage Box supports SFTP and other access methods, including S3-compatible access in beta. Encrypt archives containing credentials or personal data and rehearse the restore path. Explore Storage Box backup access.

3. Update the project, SDK selection and dependencies

Work in a separate branch with the .NET 10 SDK available in your development or CI environment. Update the application project's target framework.

<TargetFramework>net10.0</TargetFramework>

Review any SDK version pinned in global.json and the SDK image selected by CI. Update Microsoft packages and third-party dependencies to versions that support the target framework. Follow each package's migration notes, especially database providers and authentication integrations. Follow the ASP.NET Core 9 to 10 migration guide.

When moving from .NET 8, review the intervening .NET 9 changes as well. Check affected APIs, serializers, authentication behaviour and database queries against your own test cases. Review .NET 9 changes. Review .NET 10 changes.

From the solution or project directory, restore dependencies, compile and run your test suite.

dotnet restore
dotnet build --configuration Release --no-restore
dotnet test --configuration Release --no-build

Add checks for the paths users rely on. Include sign-in, permissions, API responses, uploads, database writes and background work. Compare important response formats with the old release so that dependent clients remain compatible.

4. Build an ASP.NET Core 10 Docker image

The following files create a small service called UpgradeDemo. Start in an empty directory reserved for this example. For an existing application, use its own project layout and DLL name.

Create UpgradeDemo.csproj.

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

Create Program.cs. Its health endpoint returns a small JSON response.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/healthz", () => Results.Ok(new { status = "ok" }));

app.Run();

Create Dockerfile. The SDK stage publishes the application, and the final stage contains the ASP.NET Core runtime.

FROM mcr.microsoft.com/dotnet/sdk:10.0-noble AS build
WORKDIR /src
COPY UpgradeDemo.csproj ./
RUN dotnet restore UpgradeDemo.csproj
COPY . .
RUN dotnet publish UpgradeDemo.csproj -c Release -o /out \
    --no-restore -p:UseAppHost=false

FROM mcr.microsoft.com/dotnet/aspnet:10.0-noble
WORKDIR /app
COPY --from=build /out .
USER $APP_UID
EXPOSE 8080
ENTRYPOINT ["dotnet", "UpgradeDemo.dll"]

The official Linux images provide the non-root application user used here. Keep application writes in deliberately configured writable locations. Read the official non-root user guidance.

The noble suffix selects Ubuntu 24.04 inside the container. .NET 10's default Linux image family changed to Ubuntu, so review native-library and package-installation assumptions in older Dockerfiles. The container's distribution is separate from the VPS host's distribution. Read the container image change.

Create .dockerignore to keep build outputs and common secret files outside the build context. Add your project's other private paths.

bin/
obj/
.git/
.env*
*.pfx
*.key

10.0-noble follows updates within that image line. For reproducible releases, record the tested base-image digests and application image digest in your deployment records. Rebuild and retest deliberately when adopting newer patches.

5. Stage the service with a loopback-only port

Create compose.yaml alongside the project files.

services:
  app:
    image: hyehost-upgrade-demo:net10
    build: .
    restart: unless-stopped
    environment:
      ASPNETCORE_ENVIRONMENT: Production
      ASPNETCORE_HTTP_PORTS: "8080"
    ports:
      - "127.0.0.1:8080:8080"

The application listens on port 8080 inside its container. Compose makes it reachable through the VPS loopback address, ready for a reverse proxy installed on the host. Modern ASP.NET Core container images use port 8080 by default. Check Microsoft's port guidance.

sudo docker compose config --quiet
sudo docker compose build --pull
sudo docker compose up -d
sudo docker compose logs --tail 100 app
curl --fail http://127.0.0.1:8080/healthz

Expect a JSON response containing "status":"ok". For your real application, a process health endpoint is one check among several. Verify database access and required dependencies through separate readiness or functional tests.

Our Docker installation guide covers the host prerequisites. The firewall guide explains Docker-published ports and the importance of testing reachability from another machine. Install Docker on a VPS. Review Docker firewall behaviour.

6. Test public HTTPS and application sign-in

Connect your existing host-installed reverse proxy to 127.0.0.1:8080. For an installed Caddy service, an application site block can look like this. Replace the hostname and configure its DNS records to reach your VPS.

app.example.com {
    reverse_proxy 127.0.0.1:8080
}

Validate and reload through your Caddy service's normal configuration workflow, then check the public hostname from another machine. Caddy's reverse proxy documentation covers upstream configuration. Review the Caddy directive.

If your proxy runs in another container, connect it through a shared Docker network and address the application by service name. Adapt the port publication for that layout. A container's loopback address refers to that container itself.

For a real application, configure ASP.NET Core's forwarded-header middleware with the actual trusted proxy addresses or networks. A Docker bridge can change the source address the application sees. Test secure cookies, redirects and generated URLs through the final HTTPS endpoint. Review Microsoft's proxy configuration guidance.

Check IPv4 and IPv6 wherever both appear in DNS. A staging sign-in and a successful write through the public hostname give you more information than a local health response alone.

7. Switch traffic and keep recovery usable

Use a separate staging service or VPS to complete the checks before touching the production listener. Build and retain a versioned application image, run any reviewed database migration and switch the reverse proxy during the planned maintenance window.

After cutover, watch application exceptions, response latency, database errors and background queues. Confirm the next scheduled backup completes and run a small user-facing transaction through the normal interface.

If a rollback is needed, first check database compatibility. Restarting an older image is safe only when it understands the current state. Otherwise use the rehearsed recovery procedure, including how writes since the backup are preserved or reconciled. Record the final runtime and image digest once the release is accepted.

For later patches, repeat the build, staging and verification cycle. A host runtime update leaves an application's existing container image unchanged until you rebuild or replace that image. Follow the Compose update workflow.

Choose VPS resources around the workload

HYEHOST Cloud VPS and VDS are available in Wolverhampton, Ashburn and Auckland. Choose a region close to the people and systems using the application, then measure memory use, CPU peaks, database activity and monthly public transfer.

Common .NET VPS upgrade problems

.NET end-of-life and VPS upgrade FAQ