A Successful Demo Is Not a Production Platform

Getting GitHub Actions runners working on Azure Kubernetes Service (AKS) with Actions Runner Controller (ARC) is relatively straightforward. Within a short time, you can deploy ARC, register a runner scale set, and execute workflows successfully.

However, a successful runner only proves that the components can communicate.

It does not prove the platform is secure, supportable, observable, or ready to support multiple engineering teams.

In our experience, moving ARC from proof of concept to production was defined less by Kubernetes deployment and more by operational decisions around identity, network connectivity, workload isolation, runner images, and ownership.

🎯 Production Reality

Running a workflow successfully proves the deployment works.

Running hundreds of workflows across multiple engineering teams proves the platform works.

Identity Scope Is an Architecture Decision

Authentication should be treated as a platform design decision rather than a deployment parameter.

Repository- and organization-level runner scale sets typically use a GitHub App, while enterprise-level runner scale sets require a Personal Access Token (Classic).

Before deployment, establish:

• Where the runner scale set will be registered
• Which repositories can use the runner group
• How credentials will be stored and rotated
• Who owns authentication lifecycle management

The following values quickly become platform dependencies:

💡 Production Insight

The biggest challenge is rarely authentication itself.

It is defining ownership when credentials need to be rotated, audited, recovered, or replaced.

DNS and Egress Are Part of the Runner Platform

Many ARC deployments focus on Kubernetes configuration while underestimating network dependencies.

A workflow may authenticate successfully with GitHub and still fail because actions, artifacts, package feeds, registries, or deployment targets are unreachable.

In addition to workflow-specific dependencies, ensure that AKS outbound requirements for your chosen networking model are satisfied. AKS platform dependencies are separate from ARC and workflow connectivity requirements.

The table below provides a practical baseline for outbound connectivity validation.

✅ Validation Tip

Always validate connectivity from the runner pod itself.

Validating from the AKS node does not guarantee workflow traffic can reach required endpoints.

Separate ARC Management from Workflow Execution

A production deployment should isolate platform components from workload execution.

A common architecture looks like:

The controller manages ARC resources, while ephemeral runner pods execute arbitrary workflow code.

For operational and security reasons, these workloads should not share the same boundary.

Another important design choice is container execution strategy.

The right choice depends on workload requirements and security expectations.

Configuration Names Become Platform Contracts

One of the most overlooked production considerations is naming.

A runner scale set name is not merely a Helm value. It becomes an interface consumed by development teams through the runs-on configuration.

The following quickly become platform contracts:

• Runner scale set names
• Runner groups
• Namespace boundaries
• Runner image references

Choose these names carefully and document which values are intended to remain stable.

A repository should not need to understand ARC internals. It should consume a predictable runner service.

Treat Runner Images as Managed Artifacts

Custom runner images often begin as a convenience and eventually become shared platform dependencies.

Treat them as managed platform artifacts.

Recommended practices include:

• Pin runner versions
• Pin base image versions
• Scan images before release
• Publish immutable tags or digests
• Validate representative workflows
• Maintain tested rollback versions

Once multiple repositories depend on a runner image, each image update effectively becomes a production release.

Design Observability Beyond Job Success

A successful workflow confirms execution, not operational readiness.

Monitor the entire platform, not only workflow outcomes.

At a minimum, retain logs for:

• ARC controller
• Listener components
• Runner pods

Monitor:

• Queue duration
• Pod provisioning latency
• Authentication failures
• Image pull failures
• Scheduling failures

Alerts should help distinguish between:

• GitHub-side issues
• AKS scheduling problems
• Capacity constraints
• DNS failures
• Identity failures
• Network connectivity issues

The objective is not simply knowing that a workflow failed but understanding exactly where it failed.

Production Readiness Checklist

Before onboarding additional teams, validate the following:

Troubleshoot ARC by Failure Boundary

When troubleshooting, start by identifying where workflow execution stopped.

