So I am using docker to build the different parts of my app, I have a frontend with react, backend with fastapi, a seperate worker process and a cron job. I am deploying everything using a render.yaml file.
Is it possible to benefit from CDN and static hosting pricing using this setup? Right now my frontend is counting as a service and is technically also deploying an nginx server.
I also feel like I m going to be falling into a similar trap as heroku by not having a seperate worker script and having to deploy it in its own service without being able to share resources with my main backend. Any suggestions on improving this approach?
If your front end can be built completely ahead of time there’s no reason you can’t deploy it as a Static Site to take advantage of the pricing and CDN.
Having dedicated services for cron jobs and background workers does have advantages when it comes to using render out of the box, logs, and metrics, as well as scaling them independently as your needs change over time.
However, if you’re not worried about massive scale in the near future, it could make sense to continue running them all on one machine. It really boils down to your use case.
So for the static part you are suggesting just not using docker at all but building it and then including that as a static site in the render.yaml?
Not so worried about the cron job, they are cheap and its just a process that runs once a day. More in terms of the background worker that I would like to remain scalable but at the same time it is not always active. Ideally it would be able to only be up when used.
So for the static part you are suggesting just not using docker at all but building it and then including that as a static site in the render.yaml
That’s exactly right.
As far as your background worker, it sounds like it might make sense for you to keep it on the same service as your web service for now.
We don’t have the ability to scale background workers down to zero when they’re not in use. I’d encourage you to upvote this feature request at feedback.render.com/features/p/scale-to-zero-paid-and-preview-apps. It helps to include as much context as possible about your use case, the problem you’re looking to solve, and how you’re getting around it today to help us develop the best possible solution.
We rely heavily on customer feedback as a part of our planning and product roadmap process, so capturing interest on the feature request page is very helpful.