I Built a .NET 8 URL Shortener for Free. Here's Every Problem I Hit
Free deployment promises always sound better than they actually work. I learned this the hard way when I tried to deploy a .NET 8 URL shortener without spending a dime.
My goal was simple: create a clean, maintainable URL shortener API using .NET 8 and Clean Architecture principles, then deploy it completely free. The reality? A series of infrastructure headaches that made me question whether 'free' actually means 'you'll pay with your time instead.'
The Setup Looked Perfect on Paper
I started with .NET 8 because it's fast and the tooling is excellent. Clean Architecture made sense for separation of concerns - domain logic in one place, infrastructure in another, API endpoints somewhere else. The code came together smoothly in about two days.
Then came deployment. That's where the free promise started showing cracks.
I chose a popular free tier from a major cloud provider. Their documentation made it sound effortless: 'Deploy your .NET app in minutes!' What they didn't mention was the asterisk at the bottom of every free tier page.
The Cold Start Problem Nobody Talks About
Free tiers sleep. They really do. My URL shortener would work perfectly after I visited it, but come back an hour later? The first request took 15-20 seconds to respond.
That's unacceptable for a URL shortener. People click links expecting instant redirects, not a coffee break while the server wakes up. I tried every workaround - health check pings, scheduled requests, different configuration settings. Nothing eliminated that initial lag completely.
Here's the cynical developer take: Free tiers are designed to make you upgrade. They give you just enough functionality to get hooked, then hit you with limitations that only paid plans solve.
Database Limitations That Broke My Design
I planned to use a proper database for storing URLs and tracking clicks. Most free database services offer limited connections or storage. One popular option gave me just 20 connections. That might sound like plenty until you realize each API request needs a connection, and they don't always close immediately.
I hit connection limits during testing with just three users. The solution? Switch to a different database provider with a more generous free tier. That meant rewriting my data access layer and learning a new query syntax.
Then I discovered the storage limits. Some free databases cap you at 500MB. For a URL shortener storing text, that's theoretically plenty. But add analytics, user accounts, or any real usage, and you'll hit that ceiling faster than you think.
The SSL Certificate Dance
Modern browsers hate HTTP. They want HTTPS everywhere. Free SSL certificates are available, but they require configuration. Some platforms auto-configure them, others make you jump through hoops.
I spent half a day debugging why my API worked on HTTP but failed on HTTPS. The issue? Mixed content warnings and certificate chain problems that only appeared in certain browsers. The fix involved manually configuring CORS headers and certificate trust settings that weren't documented for .NET 8 on that particular platform.
Monitoring and Logging: Basically Nonexistent
When something breaks on a free tier, you're often flying blind. Basic logging might be available, but advanced monitoring? Forget it. I couldn't set up proper error tracking without exceeding resource limits.
One night, my URL shortener stopped working. I only discovered it because I happened to test it. No alerts, no notifications, just silent failure. That's when I realized free deployment means you're responsible for everything - including knowing when it breaks.
The Performance Trade-Offs
Even when everything worked, performance suffered. Memory limits meant I couldn't cache as aggressively as I wanted. CPU restrictions made some operations slower than they should be. My beautifully architected code was running in what felt like a constrained sandbox.
I optimized where I could - reducing dependencies, minimizing startup time, tweaking garbage collection settings. Each improvement helped, but I was always working against the platform's limitations rather than with its strengths.
What Actually Worked
After all these headaches, I found a combination that worked. It wasn't elegant, but it functioned:
- A different cloud provider with better .NET 8 support
- SQLite for the database (file-based, no connection limits)
- Aggressive caching at the application level
- A simple health check service to keep the app awake
- Manual SSL configuration with Let's Encrypt
The result? A working URL shortener that costs nothing to run. It's not enterprise-grade, but it handles basic redirects reliably.
Is Free Deployment Worth It?
For learning and small projects? Absolutely. You'll encounter real-world problems that tutorials never mention. You'll learn about cold starts, connection pooling, SSL configuration, and platform-specific quirks.
For anything production-critical? Think twice. The time you spend working around limitations might be better spent elsewhere. Sometimes paying $5/month saves $500 worth of development time.
My URL shortener works, but I built it more for the education than the utility. Every problem I hit taught me something about how .NET 8 behaves in constrained environments. That knowledge is valuable, even if the application itself will never see massive traffic.
Free deployment isn't a magic solution. It's a trade-off between cost and convenience. Know what you're getting into, and you might just build something useful without opening your wallet.