From a Working Runner to a Dependable Platform

Our journey showed that deploying ARC is rarely the hardest part. The complexity emerges when runners become a shared service supporting multiple teams, environments, and business-critical workloads.

The organizations that succeed with ARC focus not only on deployment, but also on operational excellence, governance, reliability, and clear ownership from day one.

A green workflow run demonstrates capability. Consistent performance through outages, upgrades, scaling demands, and changing requirements demonstrates platform maturity.

"Deploying ARC is a project. Operating it is a platform responsibility."

The browser is becoming a new execution environment

Over the last decade, enterprises moved compute from desktops to the cloud. Applications that once depended on individual machines now run on scalable, managed infrastructure. A similar shift is beginning to happen with browser automation.

Browsers were originally designed for humans. A person opened a browser, navigated through websites, completed transactions, submitted forms, and consumed information. Today, a growing number of those same activities are being performed by automated systems. Test suites validate critical business applications before every release. Business workflows interact with legacy web portals that lack APIs. Most recently, AI agents have begun using browsers to access information and complete tasks on behalf of users.

This creates a new question for enterprises: "Where should those browser interactions run?"

Running a browser on a developer's laptop may be sufficient for experimentation and small-scale automation. However, it becomes increasingly difficult when hundreds of automated workflows, thousands of test executions, or fleets of AI agents require secure, isolated, observable, and governed browser environments.

As organizations operationalize browser automation, the browser itself is evolving from a desktop application into enterprise infrastructure.

Enterprise cloud browsers solve a different problem than local browsers

Initially browser automation focused primarily on helping developers automate repetitive tasks and run tests. Today's enterprise requirements are significantly broader. Organizations need environments that can safely support autonomous execution while maintaining visibility, compliance, and operational control. 

Cloud-hosted browsers are changing the landscape for browser automation. Instead of treating the browser as something attached to one machine, they are turning it into an elastic, isolated, observable runtime. Modern automation is no longer about running one script. It is many agents, scrapers, workflows, and tests operating in parallel across websites, regions, identities, and environments.

Some real-world problems that enterprises want to solve with the help of browser automation:

• "We have 300 employees doing thousands of data transcription operations each day, need an alternate for RPA on legacy websites"
• "I want to get pricing of my SKUs across hundreds of websites, across devices, across geographies, daily & almost real time"
• "We want to run E2E tests on our app across varied scenarios, geographies so that the quality is always very high for our customers"

Security and governance by design

Security is often the first concern enterprises raise when evaluating browser-based automation and AI agents. Browsers routinely execute untrusted code, render external content, download files, interact with third-party services, and handle sensitive information. When autonomous agents begin operating those browsers, the risk profile becomes even more significant. Cloud-hosted browsers provide a controlled environment where organizations can apply governance consistently across browser sessions.

This includes:

• Isolated browser sessions
• Role-based access controls
• Data residency and compliance controls
• Network controls
• Audit logging and activity tracking

A governed cloud environment provides a more practical foundation for these controls than unmanaged browser instances running on individual devices.

• Secure automation on enterprise portals: Finance, procurement, and operations teams can execute transactions on legacy ERP, supplier, and line-of-business applications using managed browser sessions, centralized credentials, and policy controls rather than maintaining dedicated desktops for each workflow.
• Customer support operations: Service teams can update accounts, process requests, and interact with multiple internal and external systems through individual browser sessions with centralized logging, replay, and live-view capabilities for troubleshooting.

Observability becomes critical

One of the most significant differences between experimentation and production automation is operational visibility. When a test fails, a workflow breaks, or an AI agent performs an unexpected action, organizations need to understand exactly what happened. This requires more than simply knowing whether the automation succeeded or failed.

Key observability features that cloud browser platforms are offering:

• Live view
• Screenshots and recordings
• Audit records
• Network traces
• Execution logs
• Browser console output

