Deploying Sidekick in Azure: a step-by-step setup guide

What this guide covers

This is a reference for the technical team responsible for getting Sidekick live inside an Azure environment. It covers the two deployment paths, the infrastructure each one needs, the networking that has to be in place, how to configure the language models Sidekick relies on, and what access the Sidekick team needs in order to support the engagement.

None of it is complicated, but it is worth walking through in order so that nothing surfaces as a surprise during deployment.

The core principle: Sidekick deploys inside the client's environment without internet access required for normal operation. The setup uses Microsoft defaults wherever possible to keep the moving parts to a minimum.

The two deployment options

There are two ways to get Sidekick installed. The right one depends on how the client prefers to manage Azure access.

Option 1: Sidekick deploys directly into a provisioned resource group

The simpler path. The client creates an Azure resource group for the Sidekick application and provisions accounts with Contributor access for the Sidekick deployment team (or for company accounts the client wants to use). The Sidekick team then handles the provisioning, configuration, and initial setup directly inside the resource group.

This is the default option for most engagements and the fastest way to go live.

Option 2: Self-provisioning

If the client prefers to handle provisioning themselves — common in environments with stricter change-control processes — the same architecture can be set up by the client's own infrastructure team, following the steps below. The Sidekick team supports the process and validates each stage.

Step 1 — Windows server

The Windows server runs SQL Server, which holds Sidekick's agent memory and provides the linked-server connectivity to the client's data sources.

Recommended specification:

• Size: D4_v5 on Azure (or equivalent)
• vCPU: 4
• RAM: 16 GB
• Storage: 400 GB

The setup uses Microsoft defaults wherever possible. SQL Server is installed using a standard configuration, with adjustments made later for the specific data sources being connected.

Step 2 — Linux server

The Linux server runs Sidekick's application containers via Docker Compose. The front end, the .NET Core backend, and the Airflow orchestration layer all run as containers on this host.

Recommended specification:

• Size: D4s_v5 on Azure (or equivalent)
• vCPU: 4
• RAM: 8 GB

Updates are pulled from Azure Container Registry, which means the server does not need general internet access — only the specific endpoint required to pull container updates, and that connection can be locked down via private endpoint.

Step 3 — Networking

Networking is deliberately minimal. The following ports need to be open between the two servers:

• From the Windows server to the Linux server: ports 80 and 5000 (optionally 22 for administrative access)
• From the Linux server to the Windows server: port 1433 for SQL

That is the complete list of inter-server traffic. The two VMs talk to each other, the Windows server connects to source systems via linked servers, and the Linux server reaches the local LLM endpoint. Nothing else is required for normal operation.

Step 4 — LLM configuration

Sidekick uses language models at multiple points in its workflow. There are two ways to provision them, depending on the client's infrastructure.

Option A: Microsoft AI Foundry

For most Azure-hosted clients, the simplest approach is to deploy the required models inside the client's AI Foundry instance. The process:

1. In the Azure portal, enable Microsoft AI Foundry on the relevant subscription.
2. Navigate to ai.azure.com/resource/models.
3. Search for the model Sidekick will use as its primary inference engine (for example, gpt-5-nano).
4. Select the appropriate model version and region for the deployment.
5. Click Use this model and proceed through deployment with the default settings.
6. Copy the resulting Target URL and Key, which Sidekick will use to call the model.

All inference happens inside the client's tenant. No prompts or data are sent to public model endpoints.

Option B: Local GPUs

For enterprise clients with on-premises GPU infrastructure, Sidekick can run the same models locally rather than via Foundry. This is the path for fully air-gapped deployments. The Sidekick team configures the local inference endpoint during setup.

Step 5 — Access for the Sidekick team

To support deployment and ongoing operation, the Sidekick team needs:

• VPN access into the client environment (if required by the client's network policy)
• Access to the Windows VM and the Linux VM for the named Sidekick team accounts
• Sufficient permission to configure Sidekick's connections to the agreed source systems

Access is provisioned through standard Microsoft Entra ID controls and can be revoked or scoped at any time by the client.

What happens after setup

Once the infrastructure is in place and access is provisioned, the Sidekick team configures the platform, validates the connections to the first set of data sources, and begins the initial scan. The first useful output — an inventory of assets and a preliminary data quality view — is typically available within hours of the scan starting.

From there, the Proof of Value cycle begins, and Sidekick's understanding of the estate develops continuously as it runs.

The takeaway

The setup is intentionally light. Two VMs, a small set of networking rules, a model deployment, and access provisioning. Most of the work happens after the infrastructure is in place, not during it.

For deeper technical detail on the architecture itself, see the companion article Inside the Sidekick architecture: "Our code, your cloud" explained.