If you spend your days building and designing cloud architecture, you already know the struggle of keeping your web applications clean and lightweight. For number of years, running background tasks, caching layers, or monitoring agents next to your main web app in Azure App Service was a massive headache. We had to cram everything into one giant, heavy container.

Well, the game changed recently. In November 2024, Microsoft announced the General Availability (GA) of the Sidecar feature for Azure App Service for Linux.

In my day-to-day work as a Solutions Engineer and Microsoft Certified Trainer, I am always showing teams how to separate their application concerns to make systems more secure and scalable. When I saw this feature drop, I knew it was exactly what we needed to bridge the gap between the simplicity of App Service and the advanced pod-like features of Kubernetes.

In this article, I am going to walk you through everything you need to know about the Azure App Service Sidecar pattern. I will explain it using basic, plain English, and share exactly how I am using it in my own production environments right now.

The Pain of the "Fat Container"

Before we look at the solution, let’s talk about the problem.

Let's say you build a really fast, lightweight Python FastAPI backend. The code itself is tiny. But when you get ready for production, you realize you need a Datadog agent to monitor your traffic. You also want an NGINX reverse proxy for some special routing.

Before sidecars existed, how did we handle this in App Service for Linux? We used a "fat container." We had to write a messy Dockerfile that installed Python, then downloaded the monitoring agent, then set up the proxy. Finally, we had to write a complicated Bash startup script just to make sure all three programs booted up correctly when the container started.

If the monitoring agent crashed, it often took the whole container down with it, killing your API. It was bad practice, but it was the only way to get things done without migrating everything over to Azure Kubernetes Service (AKS).

What is the Sidecar Pattern?

Think of a real-life sidecar attached to a motorcycle. The motorcycle is your main application. Its only job is to drive on the road—or in our case, serve web requests to your users. The sidecar is a completely separate attachment that goes wherever the motorcycle goes. It has a different job, like carrying extra baggage.

In cloud computing, a sidecar is simply a secondary container that runs right next to your main application container.

When your main app starts, the sidecar starts. If your app gets a huge spike in traffic and scales out to ten instances, Azure automatically spins up ten sidecars right alongside them. They share the same lifecycle.

The biggest benefit here is modularity. Your main code container only focuses on its core job. The sidecar handles all the boring, heavy, or background tasks—like grabbing secrets, forwarding logs, or running a local cache. If you need to update the version of your monitoring agent, you just swap out the sidecar image. You do not have to touch your main application code at all.

How It Works: The Magic of "sitecontainers"

Azure App Service totally redesigned how it configures Linux containers to make this work.

In the old days, if you wanted to run a single custom container, you had to go into your App Service configuration and set a variable called LinuxFxVersion to something like DOCKER|your-image-details. You also had to add a bunch of app settings to handle port configurations.

Now, Azure has introduced a much better, unified configuration model. It is called sitecontainers.

This new setting applies to almost everything:

• Single-container applications

• Multi-container applications

• Standard code-based apps that just want to add a helper sidecar

To turn this feature on for custom container deployments, you just set: LinuxFxVersion=sitecontainers

If you try to add sidecars while still using the old DOCKER| setting, Azure will just ignore them. So, updating this configuration is your very first step.

(Note: If you have ever played around with the old Docker Compose preview feature in App Service, forget about it. The new sitecontainers specification is totally different and much more native to the platform.)

Breaking Down the Sidecar JSON Specification

To actually tell Azure what containers to run, you have to use a specific JSON format. It is essentially a blueprint for your site unit. Here is an example of what the specification looks like:

{
  "image": "mcr.microsoft.com/appsvc/staticsite:latest",
  "isMain": true,
  "targetPort": "80",
  "startUpCommand": null,
  "authType": "Anonymous",
  "inheritAppSettingsAndConnectionStrings": false,
  "volumeMounts": [
    {
      "volumeSubPath": "/host/path",
      "containerMountPath": "/path/in/container",
      "readOnly": false
    }
  ],
  "environmentVariables": [
    {
      "name": "envVarName",
      "value": "APPSETTING_REF"
    }
  ]
}

Let's look at the most important parts of this blueprint from a practical perspective:

1. image This is exactly what it sounds like. It is the full URL to your container image.

2. isMain This is highly critical! Azure App Service needs to know where to send the internet traffic. It will only route incoming HTTP requests to the container that has "isMain": true. You must set this to false for all your sidecars. If you are running a code-based app, the main code container automatically gets the traffic, and your custom sidecars just run quietly in the background.

3. targetPort This is the port your specific container listens on. Since all these containers are going to share the same network, you have to be careful not to cause port conflicts. Do not let two containers try to listen on port 80!