These capabilities help engineering teams troubleshoot failures, allow operations teams to investigate incidents, and provide governance teams with accountability for automated actions. As browser-based agents become part of critical business processes, observability is becoming a foundational requirement to move to production.

• KYC and compliance verification: Financial institutions can automate identity checks across registries, verification services, and compliance portals while maintaining isolated customer sessions, auditability, and human review for high-risk decisions.

• Checkout and payment validation: E-commerce teams can validate end-to-end purchasing journeys using session recordings, traces, screenshots, and live browser visibility to quickly diagnose checkout failures, flaky tests, payment gateway issues, and abandoned transactions.

Reproducibility and environment consistency

Local browsers often fail due to incorrectly setting up environments to complete the task at hand. One runner may have a different browser version; another may have a stale driver or a missing system package. The browser states from one local browser environment to another may be different due to leftover cookies or cached state.

Cloud-hosted browsers move that surface area into a managed environment. They handle the underlying infrastructure setup and complexity, and provide consistent browser versions, dependencies, and clean starting states. This standardization ensures cleaner browser sessions and predictable states, making it easier to reproduce and debug errors.

• Testing web application workflows: Each run starts with the expected browser version and state, improving consistency and reducing failures caused by stale cookies, cached data, missing packages, or machine-specific configuration.
• Debugging support incidents: An automated support workflow can replay the same customer journey in a known environment, preserving session artifacts and making intermittent defects easier to reproduce.

Geographic distribution and network realism

Local browsers originate from one machine and one network. That is a poor match for globally used applications, regional pricing, localized content, and compliance-sensitive traffic paths.

Cloud-hosted browsers provide regional execution, IP controls, or geo-targeting. For scraping and data extraction, geography can determine what data is visible. For test automation, geography can expose latency and localization issues. For enterprise workflows, region and network path can affect compliance and access-control requirements. With cloud browsers, all of the above becomes easily configurable.

• Web data collection at scale: Organizations can gather competitor pricing, product availability, market intelligence, and localized content across thousands of websites by distributing workloads across concurrent browser sessions in multiple geographies.
• Travel, commerce, and purchasing workflows: Agents can compare offers, inventory, pricing, taxes, and payment options across regions before completing bookings or purchases, with approval checkpoints for consequential actions.
• Cross-border business processes: Logistics, trade, and operations teams can submit forms, declarations, and regulatory filings through region-specific carrier and government portals while adhering to network, residency, and compliance requirements.
• Testing digital customer experiences: Engineering and QA teams can validate signup, purchase, and service workflows from multiple regions to identify localization, performance, compliance, and geo-routing issues before they impact customers.

Scale and parallel execution

Historically, scale was often the primary reason organizations adopted cloud-based automation. Scale remains important. Browser automation benefits largely from scaled execution and parallelism because most automation tasks are independent test cases, page crawls, price checks, form submissions, document downloads, and agent evaluations, that can all run concurrently.

• Scraping competitor or vendor data: Running web scraping tasks across thousands of websites can be distributed crawls across concurrent browser sessions.
• RPA transactions: Operations teams can process hundreds of spreadsheet records through a legacy supplier portal in parallel, no need of dedicated desktop infrastructure.
• Customer onboarding: AI agents running on websites that incur seasonal surge in customer applications can complete form filling without having to worry about scaling their infrastructure.

When local browsers still make sense

The case for cloud-hosted browsers is strong, but it is not absolute. Local browsers remain useful in a few situations.

• Debugging automation scripts: Developers debugging one-flow, stepping through script or iterating on selectors, local execution may be fast and simple.
• Specialized browser modifications: Deep customizations that require patched browser binary, specialized extensions, direct file-system access, GPU behaviour, or unusual OS-level dependencies, local or self-managed infrastructure may be easier.
• Workloads with very limited scale requirements: If the scale is very small and frequency is occasional, running locally may be cheaper and simpler.

