From App Engine to Cloud Run: A New Chapter

For a long time, Google App Engine (GAE) has been my go-to for hosting web applications. It’s reliable and handles the heavy lifting of infrastructure. However, Google’s Cloud Run has emerged as a compelling successor that promises even better cost efficiency and flexibility.

What is Cloud Run?

Cloud Run is a fully managed compute platform that automatically scales your stateless containers. Unlike App Engine, which has specific language runtimes, Cloud Run allows you to run any language, library, or binary because it is built on the Knative (Kubernetes-based) standard.

Benefits vs. App Engine

1. Scale to Zero: Cloud Run is truly "pay-as-you-go." If no one is using your app, it scales to zero instances, and you pay $0. App Engine's standard environment does this too, but Cloud Run's pricing model is often more granular and cheaper for low-to-medium traffic.
2. Containerization: Since it uses Docker containers, the "it works on my machine" guarantee is much stronger. No more worrying about App Engine-specific constraints or proprietary APIs.
3. Concurrency: A single Cloud Run instance can handle up to 250 requests simultaneously, whereas App Engine instances are often more restricted in how they handle concurrent loads.

Why the "Trading Journal" Project?

For a project like a Trading Journal, Cloud Run is a perfect fit:

• Cost Efficiency: This trading tool is built for a small audience and may get very few visitors, if any. Cloud Run is a good fit because it can scale to zero when nobody is using it, keeping the monthly cost minimal.
• Fast Iteration: If this tool ever evolves, the container-based workflow will make it easier to roll out new calculation logic or UI improvements.
• Portability: If we ever need to move to a full Kubernetes cluster or another cloud provider, the Docker image is already built and ready.

---

The "Gotcha": Domain Mapping & The 24-Hour Wait

After successfully deploying the Trading Journal to Cloud Run, I hit a major roadblock: Domain Mapping.

I mapped sprolo.tyosis.com to the service, and then... nothing. I waited 24 hours, and the status remained stuck on "Waiting for certificate provisioning."

How it works under the hood

Cloud Run uses a Kubernetes-based technology stack. The domain mapping service behaves similarly to a Certbot container. To provide you with a managed SSL certificate, Google must prove to the Certificate Authority (CA) that it controls your domain. It does this via an ACME challenge: the CA looks for a specific token at your domain's IP address.

Why the mapping failed

The issue was Cloudflare. My domain was using Cloudflare's "Proxy" mode (the Orange Cloud).

When Google's verification bot tried to check the domain, it didn't see the Google servers; it saw Cloudflare's edge nodes. Because Cloudflare was hiding the actual IP from the internet, the authentication and validation process could never finish. Google was effectively shouting into a void, waiting for a challenge response that Cloudflare was intercepting.

The Fix: The "Grey Cloud" Strategy

To solve this, you have to temporarily "step out of the way" of the SSL handshake:

1. Grey Cloud the Record: In Cloudflare DNS, change the sprolo CNAME record from "Proxied" to "DNS Only" (Grey Cloud). This exposes the ghs.googlehosted.com target directly to the public internet.
2. Wait for Google: Once the proxy is off, Google's verification bot can see the challenge data. In my case, the "Ready" status appeared within about 20 minutes after being stuck for a day.
3. Re-enable Proxy: After the Cloud Run domain status shows a green checkmark and "Ready," you can flip the Orange Cloud back on in Cloudflare to regain your CDN and security benefits.

Summary

If you are moving to Cloud Run and use Cloudflare, don't wait 24 hours like I did. Turn off the proxy until the certificate is issued. Once Google has that initial validation, the routing works perfectly even when you turn the proxy back on.