[PT-BR](https://hetrodo.dev/blog/post/hetrododev--estrutura-e-funcionamento-ptbr-8eb88b51f6) [EN-US](https://hetrodo.dev/blog/post/hetrododev--structure-and-inner-workings-enus-863cd66df2) After using a diverse set of host providers and many permutations of my services, I settled on one that I found to be efficient and inexpensive.  > This is a diagram of the current structure as of now (09/2023), all source codes are stored in GitHub repositories and are automatically deployed to GCP's Cloud Run using CircleCI as my CI/CD service. The services from Google that I use (Cloud Run, Artifact Registry and Domain Mappings) are maintained using [Terraform](https://www.terraform.io/). ## In-Depth The service "api.hetrodo.dev" is a Restful API developed with [NodeJS](https://nodejs.org/en) and [NestJS](https://nestjs.com/), the source code is stored in a private GitHub repository linked with a [CircleCI](https://circleci.com/) pipeline. When the [CircleCI](https://circleci.com/) pipeline is triggered after a commit, it builds the service and creates a Docker image that is uploaded to [Google's Artifact Registry](https://cloud.google.com/artifact-registry). It is deployed on a [Cloud Run](https://cloud.google.com/run) instance shortly after. > This is how almost every service and API works. However, when it comes to web pages, there is one extra step that I found to be worth the trouble. Let's take this website as an example (hetrodo.dev). When any commit is sent to its private GitHub repository, the CircleCI pipeline takes action to generate the static files (html, css, and js) and commits them to another Git repo. And here is the trick: this repo has the configuration file to build a Docker image containing an NGINX reverse proxy with all of my static assets and routings. So, after the commit is sent, another CircleCI pipeline takes place to build the Docker image of the NGINX server, which is uploaded to the Artifact Registry to be deployed onto a Cloud Run instance as well. This maneuver may take an extra one or two minutes to deploy, but I found it to be very useful because you don't need to create a lot of web servers and complex pipelines for each WebApp or prototype. With this single central static file manager, it is as simple as pointing the domain name to the server and uploading the files. ### Cost My monthly traffic is almost nonexistent, but every website is available when it is needed, except when I forget to pay my Google bill (I'm sorry 😅). Knowing this, the vast majority of my monthly cost is generated by Google's Artifact Registry, which is responsible for storing my Docker images. I don't need to store them, but I still haven't automated the process of deleting them after some time. However, this could be another trick to reduce my already low cost. So, with this knowledge, I can share with you that my cost is around a buck a month (R$ 5,00 Brazilian reais) and has been for the past one to two years. But I know that if I had a reasonable amount of traffic, this could increase by some cents. (Check this [Google cost calculator](https://cloud.google.com/products/calculator) to make your estimate.)