DEV Community: Vincent Olagbemide

How 23,000 Repos Got Their Secrets Stolen Through Their Own CI/CD Pipeline

Vincent Olagbemide — Sun, 31 May 2026 21:54:43 +0000

Been thinking about writing this one for a while. Supply chain attacks against CI/CD pipelines have been picking up pace over the past two years and the March 2025 tj-actions incident was the one that finally made me sit down and document everything properly. This is how I think about hardening GitHub Actions pipelines and what I actually do in practice. Original is on my blog but happy to have the conversation here too.

On a regular Tuesday morning, your engineering team pushes code, the pipeline runs like it always does, and somewhere in those automated logs, your AWS access keys, your GitHub tokens, your RSA private keys, are being quietly printed out and collected by someone you have never met. You are not notified. No alarm goes off. GitHub does not send an email. Your pipeline shows green.

That is not a hypothetical. That is exactly what happened to over 23,000 teams in March 2025.

I have spent years working at the intersection of software engineering and security, where pipelines were moving over a billion dollars in monetary transactions, and more recently building Nexloy, a self-hosted deployment platform where I had to make every security decision from scratch. What I am about to share is the pattern I have watched attackers exploit again and again, the mistakes I have seen brilliant teams make, and the seven specific things that actually work when you need to lock down a GitHub Actions pipeline.

By the end of this article you will understand exactly how these attacks happen, why your pipeline is more exposed than you probably think, and what you can do about it today. Some of these changes take five minutes. Some take an afternoon. All of them matter.

Stay with me.

The Attack That Woke the Industry Up

In March 2025, engineering teams at over 23,000 companies opened their workflow logs and found something horrifying. Their most sensitive credentials were sitting there, printed in plain text, for anyone with access to those logs to read. We are talking about AWS (Amazon Web Services) access keys**, **GitHub PATs (Personal Access Tokens, which are like passwords that give programmatic access to your codebase), RSA private keys (cryptographic keys used to prove identity and encrypt data), and **npm tokens (credentials for publishing software packages).

The cause was not a sophisticated zero-day exploit. It was not a nation-state attacker breaching GitHub's own servers. It was something almost embarrassingly simple. A popular open-source GitHub Action called tj-actions/changed-files had been quietly compromised.

Here is how it worked. The attackers gained access to the repository hosting that Action and then did something sneaky. They went back and updated the version tags, which are labels like @v35 or @v44 that teams use to reference a specific version, to point at their malicious code instead of the original. No announcements. No pull requests. No alerts. Just a silent swap. Every team whose pipeline said "use version 44 of this Action" was now running the attackers' code, and that code had one job: find every secret in your pipeline environment and write it to the logs.

This vulnerability was assigned CVE-2025-30066. CVE stands for Common Vulnerabilities and Exposures, which is the official tracking system for publicly disclosed security flaws. It became the largest GitHub Actions supply chain attack on record.

But here is the detail I want you to hold onto, because it is the heartbeat of this entire article. The teams that had pinned their Actions to a specific commit SHA were not affected. A commit SHA (Secure Hash Algorithm) is a unique cryptographic fingerprint of the exact code they had reviewed, and it cannot be faked or silently moved. One configuration decision separated the impacted from the protected.

That single fact changed how I think about pipeline security. Let me explain why, and then walk you through the seven things you can do to protect your own systems.

This Was Not a One-Off

Before I get into the solutions, I want to make sure you understand the scale of what is happening, because CVE-2025-30066 was a headline but it was not an outlier.

In December 2024, Ultralytics, the company behind the YOLO (You Only Look Once) computer vision library, was hit by an almost identical attack. YOLO is one of the most widely used AI projects in the world with nearly 60 million downloads on PyPI (the Python Package Index, which is the main place people download Python libraries from). Attackers exploited a misconfigured workflow trigger called pull_request_target to run their own code inside Ultralytics' pipeline. The result was a cryptominer, which is software that secretly uses your computer's resources to generate cryptocurrency for someone else, bundled into four official releases and shipped to users around the world.

In February 2026, Trivy, Aqua Security's own open-source security scanning tool used by thousands of organisations to find vulnerabilities in their pipelines, had its GitHub Actions workflow exploited to steal an organisation-wide PAT (Personal Access Token) that had access to 33 internal workflows. The tool had been quietly vulnerable since October 2025. A separate scanner had even flagged the issue in November 2025, three months before an attacker found it first.

