Building a High-Performance SaaS for $0/mo with Java, Quarkus & Cloud Run

Ivan Napolitano — Tue, 23 Dec 2025 16:17:12 +0000

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!

Forem: Ivan Napolitano