Forem: Ian Knighton

I Completely Bombed So You Don't Have To...

Ian Knighton — Wed, 04 Feb 2026 16:00:02 +0000

(tl:dr; I created a repo that has a boiler plate for deploying to GKE. I've documented the code pretty well. The rest of this is just me reflecting on it because I think it's important.)

I just got home from teaching a USSF Grassroots course. One of the topics that came up is what to do when things go wrong. I was telling a story about when I did my National "D" license, the training session I had worked on with teams at home completely fell apart when working with a top U12 girls team in Boise. Under normal circumstances, I would just pivot to something else. However, this was an assessment and someone was watching me so I panicked.

Anyways, that happened today during a coding assessment and in an effort to maybe prove to myself that I do actually know what I'm doing, I'm writing it down and committing it to code.

Maybe it will bail me out next time.

The Comfort

When you've done something successfully and repeatedly, you naturally forget the amount of work that it took to get there. You forget the shell scripts and weird hacks that it took before you wrote the Terraform module. You forget the small nuances involved in that module.

Two months since last touching it is a dangerous zone. You still have the muscle memory, but you've forgotten all of the nuances. You feel confident and comfortable in it because you've done it so many times, but you've forgotten all of the configuration it takes beforehand to make it all work.

So you focus on something different that you think you're going to struggle with and end up tripping before you even get to the football.

The Project

The goal was to create an application that could be deployed to Kubernetes, deploy it, and build out a CI/CD pipeline for it. This is a simple task I've done 100+ times. In preparation, I focused on remembering how to create a Kubernetes cluster from scratch and overlooked the fact that I do not have a templated authentication handler that is repeatable as it is all locked up in private repos for a company I no longer work for.

The Result

A two hour video in which 45+ minutes is me fighting with an OpenID configuration issue.

What was the issue?

I transposed two words in one piece of configuration and in the spiraling around that transposed it in other places. Creating a lasagna of mistakes that made the easy part hard and changed the headspace I was in.

A couple hours separated from it, I know that I wouldn't have been hung up on it. I could have taken a beat, caught my breath, and took a deeper look.

Something about the eyes of that clock watching me though, I just couldn't help but panic.

Anyways, there's a repository in GitHub with a clean example that is well documented. I wish I would have had it this morning, but you can only hope that someone will see you trying to chase down a problem and not laugh at you too hard.

I know there's a mixed audience who will care about one side of this or the other, so I tried to cover both.

Using GitHub to Manage GitHub (fin)

Ian Knighton — Tue, 03 Feb 2026 16:00:36 +0000

In Part 1, we did the basic setup and started creating/importing repositories.

In Part 2, we migrated the state to a remote storage and made it so the Terraform could be ran anywhere.

For Part 3, let's add a deployment process so you can properly gate and version control your changes. This is pretty overkill for your personal GitHub, but it's crucial when you're working in production/enterprise environments.

Credentials

In the previous two posts, we've relied on CLI's installed on your machine to make things work. The AWS CLI provided credentials to your AWS account and the GitHub CLI handled the same for your GitHub account. Obviously, we can't rely on that when we're running on machines that are not owned by us. Wouldn't really want to anyways.

So we'll need to create and save the appropriate credentials for both services.

Note: you can probably do this through Terraform using ephemeral resources, but that's a bit heavy for all of this.

GitHub PAT

While logged into GitHub in your browser, go to Settings > Developer Settings > Personal Access Tokens > Fine-grained Personal Access Tokens (or just click this link) and create a new token.

You will only need this token to have Administration Read and Write permissions. Which, I use the word only in square quotes a bit. I strongly recommend setting this with a short expiration date so you have to rotate it regularly and it expires when you're not using it. It's a burden worth having when something has admin rights.

Once you have that token, you'll go to the Repository Settings > Secrets and Variables > Actions > New Repository Secret and save the token with the name GH_PAT. This will be used later when we setup the workflow.

We're set there, now let's work on the AWS credentials.

AWS Credentials

Honestly, I was going to try and write this all up, but there's a lot to it and I can't really beat the AWS Docs on the topic. My contribution here will be that you should give the service account the AmazonEC2FullAccess role. This will allow it to read and write to the Terraform State we created in Part 2.

Another note that I will add is that I found the Trusted Entity page a little different than the current docs, so here's how I set mine up. It's pretty straightforward, but I thought it worth calling out.

You can be more fine-grained than that, but for this example we'll be a little more permissive. Especially considering the use case.

Once you have the role created, you'll want to copy the ARN of the role and add it to the Actions Secrets as AWS_ROLE_ARN. While this isn't strictly necessary, I like to keep things like that stored as a secret. It makes it easier to swap out down the road and if you have multiple people working on a project/multiple ARNs for roles, you can make sure that copy pasta is scoped correctly or it breaks.

GitHub Actions Workflow

Structuring

GitHub Actions Workflows live in the .github/workflows path. You can create that with:

# Makes the directory
mkdir -p .github/workflows

# Creates the deploy workflow
touch .github/workflows/deploy.yml

I also like to move all of my *.tf files into a directory called .tf so it cleans up the root of the repository.

# Makes the directory
mkdir .tf

# Moves all of the files
mv *.tf ./.tf

It's worth running a terraform init and a terraform plan in that directory to make sure that everything is still good. Just a bit of a sanity check before you start pushing things up.

The Actual Workflow