When a security company's own security tool gets compromised through its CI/CD (Continuous Integration and Continuous Deployment) pipeline, that tells you something important. This is not about negligence or inexperience. It is about a systemic gap in how the industry thinks about pipeline security.

Across all of these incidents and others like them, three root causes appear again and again:

Actions pinned to tags instead of commit SHAs, because tags can be silently changed to point anywhere
Misuse of the pull_request_target trigger, a workflow setting that accidentally grants fork contributors access to internal secrets
Overly permissive GITHUB_TOKEN scopes, where the automatic credential GitHub issues to every workflow is far more powerful than it needs to be

Now let us talk about how to fix them.

Why GitHub Actions Is Such an Attractive Target

GitHub Actions is genuinely brilliant. It lets you automate almost anything. You can run tests, build Docker containers, deploy to cloud servers, and send notifications, all triggered by events in your repository. Its marketplace has thousands of pre-built Actions, which are reusable automation components contributed by the community.

That same ecosystem is also what makes it dangerous.

When you add a line like uses: some-org/some-action@v2 to your workflow file, you are doing something that should give you pause. You are downloading and executing code from the internet, written by someone you have probably never met, inside an environment that has access to every secret your pipeline uses. Your cloud credentials. Your deployment keys. Your database passwords.

Most teams apply far less scrutiny to this than they would to adding a new npm (Node Package Manager, the tool used to install JavaScript libraries) dependency. And the npm ecosystem has had its own supply chain disasters. At least with npm you tend to look at the package before running it.

There is another layer to this. GitHub Actions automatically tries to redact known secrets from your workflow logs, but that protection only works if GitHub knows what your secrets are. The moment an attacker controls the code running inside your pipeline, they can extract secrets and send them outward in ways that bypass that redaction entirely.

The GITHUB_TOKEN, which is the automatically generated credential that every workflow receives, is another underappreciated risk. In many repositories, this token defaults to write permissions across the entire repository. A compromised workflow with that token can push code to your main branch, modify releases, or quietly alter your deployment scripts. Most developers I have spoken to have never looked at what their GITHUB_TOKEN is actually allowed to do.

And then there is pull_request_target. This is a workflow trigger created to allow workflows to safely respond to pull requests from forks, which are copies of your repository made by outside contributors. The problem is it runs in the context of the base repository, meaning it has access to your secrets and write permissions, even when the code triggering it came from a complete stranger's fork. This is the root cause of the Ultralytics attack, the Trivy attack, and the initial phase of the tj-actions compromise that started by targeting Coinbase.

7 Hardening Techniques That Actually Work

1. Pin Actions to Commit SHAs, Not Tags

I will say this plainly. If you take only one thing from this article, let it be this.

A tag like @v4 is just a label. Anyone with write access to that repository can move it to point at completely different code without telling you. A commit SHA is a unique fingerprint generated from the exact contents of the code at a specific point in time. It cannot be faked or silently moved. Once you pin to a SHA, you are guaranteed to always run exactly the code you reviewed.

Before, vulnerable to silent tag manipulation:

steps:
  - uses: actions/checkout@v4
  - uses: tj-actions/changed-files@v44

After, locked to exact verified code:

steps:
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
  - uses: tj-actions/changed-files@d6e91a0f7b4c9b8e5a3d2c1f0e9d8c7b6a5f4e3d # v44.5.1

The human-readable comment next to the SHA is important. It tells future you and your colleagues what version this is supposed to be. Use tools like Dependabot or Renovate to automate the process of updating these SHAs when new legitimate versions are released.

This single change is what separated the protected teams from the 23,000 affected by CVE-2025-30066.

2. Use OIDC Instead of Long-Lived Stored Secrets

For a long time, the standard way to give your pipeline access to cloud services like AWS or GCP (Google Cloud Platform) was to create a set of credentials, copy them into GitHub's secrets manager, and have your workflow read them out at runtime.

The problem is that those credentials are static. They do not expire on their own. If they are ever leaked through a compromised Action, a misconfigured log, or a breach of GitHub itself, they remain valid until someone manually goes in and rotates them. In a security incident, that window can be hours or days.

OIDC (OpenID Connect), which is an open standard for authentication that allows systems to verify identity without exchanging long-lived passwords, solves this. Instead of storing credentials, your workflow requests a short-lived token from GitHub that proves who it is. Your cloud provider is configured to trust that token and exchange it for temporary credentials that expire when the job ends.

