Create automated AWS deploy

[jzongker]

We need to make the process easier for people wanting to self host. We have serverless deployment scripts for all of the APIs and websites. We need a single script to kick everything off. It should:

1. Create an RDS MySQL server
2. Run the serverless deploys on each of the APIs, updating the config to point to the MySQL server
3. Configure the DNS entries on Route53 for all of the APIs, given a root domain.
4. Run the serverless deploys for each of the web projects, updating the configs to point to the API urls
5. Configure the DNS entries on Route53 for all of the websites, given a root domain.
6. Set up an S3 bucket for content and configure a DNS entry for it.

The user just needs to provide the AWS credentials and the domain name they wish to use and they should have a working copy of Chums and B1 when it finishes.

[john-shaffer]

Looking into this, some initial notes:

• In serverless.yml, the role arn:aws:iam::428019619026:role/ChurchAppsRole is hard-coded but is actually pretty easy to adjust. arn:aws:iam:::role/ChurchAppsRole is equivalent but works for any AWS account.
  • Turns out that serverless does not allow omitting the account ID for some reason, but you can achieve the same end by replacing the account ID with ${aws:accountId}.
• There is no source code for creating ChurchAppsRole or its policies.
• The AWS region is also hard-coded.
• The nodejs runtime 18.x will be deprecated Jul 31, 2025, and new lambdas will be blocked from using it on Sep 1, 2025. docs
• ChumsApp and B1App don't have a serverless.yml. They are just static file deploys.

[jzongker]

Thanks diving in on this, John. A few notes.

1. It looks like you solved your first bullet point with the DoingApi commit. That looks good, I'll merge it. I assume we'll need to do the same on the other APIs.
2. Here's a screenshot of the permissions for that Role. I couldn't find a way to export it in a better format.

Those last three custom permissions are:
{ "Sid": "VisualEditor0", "Effect": "Allow", "Action": "execute-api:*", "Resource": "*" }, { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "polly:*", "Resource": "*" }, { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "ssm:GetParameter", "Resource": "arn:aws:ssm:*:428019619026:parameter/*" }
3. I believe we should be able to upgrade the node version on everything without issue
4. There's a GitHub action for deploying ChumsApp in the /.github/workflows folder. B1App and LessonsApp are NextJS applications that are hosted with Vercel. I don't believe there is a practical way to host them with AWS. At least last time I checked. Vercel monitors for updates to the "production" branch and redeploys the app when there is one.

[john-shaffer]

Yes, the other APIs will need the same changes.

Thanks for the role info. I should be able to get the right set of policies from that.

I have a template working that sets up the VPC, IAM, and RDS resources. Is there an existing repo that is a good place for those, or should it go in a new repo?

How are you doing DB migrations on your AWS account? I'm thinking I will have to package up another lambda function in order to create the DBs and tables.

[jzongker]

How about https://github.com/ChurchApps/ChurchAppsSupport for the AWS template? Just make a new folder like we have for the .github actions.

On dev, "npm run initidb" will create everything. I've always manually made the updates on production, but I think a lambda function that executes the exact same code could work. Could also add a new /initialize API route instead to keep things a bit cleaner.

[stephen-dahl]

@john-shaffer are you still working on this? I was asked to look at it.

[dnplkndll]

would a PR with a chart for helm install be useful?

[stephen-dahl]

would a PR with a chart for helm install be useful?

As a kube admin for a living I dont see any but the largests churches running their own kubernetes.