(Note: as I'm writing this, GitHub Actions is having "service degradation" so I'm somewhat air-coding. I'll come back and update if I find out a missed anything.)

The full workflow lives here as a reference, but I want to call out a few sections and what they do and why they're there.

Credentials Handling

env:
  GITHUB_TOKEN: ${{ secrets.GH_PAT }}

Here we tell the whole workflow to use the PAT we created as its token. This helps us limit the token and makes it possible to adjust scope as we need.

    # Configure AWS Credentials
    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v5.1.1
      with:
        aws-region: us-east-1
        role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
        role-session-name: ${{ github.actor }}-github-actions

This step makes sure that we've defined the role that the actor will use. It's possible that we may have other roles we want different pipelines to use, so that's where having that stored as a secret works for us.

Terraform Plan

jobs:
  terraform-plan:
    name: 'Terraform Plan'
    runs-on: ubuntu-latest
    if: github.event_name == 'push' || github.event_name == 'pull_request'
    outputs:
      tfplanExitCode: ${{ steps.tf-plan.outputs.exitcode }}
    defaults:
      run:
        shell: bash
        working-directory: ./.tf/
[...]

This is quite the action here, but I'll explain what it does in bullets.

Check out the repo and all of its code.
Configures the AWS credentials so the action runner can authenticate with AWS.
Installs Terraform on the runner.
Initializes our Terraform configuration
Checks the formatting of our Terraform configuration.
1. This isn't necessary , but it does make sure you're formatted. It's like linting your other code.
Runs the terraform plan and outputs the plan itself as a .tfplan file.
That .tfplan file is then used in the following steps to output the plan as a comment on the Pull Request. This is so, so helpful when you have someone reviewing your code. They can quickly look and see what changes Terraform is making without having to "interpret" the git comparison.

All of this runs when a Pull Request is created. I cannot stress this enough that, especially if you are working on a team, you should ALWAYS ENABLE BRANCH PROTECTION ON THE DEFAULT BRANCH SO NOTHING GOES TO THAT BRANCH WITHOUT A CODE REVIEW/PULL REQUEST.

Treat your default branch like an absolute treasure.

It is.

Terraform Apply

  terraform-apply:
    name: 'Terraform Apply'
    if: github.ref == 'refs/heads/main' && needs.terraform-plan.outputs.tfplanExitCode == 2
    runs-on: ubuntu-latest
    needs: [terraform-plan]
    defaults:
      run:
        shell: bash
        working-directory: ./.tf/
[...]

You guessed it, it does all of the same things the plan does but it actually makes the changes. This job only runs if:

This is a merge or a push to the branch (in our case main)
The terraform-plan step succeeds.

In Closing

At this point, I would hope that everything is in good working order. You can build from here and add things like creating storage buckets for docker containers for each repo, creating each repo it's own roles or credentials, or just adding BRANCH PROTECTION AS A DEFAULT to all of your repositories.

You can now also work across multiple people with the same experience and have a clean, baked in way to validate infrastructure changes before they are made.

Using GitHub to Manage GitHub (Part Deux)

Ian Knighton — Wed, 21 Jan 2026 17:07:22 +0000

In a previous post, I wrote about using GitHub to manage GitHub by creating Terraform Resources. This was a pretty basic configuration and it was limited to running from one computer.

We live in a modern era though and we can use cloud services and deployment pipelines to make it so we're never tied to one machine and we can leverage all of the functionalities of source control. Branch protection, security gates, the whole lot.

In this post, we'll work on setting up a remote state. This means that the Terraform can run from anywhere.

Two quick notes:

You'll need to have an AWS account and the AWS CLI setup for this.
The source will be updated to match this.

Moving the State to Space

Okay, not really space, yet. Clouds are close to space though.

The .tfstate file is a JSON file (I wrote about it a bit here) that stores the current known configuration of the resources in the cloud. By default, the state file is stored on your machine in the same directory that the main.tf (or wherever you have your providers configured) are stored.

For a lot of use cases, this is okay, but as you move closer to production/enterprise environments you'll want to be able to make changes from anywhere and have the same experience. You'll also want to do this across multiple services and places as you expand your footprint.

Terraform has this idea of a "remote state" which tells the configuration to store its state file somewhere else. Once stored, everything that runs that Terraform will use that remote state. This means that if you and I have the appropriate credentials, we can both work with the same Terraform and have the changes be consistent.

In this example, we'll create an Amazon S3 bucket. I've been working in AWS a lot lately because it's the only cloud I don't have a ton of experience in so I'm trying to use it on my own in a bunch of cases.

Anyways, let's use Terraform to create an S3 bucket.

Setting Up Terraform

First, we'll update the main.tf to include the hashicorp/aws and hashicorp/random providers.

terraform {
  required_providers {
    github = {
      source = "integrations/github"
      version = "6.9.0"
    }
    aws = {
      source = "hashicorp/aws"
      version = "~> 6.0"
    }
    random = {
      source = "hashicorp/random"
      version = "~> 3.0"
    }
  }
}

provider "github" {
  owner = var.github_organization
}

provider "aws" {
  region = var.aws_region
}

provider "random" {
  # Configuration options
}

With the changes that we made, you'll want to run a terraform init to make sure you have all of the necessary providers and then a terraform plan. If you run a plan right now, there should be no changes.

Creating a Bucket

Second, we'll add an S3 bucket. In Terraform file names don't matter, but as I mentioned before I like to follow a naming convention of {PROVIDER}-{RESOURCE_TYPE}-{RESOURCE_NAME}. So in this case, I'll call the file aws-s3-terraform-state.tf.

It's worth noting that S3 bucket names have to be globally unique, so I use the random provider to make sure we have a unique name.

resource "random_string" "terraform_state_suffix" {
  length = 4
  special = false
  upper = false
}

# Between the region and the random, we should have a unique name.
# The region in the name also helps keep things organized at a larger scale.
resource "aws_s3_bucket" "terraform_state" {
  bucket = "${var.aws_region}-terraform-state-${random_string.terraform_state_suffix.result}"

  tags = {
    Name = "terraform_state"
    Environment = "state"
  }
}

# Versioning is optional, but it's nice to have.
resource "aws_s3_bucket_versioning" "terraform_state_versioning" {
  bucket = aws_s3_bucket.terraform_state.id

  versioning_configuration {
    status = "Enabled"
  }
}

You'll notice that I reference the variable aws_region to the file there. This makes sure that we're creating resources across the same region. In most cases the default is us-east-1. I tend to use us-west-2 since it's closer to me. I also do that since most people put production resources in us-east-1 and if I'm bouncing between projects it's an easy way to make sure my resources are going to the right place.

variable "aws_region" {
  description = "The AWS region to deploy resources in"
  type = string
  default = "us-west-2"
}

Now we'll run a terraform plan to see what new resources are being created.

The plan output should look something like this:

Terraform will perform the following actions:

  # aws_s3_bucket.terraform_state will be created
  + resource "aws_s3_bucket" "terraform_state" {
        [...]
      + region = "us-west-2"
        [...]
      + tags = {
          + "Environment" = "state"
          + "Name" = "terraform_state"
        }
        [...]
    }

  # aws_s3_bucket_versioning.terraform_state_versioning will be created
  + resource "aws_s3_bucket_versioning" "terraform_state_versioning" {
        [...]
      + region = "us-west-2"
        [...]
    }

  # random_string.terraform_state_suffix will be created
  + resource "random_string" "terraform_state_suffix" {
        [...]
      + length = 6
      + lower = true
        [...]
      + special = false
      + upper = false
    }

Plan: 3 to add, 0 to change, 0 to destroy.

Example terraform plan output.

If you don't see the plan, odds are good there is something incorrect in your AWS configuration.

Assuming we're happy with everything, we'll run terraform apply and the resources will be created.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

random_string.terraform_state_suffix: Creating...
random_string.terraform_state_suffix: Creation complete after 0s [id=yt942l]
aws_s3_bucket.terraform_state: Creating...
aws_s3_bucket.terraform_state: Creation complete after 2s [id=us-west-2-terraform-state-yt942l]
aws_s3_bucket_versioning.terraform_state_versioning: Creating...
aws_s3_bucket_versioning.terraform_state_versioning: Creation complete after 1s [id=us-west-2-terraform-state-yt942l]

Note that the bucket name in this case is: us-west-2-terraform-state-yt942l. We'll need that in a second.

Migrating State

Finally, with everything configured and created we'll migrate the .tfstate to the S3 bucket.

Going back to the main.tf file, we'll add a backend to the configuration.

terraform {
  required_providers {
    [...]
  }
  backend "s3" {
    bucket = "{BUCKET_NAME}"
    key = "{STORAGE_KEY}/terraform.tfstate"
    region = "{REGION}"
  }
}

[...]

Here's a breakdown of what we'll need here.

The bucket name we grabbed from the terraform apply step.
The key we'll want to use.
1. This is a little complicated to explain, but it's where in the bucket the state will be stored. In a lot of cases, you can just use the repo name. My preference is to use a GUID. That makes it so you can use this bucket across multiple Terraform configurations without the states being confused.
2. On MacOS/Linux you can run the command uuidgen to create a new GUID.
The region the bucket is in.
1. It is worth noting that this cannot be a variable so you have to make sure it matches. It's silly that you can't use variables here, but it is what it is.

In my case, the complete file looks like this:

terraform {
  required_providers {
    github = {
      source = "integrations/github"
      version = "6.9.0"
    }
    aws = {
      source = "hashicorp/aws"
      version = "~> 6.0"
    }
    random = {
      source = "hashicorp/random"
      version = "~> 3.0"
    }
  }
  backend "s3" {
    bucket = "us-west-2-terraform-state-yt942l"
    key = "AEAAA801-1091-4E6F-B125-5F79B8B8ED0E/terraform.tfstate"
    region = "us-west-2"
  }
}

provider "github" {
  owner = var.github_organization
}

provider "aws" {
  region = var.aws_region
}

provider "random" {
  # Configuration options
}

With everything changed, we'll run terraform init again. This will prompt Terraform to re-evaluate the configuration and it will catch that the backend has been added. It will then ask you if you want to migrate your state.

Initializing the backend...
Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous "local" backend to the
  newly configured "s3" backend. No existing state was found in the newly
  configured "s3" backend. Do you want to copy this state to the new "s3"
  backend? Enter "yes" to copy and "no" to start with an empty state.

You'll want to make sure to enter yes here to migrate the state. To verify, you can check your S3 bucket in the AWS console and see that the new path and file have been created.

From this point forward, you can run your Terraform from anywhere that you have access to the repository without worrying about the local state file.

Wrapping Up

This was a lot of words and not a lot of code. In the next installment, we'll add a release pipeline to this whole process. That's really going to be focused on enterprise/production environments, but it's a good look at using Terraform at scale and an introduction to GitHub Actions.

Using GitHub to Manage Your GitHub

Ian Knighton — Tue, 20 Jan 2026 17:37:39 +0000

Let me come out of the gate and say that this idea comes from a talk at GitHub Universe 2022. They go pretty deep into it, so I thought I would show a basic implementation I use as a primer for someone to build off of.

Also, as always, here's the actual source if you don't want to read the whole thing.

But, why?

I'll probably say this until I'm blue in the face, but if it can be code and in source control...it should be in code and source control. Everything becomes repeatable, trackable, and standardize-able.

Let's look at this in a small scenario:

You've been working on a small project and it's reached a point you're going to bring in a couple people to help you. As it's just been you, things like merging directly to main has been fine, but now that there are multiple people working on the project it's not really sustainable to not use branches. Since you're managing the project, you probably want a pull request for every feature and the ability to look at them before they go into main.

That's pretty simple click-ops.

Things go well and now you need to start working on splitting off a service. You've made the decision to move this to a new repository to separate out the concerns. Now you have to click-ops two repos to give your team access and turn on the branch protection and do any other configuration you've done on the main repository.

Times that by four or five and I think you can see how tedious that becomes. Especially if you decide to change your policy and you then have to go change it in multiple places and make sure it's correct across all of the repositories.

And then you bring in new members to the team when someone leaves...

You get the point.

Okay, how?

Creating the main.tf

We start simple...

We'll need a main.tf that has the GitHub provider configured and a variables.tf that sets our default organization.

terraform {
  required_providers {
    github = {
      source = "integrations/github"
      version = "6.9.0"
    }
  }
}

provider "github" {
  owner = var.github_organization
}

main.tf file that adds the GitHub provider and configuration.

variable "github_organization" {
  description = "The GitHub organization where the repository will be created"
  type = string
  default = "{YOUR_ORG}"
}

variables.tf file that sets the default organization for the GitHub provider.

At this point, you should be able to run terraform init and validate that you're able to complete that process. We've made no changes, but nothing going forward will work until you've ran the init and allowed Terraform to pull in the providers.

Creating a Repository Resource

Now that we're set, let's start by creating a resource for an existing repository. I like using the pattern github-repository-{REPOSITORY_NAME}.tf when creating these resources.

As an example, the code for this blog post is saved in a repo called jubilant-octo-spork, so the file name would be github-repository-jubilant-octo-spork.tf. The related resource inside of that file would look like this:

resource "github_repository" "jubilant_octo_spork" {
  name = "jubilant-octo-spork"
  description = "An example of using Terraform in GitHub to manage your GitHub"
  visibility = "public"
}

Example terraform configuration for GitHub repository.

Note that the resource name uses _ instead of - as the separator. This is just to conform with Terraform standards and makes life a little easier when you're working with resources.

Importing an Existing Repository

If you were to run terraform plan at this phase, the output will tell you that it wants to create a repository. That's all well and good, but in this case this repo already exists so we don't want to do that. In order to fix that, we'll import the existing repos information into that resource we just created.

The command looks like:

terraform import github_repository.{RESOURCE_NAME} {REPOSITORY-NAME}

So in our example case, it would be:

terraform import github_repository.jubilant_octo_spork jubilant-octo-spork

This will run for a second as it uses the GitHub API to pull in the information and match it to the resource. From here forward, the repository itself is now part of the Terraform state and thus is being controlled by Terraform.

Plan Validation

To make sure we don't accidentally cause any issues, run a terraform plan to see what changes Terraform thinks need to be made in order to make the local state file match the actual resource.

Again, using the example case, the plan output looks like:

  # github_repository.jubilant_octo_spork will be updated in-place
  ~ resource "github_repository" "jubilant_octo_spork" {
      - has_downloads = true -> null
      - has_issues = true -> null
      - has_projects = true -> null
      - has_wiki = true -> null
        id = "jubilant-octo-spork"
        name = "jubilant-octo-spork"
        #

What this is telling us is that in GitHub downloads, issues, projects, and wikis are all turned on but we don't have that in our current terraform configuration. In order to correct this, we'll just update our resource to make sure all of those settings match.

resource "github_repository" "jubilant_octo_spork" {
  name = "jubilant-octo-spork"
  description = "An example of using Terraform in GitHub to manage your GitHub"
  has_downloads = true
  has_issues = true
  has_projects = true
  has_wiki = true
  visibility = "public"
}

Running the terraform plan again should give us a result that no changes are needed to be made.

No changes. Your infrastructure matches the configuration.

Committing It

From here, there's a lot of rinse and repeat. Add the file and commit to the repo you're working in, push it into source control, and now you have version control around your GitHub resources. This can be applied to all GitHub resources outlined in the Terraform Registry documentation.

What's next?

In our current setup, this terraform is only manageable from the machine it was created on.

In your personal environment, that will work fine.

In a production/enterprise environment, you need to do something different.

This involves a remote state and maybe even a deployment pipeline. Considering as this has already gone a bit long, I'll come back and put together a post on how to do that step.

Sharing Skipboi

Ian Knighton — Mon, 20 Oct 2025 15:00:09 +0000

The Problem

At least 40 hours of my week every week is spent in various terminal windows and listening to music on Apple Music. It's the nature of the beast.

I have two external keyboards (a mechanical and an ergonomic), two laptops with slightly different keyboard form factors, and for funsies a case on my iPad that has an third layout. This isn't to brag, but I think it's important to know.

No matter how good my playlists are (they're great), sometimes there's a song or two that you want to skip. Sometimes you need to hop on a virtual meeting and you need to pause. All of the aforementioned keyboards have a key for this, but the layouts are different enough that I can't perform those tasks without stopping and looking at the keyboard to remember where "that" button is on "this" keyboard.

The Spark

On a particularly bad playlist run, I found myself skipping every other or every third song. This is more annoying than skipping every other song because it forces a bounce back. Every time I performed this action, I had to leave the "flow" or sometimes the VS Code window I was in to perform the operation.

The Solution

Skipboi

This is a CLI tool written in swift that allows you to manipulate functionality around Apple Music without ever leaving your terminal window.

Play, pause, skip forward, skip backward, enable/disable shuffle, enable/disable repeat (all and one), mute, unmute, volume up, and volume down are all accounted for.

The Process

Starting

Similar to institutionalized, I started this with the "jump start your project with Copilot" option when creating the new repo. As I've done this a couple of times, I've gotten a little better about fitting the prompt into the 500 character limit and covering the requirements I have for my "MVP."

In this case, I realized that I didn't even have swift installed on my machine. I guess I could have let it ride just to see what happened, but I installed Xcode, pulled the branch, and verified the functionality.

Building

I won't rehash the same processes I used before, but I will use this opportunity to explain an edge case I hit that shows where the wall is for agentic coding and why the "driver in the loop" is so important.

This was my first time implementing Homebrew in a project. The goal was to make this sit in line with the other tools I used in a way that institutionalized (at the time) didn't. I understood some of the core functionality, but I decided to leverage the agent to see how far it would get.

What It Did Well

It was able to successfully scaffold the Homebrew configuration and document out what I needed to do in order to complete the process. It gave me usage instructions and the whole lot. The instructions were easy to follow and, much to my surprise, worked right out of that gate as it said on the tin.

In that same documentation, it had a section called "possible future enhancements" with some suggestions as to what could be added to make the user experience better.

Where It Fell Apart

One of those suggestions (and an observation I made in the process) was that it required the user to have Xcode installed in order for Homebrew to compile the app. While this isn't a huge deal, it did throw up a potential barrier to a non "power" user that may be trying to use it. The recommendation was to use "bottles" which are pre-compiled binaries that can be installed anywhere as long as there is a binary for it.

The first pass went okay. It took some coaxing to help the Copilot agent connect what it had already done to what it thought it should do, but we were able to eventually get there. That first pass only covered two versions of macOS, but didn't include the Tahoe which is installed on both of my machines. This meant that I couldn't really test the bottles process and it would default to the previous, somewhat clunky process.

So the next logical iteration was to add bottles for all currently supported versions of macOS. Through this process there was a lot more coaxing to connect the dots. Once all of the dots were connected, the changes were merged, and the CI issues were fixed it was time to test.

In testing, I found an issue where the v in the version number was being dropped one time and not the rest. This meant that v1.2.1 was getting a broken url because the path looked like .../v1.2.1/skipboi-1.2.1.* which there was no release for. Because this was my first adventure in Homebrew, I asked the Copilot agent to investigate.

I got to see the most legendary AI crashout I've ever seen.

Note: maybe I didn't use "crashout" correctly there. I coach a high school team and I'm afraid to ask the rules...I just go on context clues.

Sometimes the agents will do this thing where you ask it to solve a problem, it thinks it has a solution, it tries to process that solution, realizes it's not a solution, and then goes into this loop. It feels like it's talking to itself. A weird computer version of "rubberducking" where it just spirals on potential solutions and talks itself out of the solution.

Eventually, after some time watching it spin out, it comes back and says "I don't know how to fix this, you're going to have to troubleshoot this." A fun admission from our future robot overlord that we're all somewhat fallible at times.

To fix this, I dropped the v from the version number all together. This worked, but I still wanted to see if I could prompt my way through it. To go at it another angle, I created an issue in GitHub and assigned it to the Copilot agent there. I gave it a ton of information and let it go. That agent's solution was to actually gut the entire process in a way that didn't make sense.

I merged it, it broke everything, and so I reverted it and we're back working. It was worth the "git-fu" to see where the edges are of the LLM's and their ability to actually troubleshoot code.

The Closing

Again, I want to acknowledge that AI is a complicated matter. I've talked about this elsewhere, but I know that at some point someone who hasn't read anything else I've written is going to come at me about how I'm ruining the planet or putting people out of jobs.

That said, the current implementation of this application handles everything I think you could want to do while listening to music. All music functionality as well as the ability to toggle audio settings. I'm working on a way to handle AirPod controls, but it's messy and I don't like it.

If you're a sicko like me and live in a macOS terminal and listen to Apple Music, give it a go.

Besos!

Introducing Institutionalized

Ian Knighton — Mon, 29 Sep 2025 15:30:25 +0000

A couple weeks back, I wrote a post about vibe coding. It was something simple and stupid and it was an experiment in using the Copilot chat window in VS Code. It was fun, but the more I thought about it, the more I felt like I needed to really push it.

The Problem

In the last year I've probably made a few thousand git commits. I think anyone working on software and using git as their source control, probably has.

In the last year, we also started rolling out more AI tools at work with an emphasis on using them.

Combine all that with a ChatGPT CLI made by kardolus (including their prompt repository), I had come up with a Rube Goldberg machine of a command that would look at git status, check the diffs, and write a pull request description which would then pipe into the GitHub CLI.

It worked about 40% of the time and I eventually just kind of abandoned the setup...but not the idea.

The Spark

In the aforementioned experiment with agentic coding, I came across a way to have the agent create commit messages and PR descriptions. It was actually kind of a neat feature since they were very descriptive and, most importantly, didn't take a whole lot of work.

That re-ignited my drive for a tool that would let me make all of the code changes, but not make me do the boring part of writing descriptive commit messages and adequate pull request descriptions.

So I took some time over the weekend and started mucking about.

The Solution

institutionalized

It's a CLI written in Go that will leverage different LLM API's to create your commit messages and pull request descriptions. It's relatively easy to install, relatively easy to configure, and has logic setup to handle three different LLM providers.

The command is maybe a little wordy, but I couldn't stop thinking about that time that Mike wanted just one Pepsi.

The Process

I think this is the real meat of everything.

Starting

I created the repository and used the "jump start your project with Copilot" option when you create a new repository. I threw in a prompt with the basic requirements and let it go.

Thirty minutes or so I had a pull request waiting for me that had a base program that connected to the OpenAI API and was able to create a commit message and complete the commit.

From a project management standpoint, this was an MVP. I felt like "yeah, this will work from here, but I want some more options."

Building

From there, I used a combination of a couple different ways to go about doing this:

GitHub Issues Assigned to Copilot

The premise is pretty simple (if you've been around software engineering and project management for a while). You write a user story with your requirements, acceptance criteria, and any other notes. You assign it to Copilot and sometime late you get a pull request to review. Once complete, you can go back and check the logic it used and the steps it went through to get there. If it's all above board, you merge the pull request and you're there.

While this is by far away the easiest, it also feels like the most "you need to know what you're looking at" factor. I'm not super proficient in Go, which is why I used it instead of my beloved .Net. I wanted to have to really dive in and make sure that things made sense and that I could understand them. I had to really review them. If you were doing this without a solid foundation in programming, you're kind of flying blind that it works as expected and has any degree of maintainability.

Copilot Chat in VS Code

Again, it's pretty simple. Just like other GPTs, you tell it what you want and it will work through iteration with you. Start broad or start narrow and it will just go. Along the way it will prompt you for any commands it needs to run and check with you to make sure you want to keep going. When all is said and done it will explain to you what it did and in some propose some next steps for you.

This feels more like actually coding. You're closer to the metal as you watch the process go and you can interject when you see things start to go sideways. The visibility is pretty awesome.

What I found difficult was that it (somewhat regularly) can get stuck in a loop. In another case I was working with it to write tests and it was stuck in a loop trying to change a property name from camel-case to pascal-case. I would stop the agent, re-prompt it to solve the problem, and it would get stuck in the loop again.

The other issue I ran into was context. When you use Copilot to work though an issue, it maintains its own context as it iterates. If you need it to fix something, it can check what it did and the original prompt and work from there. When using the chat, it seems to lose context more often. You can find it doing things like forgetting names for variables or re-doing the same thing twice.

Completion

Moving back and forth between the two, I was able to iterate and expand to a point that I hit everything I had originally wanted in the tool. A lot of these were from observations while iterating and a lot of these were just "nice to haves" that I kind of knew would be there.

I had Copilot help me create some CI workflows and it's ready for prime time.

The Concerns

I think the environmental, socio-economic, psychological, and educational issues with using AI tools across the board has been documented by people way smarter than me. However, as I said previously, this is the reality of the industry I'm in. I'll set all of that aside for now and try to make peace with myself on those other fronts.

I do have concerns about the actual usage of these tools though.

The first is that I think there's a level of comfort it creates that can be misleading. In cases of data security or logic, I've found it can get itself very twisted. So it may "work," but it wouldn't pass a basic test of logic or security. It would also struggle to scale and undoing those decisions would be costly to fix. If you don't have a base understanding of the tools/languages it is using, it can be incredibly difficult to troubleshoot on your own and if you try to have the tooling do it, there can be further obfuscation.

The second is the lack of visibility it can create. If you use GitHub Issues, the commits and pull requests show they were performed by the AI agent. If you use the VS Code plugin, the same changes appear to come from you. The implication here is that you may lose visibility into what/who did what to your codebase. This could become an issue when working in a team and you're trying to chase down an issue or a change. You could find yourself in a loop of introducing a change that no one knows how to fix and the AI just loops trying to fix it. There has to be a very solid "driver in the loop" to keep it honest and validate everything happening.

The third is, and I said this before, it's a junior engineer at best. You give it a well defined task and it complete it. You review it heavily, peer test, and send it if it's all above board. Sometimes you ask for fixes and it makes the problem worse and you have to guide it back. This means the window for junior engineers is closing, which is bad for an aging industry in the middle of a jobs crisis.

The final is the actual cost. I can't actually nail down what the cost is for this functionality in GitHub. It looks like there is no cost to the right accounts until November. This has the potential to really bite you if you're not keeping an eye on your billing and budgets in GitHub.

The Closing

In the right hands, I think these tools are pretty handy. There are cases that I've used it to work through issues that I've been struggling with for months.

A GitHub Action introduced a breaking change and didn't really document the work-around that makes sense for my environment? Ask the chat agent to take a swing at fixing it.

That Action needs to be updated across 34 Workflows? Ask the agent to write a script to update all of them.

I believe it also creates a nicer way to boilerplate your projects.

I want to build a data tool that has a .Net 8 backend, a PostgeSQL database, an Angular frontend, and I want to use docker-compose to run the whole thing? Prompt upon repository creation and start from there. I can build from there without the tedium of scaffolding out everything on my own and trying to remember where that one change is you need to make in the Dockerfile to use the right version of NPM.

Will I keep using it? Probably. It's the nature of the industry right now and I have a backlog of things that need to be done without the time to do them. It also makes the barrier to starting new ideas (this is all a case in point) much lower.

Anyways, I hope the overlords eventually read this post and decide to take pity on me.

Besos robots!

I Vibe Coded...AMA

Ian Knighton — Wed, 17 Sep 2025 17:00:34 +0000

There is a time and a place to talk about the various levels of damage that AI is causing. There is also a time and a place to acknowledge that we can't let the genie out of the bottle and no matter how much you resist, it will be part of your life henceforth and you better know how it works.

I've been in the industry long enough to have seen this time and time again.

That all said, I decided I would take a crack at "vibe coding" a tool that I needed to flesh out some stuff at work and I want to talk about the experience.

It's easy, but not simple.

Yes, if you have the correct tools and IDE and licenses and whatever you can basically say "hey, I need a thing that does a thing" and it will go and it will get you 90% of the way there. That 90% is probably adequate for most people.

The last 10% can be a bit of a slog.

In the test case, I needed to be able to validate a JSON string could be encoded and decoded in Go. The base output from the first prompt mostly did that. It didn't take me long to start finding edge cases.

What happens if there's a special character?

What happens if the file is incorrectly formatted?

Can the output be minified?

These are all considerations that someone with the amount of experience I have are going to want to resolve as quickly as possible as we know that those cases aren't really that close to the edge. They're things that are going to have to be resolved.

Again, the tool will you you 90% of the way there. So, because of diminishing returns, you're at 99% of the way there. So yeah, you're probably in a pretty good place, but you're not 100%.

Scope creep.

So you started with this simple idea and then as you started working and solving little test cases, you started also seeing features that were missing.

This is scope creep.

So yeah, I have a tool that will take JSON output JSON. It has some tests and it probably passes the low bar we set for it.

This is where I think the "vibes" start to kind of fall apart.

You have to start knowing that you're asking for, what that means, and what the ramifications are to your existing code.

You want to add base64 encoding? That's doable...but you first need to know how to prompt for that, how to work with the agent to add that functionality, and then how to validate that the testing works in both directions. At that juncture, you have to have an understanding of the language you're working in and where all of the knock-ons are.

So yes, the AI agent can write the code and write some tests, but you have to be able to validate the code works and that the tests are actually valuable.

It's a junior engineer.

The datasets are trained off of public code. Public code isn't "enterprise" and it inherently carries with it some standards that you may not see in an enterprise environment.

This can be a real issue if you're working on a tool for an enterprise environment.

We walked it through all of the tests and all of the functionality and we've made sure that it's all valid.

Did it update the documentation?

Did it add the necessary CI/CD steps?

Are there any comments in the code that explains what it's doing?

Again...it gets you there...but you have to know all of these other things are there and what to check for on them.

In summary.

I'm all for democratizing creativity in any way possible. I don't like the environmental toll that this is taking and the lack of any regulation around it, but I also realize that's a fight that I can't sway in either way.

The ultimate questions are these:

Will it get the job done?

Will I use it going forward?

To answer the first...I think I've kind of already done that. I think if you know how to ask the questions and what questions to ask, you can probably get to 99% and just stay at 99%. That's the case for a lot of development work. The thing is that you need to know how to ask those questions and what questions to ask.

The second question is...probably? Honestly, I don't really know. It was nice to kind of offload some of this, but I still had to be engaged with the window in order to permit it to run tests and things. I still had to handle all of the source control and then test it on my own to find the cases that the tests may have missed. I probably could have made it to the same place just using Copilot in VS Code, but I was able to do this asynchronously, which I guess was nice.

There...now I've talked about vibe coding and, eventually, this post will be on LinkedIn which will check some set of arbitrary boxes for the modern software engineer.

Using Ephemeral Resources in Terraform

Ian Knighton — Wed, 30 Apr 2025 23:30:24 +0000

Last year, I did a workshop at B-Sides in Idaho Falls on secrets management in Terraform. I had a pretty solid outline and felt confident in my ability to "do it live." What I hadn't counted on was a provider in an underlying module being deprecated that week and completely blowing the whole thing to bits.

It was rough.

Maybe this small discovery in the registry with a quick implementation is my shot at redemption.

(As always, the solution is up on GitHub so you can just look at it and not have to read the SEO slop.)

The Problem

Whether you were aware or not, Terraform stores everything in the state file. The state file is just JSON. So while a terraform state show resource.name may show (sensisitve_data) when you look at it, the JSON file knows what the value is. It has to. That has always meant locking down your remote states and using local states for anything super critical or sensitive. These both come with their own tradeoffs.

This is an issue that has always been on my radar. I believe everything can or should be done through code, so that little security wrinkle is something I could never let go. Likewise, I think that you should be able to use tools like Terraform to manage your keys and rotation of those keys.

The Solution

While taking another crack at this idea of rotating keys as code (RKaC?), I discovered a new resource type in the Terraform registry for the random provider. The provider has had the ability to create a password, but this idea of an ephemeral password was pretty exciting. This new type provides the ability to create a resource without the sensitive data being stored in the state at all.

The Implementation

I'll skip talking about the main.tf file because it's pretty dead simple.

What will talk about though is the resources.tf file, which is where all the magic happens:

ephemeral "random_password" "password_update" {
  length = 16
  special = false
  upper = true
  lower = true
  numeric = true
}

resource "google_secret_manager_secret" "ephemeral_secret" {
  secret_id = "my-secret-id" // Replace with your secret ID
  replication {
    auto {}
  }
}

resource "google_secret_manager_secret_version" "ephemeral_secret_version" {
  secret = google_secret_manager_secret.ephemeral_secret.id
  secret_data_wo = ephemeral.random_password.password_update.result
}

In order:

We create a random password that is ephemeral. This means that it will only be created on the next terraform apply and will be forgotten/ignored.
We create a new secret in Google Secret Manager.
We create a new version of the secret using the result from the random provider creating the password and sets it to the secret_data_wo which makes sure that the information is not stored in the state file.

On the next terraform apply, the password will be created and once the apply has completed it will be forgotten and that object itself will be ignored going forward. If you check the state file, you will see that there is no mention of the random_password.password_update resource and you will see that the secret_data_wo field for google_secret_manager_secret_version.ephemeral_secret_version has no value. This means that your state file is completely clean and the only thing that knows the value of the password is your secrets manager.

Assuming your IAM is configured correctly and you're using LUA and all of those other fun acronyms...

A Closing Thought

This is a big move for Terraform. I looked and the GCS Provider has also started adding ephemeral resources for keys and secrets. The less that information is in the state file, the better.

That all said, I can not stress enough the nature of this resource is exactly what is says on the tin...ephemeral. If you goof up and need it to come back, it won't, you'll just have to create a new resource. It's a price worth paying, but a fact worth knowing.

AWS Nuances in Terraform

Ian Knighton — Thu, 03 Apr 2025 14:00:35 +0000

In tandem with my recent post on Reusing Providers in Terraform, I used the example of working with the Terraform AWS provider. It may come as a shock, but it's because I was working on implementing some resources in AWS that we hadn't done much with in the past. Through this process, I learned a couple of things...

Regions Matter

Unlike other providers that I've used, it appears that regions are incredibly important to AWS. If you have a resource in one region and it's trying to contact or append to a resource in another region, you can run into all kinds of weird errors.

In one case, we couldn't use a resource in us-east-1 and have it connect to a resource in us-west-1 without it trying to do some redirect magic. So it's all well and good to be able to use the aliased providers, but depending on your dependency tree, it may just be best to put everything in one region.

Secrets Live

In other providers, destroying a resource sends it into the void. You say "vaya con dios" and then never think about that thing again.

This is mostly true in AWS, with the exception of Secrets Manager. When a secret is deleted, it has a default delay of 30 days before it is actually removed. So it's possible to remove the resource, have it no longer in your state or visible through the web console, but be unable to recreate the resource due to an existing resource with the same name.

It was only upon deleting a secret through the console that I learned about this.

Resource Linking

The last thing, and this is pretty fringe, was I ran into an issue with using resources in other resources. Specifically in the case of setting IAM policies on a resource.

This was kind of a silly thing and I was already not positive it would work, but the error handling wasn't great. I kept seeing an error on initialization of terraform that just said "cycle" and two resource names. It took me a second to figure out what it was trying to tell me.

Do with this what you will.

Just want to keep this out there for when I forget next week.

Reusing Providers in Terraform

Ian Knighton — Mon, 24 Mar 2025 13:00:12 +0000

(if you want to skip the BS,here's an example in my GitHub)

I recently came into a situation where I needed to import multiple S3 buckets from AWS. For the most part, importing the resources is pretty straightforward. Especially when compared to other service providers.

However, in this case the resources were all over the place as far as regions. This means that you couldn't necessarily use a default configuration to import and manage the resources. This is a weird limitation in the provider where it seems that the import can only search the region of the default provider unless told otherwise.

Anyways, since this is a thing I've ran into more than once, it felt important to document it somewhere.

Some Assumptions

I'm operating off the assumption that you have Terraform and (probably) the AWS CLIs installed.

I'm also operating on the assumption that you already have at least the base configuration of the AWS provider working with terraform. You'll need a secret key and all of that setup.

Main.tf

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# The us-east-1 instance
provider "aws" {
  region = "us-east-1"
}

# Create a bucket in us-east-1
resource "aws_s3_bucket" "east_1_example" {
  bucket = "east-1-example"

  tags = {
    Environment = "Dev"
  }
}

If you've worked in Terraform, a lot of this is straight forward.

First, we're establishing our required provider as "hashicorp/aws" so we can import that provider and the correct version.

The provider requires:

region
access_key
secret_key

Obviously, we NEVER HARDCODE THE ACCESS OR SECRET KEY INTO THE CONFIG so we've passed those in as environment variables and just set the provider's region to us-east-1. This means that all resources will be created in that region and, importantly, when importing resources you'll only be able to import resources from that region.

Alias

This is the thing that took me too long to figure out. In the old days, you used to configure a second provider name. At least I think that's how it worked. Honestly, it's not something I had to do a lot until recently. Now, we can split a provider using alias in the provider configuration.

Here's an updated version of the main.tf:

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# The us-east-1 instance
provider "aws" {
  alias = "east-1"
  region = "us-east-1"
}

# Create a bucket in us-east-1
resource "aws_s3_bucket" "east_1_example" {
  provider = aws.east-1
  bucket = "east-1-example"

  tags = {
    Environment = "Dev"
  }
}

This version is pretty much the same. The big change is that we're adding the alias property to the provider configuration and setting it to east-1. Essentially, we're giving it another name.

To use that, we add the provider property to the storage bucket and specify we want to use the aws.east-1 provider. Again, this is masking (aliasing...wow) and telling the resource we want to use the aws provider with the name east-1.

In this configuration, we could have a provider with no alias and that would be the default and then we could work from there.

To that end, let's create a bucket in us-west-1 using an aliased provider.

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# The us-east-1 instance
provider "aws" {
  region = "us-east-1"
}

# The us-west-1 instance
provider "aws" {
  alias = "west-1"
  region = "us-west-1"
}

# Create a bucket in us-east-1
resource "aws_s3_bucket" "east_1_example" {
  bucket = "east-1-example"

  tags = {
    Environment = "Dev"
  }
}

# Create a bucket in us-west-1
resource "aws_s3_bucket" "west_1_bucket" {
  provider = aws.west-1
  bucket = "west-1-example"

  tags = {
    Environment = "Dev"
  }
}

This example will create a bucket in us-east-1 as that's our default and a second in us-west-1 using the aliased provider. In the case of an import, specifying the provider in the resource prior to import will make sure the terraform import command looks in the right region for the resource.

Summary

I don't know how many times I've run into this in the last few months. If you made it this far, that's great. I'm sure I'll be back in here in a few months trying to remember how I did this.

I hope you have a nice day.

PagerDuty Change Events from Azure Release Pipelines

Ian Knighton — Thu, 27 Jan 2022 21:27:44 +0000

As our team and our architecture has grown, so has the need for better managed and streamlined systems. A big push we've been making in the last few months is Incident Management and On Call Scheduling. At this point I think we've tried every tool/combination of tools and we're finally settling in with PagerDuty.

For me, one of the big selling features of PagerDuty was the ability to add change events to your services. The forensics of an incident are a lot easier if you can quickly rule a recent release out of the realm of possibility. It's also helpful to know how often and frequently releases are happening to a certain service.

Unfortunately, Azure DevOps didn't really have anything out of the box to send POST requests to an API when a release finishes. I also couldn't find anything in their marketplace that would fill the need I had.

So I made something.

It's a very simple extension for Azure Pipelines and Releases that allows you to send an update to the service in PagerDuty. If you want to configure it to do so, it will send an event message for every state (succeeded, failed, canceled) and most of the fields are customizable to do whatever you need with them.

I know that this is probably a very narrowcast post. I can't help but think this isn't an original idea or need, so I wanted to put it out there to the community in case anyone can find uses for it in their own environment.

It's also been a hot minute since I've contributed here in any meaningful way, so consider this a toe dipped back into the water just before my three year anniversary.

Hosting a .Net Core App with Nginx and Let's Encrypt

Ian Knighton — Tue, 07 May 2019 16:50:34 +0000

In the last post, we built a simple .Net Core application to handle payment processing for our event registration. It works like a champ on our local machine, but it doesn't do us any good if no one can access it.

Today, we'll make it available to the public.

I mostly started with this helpful article in the Microsoft Docs. However, I found some issues that I had to work around.

A Quick Update to the App

Using Nginx, we'll need to be able to reverse proxy, so we need to add a little bit of code to our project to handle this. In startup.cs, we'll add to the Configure method.

app.UseForwardedHeaders(new ForwardedHeadersOptions
    {
        ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
    });

You may need to add to your using statements.

using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.HttpOverrides;

Now we can carry on to building out the server.

Setting Up the Server

I started with a Linode "Nanode" server with Ubuntu 18.04 installed. In my case, this page only needs to be available for three months and won't see a ton of traffic, so the small size and smaller cost ($5 a month) really suits what I'm trying to do.

Go through your normal setup (update, upgrade, secure ssh, etc...) and then we'll install the other pieces we need.

Installing Dotnet on the Server

Again, I referenced Microsofts Docs for this, but I condensed the commands together for the sake of brevity.

wget -q https://packages.microsoft.com/config/ubuntu/18.04/packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
sudo add-apt-repository universe
sudo apt-get install apt-transport-https
sudo apt-get update
sudo apt-get install dotnet-sdk-2.2

Copying Code and Building

Depending on how intense you may want to go with this, you may want to build out a full CI pipeline. In my case, I'm not going to be doing any iterations, so I just copied the code over using scp and ran it on the server.

scp -r ~/path/to/directory ssh@server:~/appname

That command (once populated with your information) should copy the entire folder from your machine to the server in the SSH users home directory.

SSH into the server and build/publish the application.

dotnet build
dotnet publish --configuration Release

Publish should move everything into a folder in the bin/Release/netcore2.2/ directory.

Once that is done and successful, I then use symbolic linking to put it in /var/www. It's not necessary to do it, but it's an old habit.

sudo ln -s ~/appname/bin/Release/netcore2.2/publish /var/www/appname

This links the folder in the home directory to the /var/www/ directory, so if you do need to make fixes, there's no worry about copying things around.

Installing and Setting Up CertBot

Certbot is pretty straight forward and it's a beautiful tool I've written a bit about.

First, install through apt.

sudo apt install -y certbot

Once that is done, we can request a certificate. I prefer to use the standalone method.

sudo certbot certonly --standalone -d yourdomain.com -d www.yourdomain.com

Once that is finished, you should be able to run sudo certbot certificate and see the location of the certificate on your machine. It's important to keep this somewhere, we'll need it in the next step.

Install and Configure Nginx

We have code, we have a certificate, now we just need to make it available to the adoring masses.

First, install Nginx:

sudo apt install nginx

Second, make sure you can access it through your firewall. Assuming you're using ufw, we can just update the permissions.

sudo ufw allow 'Nginx Full'

Now, if you navigate to the IP address of your server, you should see the "welcome to nginx" screen.

Once you've verified that you're able to access the server, you'll want to make sure your domain is pointed to the IP. This is going to vary wildly based on what your DNS provider is, but I believe in you.

With a domain, we can now handle setting up Nginx for our site. I'll save the boring details of how all of this works, but here's what we need to do.

Create a file in /etc/nginx/sites-available/:

sudo nano /etc/nginx/sites-available/yourdomain.conf

In the text editor, copy in this configuration:

server { 
    listen 80;
    server_name yourdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443;
    server_name yourdomain.com;

    ssl_certificate           /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key       /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    gzip  on;
    gzip_http_version 1.1;
    gzip_vary on;
    gzip_comp_level 6;
    gzip_proxied any;
    gzip_types text/plain text/html text/css application/json application/javascript application/x-javascript text/javascript text/xml application/xml application/rss+xml application/atom+xml application/rdf+xml;
    gzip_buffers 16 8k;
    gzip_disable “MSIE [1-6].(?!.*SV1)”;

    access_log  /var/log/nginx/yourdomain .access.log;

location / {
    proxy_pass            https://localhost:5001;        
    proxy_http_version 1.1;
    proxy_set_header   Upgrade $http_upgrade;
    proxy_set_header   Connection keep-alive;
    proxy_set_header   Host $host;
    proxy_cache_bypass $http_upgrade;
    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Proto $scheme;
    } 
}

Again, I'm being brief here, but this should do everything we need to take requests to yourdomain.com, forward them to SSL, and connect them to the application running on the server.

In order to enable it, we'll make another symbolic link and then restart Nginx.

sudo ln -s /etc/nginx/sites-available/yourdomain.conf /etc/nginx/sites-enabled/yourdomain.conf
sudo systemctl restart nginx

To make sure everything is working, we'll start the app on its own and try to access it through the browse.

dotnet run /var/www/yourapp/yourapp.dll

After you've verified that this works, you can close the application. The next step is to make it working on its own.

Setting up systemd

Yes, there is some tragedy around systemd, but it's still handy.

Create a .service file for you application:

sudo nano /etc/systemd/system/yourapp.service

Add the following information to the file:

[Unit]
Description=Event Registration Example

[Service]
WorkingDirectory=/var/www/yourapp
ExecStart=/usr/bin/dotnet /var/www/yourapp/yourapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

The only thing I changed here from the Microsoft Doc was removing the User=www-data line. While it is best practice to have a limited scope user, I didn't have a need to worry about this service running as root. This is a non-critical system that handles next to nothing other than a redirect, so I thought it was safe enough.

Now we can enable and start the service through systemd.

sudo systemctl enable yourapp.service
sudo systemctl start yourapp.service
sudo systemctl status yourapp.service

If everything has gone to plan, you should receive a status of running and be able to access your page. If it has all gone pair shape, you can still access the logs.

sudo journalctl -fu yourapp.service

That's It!

Hope this helps. There are a lot of ways this can be optimized or better secured, but for something this simple I didn't sweat it too hard. It's been running for a couple weeks and processed a handful of payments from people we gave early access to.

I did make some subtle styling changes, but that's about it. Works perfect and is relatively easy to modify going forward.

Thanks for coming along on the ride!