Before, static credentials stored in GitHub secrets:

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: us-east-1

After, OIDC authentication with no stored credentials needed:

permissions:
  id-token: write   # Allow the workflow to request an OIDC token
  contents: read

steps:
  - name: Configure AWS credentials via OIDC
    uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6542e0d4c84cc4db732e71e04 # v4.0.2
    with:
      role-to-assume: arn:aws:iam::123456789012:role/github-actions-role
      aws-region: us-east-1

Even if an attacker somehow captured that OIDC token mid-workflow, it is worthless the moment the job finishes. There is nothing to steal from your secrets manager because there is nothing stored there to steal. This is the same principle I applied when building the GitHub integration layer in Nexloy, where encrypted GitHub OAuth tokens are stored rather than long-lived deploy keys sitting in plain text.

3. Restrict GITHUB_TOKEN to the Minimum It Needs

Think of the GITHUB_TOKEN like a master key that GitHub automatically hands to every workflow when it starts. In many default configurations, that key has write access to your entire repository. A compromised workflow with that key can push to your main branch, publish releases, and modify your deployment configuration, all without your knowledge.

The fix is to start from zero permissions and then explicitly add back only what each job actually needs.

First, go to your repository settings under Settings → Actions → General → Workflow permissions and set it to read-only as the default.

Then in your workflow files, declare permissions explicitly:

# Lock down the whole workflow by default, nothing is permitted
permissions: {}

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read    # Only needs to read code
      packages: write   # Needs to push a container to the registry
      id-token: write   # Needs to request an OIDC token
    steps:
      # build steps here...

  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read    # This job genuinely only needs to read code
    steps:
      # deploy steps here...

When you do this, even if one job in your workflow is compromised, the attacker is limited to what that specific job was permitted to do. A breach of your build job cannot automatically become a write to your main branch.

4. Treat Workflow Files Like Production Code, Because They Are

Here is something I have noticed over the years. Engineering teams will require two or three reviewers to approve any change to their core application code. But a change to a .github/workflows/ file, which controls what runs in their entire CI/CD pipeline, sometimes gets merged with a single click.

That inconsistency is a problem. Workflow files are your production infrastructure. A change to a workflow file can introduce a new third-party Action, relax permissions, or add a new deployment step. It deserves the same scrutiny as your application code.

The simplest way to enforce this is through CODEOWNERS, a GitHub feature that lets you specify which team must review changes to specific files or directories:

# .github/CODEOWNERS
# Any changes to workflow files require review from the security team
/.github/workflows/    @your-org/security-team @your-org/platform-engineering
/.github/actions/      @your-org/security-team

With this in place, no workflow change, including the introduction of a new third-party Action, can be merged without a review from someone who knows what to look for.

Additionally, use GitHub's Environments feature to add a human approval gate before any workflow deploys to production. This means even a fully compromised workflow has to stop and wait for a real human to click approve, which is often enough time to spot the anomaly.

5. Use Automated Tools to Scan Your Workflows

Manual review of workflow files is valuable but does not scale. Add automated scanning to your security toolchain so problems are caught before they ever reach your main branch.

Zizmor is a static analysis tool built specifically for GitHub Actions. It reads your workflow files and flags issues like dangerous use of pull_request_target, script injection vulnerabilities (places where untrusted input could be interpreted as code), and overly permissive token configurations:

# Run it locally to audit your workflows right now
pip install zizmor
zizmor .github/workflows/

# Or add it as a step inside your CI pipeline itself
- name: Scan workflows with Zizmor
  uses: woodruffw/zizmor-action@db2cb61655abc17c8f8f00bd9e3d13b91cba0ef9 # v1.5.0
  with:
    args: --format sarif .github/workflows/

StepSecurity Harden Runner takes a different approach. Instead of analysing your workflow files, it monitors what your workflow actually does at runtime. It can detect and block unexpected outbound network connections from your pipeline steps, the kind of monitoring that would have caught the tj-actions attack sending your secrets to an attacker's server while your pipeline was still mid-run.

The principle here is the same as application security. It is always better to fail at CI than to fail in production.

6. Mirror Critical Actions and Use a Private Container Registry

For environments where the stakes are high, such as fintech, healthcare, or critical infrastructure, depending on public GitHub Actions is an unnecessary risk. The solution is to fork the Actions you depend on into your own organisation's repositories, review the code, and pin to SHAs within your fork. That way you are not dependent on an external maintainer's account security.

