OpenWikicalcom/cal.diy

Deploy on AWS

Purpose and Scope

This page turns the repository’s concise AWS deployment guide into a practical runbook for self-hosters who want to place Cal.diy on Amazon Web Services. The upstream deployment page defines AWS as a manual deployment target and lists the major stages: prerequisites, AWS account setup, resource creation, Cal.diy configuration, deployment, verification, DNS, monitoring, scaling, updates, and security practice. Treat this as an infrastructure-owner workflow rather than a one-click installer. You are responsible for choosing AWS services, securing credentials, connecting the database, and operating the running instance after the initial launch.

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

The AWS guide sits inside the same deployments section as Azure, GCP, Elestio, Northflank, Railway, Render, and Vercel. The metadata file names AWS as one of the deployment destinations, while adjacent pages show the documentation pattern: some providers offer a short one-click button, and others require a cloud-resource sequence. AWS is documented in the manual category, closest to Azure’s resource-and-database workflow and GCP’s virtual-machine workflow. That placement matters because it sets expectations: this page is about assembling a deployment from AWS services, not about pressing a hosted template button.

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

Relevant Source Files

  • apps/docs/content/deployments/_meta.ts — Registers the deployment docs navigation labels, including AWS and the neighboring deployment targets.
  • apps/docs/content/deployments/aws.mdx — Defines the AWS manual deployment flow, prerequisites, resource setup, configuration, deployment, post-deployment tasks, best practices, and AWS documentation link.
  • apps/docs/content/deployments/azure.mdx — Provides a comparable manual cloud deployment structure with resource group, web app, PostgreSQL database, networking, monitoring, and post-deployment verification concepts.
  • apps/docs/content/deployments/elestio.mdx — Shows the simpler one-click deployment style used by some hosted providers, contrasting with the manual AWS path.
  • apps/docs/content/deployments/gcp.mdx — Shows a VM-oriented manual cloud deployment, including compute, networking, Docker installation, container execution, and access verification.
  • apps/docs/content/deployments/northflank.mdx — Shows another one-click provider entry and reinforces that AWS is not documented as a one-click deployment target in this source set.

Deployment Model

The AWS deployment model starts with three prerequisites: an Amazon Web Services account, familiarity with AWS services and the management console, and access to the Cal.diy source code. Those prerequisites are not formalities. The AWS guide assumes you can create and manage resources yourself, understand where credentials and endpoints come from, and update application configuration accordingly. A self-hosted Cal.diy deployment is not only an application build; it is also a database, network, DNS, security, and operations project. If those responsibilities are unfamiliar, review the general installation and Docker pages before choosing AWS.

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

Resource creation is the point where the AWS path becomes infrastructure-specific. The source guide names a new IAM user and required services such as Amazon EC2 and RDS for PostgreSQL. In practice, the IAM user should be scoped to the deployment and management tasks you intend to perform, rather than reused from a personal administrator account. EC2 represents the compute option for running the application, while RDS for PostgreSQL represents the managed database option. The guide also names Elastic Beanstalk as an acceptable application deployment service, so teams can choose either a lower-level instance pattern or a managed application platform pattern.

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

Manual Deployment Flow

Begin by preparing the AWS environment. Create or confirm the AWS account, log in to the AWS Management Console, and decide which AWS region will host the application and database. The repository guide does not prescribe an exact region, instance class, database size, or network layout, so choose values that match your expected personal or small self-hosted workload. The important source-backed requirement is that you establish enough AWS infrastructure to run the web application and provide PostgreSQL connectivity. Keep the database endpoint, username, password, port, and network access rules available for the configuration step.

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

Next, create the application and database resources. For compute, the AWS page points to EC2 or Elastic Beanstalk. EC2 gives you direct responsibility for the host operating system, runtime, process manager, reverse proxy, and deployments. Elastic Beanstalk can reduce some of that operational surface by managing an application environment around your code or artifact. For persistence, the source names RDS for PostgreSQL. The key requirement is connectivity from the application runtime to the PostgreSQL database, with security rules that permit the app to reach RDS while avoiding unnecessary public exposure of the database.

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

Cal.diy Configuration

After AWS resources exist, configure Cal.diy with the resource details. The source guide explicitly calls for cloning the repository and modifying the environment file with AWS resource details such as database endpoints. This is where the deployment changes from generic AWS infrastructure to a working Cal.diy instance. Keep the environment file aligned with the database you created, and include the externally reachable application URL when you configure production access. If you later move from EC2 to Elastic Beanstalk, replace the runtime-specific values rather than reusing stale endpoints or hostnames from the old environment.

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

The Azure and GCP deployment pages reinforce the same pattern even though they target different clouds: create the provider resources, update configuration with provider-specific connection details, deploy the application, configure the database, and verify that the app runs smoothly. GCP’s guide is more VM-centered and includes a Docker-based example, while Azure’s guide calls out web app, database, networking, monitoring, and scaling tasks. AWS readers can use those neighboring pages as a mental model, but the authoritative AWS-specific steps remain the AWS page’s IAM, EC2 or Elastic Beanstalk, RDS, DNS, monitoring, scaling, update, and security checklist.

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

Verification and Post-Deployment Operations

Deployment is not complete when the process starts successfully. The AWS page includes a separate verification step: ensure the application is operational and accessible. That means opening the deployed Cal.diy URL, confirming the web application responds, and validating that database-backed actions work against the RDS instance. If the page loads but persistent actions fail, revisit the database endpoint, credentials, security groups, and environment configuration. If the app is unreachable, work backward through the compute service, listener or proxy, DNS record, firewall rules, and application logs until the failing layer is identified.

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

Post-deployment work has two explicit parts in the source guide: DNS setup and monitoring with scaling. DNS should point your chosen hostname at the AWS deployment endpoint, whether that endpoint is an EC2 address, load balancer, or Elastic Beanstalk environment. Monitoring should cover both application health and infrastructure health, because a scheduling system depends on web availability and database responsiveness. Scaling is also an operator responsibility. Watch resource pressure, response time, and database capacity, then adjust AWS resources before users experience sustained failures or timeouts.

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

Compact AWS Checklist

PhaseSource-backed actionOperator decision
PrerequisitesHave an AWS account, AWS console familiarity, and Cal.diy source access.Decide whether this manual path matches your operational skill level.
EnvironmentCreate or confirm the AWS account and use the AWS Management Console.Choose region, naming, and ownership conventions.
ResourcesCreate an IAM user and required services such as EC2 and RDS for PostgreSQL.Scope permissions and network access conservatively.
ConfigurationClone Cal.diy and update the environment file with AWS resource details.Keep database endpoints and public URLs current.
DeploymentDeploy with EC2 or Elastic Beanstalk and connect RDS.Choose direct host control or a managed app environment.
VerificationConfirm the application is operational and accessible.Test web access and database-backed behavior.
OperationsConfigure DNS, monitoring, scaling, updates, and AWS security practices.Establish an ongoing maintenance routine.

The AWS guide ends with two best practices: keep the deployment updated with the latest Cal.diy releases and follow AWS recommended security practices. Those two items should become routine operations, not one-time launch tasks. Schedule time to review releases, update the application, rotate credentials when appropriate, and verify that your IAM user, database, and compute access remain aligned with the least access needed. For adjacent guidance, read the Docker deployment pages if you plan to run containers on EC2, the environment and URL page before configuring DNS, and the database migration page before applying application upgrades.

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

Ask a question...