One month of using the Google Cloud Platform

The services on your network probably look like this:

http://192.168.1.122:8082/login.asp.

Not here. I have a proxmox server with a docker VM running traeffik and a local DNS, so I can type:

https://nas.brno.pelc.cc … without ports. Clean. On https with a valid certificate, so that I may never see another stupid browser security warning again.

The point is, I like my infrastructure setup well configured.

The backstory

Two months ago, I was investigating the requirements for the game that we are building and decided to go with cloud & serverless.

We intentionally made stateless docker services that are backed by Redis and Postgres, so that we can use autoscaling.

No web sockets, because they are a pain in the rear.

After briefly contemplating just getting one beefy Hetzner server, the security config and failover of such a setup would be a headache and I don’t have a full-time infra engineer to deal with bare metal.

Just my hobbyist skills and a few expert friends helping on the side.

So, I went with the cloud until we need the cost savings.

I had the most experience with Amazon, but I decided to check out GCP after a recommendation and $300 worth of free credits.

The initial setup had a bit of a learning curve, but in a few days, I had the ifra set up the way I wanted it.

I leaned on the official docs, which were excellent, examples on GitHub for the GitHub Action flows and some Claude code generation to plug in the gaps.

Doing it the easy way

It’s easy to get started, but if you want to do things properly, it takes a bit of learning, and it may look complex and is no longer super cheap.

The setup:

GitHub Action → Workload Identity Pool Provider → Cloud Deploy → Cloud Pipeline → Cloud Run.

API Gateway (public) → Cloud Run Instances (private VPC).

Do you want to get out of the VPC? NAT setup.

Redis and Postgres? High availability instances.

Now this looks like overkill, and it probably is for a straightforward app. But with this setup, security, and scaling are built in.

I can bump Redis to a larger instance without downtime. The backend servers scale up or down with load automatically.

The front end is on a CDN so I don’t have to worry about that.

We also monitor everything through dashboards straight in GCP—requests per second, traffic through the load balancer, no downtime deployments.

Beautiful.

Reproducing it

I did the initial setup just using the gcloud command line tool which lets you manage all the resources. But it’s easy to lose track of all the tiny details needed for a successful deployment.

I want to be able to deploy the same infrastructure setup to a different region (US and EU) on separate environments for improved latency.

This is a huge pain in the ass if you’ve done it all manually.

Luckily, I was able to onboard a friend who helped me put some Terraform best practices in place and that I could build upon.

It took a bit of effort to reverse-engineer all the required infrastructure steps that I’ve done with the staging environment, but now I have everything documented in code.

Next step is redoing the staging with the new recipe which should be much faster this time.

Initial impressions

The GCP documentation is excellent, the UI is straightforward, and the logs are helpful.

My process was … deploy → it breaks → check logs → fix it → repeat.

This is a huge pain if the docs, examples and logs are bad. But here, I never felt stuck not knowing what went wrong.

Usually, I had a pretty good idea, and I just needed to figure out the GCP way to resolve the issue.

So far, it’s probably the most elaborate setup that I’ve built, but it’s also the most elegant.

Things are organized and there with a purpose. It’s well-documented.

Now what’s needed is a proper stress test, to see how it performs under load.

But more on that soon.

Yours,

Taj