.NET Does Not Need Windows Any More: What It Actually Costs to Run in 2026

The most common reason .NET gets dropped from a shortlist in India is Windows licensing. The cost structure behind that objection stopped being true around 2016, and it still decides stacks, because most of the time nobody checks whether it is still the case.

This is the checkable version. What it actually costs to run a .NET application today, where the real costs sit once the licence question goes away, and the cases where .NET genuinely is the wrong pick. We run our own hosting platform, so the infrastructure half of this is something we operate rather than quote from a vendor page.

What changed, and what did not

There are two .NETs and conflating them is where the confusion starts. .NET Framework is the original: Windows-only, versions up to 4.8, still supported but no longer where new features land. .NET, the one without the word Framework, is the rebuilt cross-platform runtime that came out of .NET Core. It runs on Linux, it runs in a container, and the runtime itself costs nothing.

So an ASP.NET Core application deploys to an ordinary Linux box the same way a Node or Laravel application does. Kestrel is the built-in web server, nginx or Caddy sits in front of it, and there is no Windows Server licence anywhere in that picture.

bash# A publish and run, on Ubuntu, with nothing Microsoft-licensed involved
$ dotnet publish -c Release -o /srv/app
$ ASPNETCORE_URLS=http://127.0.0.1:5000 dotnet /srv/app/YourApp.dll

# Or in a container, which is how we would actually ship it
$ docker build -t yourapp .
$ docker run -d -p 127.0.0.1:5000:8080 yourapp

What did not change: if your application is .NET Framework, none of the above applies to it. It is Windows-only and stays Windows-only until it is migrated, and if it uses WebForms there is no supported migration target for that part at all. That is a real constraint and our .NET page says which side of the line a project sits on before quoting it.

Where the cost actually sits

Once the licence disappears, the cost of running .NET is the cost of running anything. Three things dominate, and none of them is the language.

• Memory, not CPU. A .NET worker process holds more resident memory at idle than an equivalent Node process, and the difference shows on the smallest instances rather than on large ones. On a box with a couple of gigabytes it is the number to size against; above that it stops mattering.
• The database, which is where the licence question actually still lives. If the application assumes SQL Server, that is a commercial product and it is a real line item. PostgreSQL with Npgsql is a first-class option and Entity Framework Core supports it properly, so the question to ask early is whether SQL Server is a requirement or a habit. This is the decision that moves the number, not the runtime.
• Who can deploy it. The cheapest infrastructure in the world is expensive if one person understands the pipeline. .NET on Linux in a container deploys like anything else in a container, which is the point: the same Docker and CI approach works, and anyone on the team can read it.

We do not publish per-hour hosting figures in an article because they date faster than the article does. What we will say is that an ASP.NET Core service sits on the same class of Linux instance as a comparable Node or Spring Boot service, and if a quote tells you otherwise, ask which of the three items above is driving it.

When .NET is still the wrong pick

The licensing objection being out of date does not make .NET the right answer. Three situations where we would tell you to pick something else, and the reason is the same each time: hiring.

1. A small team that has no .NET already. The hiring pool for .NET in India is real but it is concentrated in enterprise and services firms rather than in the product startup market. If you are two people and hiring your third, the pool for Node or Laravel is simply wider. That is a staffing fact rather than a technical one, and it is usually the deciding one.
2. A marketing site or a content-led build. .NET will do it and the result will be fine, but it is not what the ecosystem is strongest at, and you will be picking your CMS uphill.
3. A team already fluent in something else. The best backend is the one your people can debug at 2am. Nothing about .NET beats that.

And where it genuinely wins: a team with existing C# skill, an organisation already on Azure or Microsoft tooling, anything integrating with Microsoft systems, and long-lived line-of-business applications where the framework's stability and the strength of the type system pay back over years rather than over a sprint.

Where we stand on this

.NET is a newer service line for us than Laravel, Node or Next.js, and the service page says so in those words rather than leaving you to find out. What we are not newer at is the part this article is actually about, which is running things: we build and operate our own hosting platform, and a containerised ASP.NET Core service on Linux is the same deployment problem as everything else we run.

So if the question is whether to rule .NET out on cost, the answer is no, and you can verify every claim above yourself in an afternoon. If the question is who should build a large greenfield .NET product for you, a firm that does only .NET has more years behind it than we do, and we would rather say that here than in month two.