Tools: I Deployed a .NET 8 URL Shortener for Free — Here's Every Problem I Hit (2026)
The Stack
The Architecture
The Free Hosting Stack
Render for the API
Supabase for PostgreSQL
Upstash for Redis
Bugs I Found During Deployment
1. ObjectDisposedException on fire-and-forget
2. Credentials leaking in error responses
3. Token expiry hardcoded in the wrong place
4. Missing attributes on a controller
Observability
Testing
GitHub Traffic After Publishing
What I'd Do Differently
Summary I built a URL shortener API using .NET 8 and Clean Architecture, deployed it fully for free using Render + Supabase + Upstash, and hit nearly every possible problem along the way. This isn't a "here's how easy deployment is" post. This is the actual story — connection string failures, disposed DbContext exceptions, credential leaks in error responses, and a Npgsql version that silently stopped supporting URI formats. If you're trying to deploy a .NET API for free, this will save you hours. Live API: https://shrinkit-1cmp.onrender.com
GitHub: https://github.com/syedhhassan/url-shortener The free tier on Render spins down after 15 minutes of inactivity. First request after sleep takes ~30 seconds. Expected behaviour — just hit the Swagger UI and wait. All three have genuinely usable free tiers with no credit card tricks. This stack runs indefinitely. Before getting into the deployment problems, here's how the API is structured. Four layers, dependencies pointing strictly inward: The key design decision worth calling out: caching is implemented as a decorator on IUrlRepository, not injected into services. Using Scrutor: CachedUrlRepository wraps every read with a Redis lookup and invalidates on write. Services have zero knowledge that caching exists. Swapping the caching strategy — or removing it entirely — requires no changes in Application or Domain. Render doesn't have a native .NET runtime. You need Docker. The first mistake I made was restoring the whole solution in the Dockerfile: The solution file references the tests project. Docker's build context didn't include it. Fix: restore only the API project: The full Dockerfile uses a multi-stage build — the SDK image compiles, the runtime image runs. The deployed container doesn't carry the SDK: Two things worth noting: All config comes through environment variables. ASP.NET Core maps them automatically using __ as a separator for nested keys: Supabase gives you a fully managed Postgres instance. Running EF Core migrations against it is straightforward: --startup-project is required — that's where appsettings.json and DI live. Without it, EF can't find the connection string. Now here's where I lost two hours. Supabase gives you a connection string in their dashboard. I used it. The API deployed fine but every DB request returned: The actual error in logs: TCP timeout. Render's free tier runs on IPv4. Supabase's direct connection doesn't work from IPv4-only hosts. The fix is their Session pooler, which is designed exactly for this: Note the username format: postgres.YOUR_PROJECT_REF — not just postgres. That's required for the pooler. Second problem: Npgsql 9.x dropped support for URI-format connection strings. This fails: Error: Keyword 'Host' is not supported — confusingly, that error also appears when you use Host= in the keyword format with certain Npgsql builds. Use the full keyword format with Server= or Host= consistently and make sure you're on the Session pooler. Upstash gives you a serverless Redis instance. The connection string format for StackExchange.Redis (which AddStackExchangeRedisCache uses) is not the rediss:// URI format — it's this: ssl=True is required — Upstash enforces TLS. Port 6379 not 6380. No Host= prefix. Deployment surfaces bugs that local development hides. Here are the ones I hit. The redirect endpoint logs visits in the background — you don't want users waiting on analytics: This silently discards the Task. When it runs, the HTTP request has completed, ASP.NET has disposed the DI scope, and ShortenerDbContext is gone. Result: The fix creates a new scope for the background work, independent of the request: IServiceScopeFactory is a singleton — safe to inject into a controller. The using var scope inside Task.Run gives the background work its own scoped lifetime. My ErrorHandlingMiddleware was returning ex.Message for all exceptions: When a DB connection fails, Npgsql's exception message contains the full connection string, including the password. I discovered this when a 500 response came back with my Supabase password in the body — visible to anyone with browser devtools open. Fix: generic message for 500s, specific message only for known domain exceptions: Rotate your credentials immediately if you've ever returned raw exception messages from a production API. JwtTokenGenerator used _settings.ExpiryMinutes from config to sign the token. UserService independently hardcoded DateTime.UtcNow.AddMinutes(60) for the response. Two sources of truth that could silently diverge. Fix: make ITokenGenerator return a tuple: The generator owns the expiry. The service just uses what comes back: VisitController was missing both [ApiController] and [Route]. Without [ApiController], model binding and automatic 400 responses don't work. Without [Route], the endpoints have no route prefix. They were effectively unreachable. The project uses prometheus-net.AspNetCore to expose metrics and Grafana for visualization. Tracked metrics include HTTP request duration, status codes, and endpoint-level throughput. Unit tests use xUnit + Moq with mocked repositories — no database required. The test that drove the duplicate email fix: Write the test first, watch it fail, add the check, watch it pass. The test existed before the fix — that's how the fix was driven. Two weeks after pushing the repo with a clean README: 182 clones, 81 unique cloners — without posting anywhere. The README does the work if it explains why decisions were made, not just what was used. Use a random short code generator instead of Base62 on the DB ID. The current approach encodes the auto-increment long ID directly — so short codes are sequential and enumerable. Anyone can iterate through all URLs by incrementing the code. Fine for a portfolio project, not for production. Add integration tests. Unit tests with mocked repos are fast but they don't catch connection string issues, migration drift, or EF query translation bugs. A TestContainers setup spins up a real Postgres instance in Docker for tests — worth adding. Use a health check endpoint. Render's free tier pings your service to check liveness. A proper /health endpoint that checks DB and Redis connectivity would catch connection issues before users do. The free stack works. Render + Supabase + Upstash runs a production-quality .NET API at $0/month. The problems are all solvable — you just need to know where to look. The two things that'll catch you: Built with .NET 8 · PostgreSQL · Redis · Docker · Render · Supabase · Upstash Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse
