To get around this, I set up proxying so that the GoatCounter requests go to an endpoint under my domain nelson.cloud/gc/count, and then from there CloudFront handles it and sends it to GoatCounter. Most ad blockers work based on domain and GoatCounter is on the blocklists. Since the browser is now sending requests to the same domain as my site, it shouldn’t trigger any ad blockers. This post explains how I did it in case it’s useful for anyone else.

It’s possible to self-host GoatCounter, but my approach was easier to do and less infrastructure to maintain. Perhaps in the future.

On Analytics and Privacy

I know I’m bypassing a user’s preference to not be tracked, even if it’s (in my opinion) a harmless analytics tool. I just want to see who reads my stuff, that’s all.

Read the GoatCounter developer’s take if you want another opinion: Analytics on personal websites.

Managing Infrastructure with Pulumi

Clicking through the AWS console to configure CloudFront distributions is a pain in the ass. I took the time to finally get the infrastructure for my blog managed as infrastructure-as-code with Pulumi and Python. So while you can click around the console and do all of this, I will be showing how to configure everything with Pulumi.

If you don’t want to use IaC, you can still find all of these options/settings in AWS itself.

Setting it up

To set up GoatCounter proxying via CloudFront, we’ll need to

• Create a new CloudFront function resource
• Add a second origin to the distribution
• Add an ordered cache behavior to the distribution (which references the CloudFront function using its ARN)
• Update the GoatCounter script to point to this new endpoint

CloudFront Function

CloudFront functions are JavaScript scripts that run before a request reaches a CloudFront distribution’s origin. In this case, the function strips the /gc from nelson.cloud/gc/count.

We need to strip /gc for two reasons:

1. I chose to proxy requests that hit the /gc/count endpoint on my site to make sure there’s no collision with post titles/slugs. I’ll never use the /gc/* path for posts.
2. GoatCounter accepts requests under /count, not /gc/count

Here is the code for the function:

function handler(event) {
    var request = event.request;
    request.uri = request.uri.replace(/^\/gc/, '');
    if (request.uri === '') request.uri = '/';
    return request;
}

And here is the CloudFront function resource defined in Pulumi (using Python) that includes the JavaScript from above. This is a new resource defined in the same Python file where my existing distribution already exists:

goatcounter_rewrite = aws.cloudfront.Function("goatcounter-rewrite",
    name="goatcounter-rewrite",
    runtime="cloudfront-js-2.0",
    code="""\
function handler(event) {
    var request = event.request;
    request.uri = request.uri.replace(/^\\/gc/, '');
    if (request.uri === '') request.uri = '/';
    return request;
}
""",
)

CloudFront Distribution Origin and Cache Behavior

Here is my existing CloudFront distribution being updated with a new origin and cache behavior in Pulumi code.

Note:

At the time of writing CloudFront only allows allowed_methods to be a list of HTTP methods in specific combinations. The value must be one of these:

• [HEAD, GET]
• [HEAD, GET, OPTIONS]
• [HEAD, DELETE, POST, GET, OPTIONS, PUT, PATCH]

Since the GoatCounter JavaScript sends a POST request, and the third option is the only one that includes POST, we’re forced to use all HTTP verbs. It should be harmless though.

nelson_cloud_distribution = aws.cloudfront.Distribution("nelson-cloud",
    aliases=["nelson.cloud"],
    ###
    # other configuration
    ###
    # route /gc/* requests to GoatCounter, stripping the /gc prefix via CloudFront function
    ordered_cache_behaviors=[{
        "path_pattern": "/gc/*", # the path gets matched here
        "allowed_methods": ["GET", "HEAD", "OPTIONS", "PUT", "PATCH", "POST", "DELETE"],
        "cached_methods": ["GET", "HEAD"],
        "target_origin_id": "goatcounter",
        "viewer_protocol_policy": "redirect-to-https",
        "compress": False,
        "cache_policy_id": "4135ea2d-6df8-44a3-9df3-4b5a84be39ad",  # CachingDisabled
        "origin_request_policy_id": "b689b0a8-53d0-40ab-baf2-68738e2966ac",  # AllViewerExceptHostHeader
        "function_associations": [{
            "event_type": "viewer-request",
            "function_arn": goatcounter_rewrite.arn, # CloudFront function from above
        }],
    }],
    origins=[
        ###
        # other existing origins
        ###
        # a new origin to proxy GoatCounter requests
        {
            "custom_origin_config": {
                "http_port": 80,
                "https_port": 443,
                "origin_protocol_policy": "https-only",
                "origin_ssl_protocols": ["TLSv1.2"],
            },
            "domain_name": "nelsonfigueroa.goatcounter.com",
            "origin_id": "goatcounter",
        },
    ],
    ###
    # rest of configuration
    ###
    opts = pulumi.ResourceOptions(protect=True))

Now that my Pulumi code has both the CloudFront function defined and the CloudFront distribution has been updated, I ran pulumi up to apply changes.

Update the GoatCounter Script

Finally, I updated the GoatCounter JavaScript to use the new endpoint. So instead of goatcounter.com I changed the data-goatcounter attribute to my own domain nelson.cloud/gc/count:

<script data-goatcounter="https://nelson.cloud/gc/count">
/* rest of script */
</script>