4. authType This tells Azure how to log in to your container registry. You can use Anonymous, UserCredentials, SystemIdentity, or UserAssigned. As an architect, I always push for SystemIdentity (Managed Identities). It is the most secure way to pull images from Azure Container Registry because you don't have to manage any passwords.

5. inheritAppSettingsAndConnectionStrings By default, this is set to true. It means every App Setting you type into the Azure Portal automatically shows up as an environment variable inside all your containers. But sometimes, your monitoring sidecar doesn't need to know your master database password. If you want strict security, you can set this to false and pass specific environment variables manually.

The Ultimate Sandbox: Shared Network and Storage

The absolute best part about the sidecar pattern in App Service is how the containers interact with each other. All containers inside the same site unit share the exact same network namespace.

What does this actually mean? It means they can talk to each other using localhost.

There is no complicated DNS setup. There are no virtual network routing rules to figure out. If you have a sidecar running on port 6379, your main application just sends a request to localhost:6379 and it connects instantly with almost zero latency.

They also share storage. By default, the /home volume is mounted to all the containers (unless you explicitly turn off App Service Storage using WEBSITES_ENABLE_APP_SERVICE_STORAGE=false).

Real-World Use Cases from the Trenches

It is easy to talk about JSON files, but how does this actually help you build better web applications? Here are a few ways I am personally using this pattern right now in real-world scenarios.

1. High-Speed Local Caching When running a platform that serves a lot of heavy traffic—like KloudSchool, where users are constantly loading Azure tutorials and course structures—speed is everything. Every time you query a database, it takes time. While Azure Cache for Redis is a fantastic managed service, sometimes you just want an in-memory cache sitting right next to your application code. By deploying a tiny Redis container as a sidecar, the main web app can fetch cached data over localhost in less than a millisecond.

2. Background AI Document Processing Web applications are doing a lot more heavy lifting these days, especially with AI. On platforms like ConvertSoon, where users upload files to be converted using Python AI models, you run into a problem. You never want your main web server to handle heavy CPU tasks. If the web server is busy processing a massive PDF, it might freeze up and drop new user requests.

With sidecars, you can solve this elegantly. The main web application receives the uploaded file from the user and saves it to the shared /home directory. It immediately replies to the user saying "Processing started!" Meanwhile, the sidecar container sees the new file in the shared folder, quietly picks it up, runs the AI conversion, and updates the database when it is done.

3. Drop-in Observability Tools like Datadog and Dynatrace are amazing for seeing exactly what is happening inside your app. But installing their agents directly into your application code can be messy. Now, you can just deploy the official Datadog sidecar image. It sits next to your app, collects all the metrics from the shared environment, and pushes the logs out without you ever modifying a single line of your actual application code.

Summary

The Sidecar pattern in Azure App Service for Linux is a massive step forward for cloud developers. By allowing multi-container support inside a single App Service plan, we can finally build modular, complex applications without having to manage a full Kubernetes cluster.

Whether you want to keep your main container completely lightweight, add advanced monitoring, or run background worker processes, the sitecontainers configuration makes it incredibly easy.

Stop building heavy, slow, "fat containers." Start looking at your architecture, find the background tasks that are slowing down your main code, and spin them off into a sidecar today!

Frequently Asked Questions (FAQ)

1. Can I use Docker Compose with the new Azure App Service Sidecar pattern? No. While App Service previously had a preview feature for Docker Compose, the new Sidecar feature relies on a native JSON specification via the sitecontainers configuration. Any Docker Compose configurations will not work with this specific GA feature.

2. Does adding a sidecar to Azure App Service cost extra money? You do not pay an extra "sidecar fee," but sidecars consume the CPU and RAM resources of your existing App Service Plan. If your main application and your new sidecar combined require more memory than your current plan allows, you will need to scale up your App Service Plan, which increases your cloud hosting costs.

3. How do my main container and sidecar container talk to each other? Because all containers within a single App Service site unit share the exact same network namespace, they can communicate directly using localhost. Just make sure that your main app and sidecars are listening on different ports to avoid conflicts!

4. Can I add sidecars to a standard code-based application, or is it only for custom containers? Yes, you can absolutely add sidecars to code-based apps! For code-based deployments, the platform automatically routes incoming traffic to your main code container. You simply configure your sidecars to run alongside it with the "isMain": false attribute.

5. How do I pass connection strings to my Azure App Service sidecar? By default, the inheritAppSettingsAndConnectionStrings attribute is set to true in your JSON specification. This means any App Settings or Connection Strings you configure in the Azure Portal will automatically be injected into both your main container and your sidecars as environment variables. You can also specify unique variables just for the sidecar within the JSON spec itself.