The transition point typically occurs when requirements expand beyond a single user and begin involving multiple teams, environments, agents, regions, or when concurrency, reliability, observability, security, or maintenance becomes more important than initial setup simplicity.

What customers should look for in a cloud-hosted browser platform

A managed cloud browser platform is not just about connecting to browser instances from anywhere. Customers should evaluate:

• Isolation: Are sessions cleanly separated? Can state be controlled, persisted, or discarded intentionally?
• Scale: Can the platform handle bursty traffic and parallel execution automatically without having to worry about the scale?
• Reproducibility: Are browser versions, OS environments, and artifacts consistent and standard across the platform?
• Observability: Are live view, logs, traces, screenshots, videos, network data, and audit records available?
• Security: Are the browsers updates managed and kept up-to-date with the latest security patches? Are least privilege, identity, network boundaries, domain controls, and human approval patterns supported?
• Geography: Can workloads run from relevant regions or network paths?
• Cost visibility: Is pricing tied to minutes, sessions, data transfer, or concurrency and does that match the expected workload?

Looking ahead

The browser is now an execution environment. AI agents use browsers to interact with the parts of the web that do not have APIs. Test suites use browsers to validate releases. Data teams use browsers to extract information from the web. Operations teams use browsers to bridge legacy systems that will not be replaced soon.

While local browsers helped get the automation started and they will continue to remain useful for prototyping, debugging, and small-scale work, the future of serious production-grade browser automation is cloud-hosted: elastic, isolated, observable, governed, and integrated into the rest of the enterprise platform.

To know more:

• What is Playwright Workspaces?
• Playwright Workspaces free trial

Today, we are thrilled to announce the General Availability (GA) of Managed Instance on Azure App Service. Following the tremendous response to our  Public Preview announcement at Ignite 2025, we've spent the past nine months working closely with customers, partners, and the community to harden the platform, expand capabilities, and validate real-world enterprise migration scenarios. Managed Instance on Azure App Service is now ready for your production workloads, backed by a full enterprise SLA.

The journey from Preview to GA

Since November 2025, thousands of customers have used the public preview to move workloads that were previously "stuck" on-premises or on aging Windows Server VMs. The feedback has been unmistakable: Managed Instance on Azure App Service dramatically shortens the path to the cloud for legacy and complex .NET Framework applications often removing the need for code changes entirely.

Enterprises across various sectors like financial services, healthcare, manufacturing, and the public sector migrated applications that depended on GAC assemblies, COM components, Windows Services, registry configuration, and mapped network drives apps that historically required expensive re-platforming or a full rewrite. With Managed Instance on Azure App Service, these workloads now run on a fully managed PaaS platform, side-by-side with modern cloud-native apps.

What's new at GA

Building on the preview foundation of configuration scripts, registry adapters, storage mounts, and RDP via Azure Bastion, GA brings several important additions:

• Production SLA (99.95%) – Full enterprise-grade availability commitment across all supported regions.
• Expanded regional availability – Available in at least 8 Azure regions worldwide at GA with continued expansion planned through the remainder of 2026.
• Deeper Premium v4 integration – Managed Instance now takes full advantage of the Premium v4 App Service Plan tier for enhanced performance, memory-optimized SKUs, and improved price-performance.
• Zone redundancy – Deploy Managed Instance workloads across Availability Zones for higher resiliency without additional configuration effort.
• Enhanced observability – First-class integration with Azure Monitor, Application Insights, and Log Analytics, including instance-level metrics for CPU, memory and disk.
• Improved configuration script experience – Faster startup times, richer diagnostics when scripts fail, versioning support for configuration bundles, and streamlined rollback.
• Managed Identity everywhere – All secrets, storage connections, and Key Vault references at GA use Managed Identity by default, eliminating stored credentials from your deployment pipelines.
• Azure Policy and Defender for Cloud coverage – Governance, compliance, and threat protection controls now apply to Managed Instance the same way they apply to standard App Service workloads.
• Bicep, Terraform, and ARM templates – Full IaC support with new resource providers and modules for repeatable, auditable deployments.