After this, I built my site with Hugo and deployed it on S3/CloudFront by updating the freshly built HTML/CSS/JS in my S3 Bucket and then invalidating the existing CloudFront cache.

Verifying that it Works

Now, GoatCounter should no longer be blocked by uBlock Origin. I tested by loading my site on an incognito browser window and checked that uBlock Origin was no longer blocking anything on my domain.

And for further proof, checking the network tab shows a successful POST request to the /gc/count endpoint on my domain along with response headers from AWS/CloudFront:

Everything looks good!

Support GoatCounter

If you’re using GoatCounter you should consider sponsoring the developer. It’s a great project.

References

• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html
• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistS3AndCustomOrigins.html
• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistValuesCacheBehavior.html
• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html
• https://www.goatcounter.com/help/js
• https://www.goatcounter.com/help/backend
• https://www.goatcounter.com/help/countjs-host

This is a quick guide to set up GitHub Actions for Pulumi with an AWS S3 backend. It builds on a previous guide I wrote: How to Use an AWS S3 Bucket as a Pulumi State Backend.

This guide assumes you have the following:

• An AWS S3 Bucket created and ready to be used with Pulumi
• An IAM User that has permissions to read/write to the S3 bucket
• The Access Key and Secret Access Key for the IAM User to use for authenticating to AWS within GitHub Actions
• A passphrase of your choosing that will be used to encrypt secrets in the pulumi stack
• A GitHub repository

Setting up Repository Secrets

First, set up secrets on your GitHub repository. These will be filled in by GitHub Actions once we create a workflow YAML. You’ll need to create 3 secrets. You can name them whatever you want, but I’ll be naming them:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• PULUMI_CONFIG_PASSPHRASE

You can create these by browsing to your GitHub repository > Settings > Secrets and variables > Actions. There are “Environment secrets” and “Repository secrets”. In this case go with “Repository secrets”.

Create the three secrets and fill in their respective values. PULUMI_CONFIG_PASSPHRASE can be whatever you want and doesn’t come from AWS.

Warning:

Make sure you don’t change this passphrase after the fact, or your Pulumi state may break.

The end result should look like this:

Defining the GitHub Actions Workflow

Next, clone the repository locally with git clone. We’ll need to create a few files for a minimum viable Pulumi program. Run pulumi new and it’ll guide you through the creation of a basic Pulumi program. The language you choose doesn’t matter.

Then we can create the YAML file to set up GitHub Actions. Create a YAML file under <your-repository-name>/.github/workflows/. I’ll call it preview.yml in my example. Fill it in with the following YAML, changing values as needed.

name: Pulumi
on:
  push:
    branches:
      - main # change this if you're using a different branch name

jobs:
  preview:
    name: Preview
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Pulumi Preview
        uses: pulumi/actions@v6.6.1
        with:
          command: preview
          stack-name: dev # change this to your stack's name (or whatever you want it to be if it doesn't exist)
          cloud-url: s3://nelson-test-bucket-for-github-actions # change this to your bucket name to be used as a pulumi backend
          upsert: true # creates a stack if it doesn't exist (along with Pulumi.<stack>.yaml)
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          PULUMI_CONFIG_PASSPHRASE: ${{ secrets.PULUMI_CONFIG_PASSPHRASE }}
          AWS_REGION: us-east-1 # change the region as needed

This runs a pulumi preview so it’ll verify that everything is set up correctly without actually deploying anything.

Testing the Workflow

Now push your code to GitHub and see if the GitHub Action workflow ran successfully. You should see output from a successful pulumi preview.

If this works, you should be good to go. You can update your Pulumi code and change command: preview to command: up in the GitHub Actions YAML file and run it again to actually deploy some infrastructure.

References

• https://github.com/pulumi/actions

tl;dr:

You can run this command (replacing placeholders as needed) if you already have an S3 bucket and AWS credentials configured on your machine:

Shell

pulumi login 's3://<bucket-name>?region=<region>&awssdk=v2&profile=<aws-profile-name>'

This post assumes you have the Pulumi CLI installed. Check out the following guide if you don’t have it installed: Download & install Pulumi.

Creating an S3 Bucket

First, we need to create the S3 bucket where the Pulumi state file will be stored. I created a bucket called nelsons-pulumi-state-backend and left all the default settings as-is.

Creating an IAM User

Then we need to create an IAM user in AWS that the Pulumi CLI can use. This IAM user needs permissions to access the S3 bucket we just created.

I go to IAM and create a new user. I just called it pulumi:

