# 1. Use Azure Container Apps for the customer portal

Date: 2026-10-17

## Status

Accepted

## Context

**Question:** Which platform should host the new customer portal?

**Must:**
- Private network access to our existing Azure SQL database
- Can be run by the current team without platform specialists

**Should:**
- Scales down outside business hours
- Deploys from our existing GitHub Actions pipelines

**Options considered:**
- Azure App Service
- Azure Container Apps (chosen)
- Azure Kubernetes Service
- Static Web Apps with Azure Functions

**Background:**

The current customer portal runs on an on-premises server that goes out of support next year, so the new portal will be hosted in Azure alongside our existing services.

## Decision

We will adopt Azure Container Apps.

Container Apps meets both musts: it runs inside our virtual network, so the portal reaches the existing Azure SQL database over a private endpoint, and it is fully managed, so the current team can run it without Kubernetes expertise. It also meets both shoulds, scaling to zero outside business hours and deploying from our existing GitHub Actions pipelines. App Service ranked a close second and remains the fallback if containers prove a burden.

## Consequences

- Hosting costs fall outside business hours because idle replicas scale to zero.
- The first request after an idle period is slower while a replica starts. If that matters, keep one replica running during business hours.
- The team must build container images and run a container registry, which adds a pipeline step and a new skill to learn.
- Because the portal runs in containers, moving to AKS stays possible if requirements outgrow Container Apps.

Recorded with Decided · decisionrecords.app