For container images, which are the self-contained software packages that most modern deployments are built around, use a private registry like Harbor instead of pulling from Docker Hub or public GHCR (GitHub Container Registry) at runtime.

# Build and push your image to your own Harbor instance
- name: Build and push container image
  uses: docker/build-push-action@...
  with:
    push: true
    tags: harbor.internal.yourdomain.com/myapp:${{ github.sha }}

# In your Dockerfile, reference your Harbor instance, not Docker Hub
FROM harbor.internal.yourdomain.com/base/node:20-alpine

When every image flows through your own Harbor instance, you can enforce signing, which is cryptographic proof that the image came from your build pipeline and has not been tampered with. Nothing gets deployed unless it was built and approved through your controlled process.

7. Enforce Branch Protection Rules and Deployment Gates

Every security measure I have described so far is most effective as one layer in a defence-in-depth approach, meaning multiple independent barriers that an attacker would need to defeat simultaneously.

Branch protection rules and environment gates are your last line of defence. Even if a workflow is compromised, these controls can stop it from doing lasting damage:

# In your deployment workflow
jobs:
  deploy-production:
    runs-on: ubuntu-latest
    environment: production   # This triggers a mandatory approval gate
    permissions:
      contents: read
      id-token: write
    steps:
      - name: Deploy to production
        run: ./deploy.sh

Configure your production environment in GitHub settings to require manual approval from a named person or team before the deployment proceeds, a deployment branch restriction so only your main branch can deploy to production, and a wait timer for especially sensitive operations that gives you time to cancel if something looks wrong.

A compromised workflow that needs human approval to reach production is a compromised workflow that gets caught.

How I Applied All of This in Nexloy

Everything I have described in this article is not just theory I picked up from documentation. It is the set of decisions I had to make in practice while building Nexloy, a self-hosted deployment platform I have been working on quietly for a while now.

I am not ready to share the full details yet because the open source launch is coming soon, and I want to do it properly. But here is enough context to show you why these principles mattered so much to me as a builder.

The core problem Nexloy was built to solve is that small engineering teams are stuck between two painful extremes. On one side you have manual SSH scripts, scattered environment variables, and deployment processes that live only in someone's head. On the other side you have Kubernetes, which is powerful but brings enormous complexity that most small teams do not actually need. Nexloy sits in the practical middle ground: Docker Compose, Nginx, and GitHub Actions on servers you own, with a proper dashboard, deployment history, secret management, and resource bindings all in one place.

Building it meant I had to think hard about every security decision because the platform itself holds the keys to your production servers. A deployment pipeline that manages other deployment pipelines has no room for the mistakes I described earlier in this article. So the principles around encrypted credential storage, explicit deployment gates, secret redaction, and role-based access with MFA (Multi-Factor Authentication) were not optional extras I bolted on. They were the foundation.

The most important lesson I took from incidents like Trivy's compromise is this: the best security is the kind that gets generated for you, not the kind you have to remember to configure. When Nexloy creates a GitHub Actions workflow for your project, the secure patterns are already in it. The burden should not fall on every individual team to get this right from scratch every time.

I will be writing a full dedicated post about Nexloy soon, covering the architecture, the decisions behind it, and how to get started. If you want to be the first to know when it drops, follow along at nexloy.dev, on GitHub at github.com/Nexloy, or on X at @NexloyDev. It is coming.

Your Quick Wins Checklist

Here are the things you can start on today. Most of these take under 30 minutes.

Search every workflow file for Actions referenced by tags like @v1, @v2, or @main and convert each one to a SHA pin with a comment showing the version
Go to Settings → Actions → General and set your default GITHUB_TOKEN permissions to read-only
Add permissions: {} to the top of every workflow file, then declare only what each job specifically needs
Search your repository for pull_request_target and review every instance against CISA advisory guidance
Install Zizmor and run it against your .github/ directory right now, before you close this tab
Create a .github/CODEOWNERS file that routes all workflow file changes to your security team for review
Enable Dependabot for Actions so it automatically opens pull requests to update your SHA pins when new legitimate versions are released
Set up at least one production Environment in GitHub settings with a required reviewer
Enable secret scanning and push protection in your repository security settings, which catches accidental credential commits before they land on your main branch
Do a third-party Actions audit and for every Action you use, ask yourself: do I know who maintains this? Have I read the source code? Can I replace it with a SHA-pinned fork inside my own organisation?

If you genuinely cannot do all of these right now, do the first one. Pin your Actions to commit SHAs. It is the single change that would have protected the vast majority of the 23,000 repositories hit by CVE-2025-30066.

Closing Thoughts

I have been building and securing software systems for long enough to know that most breaches do not happen because a team was careless. They happen because of a gap between how seriously we treat application security and how seriously we treat pipeline security. The application gets pentest reviews, code audits, and threat modelling. The pipeline gets trusted blindly.

The attacks of 2024 and 2025 are the industry's correction. Supply chain attacks against GitHub Actions pipelines increased sharply across that period, hitting not just small teams but well-resourced companies and, in Trivy's case, security professionals who knew exactly what the risks were.

The encouraging thing is that the defences are not exotic. SHA pinning, OIDC, least-privilege tokens, and automated scanning — none of these require a large security team or a significant budget. They require intention, and they require treating your pipeline with the same seriousness you treat your code.

The teams that got hit were not failures. They were running behind the curve on a threat the industry is only now taking seriously at scale. You do not have to be.

If this was useful, I write about secure DevOps, API security, and real-world engineering lessons at vincenttechblog.com. I am also building Nexloy, an open source self-hosted deployment platform launching soon. And if you learn better by watching than reading, I break down topics like this on my YouTube channel, where I am approaching 5,000 subscribers and have crossed 1 million views. Come find me. I would love to hear what you are building and what security challenges you are working through.

If any of this was useful, I write about secure DevOps, API security, and real engineering lessons from the field at vincenttechblog.com. Also, in the middle of building Nexloy, an open source self-hosted deployment platform launching soon at Nexloy, and if you prefer video, I cover topics like this on my Youtube Channel too. Would love to hear how your team currently handles pipeline security. Drop a comment below.

How Encrisoft Achieved 20x Speedup Without More Hardware

Vincent Olagbemide — Fri, 03 Oct 2025 20:03:27 +0000

Introduction

At Encrisoft, we are genuinely excited about Alerta, our flexible instant alerting API that’s built to fit the unique needs of businesses. It has been amazing to see it in action, delivering over 80 million alerts so far, helping companies stay on top of things with timely, tailored notifications that make a real difference.

But here’s the thing about growth: it’s a double-edged sword. More alerts means more value for customers, but it also means more pressure on the system. Over time, we started noticing signs of strain:

Dashboards that once loaded instantly began to lag.
Queries that were lightning-fast slowed to a crawl.
Uptime felt fragile because the database was under stress.

This article is a technical deep-dive into how we fixed that. You’ll see exactly how we:

Optimised PostgreSQL with the right indexes.
Introduced Redis caching (the smart way).
Achieved a 20× speedup without adding a single new server.

And most importantly, you’ll get the code, reasoning, and metrics so you can apply the same lessons in your own systems.

The Scale Problem

Let’s make it concrete.

Our Alert table grew past 80 million rows, and it was still growing every month.
Queries that powered critical dashboards, things like “how many alerts in the last 30 days?” or “show me transaction counts by type” started taking seconds instead of milliseconds.
Even modest delays caused real pain. For businesses who rely on Alerta to see what’s happening right now, waiting two seconds for a dashboard to load is like driving with foggy glasses.

It was clear - the system wasn’t scaling gracefully.

Index to the Rescue

We started by looking at the data. PostgreSQL has a wonderful feature: slow query logs. By turning those on, we could see exactly which queries were dragging.

The culprit? Sequential scans. Our queries were walking through millions of rows because they didn’t have the right indexes to guide them.

So we fixed that by creating composite indexes, indexes tailored specifically to the queries users were actually running:

-- For queries by user and time
CREATE INDEX CONCURRENTLY idx_alert_uid_createdat
  ON "Alert" ("userId", "createdAt" DESC);

-- For queries by user, type, and time
CREATE INDEX CONCURRENTLY idx_alert_uid_type_createdat
  ON "Alert" ("userId", "type", "createdAt" DESC);

The impact was immediate:

Dashboard queries that once took ~2 seconds now returned in ~100 ms.
Database CPU usage during peak hours dropped by 60%.

One small change, just two indexes, transformed performance.

Redis Caching (Smart, Per-User)

Indexes solved the first problem, but we noticed another: users kept hitting the same dashboards again and again. That meant the same queries were being re-run, even though the results hadn’t changed.

The solution? Redis caching.

But we didn’t just cache everything blindly. Instead, we cached at the per-user level, so each user got their own cached results, isolated from others.

Here’s what the cache key looked like:

u:${userId}:alert_count:${filter}:${start}:${end}

And here’s what that meant:

u:${userId} → cache scoped to a specific user (no data leaks).
alert_count→ the kind of query.
${filter}:${start}:${end} → captures the parameters so the cache is precise.

With a short TTL (time-to-live) of 60 seconds, users received nearly instant responses most of the time and had access to fresh data whenever needed.

The results:

Repeat queries came back in <50 ms.

Database load dropped even further, with 80% fewer queries during peak.

Results Snapshot

Here’s the before-and-after in one table:

Metric	Before Optimization	After Optimization
Dashboard load time	~2 seconds	~100–150 ms
Query load on database	Very high	70–80% lower
CPU usage during peak	80–90%	30–40%

Alerta went from fragile at millions of rows to scalable at billions.

Personal Lessons as a Founder

Looking back, here’s what this journey taught me:

Measure before you optimise: We didn’t guess, we looked at slow query logs. That saved us from “fixing” the wrong thing.
Index smart, not more: A single composite index delivered massive gains. Randomly adding indexes just bloats your database.
Cache with precision: User-level caching avoided the pitfalls of global caching (like data leaks or stale results).
Scaling ≠ buying hardware: Throwing servers at the problem would have been expensive and temporary. Engineering finesse gave us a long-term win.

Closing

Performance is more than numbers; it’s about trust.

When dashboards respond instantly, users feel confident. When queries drag, even for a second, trust erodes.

At Encrisoft, we restored that confidence in Alerta with nothing more than two indexes and smart caching. The result was a 20× speedup, a database that runs cooler, and a platform ready for billions of alerts.

And want to know the best part? These aren’t exotic tricks. Any engineering team can apply them. Measure, index smartly, cache wisely, and you’ll be amazed how far your existing infrastructure can go.

How to integrate Alerta into your Business

Vincent Olagbemide — Tue, 01 Oct 2024 18:34:17 +0000

In this post, we'll be creating a Slack channel called #finance where we'll send alerts on the transfer of funds and also send a reply to the same message after the transfer has been delivered.

Prerequisite:

You should be a user of Slack, or have your own slack.com account,
Create Channels for your notifications
Create an Alerta account on (app.usealerta.com)
Create a basic fintech app to plug in our alerts

We are going to use a Sample Fintech app,

Create Slack Channel

On Slack, let's assume we have a #finance team, #marketing team, and #security team.

We'll go ahead and create a channel for each team and add each employee respectively.

After this is done, you should have your channels created and ready to be integrated.

Create Alerta Account

Create an account to get your API key from the Alerta App Here

After successfully creating an account, save your API key, then switch to the integrations page and select slack

Select the channel you created from the Slack Oauth page. See below

After successful integration, the channel should be integrated

Note: This is how you can add any channels to your alerta account

Create the Sample Fintech App

Now that we have successfully added our channels to the slack workspace.

Let us see how to integrate Alerta into our code base. In case you want o see the full app, See GitHub to skip the step-by-step process

Also, you can watch the Youtube video

Otherwise, let us continue

Installing Nest JS and create a nest app using the following commands

❯ npm i -g @nestjs/cli
❯ nest new sample-fintech-app
❯ cd sample-fintech-app

Let's create the wallet service, module and controller

❯ npm i @nestjs/config @nestjs/axios    
❯ nest g module wallet
❯ nest g service wallet
❯ nest g controller wallet

Let's create the alerta service, module and controller

❯ nest g module alerta
❯ nest g service alerta

Folder API Structure

After running all the commands above, your sample finance app which should have this folder structure, feel free to remove the .spec files.

sample-wallet-app/
├── src/
│   ├── alerta/
│   │   ├── alerta.module.ts        # Module for alerta functions
│   │   └── alerta.service.ts       # for alerta external api calls
│   ├── wallet/
│   │   ├── wallet.controller.ts    # Controller handling wallet
│   │   ├── wallet.module.ts        # Module for Wallet functions
│   │   └── wallet.service.ts       # handling business logic
│   ├── app.module.ts               # Main application module
│   └── main.ts                     # Entry point for the application
├── node_modules/                   # Node dependencies
├── package.json                    # Dependencies
├── package-lock.json               # Lock file extracting version of our dependencies
├── tsconfig.json                   # TypeScript configuration file
└── .eslintrc.js                    # ESLint configuration (optional)

Add Wallet Services

We'll create two functions in our wallet.service.ts file. One to transfer funds and the second to withdraw funds.

import { Injectable } from '@nestjs/common';
import { AlertaService } from 'src/alerta/alerta.service';

@Injectable()
export class WalletService {
  constructor(private readonly alertaService: AlertaService) {}

  async walletTransfer(transferDto: {
    fromWalletID: string;
    toWalletID: string;
    amount: number;
  }) {
    const { fromWalletID, toWalletID, amount } = transferDto;
    const message = `Transferred ${amount} from wallet ${fromWalletID} to wallet ${toWalletID}`;

    return { message, success: true };
  }

  withdrawToBank(withDrawDto: {
    walletID: string;
    bankAccount: string;
    amount: number;
  }) {
    const { walletID, bankAccount, amount } = withDrawDto;
    const message = `Withdrawn ${amount} from wallet ${walletID} to bank account ${bankAccount}`;
    return { message, success: true };
  }
}

Add Wallet Controller

We'll create two functions in our wallet.controller.ts file. One initiates the transfer of funds and the second to withdraws funds.

import { Body, Controller, Post } from '@nestjs/common';
import { WalletService } from './wallet.service';

@Controller('wallet')
export class WalletController {
  constructor(private readonly walletService: WalletService) {}
  @Post('transfer')
  walletTransfer(
    @Body()
    transferDto: {
      fromWalletID: string;
      toWalletID: string;
      amount: number;
    },
  ) {
    return this.walletService.walletTransfer(transferDto);
  }

  @Post('withdraw')
  withdrawToBank(
    @Body()
    withDrawDto: {
      walletID: string;
      bankAccount: string;
      amount: number;
    },
  ) {
    return this.walletService.withdrawToBank(withDrawDto);
  }
}

Now that we have created our service and controller for the wallet service, lets add the module

for wallet.module.ts

import { Module } from '@nestjs/common';
import { WalletController } from './wallet.controller';
import { WalletService } from './wallet.service';

@Module({
  controllers: [WalletController],
  providers: [WalletService],
})
export class WalletModule {}

Add Env Variables

To secure our API keys, we'll add a .env file and specify the api key and url there

ALERTA_URL=place your api url
ALERTA_KEY=place your api key here

Add Alerta Service

After setting up our wallet and our env file, we'll create two functions in our alerta.service.ts file. One to send the message and the second to reply to messages.

import { HttpService } from '@nestjs/axios';
import { HttpException, HttpStatus, Injectable } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import { catchError, lastValueFrom } from 'rxjs';

@Injectable()
export class AlertaService {
  private alertaUrl = this.config.get('ALERTA_URL');
  private alertaKey = this.config.get('ALERTA_KEY');

  constructor(
    private config: ConfigService,
    private httpService: HttpService,
  ) {}
  async sendAlert(alertaDto: {
    message: string;
    channel: string;
    replyTo: boolean;
  }): Promise<any> {
    const { message, channel, replyTo } = alertaDto;

    try {
      const headers = {
        secretKey: `secret ${this.alertaKey}`,
        'Content-Type': 'application/json',
      };

      const res = await lastValueFrom(
        this.httpService
          .post(
            `${this.alertaUrl}/send`,
            { message, channel, replyTo },
            {
              headers,
            },
          )
          .pipe(
            catchError((error) => {
              throw new HttpException(
                `Error fetching data from external API: ${error.message}`,
                HttpStatus.BAD_REQUEST,
              );
            }),
          ),
      );
      return res.data;
      return res.data;
    } catch (error) {
      return error;
    }
  }

  async replyAlert(alertaDto: {
    channelId: string;
    threadId: string;
    channelRef: string;
    message: string;
  }): Promise<any> {
    const { channelId, threadId, channelRef, message } = alertaDto;

    try {
      const headers = {
        secretKey: `secret ${this.alertaKey}`,
        'Content-Type': 'application/json',
      };

      const res = await lastValueFrom(
        this.httpService
          .post(
            `${this.alertaUrl}/reply`,
            { channelId, threadId, channelRef, message },
            { headers },
          )
          .pipe(
            catchError((error) => {
              throw new HttpException(
                `Error processing data from API ${error}`,
                HttpStatus.BAD_REQUEST,
              );
            }),
          ),
      );
      return res.data;
    } catch (error) {}
  }
}