Then in the next step, I selected “Attach policies directly” and selected the AWS-managed “AdministratorAccess” policy just to keep things simple. You can provide more fine-grained access depending on your needs. Then click “Next” at the bottom.

In the next screen, double-check everything and then click on “Create user”.

Now that we have a user with the appropriate permissions, we’ll need to get an AWS access key and secret to use with the Pulumi CLI.

Go to your IAM user and click on “Create access key” on the right side.

In the next screen, select “Command Line Interface (CLI)”. Check the box at the bottom, then click “Next”.

The next screen will ask for setting a description tag. This is optional. I chose to skip it and clicked on “Create access key”.

We finally have our Access key and Secret access key. Save these somewhere safe and click “Done”. (Don’t worry, the credentials in the screenshot are fake.)

Setting Up AWS Credentials for the Pulumi CLI

Now we can try using these credentials to tell the Pulumi CLI to use the S3 bucket as a backend.

Note:

Note that you do NOT need the AWS CLI installed. Pulumi just needs the AWS credentials.

Create the file ~/.aws/credentials if you don’t have it. Then add in your credentials there under the [default] profile. (You can add more profiles, but this is beyond the scope of this post.)

[default]
aws_access_key_id = <key_id>
aws_secret_access_key = <access_key>

You’ll need the bucket’s region and your local AWS profile name to use S3 as a backend.

The command formula looks like this:

pulumi login 's3://<bucket-name>?region=<region>&awssdk=v2&profile=<aws-profile-name>'

In my case, the command looks like this (make sure to edit for your needs):

pulumi login 's3://nelsons-pulumi-state-backend?region=us-west-1&awssdk=v2&profile=default'

A successful login shows the following message:

Logged in to 0x6E.local as nelson (s3://nelsons-pulumi-state-backend?region=us-west-1&awssdk=v2&profile=default)

Alternatively, you can add your backend to your Pulumi.yaml file. This is useful if you’re working on multiple Pulumi projects that each have different backends. You won’t need to run pulumi login all the time. Just add a backend key and a nested url key:

name: my-pulumi-project
description: a pulumi project for testing
runtime: nodejs

# add this section
backend:
  url: s3://nelsons-pulumi-state-backend?region=us-west-1&awssdk=v2&profile=default

More information here: Pulumi project file reference.

Testing The Setup

Finally, it’s time to test this out.

To demonstrate, I created a simple Pulumi program by running:

pulumi new aws-python

You can choose whatever language you want though.

This is the main Pulumi code that is generated. It’s code for creating an S3 bucket:

"""An AWS Python Pulumi program"""

import pulumi
from pulumi_aws import s3

# Create an AWS resource (S3 Bucket)
bucket = s3.Bucket('my-bucket')

# Export the name of the bucket
pulumi.export('bucket_name', bucket.id)

Then I ran pulumi up -y and it worked!

And just to double check, I can see that my previously empty S3 bucket now has contents created by the Pulumi CLI:

Everything works!

If you’re interested in setting up CI/CD with this setup, I wrote a post showing how to do so: GitHub Actions for Pulumi with an AWS S3 Backend.

References

• https://www.pulumi.com/docs/iac/download-install/
• https://www.pulumi.com/registry/packages/aws/installation-configuration/
• https://www.pulumi.com/docs/iac/concepts/state-and-backends/#aws-s3
• https://www.pulumi.com/docs/iac/concepts/projects/project-file/
• https://ashoksubburaj.medium.com/pulumi-with-aws-s3-as-backend-ac79533820f1

Delete All Stacks in the Current Project

To delete all Pulumi stacks in the current Pulumi project you can run the following command:

pulumi stack ls | tail -n +2 | tr -d "*" | awk '{print $1}' | while read -r stack; do pulumi stack rm -y "$stack"; done;

Delete All Stacks Across All Projects

Warning:

It should go without saying but, be careful when doing this.

To delete all Pulumi stacks across all Pulumi projects we need to use pulumi stack ls -a instead of pulumi stack ls. So the full command is:

pulumi stack ls -a | tail -n +2 | tr -d "*" | awk '{print $1}' | while read -r stack; do pulumi stack rm -y "$stack"; done;

Command Breakdown

List pulumi stacks (use -a option for all stacks across all projects):

pulumi stack ls

Start at the second line of the previous output:

tail -n +2

Delete all occurrences of *. There is a * character next to the currently selected stack and we need to remove this:

tr -d "*"

Print only the first column:

awk '{print $1}'

This is a loop in one-liner format. It reads the previous output line by line and assigns each line to a string variable called stack, then runs the command pulumi stack rm -y on each stack.

while read -r stack; do pulumi stack rm -y "$stack"; done;

References

• https://stackoverflow.com/questions/7318497/omitting-the-first-line-from-any-linux-command-output
• https://www.pulumi.com/docs/iac/cli/commands/pulumi_stack_ls/
• https://www.pulumi.com/docs/iac/cli/commands/pulumi_stack_rm/