Most developers think that running a Java application in the cloud is expensive and heavy. They imagine huge JVMs eating up gigabytes of RAM and taking 10 seconds to start.
I thought so too, until I discovered the power of Quarkus Native combined with Google Cloud Run.
In this post, I’ll share how I built and deployed a production-ready Email Validation API that handles syntax checks, MX record lookups, and disposable email detection—all running on a serverless infrastructure that costs me $0.00/month to maintain.
The Problem: Validating Emails is Tricky
I needed a reliable way to validate user emails for a side project. I didn't just want a regex check; I needed to know:
- Is the format valid?
- Does the domain actually exist (MX records)?
- Is it a disposable/burner email (like Mailinator)?
- Did the user make a typo (e.g.,
gmal.com)?
Existing APIs were either too expensive ($20+/month for hobby tiers) or too slow. So, I decided to build my own "Micro-SaaS".
The Stack: Going Cloud Native
To achieve high performance with zero idle costs, I chose this stack:
- Language: Java 21
- Framework: Quarkus (The "Supersonic Subatomic Java" framework)
- Compilation: GraalVM Native Image
- Hosting: Google Cloud Run (Serverless Container)
- Monetization: RapidAPI
The Secret Sauce: GraalVM Native Image
The biggest enemy of Serverless Java is the Cold Start. When a container wakes up after being idle, a traditional JVM takes seconds to load classes and initialize. In an API context, a 3-second latency is unacceptable.
Enter Quarkus Native.
By compiling the Java code ahead-of-time (AOT) into a native Linux executable, I achieved:
- Startup time: < 0.05 seconds (Instant)
- Memory Footprint: ~30MB (vs 200MB+ for a JVM)
- Disk Size: The final Docker image is tiny.
This allows the API to "scale to zero". When no one is using it, Google shuts it down (I pay nothing). When a request comes in, it wakes up instantly.
The Challenges (and how I fixed them)
It wasn't all smooth sailing. Here are two technical hurdles I faced:
1. The Read-Only Filesystem
Cloud Run containers are ephemeral and mostly read-only. My app was trying to cache disposable domain lists to disk.
Solution: I had to modify the code to use the system's temporary directory (/tmp/ on Linux), which is an in-memory writable layer on Cloud Run.
2. Configuration Injection
Quarkus is smart—sometimes too smart. It tries to bake configuration values into the binary at build time. When I tried to inject API keys via Environment Variables in the cloud, the app crashed because it expected the values from my local application.properties.
Solution: I switched to dynamic config lookup using ConfigProvider.getConfig().getValue(...) at runtime, bypassing the build-time optimization for sensitive keys.
The Business Model: RapidAPI
I didn't want to deal with Stripe, VAT handling, or building a frontend dashboard.
I deployed the API behind RapidAPI.
- They handle: Auth keys, rate limiting, billing, and customer support.
- I handle: The code and the logic.
This setup allows me to focus purely on the backend.
The Economics ($0 Cost)
Google Cloud Run offers a generous free tier:
- First 2 million requests/month: Free
- First 360,000 GB-seconds of memory: Free
Since my Native Image uses so little RAM and executes so fast (milliseconds), I can virtually serve thousands of users without paying a cent. Every dollar generated via RapidAPI is almost pure profit margin.
Conclusion & Demo
Building a SaaS doesn't require a VC budget or massive servers. With modern tools like Quarkus and Cloud Run, Java is a top-tier contender for serverless development.
I've just launched the API publicly. If you are building a registration form and want to block spam or fix user typos, feel free to give it a spin!
🚀 Try the API here: Deep Email Validator on RapidAPI
Let me know in the comments if you have questions about the Quarkus Native build process!
Top comments (0)