Deploy .NET Web API to public hosting for FREE (with MSSQL database)
Introduction
A side project or a portfolio API doesn't need Azure App Service pricing to prove it works end to end on the public internet. This video deploys a .NET Web API, backed by a real SQL Server database, entirely on free-tier hosting - the same publish-and-migrate workflow as a paid deployment, minus the bill.
🎬 Watch the full video here:
What "free" actually gets you
Free-tier .NET hosts typically give you a Windows-based IIS site with a small SQL Server database attached, provisioned through the host's own control panel rather than the Azure portal. The trade-offs versus a paid tier are real and worth knowing going in: a cold start after idle periods, a hard cap on database size (often a few hundred MB), and no SLA - fine for a demo or a learning project, not for anything a client depends on.
Publishing without Visual Studio's wizard
The core of the deploy is still dotnet publish, producing a self-contained set of files the host's file manager or FTP client uploads:
dotnet publish -c Release -o ./publish
Most free .NET hosts run on IIS under the hood even when the branding doesn't mention it, so the same web.config that a Windows Server IIS deploy needs (pointing IIS at the ASP.NET Core Module to proxy requests into Kestrel) is what actually makes the published output work once uploaded.
The connection string has to work from outside the host's own network
Locally, Server=localhost or Server=. just works. The moment the API and the database live on infrastructure you don't control, the connection string needs the host's actual server address, often with a non-default port and TrustServerCertificate=True if the host's SQL Server certificate isn't one your client machine already trusts:
Server=<host-provided-server>,1433;Database=MyAppDb;User Id=<user>;Password=<password>;TrustServerCertificate=True;
Free-tier SQL Server instances are usually shared, multi-tenant boxes - so the exact server name, port, and credentials come from the host's control panel, not something you invent.
Running migrations against a database you can't Database.Migrate() into easily
Without shell/RDP access to the box, dotnet ef database update from your own machine, pointed at the remote connection string, is often the most practical option:
dotnet ef database update --connection "<remote-connection-string>"
This runs the same idempotent migration history check as running it locally - EF Core reads __EFMigrationsHistory from the remote database and applies only what's missing.
Common pitfalls
- Assuming
localhoststill means anything. It doesn't once the app and database aren't on the same box. - Forgetting
TrustServerCertificate=Trueagainst a host whose SQL Server certificate chain your client doesn't already trust. - Not planning for cold starts. A free tier that sleeps after inactivity means the first request after idle time is slow - don't be surprised by it in a demo.
- Outgrowing the database size cap without noticing until inserts start failing.
- Treating a free tier as production-ready. It's genuinely useful for demos and learning, not for anything with real uptime requirements.
Key Takeaways
- Free .NET hosting typically means an IIS-backed site plus a small shared SQL Server instance provisioned through the host's control panel.
- The connection string needs the host's real server address and often
TrustServerCertificate=True-localhostno longer applies. - Run
dotnet ef database updateagainst the remote connection string directly when you don't have shell access to run it on the box itself. - Know the limits (cold starts, database size caps, no SLA) before relying on a free tier for anything beyond a demo.
Get the Full Source Code
The complete runnable solution - the API, its web.config, and the migration command used against the remote database - is available to Patreon supporters. If you want the exact publish and migration steps instead of rebuilding them from the walkthrough above, you can find it on Patreon.