Deploy on Azure

Purpose and Scope

This page explains how to use the repository’s Azure deployment guide as an operator checklist for running Cal.diy on Microsoft Azure. The upstream Azure document presents two paths: a one-click deployment through the Azure Portal template flow, and a manual deployment that creates Azure resources, configures Cal.diy, deploys the web application, verifies the database connection, and then finishes with DNS, monitoring, and scaling. The document is short, so the practical value comes from treating each heading as a required deployment phase rather than as optional background reading. In particular, the manual path assumes that the operator understands Azure accounts, resource groups, application hosting, PostgreSQL, networking, environment configuration, and post-deployment operations before exposing a scheduler to users.

Sources: apps/docs/content/deployments/azure.mdx

The Azure page belongs to the same deployment documentation group as AWS, GCP, Vercel, Railway, Render, Elestio, and Northflank. The metadata file registers Azure as a first-class deployment target, while neighboring pages show the style of the deployment section: some providers are one-click only, some are manual cloud guides, and some combine both. Azure is in the combined category because it includes a deploy button as well as manual instructions. That means readers can start with the one-click route when the hosted template is sufficient, but should fall back to the manual route when they need to control the resource group, App Service settings, PostgreSQL configuration, network access, monitoring, or deployment verification themselves.

Sources: apps/docs/content/deployments/_meta.ts, apps/docs/content/deployments/elestio.mdx, apps/docs/content/deployments/northflank.mdx, apps/docs/content/deployments/gcp.mdx, apps/docs/content/deployments/aws.mdx

Relevant Source Files

• apps/docs/content/deployments/azure.mdx — Primary Azure guide. It defines the Azure title, one-click deployment button, manual prerequisites, Azure setup, resource creation, Cal.diy configuration, deployment, verification, DNS, monitoring, and scaling checklist.
• apps/docs/content/deployments/_meta.ts — Deployment navigation metadata. It lists azure alongside aws, gcp, elestio, northflank, railway, render, and vercel, confirming that Azure is part of the supported deployment docs section.
• apps/docs/content/deployments/aws.mdx — Comparable manual cloud deployment guide. It uses a similar structure for prerequisites, resource creation, environment configuration, deployment, verification, DNS, monitoring, scaling, and security best practices.
• apps/docs/content/deployments/elestio.mdx — One-click deployment example. It shows the shorter provider pattern used when the documentation only needs to point readers at a managed deployment button.
• apps/docs/content/deployments/gcp.mdx — More detailed cloud deployment example. It expands manual infrastructure tasks such as virtual machine creation, networking, Docker installation, image pull, container run, and access verification.
• apps/docs/content/deployments/northflank.mdx — One-click deployment example with an external provider guide reference, useful for understanding how Azure’s deploy button fits the broader documentation style.

Choosing the One-Click Path

The Azure guide’s first deployment option is the one-click button labeled Deploy to Azure. It points readers directly into the Azure Portal template creation flow, which is the fastest path when the default template behavior matches the environment you want. Use this route when you are comfortable letting the portal guide resource creation and when your immediate goal is to get a Cal.diy instance running before refining operational details. Even in this path, the surrounding manual headings remain useful: after the portal finishes, you still need to understand where the web app runs, what database was created or connected, how environment values are set, and how DNS and monitoring will be handled.

Sources: apps/docs/content/deployments/azure.mdx

A one-click deployment should not be treated as a substitute for operational ownership. Cal.diy is self-hosted software, and the Azure page’s post-deployment section still calls out DNS configuration plus monitoring and scaling. In practice, that means a successful template run is only the beginning of the service lifecycle. The operator should inspect the created resources, confirm that the application endpoint responds, check that database connectivity is healthy, and decide whether the resource sizes are appropriate. If the one-click flow hides too much detail, move to the manual path and create the resource group, App Service, PostgreSQL database, networking rules, and monitoring intentionally.

Sources: apps/docs/content/deployments/azure.mdx

Manual Deployment Workflow

The manual Azure workflow starts with prerequisites. The documented requirements are a Microsoft Azure account, basic knowledge of Azure services, and access to the Cal.diy source code. Those requirements are deliberately broad because this is not a purely application-level install; it is a cloud operations task. Before beginning, decide who owns the Azure subscription, which region will host the service, what naming convention the resource group will use, and how secrets will be stored. The guide does not prescribe a particular subscription model, but it does require enough Azure familiarity to navigate the portal, create resources, and update Cal.diy configuration with Azure-specific values such as database connection strings.

Sources: apps/docs/content/deployments/azure.mdx

The next phase is Azure setup. The guide explicitly tells the reader to create an Azure account and become familiar with the Azure Portal. That wording matters because the rest of the manual path is portal-oriented rather than command-line-oriented. The operator is expected to create a new resource group for the Cal.diy project, then add the required Azure services inside that boundary. A resource group gives the deployment a practical management unit: it helps keep the web application, PostgreSQL database, network settings, and monitoring resources discoverable together, and it gives the operator a clear place to review cost, access, and cleanup decisions later.

Sources: apps/docs/content/deployments/azure.mdx

The resource creation section names Azure App Service and Azure Database for PostgreSQL as representative required services. It also separates the work into Create Web App, Setup Database and Networking, and Setup Monitoring. Read those subheadings as the infrastructure contract for a minimal Azure deployment. The web app hosts the Cal.diy application process. The PostgreSQL database stores application data and must be reachable by the app. Networking controls whether the app can reach the database and whether users can reach the public site. Monitoring gives operators visibility after launch, especially when traffic, errors, or resource pressure appear.

