One-Click Deployments
Purpose and Scope
This page groups the short hosted-platform deployment paths that are intended to reduce the amount of infrastructure work required to run Cal.diy. A one-click deployment is a provider-hosted workflow that starts from a button or platform template instead of a fully manual server build. It is useful when you want the platform to provision or guide the application setup, but it does not remove the responsibility of operating a self-hosted Cal.diy instance. You still need to review environment variables, database connectivity, public URLs, secrets, integrations, DNS, and upgrade behavior after the provider creates the initial service. Sources: apps/docs/content/deployments/_meta.ts, apps/docs/content/deployments/elestio.mdx, apps/docs/content/deployments/northflank.mdx
The deployment section is organized as a provider catalog. The metadata file registers AWS, Azure, Elestio, GCP, Northflank, Railway, Render, and Vercel as deployment pages, which means the one-click pages live beside larger manual cloud guides rather than in a separate product area. This is important when choosing a route: one-click options are fast entry points, while the AWS, Azure, and GCP pages show the kind of infrastructure concepts you may still need to understand when troubleshooting. Treat the button as the start of deployment, not as a complete operations model. Sources: apps/docs/content/deployments/_meta.ts, apps/docs/content/deployments/aws.mdx, apps/docs/content/deployments/azure.mdx, apps/docs/content/deployments/gcp.mdx
Cal.diy’s self-hosting documentation warns that the project is for personal, non-production use unless you are prepared to run the infrastructure yourself. That warning matters especially for one-click installs because they can make setup feel simpler than ongoing maintenance really is. A template can create an application service, but it cannot decide your security posture, backup plan, observability thresholds, custom domain policy, or integration credentials. Before using any provider button, confirm that you understand where the database will live, how secrets are stored, and how you will update the instance later.
Relevant Source Files
apps/docs/content/deployments/_meta.ts- Registers the deployment navigation entries, including Elestio, Northflank, Railway, Render, and the neighboring manual cloud guides.apps/docs/content/deployments/aws.mdx- Shows the manual AWS deployment shape used as a contrast for one-click workflows: account setup, IAM, EC2 or Elastic Beanstalk, RDS for PostgreSQL, DNS, monitoring, and scaling.apps/docs/content/deployments/azure.mdx- Documents both an Azure one-click button and a manual Azure flow with App Service, Azure Database for PostgreSQL, DNS, monitoring, and scaling.apps/docs/content/deployments/elestio.mdx- Provides the Elestio one-click deployment page and its deploy button target.apps/docs/content/deployments/gcp.mdx- Documents both a Google Cloud one-click button and a manual VM-plus-Docker path, including port 80, Docker installation, image pull, and container run commands.apps/docs/content/deployments/northflank.mdx- Provides the Northflank one-click deployment page, deploy button target, and a link to Northflank’s detailed platform guide.
Deployment Catalog
The deployment metadata is the source of truth for which provider pages are exposed under the docs deployment section. It names elestio, northflank, railway, and render alongside aws, azure, gcp, and vercel, so readers should think of the one-click pages as siblings in the same deployment catalog rather than as separate installers. This catalog design gives the docs a common place to compare hosted shortcuts with manual deployment guides. If you are unsure which option to choose, start with the most managed provider that matches your account and then use the manual cloud pages to understand what is being abstracted. Sources: apps/docs/content/deployments/_meta.ts
| Provider | Source-backed status | Reader task |
|---|---|---|
| Elestio | Dedicated one-click page with a deploy button | Launch the Cal.diy template from the Elestio dashboard flow |
| Northflank | Dedicated one-click page with a deploy button and external guide reference | Launch the Northflank stack template, then use the platform guide for details |
| Railway | Registered in deployment navigation metadata | Use the provider page from the docs navigation when available in your checkout |
| Render | Registered in deployment navigation metadata | Use the provider page from the docs navigation when available in your checkout |
| Azure | One-click button plus manual deployment guide | Choose quick template creation or follow App Service and PostgreSQL setup manually |
| GCP | One-click Cloud Run button plus manual VM/Docker guide | Choose Cloud Run template deployment or build a VM-based Docker host |
Elestio is the smallest documented one-click page in the supplied source set. Its deployment page states that Cal.diy can be deployed on Elestio using the button below, and the button target points to the Elestio dashboard deploy URL with Cal.diy identified as the software. The page intentionally does not include a manual Elestio walkthrough, so the practical workflow is to start in Elestio, let the provider template create the initial stack, and then verify the resulting Cal.diy configuration from inside the running instance and provider dashboard. Sources: apps/docs/content/deployments/elestio.mdx
Northflank follows the same short-button pattern but adds a second reader aid: the page references a detailed Northflank blog post for deploying Cal.diy on that platform. That makes Northflank a good choice when you want a one-click stack template but still need provider-specific explanation after the initial launch. The repository page’s button targets Northflank’s stack-template deployment route, so the source-backed responsibility of the Cal.diy docs is to route you to the provider flow, while the platform guide can explain Northflank-specific resources, networking, environment variables, and service behavior. Sources: apps/docs/content/deployments/northflank.mdx
Provider Workflows and Operational Checks
A one-click workflow should be followed by the same verification steps you would apply to a manual deployment. First, confirm that the application can reach PostgreSQL and that the public web URL is correct for redirects, webhooks, and app integrations. Next, check whether the platform generated secure secrets or expects you to provide them. Then verify the first-user onboarding path, outbound email settings, calendar integrations, and payment or video integrations if you plan to enable them. Finally, document the provider-specific update process, because Cal.diy upgrades often involve both application code and database schema state.
Azure and GCP demonstrate why these checks matter. Azure includes a one-click deployment button, but its manual section still describes resource groups, Azure App Service, Azure Database for PostgreSQL, DNS configuration, monitoring, and scaling. GCP includes a one-click Cloud Run button, but its manual path walks through creating a VM, opening port 80, installing Docker, pulling calcom/cal.diy, and running the container with port mapping. Even when you do not follow those manual steps, they identify the underlying responsibilities that a hosted template is likely handling for you. Sources: apps/docs/content/deployments/azure.mdx, apps/docs/content/deployments/gcp.mdx
AWS does not appear in the supplied snippets as a one-click target, but it is useful context because its page is entirely manual. The AWS guide calls out IAM users, EC2 or Elastic Beanstalk, RDS for PostgreSQL, .env updates, DNS, monitoring, and scaling. This contrast helps define the boundary of one-click deployments: the button reduces initial provisioning work, while the manual guide exposes the infrastructure layers that still exist under every deployment. If a one-click instance fails, debugging usually means reasoning about the same categories: compute, database, environment, networking, and domain configuration. Sources: apps/docs/content/deployments/aws.mdx
Compact Reference
| Item | Concrete value from source | Use it for |
|---|---|---|
| Deployment nav entry | elestio: "Elestio" | Confirms Elestio is part of the deployment catalog |
| Deployment nav entry | northflank: "Northflank" | Confirms Northflank is part of the deployment catalog |
| Deployment nav entry | railway: "Railway" | Confirms Railway is part of the deployment catalog |
| Deployment nav entry | render: "Render" | Confirms Render is part of the deployment catalog |
| Elestio button target | https://dash.elest.io/deploy?soft=Cal&id=347 | Starts the Elestio one-click flow |
| Northflank button target | https://app.northflank.com/s/account/stack-templates/deploy-calcom | Starts the Northflank stack-template flow |
| Azure button target | https://portal.azure.com/#create/Microsoft.Template | Starts Azure template creation |
| GCP button target | https://deploy.cloud.run/?git_repo=https://github.com/calcom/cal.diy | Starts Google Cloud Run deployment from the repository |
Use these links as launch points, not as final configuration references. After the provider creates the service, record which environment variables were generated, which ones you supplied manually, and where the database connection string is stored. If you plan to use custom domains or third-party apps, verify the deployed URL before enabling OAuth callbacks or webhooks. A common failure mode in self-hosted applications is configuring integrations against a temporary provider URL and then switching to a custom domain later without updating callbacks, redirect URLs, or webhook endpoints.
Recommended Next Steps
Start with Elestio or Northflank if your goal is the shortest path from provider dashboard to a running Cal.diy instance. Use Railway or Render from the deployment navigation when their provider pages are present in your docs checkout. Choose Azure or GCP one-click deployment if you already operate in those clouds and want a path that can be expanded into the manual infrastructure guides. If you need full control over IAM, networking, database sizing, or monitoring, read the manual AWS, Azure, or GCP pages before relying on a template.
After the first successful launch, move immediately from deployment to operations. Set the canonical URL, configure DNS, test account creation and booking, connect only the integrations you need, and decide how upgrades will be applied. Keep a short runbook that records the provider, database location, secret storage location, custom domain, and rollback strategy. For deeper follow-up, read the Docker, environment and URLs, reverse proxy and SSL, database migrations, and upgrading pages before treating the instance as dependable.