Google Cloud Platform

Backend

Cost Optimization

Decision Making

Serverless

Leveraging Google Cloud App Engine for Easy, Scalable, and Cost-Efficient Backend Deployment

Understanding the benefits of serverless architecture and usage-based pricing for faster, low-cost backend launches.

Arista Indrajaya

5 min readOct 9, 2025

Background

I’ve performed several backend development and server configuration tasks throughout my entire career as a Software Engineer. I’ve seen many decisions that can make a business work properly, or it can be a disaster for the business. And it depends, first of all, on ensuring that the purpose is clear. Does it need to launch quickly, launch quickly with the cheap mode, or find the cheap mode first?

There are many ways to determine which service can be helpful. For example, when you choose a service with a specific flat budget, you can opt for a VPS or a compute engine option. You must make sure that your code can handle the specific machine specifications to run optimally. Alternatively, you can test it using a pay-as-you-go service that is auto-scalable, albeit with certain limitations. You don’t need to worry too much about code performance; test it. I decide to choose the second option when the code is not yet optimised, and I need to launch it quickly; that’s why I will choose the GCP Standard App Engine service.

Bridging

Currently, a large company offers a serverless service similar to GCP App Engine Service. For example, AWS offers the AWS Lambda service, which I can share later. I want to optimise and utilise my $300 credits on GCP, which have a limited timeframe of 3 months from October 2025.

As a serverless platform, there are two main environments: Standard and Flexible. For this article, I will focus on the Standard environment, as it offers several advantages for me, including a second instance startup time, the ability to scale to zero, and various maximum request timeouts. This specification has already met my needs and purpose for my early SaaS project, allowing me to launch quickly and analyse the specific SaaS growth from zero, with exact calculations needed for the future.

I used the Node.js runtime environment, where we can specify the Node.js major version we need, for example:

runtime: nodejs20
#or latest
runtime: nodejs

And we can create our application environment definition by creating a file `app.yaml`. For example, here’s my `app.yaml` that I’ve written:

runtime: nodejs20
instance_class: F2
automatic_scaling:
  min_instances: 0
  max_instances: 3
  target_cpu_utilization: 0.6

This setup is cost-friendly for low or fluctuating traffic, which will help us achieve a reasonable burst handling capacity to avoid excessive costs. Here’s the explanation from that field’s setup:

The `runtime` specifies your app runtime,
`instance_class` is used to select the instance class provided by GCP App Engine Standard. You can check it here (https://cloud.google.com/appengine/docs/standard). This instance class affects the resources available per instance (CPU, memory) and the associated cost.
`automation_scalling` is to control how the App Engine automatically add or removes instances based on the exact app request for the current time.
Subfield: `min_instances` meaning the allowed scaling down to zero instances if there is no request or traffic happening.
Subfield `max_instances` means that the App Engine project has a limitation to never run more than three instances, even in peak traffic.
Subfield `target_cpu_utilization` means that the App Engine attempts to keep each instance’s CPU usage below 60%. If the instance has more CPU usage 60% it will create a new instance up to the maximum number of instances allowed.

I’ve also made an API enablement, such as enabling App Engine Admin API and Cloud Build API for cloud deployment automation trigger.

If you want to look up about the project structure using Node.js, you can go to this repository https://github.com/aindrajaya/simplenode.

Starting

This article also has the purpose of explaining technical things, so here are the steps I take to start this project.

Step 1: Project Setup

Create a Google Cloud Project

After that, we can enable the necessary APIs; for this case, I enabled App Engine Admin API and Cloud Build API

Step 2: App Engine Configuration

Start App Engine Configuration by creating the application environment.
You can choose the deployment region based on your preference (I’ve used Central Europe for this case)
Choose the App Engine default account that is provided in the App Engine account option; by default, you can use the App Engine default service account.
When the application environment is created, go to your code editor and your Node.js project, set up and define the runtime and environment by creating an `app.yaml` file.

Step 3: Auto-deploy Trigger Setup

This has the purpose to trigger the automated deployment process when you push your code into the GitHub repository branch (I use GitHub as my git repository)
Go to create a trigger and authenticate to your GitHub repository. For this case, I used this https://github.com/aindrajaya/simplenode as the connected repository to trigger.
This will set up the trigger to monitor the Main branch if there is a new commit.
We can set Autodetected programmatically and ensure the build pipeline by using the instructions that we can set up through the `cloudbuild.yml` file in the repository. For example, you can refer to this file: https://github.com/aindrajaya/simplenode/blob/main/cloudbuild.yaml.

Step 4: Test the trigger

Made a minor change in your code editor
Commit and push code from your code editor.
Monitor and verify from the Cloud Build History

Closing

Not every idea has the same approach, and in summary, by choosing GCP Standard App Engine, it can offer many ideas and side projects a unique blend of simplicity, built-in scalability and more importantly, cost-friendly.

This article reminds me to start the journey as soon as possible, and it’s just the beginning, to provide comprehensive alternative backend deployment strategies. There will be another article that I can share on how I approach starting this journey, and explore a more practical or reasonable approach.

Stay tuned for the next steps and deeper dives into backend approach and deployment workflows- so it can help you to make informed choices for your own projects.