The Simplest Way to Make Cloud Run IIS Work Like It Should

You finally get an ASP.NET app running in a container, but now you want it to serve traffic from Google Cloud Run without breaking every config file you’ve ever written. Enter Cloud Run IIS, the unholy (and yet somehow perfect) marriage of Microsoft’s classic web server and Google’s modern serverless runtime. Sounds weird, but it works beautifully once you understand what’s happening under the hood.

IIS (Internet Information Services) expects a full Windows environment. Cloud Run lives in a container that scales to zero in seconds. At first glance, they look incompatible. But with Windows container support and custom container images, you can use IIS inside Cloud Run to host .NET Framework or legacy web apps with identity, logging, and lifecycle automation built right in.

The logic is simple. Your Docker image includes IIS on a Windows base, exposes port 8080, and runs your site through the ASP.NET pipeline. Cloud Run runs that container as a fully managed service, with autoscaling and HTTPS built-in. GCP handles load, security, and credentials. IIS handles the app itself. Together, they let enterprises modernize ancient code without living in VM purgatory.

Quick answer for the impatient reader:
To run IIS on Cloud Run, package it in a Windows container image, publish to Artifact Registry, deploy via Cloud Run (Windows), and set your service account permissions. Cloud Run provides autoscaling and HTTPS, IIS serves your app. It’s the fastest way to modernize existing .NET workloads without a rewrite.

How do identity and permissions work in Cloud Run IIS?

Cloud Run uses IAM service accounts for fine-grained access. You can map app-level auth in IIS using OpenID Connect (OIDC) or delegate it to your organization’s IdP like Okta, Azure AD, or Google Identity Platform. This isolates app logic from platform identity, which means fewer password leaks and faster audits.

Best practices to keep Cloud Run IIS happy

Keep container layers minimal to reduce cold starts. Rotate secrets through Secret Manager instead of web.config. Make sure IIS logs go to stdout so Cloud Logging captures them. If you use URL Rewrite or ARR, test locally—container networking differs slightly from on-prem.

Why teams actually like this setup

• Lift-and-shift legacy .NET apps with minimal change
• Instant scaling to zero, no idle compute cost
• HTTPS termination handled automatically
• Integration with IAM, OIDC, and service-to-service policies
• Simplified observability with Cloud Logging and Metrics Explorer

Developers appreciate that they can retire those 2012 R2 boxes for good. No more waiting on ticket queues for someone to restart IIS after a bad deploy. Once automated, new containers move from build to production in minutes, which feels nothing like managing servers—because it isn’t.

Platforms like hoop.dev take this even further by enforcing identity-aware access rules at the edge. That means the same guardrails you configure for APIs can apply to your Cloud Run IIS endpoints automatically. Compliance that just happens, without cron jobs or wishful thinking.

As AI-driven copilots start managing application configs, safe identity contexts become more crucial. If an AI assistant deploys your next container, you’ll want an access control layer that’s policy-first, not person-first. This integration style fits that world neatly.

Cloud Run IIS proves that “legacy” and “cloud-native” can sit in the same container without burning the datacenter down. For anyone modernizing .NET, it’s the cleanest path to agility with zero excuses left.

See an Environment Agnostic Identity-Aware Proxy in action with hoop.dev. Deploy it, connect your identity provider, and watch it protect your endpoints everywhere—live in minutes.