Coming from a Google (GCP) ecosystem, there are many things that AWS does not do, that you’ll miss. One of these things is automatically mounting secrets from Secret Manager on your serverless Cloud Run instances like so: gcloud run deploy SERVICE --update-secrets=PATH=SECRET_NAME:VERSION This is extremely convenient, as the application itself does not need to be aware of the complexities of retrieving the secret. This is a form of separation of concerns, and has the advantage that locally you can just use .

Running Docker images 24/7 on GCP for $1.83/month (using Konlet & Pulumi)

Sometimes your hobby project needs to run something continuouly, even in this ‘serverless-era’. In most situations you could get away with CronJobs (Google Cloud Scheduler) and static hosting & serverless functions, but not always. For example, if you consume an API that is only available over WebSockets, like when building a chat bot for example. These applications often sit idle most of the time. They simply leave the connection running, “awaking” only when a message comes in.

Application Default Credentials errors with Workload Identity

When me and my collegues at Q42/Hue inspect our applications and there error messages they produce, we sometimes see this gem: Could not load the default credentials. Browse to for more information. This seems to be a nice error message, as it clearly explains what happens and where more information can be found. However, the message and the background information do not capture all peculiarities that can cause this error.

Custom Envoy xDS server in Golang with Cluster Subsets

At work (at Q42, check it out) we started using Envoy for some use cases. Envoy is a very customizable proxy. Think of it as something like NGINX, but with more dynamic configuration possibilities (NGINX Plus probably also has these, but that is behind a paywall). In this post I’ll explore how you can dynamically configure it, via its control plane API called “xDS”.