Sources: apps/docs/content/deployments/azure.mdx

Cal.diy Configuration and Deployment

After the Azure resources exist, the guide moves back to the Cal.diy project. It instructs the operator to clone the repository locally and update the environment file with the necessary Azure configuration, including database connection strings. This is the point where cloud infrastructure becomes application configuration. The application cannot be verified until its environment points at the correct PostgreSQL database and any other required deployment values are present. Treat the environment file as sensitive operational material: it will usually contain credentials, connection endpoints, and host-specific settings that should not be committed back to the repository or copied into public issue reports.

Sources: apps/docs/content/deployments/azure.mdx

The deploying phase has three documented tasks: deploy the web application through Azure App Service, deploy and configure Azure Database for PostgreSQL with Cal.diy, and verify that the application runs smoothly after deployment. The phrasing puts verification on equal footing with provisioning. A deployment is not complete merely because App Service accepted an artifact or a web process started. Confirm that the homepage loads through the deployed URL, that application actions which require persistence can reach PostgreSQL, and that any Azure-side configuration changes have propagated. If verification fails, return to the environment values, database connectivity, and networking decisions before changing unrelated application code.

Sources: apps/docs/content/deployments/azure.mdx

The Azure page does not specify a particular package command, container image, or pipeline for App Service, so the safest way to use it is as a cloud checklist layered on top of the repository’s general installation and build guidance. In other words, Azure is responsible for hosting, database, networking, DNS, and monitoring, while the Cal.diy installation flow is responsible for preparing the application and its configuration. This separation helps avoid a common mistake: debugging Azure resource settings as if they were application bugs, or changing application configuration when the real issue is a blocked database endpoint, incorrect connection string, or missing DNS record.

Sources: apps/docs/content/deployments/azure.mdx

Post-Deployment Operations

The documented post-deployment steps are DNS configuration and monitor-and-scale. DNS configuration points your chosen domain toward the Azure deployment, which turns a portal-generated endpoint into the user-facing scheduling address. Make this change only after the deployed app has passed basic verification, because DNS can make a broken configuration visible to users quickly. Once DNS is live, revisit any URL-sensitive settings in the broader Cal.diy environment guidance so redirects, callbacks, and absolute links use the public address. The Azure guide itself keeps DNS concise, but it is an essential boundary between an internal deployment test and a usable self-hosted instance.

Sources: apps/docs/content/deployments/azure.mdx

Monitoring and scaling are the long-running responsibilities after launch. The Azure page tells readers to use Azure monitoring tools to track performance and scale resources as needed. For Cal.diy, that means watching the web app and database together rather than treating them as isolated services. Slow responses, failed booking flows, or intermittent errors may come from application resource limits, database pressure, networking instability, or a misconfigured environment. Scaling should therefore follow evidence from monitoring rather than guesswork. The AWS page mirrors this same post-deployment pattern, which reinforces that cloud deployment docs expect operators to keep observing and adjusting the instance after the first successful launch.

Sources: apps/docs/content/deployments/azure.mdx, apps/docs/content/deployments/aws.mdx

Azure in the Deployment Documentation Spine

Azure sits between the extremely short one-click provider pages and the more detailed manual GCP walkthrough. Elestio and Northflank primarily direct users to provider deployment buttons, while GCP walks through virtual machine creation, networking, Docker installation, pulling the Cal.diy image, running a container, and accessing the application. The Azure page is less prescriptive than GCP but broader than the one-click-only pages. Its headings define what must exist, not exactly how every click or command should be performed. Operators should therefore use Azure-native documentation for exact portal screens while preserving the Cal.diy-specific sequence from this guide.

Sources: apps/docs/content/deployments/elestio.mdx, apps/docs/content/deployments/northflank.mdx, apps/docs/content/deployments/gcp.mdx, apps/docs/content/deployments/azure.mdx

This comparison also clarifies when to choose another page. If you want a cloud virtual machine and a Docker-oriented walkthrough, the GCP guide is the closest match in the supplied deployment docs. If you want a provider-managed one-click experience, Elestio or Northflank show that pattern. If you want Microsoft Azure specifically, stay with this page, but expect to make infrastructure decisions yourself. The Azure guide names the required categories: account, portal, resource group, App Service, PostgreSQL, database and networking setup, monitoring, environment configuration, deployment verification, DNS, and scaling. Those categories are the practical acceptance checklist for an Azure-hosted Cal.diy instance.

Sources: apps/docs/content/deployments/_meta.ts, apps/docs/content/deployments/azure.mdx, apps/docs/content/deployments/gcp.mdx

Next Steps

Before deploying, read the general installation, environment, and database migration material so the application-side requirements are clear. During deployment, follow the Azure sequence in order: prepare the account, create a resource group, provision App Service and PostgreSQL, configure networking and monitoring, clone and configure Cal.diy, deploy through App Service, verify the running application, then update DNS. After deployment, keep the Azure resource group under active review for cost, scaling, access, and health. If problems appear, separate them into infrastructure, database, URL, or application configuration categories before changing code or rebuilding the deployment.

Sources: apps/docs/content/deployments/azure.mdx