• GitHub Copilot Modernization - Deep Integration with GitHub Copilot modernization for Application assessment targeting Managed Instance on App Service https://learn.microsoft.com/en-us/dotnet/azure/migration/appmod/working-with-assessment 

Why customers are choosing Managed Instance on Azure App Service

The core value proposition remains the same and it's stronger than ever at GA:

1. Lift-and-Improve legacy applications

Migrate .NET Framework apps with hardcoded file paths, COM dependencies, GAC entries, or registry access with no major code rewrites. Install custom components directly on the managed instance using configuration scripts.

2. Re-platform hard-to-modernize apps

Move applications with lost source code, legacy middleware (MSMQ, SMTP servers, third-party runtimes), or tight infrastructure coupling. Managed Instance removes the blockers that historically forced these apps to stay on VMs.

3. Hybrid and regulated workloads

Integrate securely with on-premises resources using VNet integration and private endpoints. Enforce data residency, Bring Your Own Storage, and Managed Identity–backed access controls to meet finance, healthcare, and government compliance requirements.

4. Incremental modernization

Start with "lift and Improve" then adopt PaaS features like DevOps automation, autoscaling, deployment slots, and centralized configuration at your own pace. Future-proof your portfolio without a big-bang transformation.

What customers are saying

During preview, we saw real numbers:

• Migration timelines cut from months to weeks for apps that would otherwise have required substantial refactoring.
• Zero code changes for a significant share of preview workloads that previously blocked App Service adoption.
• Reduced infrastructure footprint as customers consolidated Windows Server VMs onto managed App Service Plans with zone redundancy and autoscaling built in.

We are grateful to every preview customer whose feedback shaped this release.

Pricing and licensing

Managed Instance on Azure App Service is billed as a capability on top of the Premium v4 App Service Plan. There is no separate Managed Instance surcharge at GA you pay for the underlying Premium v4 compute you consume. Existing App Service reservations, savings plans, and any other Azure Benefit all apply, helping you optimize the total cost of ownership as you migrate.

Getting started

Getting started is straightforward:

1. Assess your workload using Azure Migrate's updated App Service assessment, which now flags candidates ideal for Managed Instance.
2. Create a new Web App using the Managed Instance on Azure App Service option in the Azure Marketplace, or via Bicep, Terraform, or the Azure CLI.
3. Package your dependencies into a configuration bundle (a zip file plus a PowerShell install script) and store it in Azure Storage. Grant access via Managed Identity.
4. Configure registry values, storage mounts, and networking to match your on-premises environment.
5. Deploy your application using the same App Service deployment mechanisms you already know—ZIP deploy, GitHub Actions, Azure DevOps, or Visual Studio publish.
6. Operate with confidence use RDP over Azure Bastion for deep troubleshooting when you need it, and Azure Monitor for everything else.

Resources

• 📘 Managed Instance on Azure App Service documentation
• 🎥 Technical Deep Dive session recording from Build 2026
• 🧭 GitHub Repo with sample configuration scripts, webapp and guidance for Managed Instance on App Service workloads

Looking ahead

GA is a milestone, not a finish line. On our roadmap we're already working on:

• Deeper integration with Azure Migrate's web app discovery and assessment capabilities to help identify web apps suitable for migration to Managed Instance on App Service
• Enhanced migration tooling with easier dependency detection and one-click configuration bundle generation.
• Expanded Rollout to Azure Regions across 2026 and beyond.
• Continuously Release new features and capabilities to make migrations easier and faster than ever before

We can't wait to see what you build and what you migrate. Managed Instance on Azure App Service is here to make your modernization journey faster, simpler, and more secure than ever.

Welcome to GA. 🚀

The Azure App Service Team