Update Strategy When Using Auto Scaling with MIG on GCP

Question

I'm new with GCP and I've been reading some articles online on how to create Auto Scaling on GCP. I found this StackOverflow answer that answered all my questions on how to setup Auto Scaling with MIG (Use existent VM Instace (bitnami) for Autoscale Group of Instances)

However, I have a question which I'm unable to find online. How can I do my App Update for each Instance on the MIG? My App is a simple app running on Node js and for the source code basically I just pull from my Github from the main branch for the latest stable release then rebuild the app and run it with pm2.

Based on my research, I found out there is 2 ways to do the update strategy. First one is to create an Image template then write a startup script to setup the depedencies on the Instance and to do Git pull and build then run the app. The second one is to create an instance then setup the app then convert it to Image Template then use that template for the MIG. And for each update I need to do the same thing and replace the image template with a new one.

Which Solution is the best practice for my question?

[Edited on 7th Feb 2025 After getting one answer]

So, based on the answer using App Engine is cheaper for reliability and auto-scaling than MIG. My budget is not that much with maximum 300 USD / month and I expected during low traffic the monthly usage is 50-60% from the maximum budget.

My App is stateless but it needs one MongoDB for storing some data. So is it better to use MIG or App Engine based on my limited budget?

Thanks!

Answer 1

Both approaches you described are working solutions with own pros and cons. The right choice depends on your needs.

1. Pre-baked Template (manual, but reliable)

Pros:

• Fast VM startup since dependencies are already installed
• Ability to fine-tune the VM environment for each release

Cons:

• Requires manual image creation and configuration for every release

When to use:

• If you have very infrequent releases
• If you just a chill guy and don't want to bother about automation (e.g., demo environments, pet projects, etc.)

2. Lightweight Template & Startup Script (automated, but dependent)

Pros:

• Zero manual actions required when releasing a new app version

Cons:

• Slower startup since each new VM must install dependencies
• Instance creation depends on dependency availability (the startup script might fail)

When to use:

• If you have frequent releases and don’t anticipate breaking changes in the environment
• If you can tolerate dependency installation time for each new instance

---

However, I cannot fail to mention that the approaches above only make sense for stateful apps where local data persistence.

From your description, it’s unclear whether your «simple app running on Node.js» is stateful or not. If it’s stateless, consider using Cloud Run or App Engine, depending on your specific requirements (scalable by design, minimal maintenance, and most likely much cheaper than MIG).