Add Alerta Module

After setting up our alerta service, we'll update our module file alerta.module.ts file.

import { HttpModule } from '@nestjs/axios';
import { Module } from '@nestjs/common';
import { AlertaService } from './alerta.service';
import { ConfigService } from '@nestjs/config';

@Module({
  imports: [HttpModule.register({ timeout: 5000, maxRedirects: 5 })],
  providers: [AlertaService, ConfigService],
  exports: [AlertaService],
})
export class AlertaModule {}

We are almost there,
Before we test, lets us add the alerts to some places in our wallet service so we get the alerts when there is an operation.

First lets update the wallet.module.ts file to know our Alerta service

.
.
.
import { AlertaModule } from 'src/alerta/alerta.module';

@Module({
  imports: [AlertaModule],
  controllers: [WalletController],
  providers: [WalletService],
})
export class WalletModule {}

also, let us update the app.module.ts

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { WalletService } from './wallet/wallet.service';
import { WalletModule } from './wallet/wallet.module';
import { WalletController } from './wallet/wallet.controller';
import { AlertaService } from './alerta/alerta.service';
import { AlertaModule } from './alerta/alerta.module';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { HttpModule } from '@nestjs/axios';

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    WalletModule,
    AlertaModule,
    HttpModule,
  ],
  controllers: [AppController],
  providers: [AppService, ConfigService],
})
export class AppModule {}

You will notice that we added the ConfigModule.forRoot({ isGlobal: true }) this will ensure that all env config is availble and can be used app-wide.

Plug in Alerta into the codebase

Now, in the wallet.service.ts, let us assume we want to know when any user does a transfer or does a withdraw, we can send a message to the #finance channel that we created and integrated earlier.
Lets update our code.

import { Injectable } from '@nestjs/common';
import { AlertaService } from 'src/alerta/alerta.service';

@Injectable()
export class WalletService {
// bring the service in by adding it the contructor
  constructor(private readonly alertaService: AlertaService) {}

  async walletTransfer(transferDto: {
    fromWalletID: string;
    toWalletID: string;
    amount: number;
  }) {
    const { fromWalletID, toWalletID, amount } = transferDto;
    const message = `Transferred ${amount} from wallet ${fromWalletID} to wallet ${toWalletID}`;

// Add the alert from the alerta service here. Also, because we want 
// to reply to it later, we'll set `replyTo` to true
    await this.alertaService.sendAlert({
      message,
      channel: 'finance',
      replyTo: true,
    });

    return { message, success: true };
  }
.
.
.

}

Now we can send messages to Slack in the channel. Let's assume we want to reply to the same message that was sent earlier.
Usually, you can save the data from the response after you have sent a message so the message can be replied to in the future.

The data needed for the reply is threadId, channelId and channelRef

To add the Reply

Before adding the reply feature, we have to mention the @Alerta App in the channel

import { Injectable } from '@nestjs/common';
import { AlertaService } from 'src/alerta/alerta.service';

@Injectable()
export class WalletService {
  constructor(private readonly alertaService: AlertaService) {}

  async walletTransfer(transferDto: {
    fromWalletID: string;
    toWalletID: string;
    amount: number;
  }) {
    const { fromWalletID, toWalletID, amount } = transferDto;
    const message = `Transferred ${amount} from wallet ${fromWalletID} to wallet ${toWalletID}`;

    const alertRes = await this.alertaService.sendAlert({
      message,
      channel: 'finance',
      replyTo: true,
    });

// triggering the reply
    setTimeout(() => {
      this.alertaService.replyAlert({
        message: 'Transfer delivered!',
        threadId: alertRes.data.replyData.threadId,
        channelId: alertRes.data.replyData.channelId,
        channelRef: alertRes.data.replyData.channelRef,
      });
    }, 5000);

    return { message, success: true };
  }

  withdrawToBank(withDrawDto: {
    walletID: string;
    bankAccount: string;
    amount: number;
  }) {
    const { walletID, bankAccount, amount } = withDrawDto;
    const message = `Withdrawn ${amount} from wallet ${walletID} to bank account ${bankAccount}`;
    return { message, success: true };
  }
}

Now let's test our implementation

Test transfer

The Slack Message

The Reply to the existing message

In conclusion, we created a Slack channel called #finance where we'll send updates messages on the transfer of funds and also send a reply to the same message after the transfer has been delivered.

Thank you.