Ah, you're encountering the age-old problem of asynchronous recurring tasks, better known as cron. Your current GitHub Actions workflow is a clever workaround, but it might not be the most efficient or scalable solution in the long run. Given that you're already using specific tooling for your product, I'd suggest one of the following options:

• vercel.com/docs/cron-jobs
• docs.railway.app/reference/cr…
• cronhub.io

Alternatively, you can roll your own solution. For example, #daylang runs in a single Docker container on Railway. This container bundles the API, cron task emitter, and cron task consumer as a Go application.

Each approach has its merits, so choose the one that best fits your stack and workflow.

At the moment:
- I use AWS Lambda for the code that needs to run
- I use AWS EventBridge to trigger the lambda on a schedule

This is all free as it fits within AWS' free tier for both products

However, I'm going to start migrating off AWS because bills for other parts of AWS are fairly unpredictable with lots of gotchas

My lambda needs to send emails, and the "gotcha" there is that you can't use the normal SES endpoint in Lambda - you have to provision a special VPC endpoint which of course costs a million dollars per month.

I'm going to move to this approach:
- Deploy to a Cheap VPS on Hetzner for my API and the scheduled worker. API will be one container, and I'll run the scheduled work as a cron job in a separate container. This will all be using Kamal for deployment: kamal-deploy.org/docs/configu…
- I'm using Golang for everything, so I'm able to generate a statically linked binary for the CPU architecture used by my VPS and directly execute the binary from cron without needing any special setup, which simplifies a lot.

Thank you @revcd and @ben for sharing your approach! I haven't had time to properly go through everything but as soon as I do, I'll share my learnings.