People in security spend their day in dashboards, tickets and log queries. I spend a good chunk of mine working out how to explain a ransomware gang’s toolkit with a camera, some lighting and a script.

Sneak Preview

My job is making videos about threat research at Sophos. Video has always been a huge passion of mine, right alongside cybersecurity, and for a long time those two things lived in separate boxes. One was the day job. The other was the thing I did on evenings and weekends. Getting the chance to host The X-Ops Brief full time is a dream come true, and I still find it a bit strange saying that out loud.

I’m telling you this for a reason, and it isn’t just to show off the cool mic I got

A lot of you reading Cyber Notes are just getting started. Cloud students, career changers, people building their first home lab project. And a question I get in my DMs almost every week is some version of “do I need to follow the exact standard path to get into cyber?”

You don’t. I have an art degree. That’s not the CV most people picture when they think “security engineer”, and yet it’s the exact thing that led me to a role nobody would have put on a careers poster. Security needs people who can build, break and defend things. It also needs people who can explain what’s going on to everyone else. Your odd mix of skills might be your biggest advantage.

If you’re studying for a cloud or security cert, watch it with that lens. Every technique mentioned is something you can look up, map to MITRE ATT&CK and then try spotting in your own test environment. That’s a free project idea right there.

👉 Watch the new episode of The X-Ops Brief:

If you enjoy it, hit reply and tell me which attack you’d like me to break down next. I read every one.

W J Pearce - Cyber Notes

If you’ve read any security news this year, you’ll have seen “supply chain attack” everywhere. OpenAI got caught up in one in May. Coder, a developer platform whose users include prominent private and government organisations was hit at the end of August. So what actually is one and why does it keep working?

What is it?

A supply chain attack is when a criminal doesn’t break into you directly. They break into something you already trust and let that trust carry them inside…sorta speak.

Think about a bakery. You can fit the best locks going on the front door, but if someone poisons the flour at the mill, it comes in through the delivery entrance and nobody checks it, because it’s the same flour you’ve bought every week for ten years. Swap flour for software and you’ve got it. Companies spend a fortune on the front door, so the clever attackers stopped knocking and went after the suppliers instead. Stupid example I know but it works.

Attackers love this for two reasons: trust and scale. Whatever a supplier sends you is expected and usually waved straight through. And if I break into one company, I’ve got one victim, but if I break into software that ten thousand companies use, I’ve got ten thousand victims for the same effort.

One of the packages hit in May, @tanstack/react-router, gets around 12 million downloads a week on its own. Why bother phishing people when they’ll install your malware for you?

So where’s the “chain”?

Very little modern software is written from scratch. Most of the code inside an app came from somewhere else: free open source packages, libraries and tools written by other people, which rely on their own packages, which rely on more. That code then runs through a build pipeline (the automated system that tests and packages it), gets published to an update server or registry, and ends up on customers machines.

Mini Shai-Hulud (yes like the sandworm from Dune). On 11 May 2026, TanStack, a widely used open source library, was compromised as part of this wider campaign. TanStack confirmed 84 malicious versions across 42 of its packages, and the whole thing reached more than 170 packages across npm and PyPI, including ones from Mistral AI and UiPath. What makes it different is that it’s a worm, so it spreads on its own. Once it steals credentials from one build pipeline, it finds every package that maintainer controls and publishes infected versions of all of them. Anyone who installs those gets infected, their tokens get taken, and round it goes again.

The malicious versions were pushed through the project’s own release pipeline. In plain English, the “this is genuine” stamp was real. OpenAI was one of the victims. Two employee devices were affected and OpenAI saw credential theft activity in a limited set of internal code repositories those staff could reach. It found no evidence that user data, production systems or its software were touched but it still replaced the certificates that prove its Mac apps are legit, so every macOS user had to update. The part I’d pay most attention to: those two devices hadn’t yet received the new package protections OpenAI was rolling out, which would have blocked the malicious dependency. The fix existed It just hadn’t reached them yet.

Another cool example: An attacker got into Coder’s Cloudflare infrastructure and added their own servers to the pool behind its module registry. Between 07:35 and 21:45 on Monday 31 August, those servers handed out modified Terraform modules (ready made building blocks for setting up cloud infrastructure). The modules hunted for cloud and AI tool API keys, CI/CD credentials, SSH keys and other secrets, then sent them to a lookalike domain, coder-infra[.]com which had been registered three days before the attack. There was no weird link to spot. The address was right, the vendor was right and developers still got malware.

So what can you actually do?

You can’t read every line of every package you install and tbh nobody expects you to. You can make yourself a much harder target though. Keep a Software Bill of Materials: SBOM, which is just a list of everything inside your software. Pin your versions and use lockfiles so new releases can’t sneak into a build. Wait a few days before installing brand new versions, because most the time security vendors constantly scan package registries for malware and plenty of bad releases get flagged quickly. Use short lived credentials so a stolen token dies fast. Give suppliers only the access they need and check which third party apps are connected to your email and cloud accounts. Finally, practise rotating keys!

Cyber Notes - W J Pearce

Related Projects:

Every week my DMs fill up with the same question. “I want to get into cybersecurity. Where do I actually start?”

I built a map to help.

It covers 29 roles across seven career lanes: defence, offence, intel and forensics, engineering and cloud, DevSecOps and AppSec, network and identity and GRC and leadership. For every single role you get:

• What the job actually does

• UK and US salary ranges

• Years of experience needed to reach it

• How technical it really is, rated out of five

• How hard the first job at that tier is to land

• Skills, study, certs and tools

• What you can side step into, and what comes next

Everything is colour coded by difficulty. Blue is your way in and is not a security role yet. Green is realistic within a couple of years. Amber needs real depth. Red is senior or specialist.

Two things before you open it. The salaries are typical 2026 ranges, so London and US metros sit above them and regional roles sit below.

Hit reply and tell me which lane you’re in. If your role is missing, I’ll add it to version two.

Get it here [Download the map] or here ⬇️

Calm, practical & self paced training to help you break into Cloud Security & DevSecOps

👉 Pre-order here: techtwoforty.com

Reposting this from the archive 📖

It’s one not many people saw through to the end, and it’s well worth doing.

It’s about 18 months old, so a couple of the tools have moved on, but the core still stands up

By the End of This Newsletter, You’ll:

✅ Know exactly what Hugging Face is and why it’s important in the AI space.
✅ Learn how to download and run a model locally - Deepseek-R1 🐳
✅ Understand how to use the Transformers library - Level 1 For building AI applications and workflows.

Start here: What is Hugging Face?

Hugging Face is a free platform for AI and machine learning with:

• Pre trained models

• User friendly APIs

• Cloud integration

• An open source ecosystem

• A vibrant community

It’s the best place to start with AI in my opinion, if you’re looking to move past chatbots.

Let’s take a look:

First things first I encourage you to head over to the website and just start poking around. This is my approach to learning anything, Just get stuck in and if you break something, all the better.

Along the top, you’ll see some interesting tabs. Here’s what they do:

• Models: Thousands of pre trained models for tasks like text generation, image recognition, and more.

• Datasets: Datasets curated for AI training and experimentation, covering everything from language to images.

• Spaces: Demos and custom AI apps built by the community, or host your own projects.

• Posts: Blog posts, news, and insights from the Hugging Face team and community.

• Docs: Documentation to help you get started or troubleshoot like a pro.

Buzzwords Aside: How can I actually use it?

If you’re new to AI, the best starting point is downloading and running a model. This simple step lays the foundation for understanding how AI works.

We’ll start with Ollama, a lightweight tool that makes running LLM’s locally super easy, no coding or cloud setup required.

Head over to Ollama and download:

Run through the set up wizard:

You’ll then be presented with a cmd to run your first model - let’s do this. Open up your terminal and copy pasta the cmd. This command tells Ollama to download and run the specified model, llama3.2

Pulling the model’s data (manifest and other files) may take a while, depending on your internet speed.

We now want to run the model we’ve just downloaded. How well you can run this is hardware dependant. You don't need a GPU to run this model but it will make it faster especially when you have at least 16GB of VRAM.

We can do this by running ollama run llama3.2
Tip: (cntrl + D) if you want to exit.

Easy as that! 🎉

Running a custom model from Hugging Face

This is where the fun starts. Head on over to Models Tab on the hugging face website.

From here we can find some weird and wonderful models to download, lets’s download DeepSeek-R1, you’ve probably heard about Deepseek in the news recently.

We actually need the GGUF version to use with Ollama so go here: DeepSeek-R1-GGUF - GGUF is optimised for: Local inference (no cloud required) and has Faster loading and execution than older formats.

Click on the small square copy button next to the Model Title and paste this into your terminal:

ollama run hf.co/unsloth/DeepSeek-R1-Distill-Llama-8B-GGUF

Once it’s downloaded we can run it with:

Super simple right!? You now know how to find, download and run a model locally from Hugging Face! This is only the start…

Let’s take things to the next level

If you're looking to start and build your own AI powered applications or build and LLM into your existing workflows, this is a great starting point.

In this next part, i’ll get you started with Hugging Face’s Transformers library:

• What Transformers?

• How to install and set up the library.

• How to run your first model as part of a script.

By the end, you’ll be equipped with the skills to start building AI applications, not just using them. Let’s do this!

Step 1: Start a New Python File in Cursor

1. Open your IDE of choice

2. Click File > New File.

3. Name it something like huggingface_model.py

Step 2: Install Required Dependencies

Before running the script, start a new virtual environment and install the Hugging Face libraries:

pip install transformers torch sentencepiece

• transformers: A library that provides pre trained AI models for tasks like text generation, translation, and classification.

• torch: A framework that enables deep learning, mainly used for training and running AI models efficiently.

• sentencepiece: A tokenizer that breaks text into smaller pieces, helping AI models process different languages

Step 3: Write the Python Script

Paste the following python script into huggingface_model.py:

NOTE: I’ve tried my best to explain the script using comments but I really encourage you to not just blindly paste this script - Try take the time to understand it.

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

# Step 1: Use a small, lightweight model
model_name = "HuggingFaceTB/SmolLM-135M"

# I ended up taking this out eventually
# Step 2: Set device (MPS for Mac GPU, fallback to CPU)
# device = torch.device("mps") if torch.backends.mps.is_available() else # torch.device("cpu")

# Step 3: Load the tokenizer and model (use bfloat16 for MPS)
tokenizer = AutoTokenizer.from_pretrained(model_name)

# Ensure tokenizer has a padding token
if tokenizer.pad_token is None:
    tokenizer.pad_token = tokenizer.eos_token

# Load model & move to device
model = AutoModelForCausalLM.from_pretrained(model_name, torch_dtype=torch.bfloat16).to(device)
model.eval()  # Set to evaluation mode

# Step 4: Define an input prompt
prompt = "What is the capital of France?"

# Step 5: Tokenize input
inputs = tokenizer(prompt, return_tensors="pt", padding=True, truncation=True).to(device)

# Step 6: Generate a response
with torch.no_grad():
    output = model.generate(**inputs, max_new_tokens=100, pad_token_id=tokenizer.pad_token_id)

# Step 7: Decode and print response
response = tokenizer.decode(output[0], skip_special_tokens=True)
print("\nAI Response:\n", response)

Step 4: Run the Script

1. Save the file (Ctrl + S) in Cursor.

2. Open a Terminal in Cursor (View > Terminal).

3. Run the script:

python3 huggingface_model.py

This first time may take a short while

You’ll see I’m using a different model here, it’s pretty cool: HuggingFaceTB/SmolLM-135M - I recommend checking it out: “state-of-the-art small language model”

AI Response:
What is the capital of France?
Paris, the capital of France, is the largest city in the country and the second-largest city in the world. It is located in the south-central part of the country, on the banks of the Seine River.

Congrats! 🎉

How could we leverage what we have just created? Use Case? AI Powered Customer Support Chatbot

Scenario:
A company wants to automate its customer support by deploying an AI chatbot that can handle frequently asked questions and assist users 24/7

How This Script Helps

1. A user types a question (“How do I reset my password?”).

2. The script processes the input and feeds it into the model.

3. The AI generates a human like response and returns it to the user.

4. The response is displayed in a live chat widget or automated email reply.

We just walked through how to get AI models running on your own machine using Hugging Face - no fancy cloud services needed! You learned how to download models, run them locally with Ollama, and even started the journey of how to code your own AI applications and workflows using the Transformers library. These are super practical skills that'll make you stand out, especially if you're looking to work with AI tools or build your own applications. Pretty cool stuff that you can actually use right away!

Thank you for reading: Keep it secure, keep it light-hearted!

W J Pearce - Cyber Notes

Cyber Threat Intelligence 101

Not sponsored!

it's about four hours of material carved out of their practitioner level CTI course.

arcX are a CREST accredited training provider, not a dude with a Udemy account and a stock photo of a hoodie. They've trained something like 70,000 people and the client list includes the big four!

Watch this first 🚨

Before you open module one.

The course teaches you to sort threat actors by intent: white, grey and black hat, then nation state, criminal & hacktivist.

What it can’t tell you, is what those actors are doing with AI right now.

That’s the gap this video fills ⬇️ ⬇️

W J Pearce - Cyber Notes

Last Issue: Break into Cloud Security. Calmly.

Next Issue: Kali Linux… on A STEAM MACHINE?

Why enterprise AI does not look like your ChatGPT tab

When you use ChatGPT or Claude through the consumer apps, you are a guest on their server. Fine for drafting an email. Not fine when the prompt or data contains customer records, source code or the contents of your ticketing system.

Organisations solve this one of two ways. Either they configure their own tenant with the vendor directly, or they put the models behind a cloud platform they already control and already audit. Bedrock is the second option on AWS.

The difference is worth spelling out, as up in interviews:

• The call stays inside your account boundary. Requests go to a Bedrock endpoint in your region, under your account, not off to a consumer endpoint somewhere.

• Access is IAM. Same roles, policies and conditions you already use for everything else. No separate user list to forget about.

• You can sanitise what goes in and what comes out. Bedrock calls this Guardrails. It will strip PII, block topics, and filter content before the model ever sees the input.

• It becomes a component. Once the model is an API inside your account you can wire it into Lambda, Step Functions, a Knowledge Base sitting on S3 or an agent that calls your internal tools.

That last point is where it gets interesting, and it is the reason this is worth learning properly rather than just knowing the marketing page exists.

Try a model before you commit to one

Before writing any code, go to Playground under Test. Pick a model, type something, watch what comes back.

I gave DeepSeek V3.2 a plain “Hello!” and got a reply in 1379ms for 28 output tokens. Not a benchmark by any stretch, but it tells you two useful things: the model is available in your region, and your account is allowed to call it.

Project time!

Step 1: get into the new console

Sign into AWS and search for Bedrock. If you land on the old console, take the Try the new Bedrock Console button on the Overview page.

The new experience is built around the bedrock-mantle endpoint, which is the part that speaks OpenAI and Anthropic request formats. The old console has not gone anywhere. Agents, Knowledge Bases, fine tuning and the original bedrock-runtime APIs all still live there.

Step 2: Quickstart, then Generate text

Click Quickstart in the left nav. You get three use cases: Generate text, Stream responses, and Analyze media. Choose Generate text.

Each card offers three API methods underneath it: Responses, Converse and Invoke. Responses is the OpenAI compatible one, and it is what AWS recommends starting with. Then hit Generate API Key.

A word on those keys. They are short term, and AWS is explicit that they are for exploration and development only. Do not put one in a production service. For anything real, attach an IAM role and let the SDK pick up credentials the normal way.

As usual, I reserve the Projects for community members…Come join the fun! 🌍

Read more

Last Issue: AWS Firewall Project: 100% Do this one 🔥🧱

Next Issue: Kali Linux… on A STEAM MACHINE?

Pre-order Here 🚀

No shouting. No hustle culture.

Let’s look at how the course is coming together, built in the evenings around a full time job, at a pace that doesn’t burn anyone out. That’s the whole ethos of TechTwoForty, and it applies to how I’m making it too.

What the course covers

TechTwoForty takes you from complete beginner to job ready in Cloud Security and DevSecOps. Starting with the fundamentals:

• How networking and the internet work, identity and keys, cloud versus traditional infrastructure, IAM, and the threats you’ll be defending against.

• From there we build up through the tools of the trade, including Linux , Docker, Terraform, and Git.

Reading walls of text is nobody’s idea of learning, every unit comes with animated explainer videos.

Each one is built, quality checked and narrated scene by scene so the visuals actually match what’s being said.

No stock footage of hoodie hackers, I promise.

Resources that come with it

This is the bit I’m most proud of. Alongside the videos you’ll get:

• Interactive playgrounds. Standalone files you download and open in your browser. Practise Linux permissions, Docker, Terraform, and Git hands on.

• Quizzes throughout, so you can check what’s going in before moving on.

• Accessible by design. I’ve built this for busy brains, including dyslexic and ADHD learners. Every unit comes with the dialog, cmd’s and exact steps that I walk through in each video. For each section you can change the Font, Size and colour.

What we’re building towards

Section 10 brings mini projects that pull the skills together, and it all builds towards a capstone project: a end to end build you can point at and say “I made that.” You’ll come out with an architecture diagram, a project plan, and a working understanding of how the whole pipeline fits together.

The extras

Landing the job is the actual goal, the course also includes CV and portfolio guidance. How to present your capstone, how to talk about your projects, and how to make your application stand out when you don’t have “5 years experience” for an entry level role. Practical prep from someone who reviews this stuff, not generic advice.

When?

TechTwoForty launches in November 2026. Production is well underway and I’ll keep sharing updates as we get closer, including some previews of the animations and playgrounds.

W J Pearce - Cyber Notes

Pre-order Here 🚀

Last Issue: Are Cloud Security Certs Still even worth it? 📜

Next Issue: TechTwoForty Update 🔊🔊

Let’s get back to basics. We’ve been upskilling with AI tools recently, but this week it’s time to return to a core skill that hasn’t changed and isn’t going anywhere.

Cloud Based Firewalls: AWS WAF

Setting up AWS WAF early in my career was one of those real "Oh, cool... I can actually do this." moments.

What is it?

Chances are you know this but if not. A web application firewall sits in front of your app and checks every HTTP request before it reaches your code. Anything that looks like SQL injection, cross-site scripting, or a flood from a single address gets stopped. Everything else carries on as normal.

AWS WAF is Amazon’s version of that. In this project you’ll build one, or I should say enable the service: Create the firewall, give it a rule set, point it at a live endpoint, and then throw traffic at it to prove it works. By the end you’ll have watched a request get blocked and seen exactly which rule caught it - not something you’ll do everyday but something you need to understand.

What we are going to deploy?

This project has three moving parts, and it helps to picture how they fit before you start clicking.

WAF attaches to a public facing AWS resource: a CloudFront distribution, an Application Load Balancer, or an API Gateway stage. Every request to that resource gets routed through a web ACL (this is an access control list) first. The web ACL is just a container of rules. Each request is checked against those rules in order, and the first rule that matches decides what happens: allow it, block it, or count it. If nothing matches, a default action you set takes over.

Where WAF sits. Legit traffic passes the web ACL and reaches the app (200). A malicious request is turned away at the firewall and never touches your code (403).

Simple…Sorta.

As usual, I reserve the Projects for community members…Come join the fun! 🌍

Read more

Last Issue: Micro Sec Project (Fixed)

Next Issue: AWS Firewall Project: 100% Do this one 🔥🧱

Super Quick one this week and a question I get a ton…

“Are Cloud Security Certs Still even worth it? 📜”

People in my position don’t actually have a definitive answer to this.

I’ve been in this space for 7+ years. I really don’t know how hard it is to break in right now. The market shifts every six months, the requirements drift and what worked when I was getting started might be useless advice today.

So I’m not going to pretend I do.

However, here’s what I do know about certs.

They give you accountability. Dropping £300+ on an exam voucher with a date attached forces you to start the study. It stops “I’ll get to it next weekend.” You either show up prepared or loose your money.

They give you a structured learning path. This is underrated. The hardest part of self teaching Cloud or Security isn’t the material, it’s figuring out what to learn and in what order. A good cert has done that work for you. You’re paying for the curriculum as much as the credential.

Vendor certs often reflect the tools real engineers actually use. AWS, Azure, vendor specific security certs, the labs and concepts map directly onto what people are touching in production. That’s not always true of the more academic certs, but for Cloud and Security? Almost 100%

They’re an HR tick box. I don’t love it either, but it’s reality. Recruiters filter resumes on keywords and “AWS Solutions Architect” works well.

So yes, I’d still do certs.

Don’t just pass the exam.

Take it one step further and actually build the things the cert is teaching you.

AWS is the perfect example. If you’re studying for the Solutions Architect Associate, don’t just memorise when to use S3 vs EBS vs EFS. Spin up the resources. Push files into a bucket. Mount EFS to an EC2 instance. Break IAM permissions and figure out why your Lambda can’t read from DynamoDB.

My honest answer: Yes, certs are still worth it, if you treat them as the floor and not the ceiling.

W J Pearce - Cyber Notes

Calm, practical & self paced training to help you break into Cloud Security & DevSecOps

👉 Pre-order here: techtwoforty.com

Last Issue: Setup Guide: Odysseus from pewdiepie!?

Next Issue: Are Cloud & Security Certs still worth it?

One from the Archives

I wanted to revisit an old project this week, it was one of the first Cloud Security tools I used and got my head around how it works.

Secrets… Secrets… Secrets… Every company has them, every hacker wants to know them.

TruffleHog is a lightweight tool used to scan for secrets, such as API keys, passwords, or other sensitive information, in code repositories.

While TruffleHog is traditionally used in CI/CD pipelines as part of DevSecOps practices, this project is aimed at those who are just getting started with security scanning. The focus will be on how to use TruffleHog on a single static repo.

I will cover:

• How to set it up (Micro Project)

• CV Challenge Pointers (You should do this)

So how can you easily set this up?

You’ll need a few things like Docker and Basic Bash commands knowledge but I’ll walk you through it all…

Step One: Install Docker

Install docker. This can be done with a few simple commands:

## Update your system ## 
sudo apt-get update 

I recently found a new quick way of installing docker.

## Download script and run ## 
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

The above is an official script that will do all the work for you. If you are paranoid about running a random script, feel free to look inside it.

Finally check you have docker & docker compose installed correctly

## Version Checker ## 
docker --version
docker compose version

Step Two: Get Trufflehog

Remember, we are using Docker for this project so run the following

docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keys

Command Breakdown:

docker run: This runs a Docker container.

--rm: Automatically removes the container once it stops, cleaning up after execution.

-it: Runs the container in interactive mode with a terminal (-i for interactive and -t for terminal).

-v "$PWD:/pwd": Mounts the current working directory ($PWD) on your host machine to the /pwd directory inside the Docker container. This allows the container to access files in your local directory.

trufflesecurity/trufflehog:latest: Specifies the Docker image to run, in this case, the latest version of the trufflesecurity/trufflehog image.

github --repo https://github.com/trufflesecurity/test_keys: Runs the TruffleHog tool inside the container to scan the specified GitHub repository (https://github.com/trufflesecurity/test_keys) for sensitive information like secrets.

You should see something like this pop up on the command line, followed by some test results from the example repo.

🐷🔑🐷 TruffleHog. Unearth your secrets. 🐷🔑🐷

Step Three: Target our own Git Repo

We now want to run TruffleHog against our own repo, so lets run that command again but this time swap out the example repo with yours. If you don’t have one, follow my guide here: Set up your own Repo!

As you can see I’ve swapped out the example one with my own (Feel free to Fork this):

docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/wjpearce-git/Basic-AWS-Networking

Trufflehog will run against this repo and apart from some metadata about the scan, no secrets will be found.

Step Four: Let’s find some secrets

What if I put a fake user pass and IP in my repo though?!

Let’s try that, I’ll create a new branch with:

git checkout -b thogtest

If you’ve looked at my repo, you’ll see I’m working with Terraform so let’s add the following “Bad” code into the variables.tf file:

##### Trufflehog Test #####
variable "creds" {
  description = "Testing Server"
  default = "http://user:password@192.168.0.1:8080"
}

Let’s push and merge that:

git add .
git commit -am "wip: testing secret detection"
git push --set-upstream origin thogtest

Now run the Docker and Trufflehog again

As you would expect, Trufflehog has picked up on this and provided the issue with the line and file.

🎉 Congrats you’ve found your first secret! 🎉

Trufflehog’s capabilities go well beyond what we’ve done here.

CV Challenge

If you’re up for a challenge I recommend trying AND DOCUMENTING the following:

• Scan an S3 bucket for verified keys - Remember you’ll need to set up an AWS Account.

• Scan individual files or directories

• Finally, set up Trufflehog to run when a PR is created using GitHub actions so that only the Source Code in the PR is scanned

Here’s a hint to get you started:

name: TruffleHog PR Scan
on: pull_request
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Run TruffleHog
        run: docker run --rm -v ${{ github.workspace }}:/pwd trufflesecurity/trufflehog:latest filesystem /pwd

WJPearce - Cyber Notes

Enjoyed this? Why not check out my other reads…

The Ultimate Docker Project🐋

Part Two: The Ultimate Docker Project 🐋

The AWS Starter Pack

Easy Cloud DevOps Project🔧

New AWS Account Step-by-Step Guide✔️

Beginner AI Cloud CV Project📝

SQL Injection: Made Simple 💉

The Ultimate Cloud Project ☁️

Easy Cloud Automation Project ⚙️

Last Issue: Claude Code for Cloud Security: What you should know 🌩️

Next Issue: Are Cloud & Security Certs still worth it?

We’re going to stand up Odysseus: An open source, self hosted AI app, get it talking to a model, and then walk every feature one by one.

I want to run it with a local model rather than a cloud API. With everything we’re putting into these tools now, I think local is the future, and security is the why.

Want to follow the source as we go? Start here: github.com/pewdiepie-archdaemon/odysseus.

open source, free, bring your own models with no telemetry.

1. Getting it running

The whole thing ships as a set of Docker containers, so setup is just a few commands. Open a terminal in whatever folder you keep projects in.

Clone the repo and move into it:

git clone https://github.com/pewdiepie-archdaemon/odysseus.git && cd odysseus

Clone done, you’re now sitting inside the odysseus folder on the main branch.

Make sure your Docker engine is running (open Docker Desktop), then build and start everything in the background:

docker compose up -d --build

First run pulls a few images, the chat app itself plus its helpers: searxng (search), chromadb (the memory/vector store), and ntfy (notifications). Give it a minute.

Compose pulling the supporting containers on first build.

On first boot it creates an admin user and prints a temporary password into the logs. Grab it with:

docker compose logs odysseus

Look for the “Initial admin user created” line — the temporary password is right under it.

Now open the app in your browser and sign in as admin with that password.

The login screen. Username admin, password from the logs.

2. A quick look around

You land in the chat view with the full sidebar on the left: Chat, Search, Email, Tools, Brain, Calendar, Compare, Cookbook, Deep Research, Gallery, Library, Notes, Tasks. That sidebar is the giveaway that this is a complete orchestration platform, not just a chat box. We’ll come back to the headline features later.

The home view. Note the prompt: type /setup to get started, or just paste an endpoint in chat.

Right now though, the model picker says it all: “No models connected.” Nothing can happen until we give Odysseus a brain to talk to. That’s next.

3. Adding a model

Head into Settings from the sidebar. There’s a lot in here, you can set your default search engine for deep research and pick model defaults for different features, but let’s stay focused on the one job that matters first: adding a model. Two roads, cloud or local.

Settings → Add Models. Two endpoint types: LOCAL and API. Right now both read “None.”

The easy road: a cloud model

Adding a cloud model is about as simple as it gets. We’ve done this a million times. Open the API section, pick your provider from the dropdown, and it fills in the right API endpoint for you. Then paste in the key you got from that provider.

The road I care about: a local model

Since the whole point here is security, I want to run a model on my own machine. For me that’s gemma4:26b. You’ll want it set up and serving before this step, I have a separate guide on doing that with Ollama here:

Once your local model is being served, adding it to Odysseus is just one line. Open the LOCAL endpoint and paste:

http://host.docker.internal:11434/v1

(Odysseus even hints at this in its quick-start, on your own machine it’s the http://localhost:11434/v1 address; from inside a container you reach the host with host.docker.internal instead.)

4. Wait?! What actually runs the model?

A 17 GB model like gemma4 isn’t a program you “open.” To actually generate text from it, something has to do a genuinely hard job:

• Load 17 GB of weights into memory (RAM or GPU memory) and keep them there.

• Run the math, billions of matrix multiplications per response, using your Mac’s GPU/Neural Engine efficiently.

• Manage the file formats, tokenization, quantization, context window, and the rest.

That whole job is called an inference engine, and it’s a serious piece of engineering. Ollama is that engine (built on top of llama.cpp). Its entire reason to exist is to do this one hard thing well.

Odysseus is a different kind of app. It’s an orchestration / chat app — its job is everything around the model:

• the chat UI, login, and sessions

• memory and RAG/search (that’s the chromadb + searxng containers)

• tools, scheduling, email, MCP servers

To get an answer, Odysseus doesn’t run the model itself: it just fires an HTTP request at the inference engine and gets text back:

Odysseus ──“here’s the prompt”─> Ollama ──runs gemma4─> “here’s the answer”

The whole reason the local setup is one little URL: you’re just pointing the orchestrator at the engine.

5. A word on security (read this before you play)

Before we start poking around, I highly recommend reading the project’s security notes: github.com/pewdiepie-archdaemon/odysseus#security-notes.

We’re not going to change any of these settings — but this is a fantastic learning opportunity. Take one line as an example:

“Use SECURE_COOKIES=true when Odysseus is served through HTTPS by a trusted reverse proxy or private access gateway.”

Ask yourself: why would that be? Do you know what a reverse proxy is? Sitting with questions like that, instead of just copy pasting and moving on, is exactly the approach that turns a fun weekend project into something genuinely worthwhile. Keep doing projects this way and before you know it you’ve built up a huge library of knowledge.

6. The feature tour

With a model connected, here’s the good stuff.

Chat: Talk to any model

Chat with any local model or API; adding them is as simple as we just saw. Here’s gemma4:26b answering a friendly “Hello, what are you?” — running entirely on my own hardware.

Cookbook: Right sized models for your machine

Cookbook scans your hardware, recommends models that’ll actually run well, and lets you download and serve them with a click. Easy. This is where you (or I) can see which models suit the machine in front of us, with a clear read on VRAM, context, and speed before committing to a download.

Deep Research: Multi-step reports

Deep Research runs multi-step jobs that gather, read, and synthesize sources into a clean visual report. You can steer the run (Auto, Product, Compare, How-to, Fact-check) and even pick the search engine, endpoint, and model per run. I kicked off: “Give me a complete report on the new Nvidia announcement around Spark and its new line of CPUs.”

And yes, because we set the search engine ourselves, the whole pipeline stays self-hosted too. Odysseus defaults to SearXNG (self-hosted), with DuckDuckGo, Brave, Tavily and others available if you’d rather.

One more settings note worth knowing: under AI Defaults you can set the default chat model, a smaller “utility” model for background tasks like memory and auto-naming, and even a vision model for images. Set it once and forget it.

Explore and have fun

I’ve covered the basics here. I encourage to take a look at all the other features it has to offer and really take the time to understand what’s happening at each stage. Understanding how to correctly use an AI orchestration platform is soon becoming an non negotiable skill in Cloud and Security.

W J Pearce - Cyber Notes: Keep it secure, keep it light hearted

Calm, practical & self paced training to help you break into Cloud Security & DevSecOps

👉 Pre-order here: techtwoforty.com

Last Issue: Quick Weekend Project: WARP Terminal ⌨️

Next Issue: Are Cloud Security Certs Still even worth it?

AI skills used to be “cool to know.” Now they’re “need to know” and if you’re early in your cloud security career, that can feel like drinking from a firehose.

Good news: you don’t need to learn everything.

Here are three very basic ways I’m actually using Claude Code in my day to day cloud security work. All stuff you can copy this week.

1. Stop fighting the AWS CLI

The AWS CLI is essential. The syntax is also brutal. Nobody remembers the flag order for aws s3 put-bucket-policy off the top of their head.

Claude Code fixes this. Launch it in your terminal and just ask:

• “List my S3 buckets” → it runs the bash, returns a clean table.

• “Create a text file and push it to bucket X” → done.

• “Delete this bucket” → it actually pauses and warns you the action is irreversible before proceeding. Small thing. Saved me already.

One caveat I won’t shut up about: a compromised Claude Code session is a compromised AWS estate. So before you let it loose:

• Scope it to a dedicated IAM user with minimal permissions

• Run it inside a dummy virtual environment

• Store your credentials in AWS Vault, not in plaintext config files

This is the difference between a productivity boost and a breach waiting to happen.

2. Terraform that doesn’t embarrass you

Cloud security engineers live in Infrastructure as Code. Mostly Terraform.

Here’s the problem: vanilla AI generated Terraform is shitty. Inconsistent naming, no modules, no security checks, no thought to versioning. Fine for a tutorial. Useless in production.

The fix is using a proper Terraform skill, one that bakes in:

• Pinned versions and consistent formatting

• Reusable modules

• Testing frameworks and CI/CD hooks

• Security scanning with Trivy and policy as code

I tested it with a basic ask: VPC, two subnets, an EC2 instance. Standard models gave me something that would fail any half-decent review. Claude with the Terraform skill loaded up in VS Code pinned everything correctly and automatically split VPC security group ingress and egress into separate rules. which is the modern best practice most tutorials still get wrong.

3. Connect everything with Docker MCP

Containerisation is the bread and butter of this job. So is wiring tools together.

Historically, getting AI to talk to your tools meant writing custom API integrations for every single one. That gets ugly fast.

Enter Model Context Protocol. It’s a standardised way for LLMs to talk to external tools. Instead of teaching the AI how to authenticate against ten different APIs, you run an MCP server in the middle that handles all of that for you.

The easiest on ramp is Docker Desktop’s MCP support. Quick demo: I spun up the Obsidian MCP server, gave it a local REST API token, and Claude Code immediately connected to my vault. Now I can:

• Generate a structured note (AWS pen testing rules of engagement)

• Drop it into the right folder

• Query that knowledge later from any Claude session

That’s a real second brain. And it took about ten minutes to set up.

Takeaway

You don’t need to chase every shiny AI project. You need to find the manual, repetitive parts of your workflow, writing Terraform, typing CLI commands, organising notes and offload them.

You still need to understand what’s happening underneath. AI is amazing at doing the boring parts for you. It’s terrible at being your fundamentals.

WJPearce - Cyber Notes

⬇️ ⬇️ ⬇️ ⬇️ More Projects ⬇️ ⬇️ ⬇️ ⬇️

The Ultimate Cloud Project ☁️

DevSecOps AWS Project

Supply Chain Security Project 📦 ⚔️

You should learn AWS Security Hub CSPM

The Ultimate Docker Project🐋

Part Two: The Ultimate Docker Project 🐋

The AWS Starter Pack

Easy Cloud DevOps Project🔧

New AWS Account Step-by-Step Guide✔️

Beginner AI Cloud CV Project📝

SQL Injection: Made Simple 💉

Easy Cloud Automation Project ⚙️

Last Issue: How to run Gemma4 Locally with Claude Code 🌟

Next Issue: Claude Code for Cloud Security: What you should know 🌩️

The core fundamentals remain the same, but the way we interact with them is changing.

In DevSecOps and Cloud Security you need to know how teams are building and shipping code. This is the future.

It’s not just other teams code though, Cloud Security Engineers are still:

• Deploying Terraform, but now with AI assisted security checks built directly into the pipeline.
• Monitoring cloud environments, but now with AI driven alerting and drift detection.
• Writing scripts, but now with AI supported coding tools that accelerate delivery.
• Performing security architecture reviews, but now with AI copilots that help analyse risk faster.
• Working in Linux environments, increasingly enhanced by AI tooling.
• Managing networking, now supported by AI assisted troubleshooting and optimisation.

You can see where this is going….

With that in mind, one of the first skills you’ll use every day is the terminal.

So let’s learn how to use Warp, a modern agentic terminal designed for how security engineers work in 2026.

What we’re going to cover

• Installation

• What is it

• Fun Useful Features

• Coding Features

• Agent Mode

  

Installation:

Install here, warp.dev and download the .DMG

or via the CLI with:

brew install --cask warp

Or for Windows just got here and install the .exe file:

https://www.warp.dev/windows-terminal

What is it?

When you first open warp, after signing in in etc you’ll be faced with a blank terminal and that’s because warp is just….a terminal. Sort of.

While that's technically true, it’s also so much more.

• Modern terminal built from scratch in Rust

• AI agent built directly into the terminal

• GPU rendered UI for speed

• Team collaboration features via Warp Drive

• Warp supports all major shells, including Zsh, Bash, Fish, and PowerShell across macOS, Linux, and Windows

Let’s take a look at what it can do now and why in 2026 I think it should be your default terminal.

Fun Useful Features

Auto Complete File Path

Okay, starting off with the “Nice to have“ features. Warp has autocomplete, where it shows you a path based on your activity history which is super handy if you can’t remember the exact name/structure of a file path you’ve recently worked on.

Auto Complete Tool Context

In addition to auto complete for file paths it brings up the relevant options for a tool your using and quick description on what they do. Here I have typed docker and it’s suggesting all the commands I might want to use.

Vertical Split Windows

A nice touch is the vertical window splitting so you can quickly see and select between multiple terminal sessions. Again, not ground breaking but handy.

Vertical Split Panes

You can of course, split the same window to have extra context with cmd + d

Block Filtering

Yes I know how to grep, tail etc and you should 100% know how todo this manually but lets be real. Being able to see the results disappear that aren’t relevant is a nice for light work and ESPECIALLY for log hunting quickly

Typing ls

Then filtering out the results with the button in the top right

Coding Features

Nice to haves aside, what are some of the features that really make warp worth learning here.

When you’e working on a project you’ve cloned from Github you instantly see a few cool things. Again, not a substitute for learning how todo these thing manually.

As usual, I reserve the Projects for community members…Come join the fun! 🌍

Read more

Last Issue: Agentic AI Hacking Project 🤖

Next Issue: Claude Code for Cloud Security: What you should know 🌩️

Quick one this week…

I want to show you how to run Gemma 4, Google’s free open source model, locally.

This is cool enough on its own, and running local AI models is something you should definitely do at least once before you deploy them into the cloud. But for my use case here, it’s to avoid hitting those pesky Claude code limits every two minutes.

You don’t have to use Gemma 4 here, but if you take a look at the recent benchmarks compared to some of the bigger models, it’s really worth at least trying it out.

Step One: Install Claude Code

You’ll of course need to have Claude Code installed, follow this guide if you haven’t:

Step Two: Install Ollama

You can do this with the single command, here: https://ollama.com/

Once installed you should see a blank chat terminal with the model selector the bottom right

Step Three: Download Gemma 4

Now, the Gemma 4 model comes in quite a few sizes, and we want to get the right one for our machine. This will obviously depend on what hardware you’re running.

I have a Mac mini M4 Pro here, so I pasted my system specs into Claude and asked it to recommend the best model for my setup.

So all we need to run now is:

ollama run gemma4:26b

Step Four: Validation

You can now navigate back to Ollama and you should see the Gemma4 model we downloaded in the bottom right:"

Step Five: Running with Claude Code

We now want to configure this to be the default model with Claude Code. So open a new terminal and run:

ollama run gemma4:26b

Select the model from more and then start claude code and run /model selecting Gemma4

Congratulations 🎉

You are now running a local AI Model and you’ve got Claude Code using it as the default.

W J Pearce - Cyber Notes

Calm, practical & self paced training to help you break into Cloud Security & DevSecOps

👉 Pre-order here: techtwoforty.com

Last Issue: Deploy Faster on AWS: EC2 vs Lightsail (Hands On Guide)

Next Issue: How to run Gemma 4 Locally with Claude Code 🌟

I’ve recently covered two methods of AI hacking. Let’s go one step further today.

The first one was great but effectively a gpt wrapper.

The second got a little more complex: We set up an MCP server with Kali, but still pretty simple.

Cyber Notes

Easy AI Pentesting Project 💉

Last Issue: DevSecOps Course: 2026 🛣️…

Read more

8 months ago · 10 likes · 1 comment · W J Pearce

Cyber Notes

AI Hacking CV Project 🤖

Last Issue: 10,000 Readers Giveaway: AWS Cert 🚀…

Read more

9 months ago · 21 likes · 2 comments · W J Pearce

This time I want to take it up a notch.

AI is moving fast, and we’re slowly transitioning into agentic workflows. It’s no longer “user queries model, model maybe hits a database.” We’ve got a full blown ecosystem now: Agents talking to agents, running tools, chaining actions

So… we need to understand how attackers are going to use this shift against us.

Enter Strix: An open-source project that’s already pulled 20k+ stars on GitHub. It’s not a wrapper and it’s not just an MCP hookup. Strix is a team of autonomous AI agents that behave like actual hackers: they run your code dynamically, probe for vulnerabilities and validate findings with proof of concepts instead of dumping a pile of false positives on you.

Out of the box it ships with an HTTP proxy, browser automation, a terminal, a Python runtime for custom exploits and recon tooling. Multiple agents can run in parallel, share discoveries, and coordinate attacks across different pieces of your app.

Let’s set this up together and walk through how it works 👇

Prerequisites

• Docker

• Docker Compose

• An LLM (Running Locally or in the cloud with your API key)

• Two running Targets (I will show you how to set these up)

• An understanding of Github actions (Not 100% needed but handy)

Just Quickly…

One of the coolest things about Strix is its multi agent architecture. You’ve got a main agent acting as the coordinator, it does the initial recon, maps the attack surface, and decides what needs testing. From there, it spawns specialised sub agents, each tasked with a specific slice of the attack: one hunting for IDORs in the user endpoints, another fuzzing the search API for injection, another probing the auth and password reset flows. They run in parallel, share discoveries back to the main agent and you can monitor and manage each one individually.

It’s less “AI tool running a scan” and more “a small pentest team working your app at the same time” which is exactly why agentic workflows are such a step up from the wrapper and MCP approaches we looked at previously.

As usual, I reserve the Projects for community members…Come join the fun! 🌍

Read more

Last Issue: Become Cloud Security Engineer FASTER

Next Issue: Project: Claude Code Will 10x Your Cloud Security Career (Three Ways)

Both useful but one will give you the skills…

If you’re just starting out in cloud, this question comes up a lot.

Both run on AWS infrastructure. Both give you a Linux box in the cloud. So what’s the actual difference, and which one should you touch first?

Short version: it depends on why you’re here… 👀

If you’re here to learn Cloud Security or DevSecOps

Use EC2.

Every enterprise environment you’ll encounter, in a job, a lab, a CTF, or a pentest scope runs EC2 or something that behaves like it. Security groups, IAM roles, VPCs, instance metadata endpoints... these aren’t optional extras. They’re the attack surface. Lightsail hides most of that from you. Great for shipping a side project; bad for building the skills needed in this field.

The EC2 free tier gives you 750 hours/month of a t2.micro. Spin one up, SSH in, break it, rebuild it.

If you have an app idea and want it live this weekend…You’ve been messing about with Claude Code right??

Lightsail is super useful here. Pick a $5/month bundle, choose a one click stack (WordPress, LAMP, Node), and you’ll have something running in under ten minutes. The networking is pre-wired. The firewall has a simple UI. You get a fixed monthly bill with no surprise line items.

1. Navigate to the Lightsail Service

2. Choose an existing Blueprint APP Stack

   

   or if it’s a custom app choose OS only

   

3. Stick with General purpose here and upload an SSH Key (Or make one)

4. Connect using the Cloud Shell

5. Or locally with

 chmod 400 /Users/williampearce/Downloads/LightsailDefaultKey-eu-west-2.pem

ssh -i /Users/williampearce/Downloads/LightsailDefaultKey-eu-west-2.pem
      ubuntu@13.135.173.184

I’m not going to configure OpenClaw here, that’s not what this is about. I wanted to show you how blazingly quick you can set up a VPS and get stuck into new technology to run a quick test or learn.

It’s a good way to validate an idea before you care about infrastructure. Just don’t expect to learn much about how AWS actually works under the hood.

It’s a question I got last month…

Lightsail and EC2 live in separate AWS worlds. A Lightsail instance doesn’t automatically talk to your EC2 resources, RDS databases, or most other AWS services. If your app grows and you need to bring in Lambda, S3 permissions, or VPC peering, you’ll hit a wall and probably end up migrating anyway.

EC2 also has a steeper learning curve on billing. Data transfer costs, EBS volume charges, Elastic IP fees, they can catch you off guard if you’re not watching the cost

Calm, practical & self paced training to help you break into Cloud Security & DevSecOps

👉 Pre-order here: techtwoforty.com

Last Issue: Project: Get Started With Docker MCP 📦

Next Issue: AWS EC2 vs Lightsail - Which one to start with?

This Issue: Become Cloud Security Engineer FASTER

I’ve always looked up to Abed Hamdan (Unix Guy) and what he does in this space. Having the opportunity to sit down with him last week for a chat all things Cloud Security was a real honour!

Fare warning, I ramble a little. As a new Dad this year, sleep isn’t always guaranteed, I’d had a solid 4 the night before this!

- Will AI Steal Cloud Security Jobs?

- What is the most underserved area in Cloud Security Right Now?

- Where should Cloud Security Projects go on your resume?

- What’s the biggest mistake Cybersecurity Beginners make?

The “Yassified“ picture of me on the left here made me chuckle, totally my bad as I forgot to send Unix Guy a photo he could use.

Calm, practical & self paced training to help you break into Cloud Security & DevSecOps

👉 Pre-order here: techtwoforty.com

W J Pearce - Cyber Notes

Last Issue: DevSecOps Project Video Walkthrough 🚧

Next Issue: AWS EC2 vs Lightsail - Which one to start with?

This Issue: Get Started With Docker MCP Project 📦

By the End of This Post, You:

✅ Understand what MCP is and why it exists
✅ Have Docker MCP Toolkit running locally
✅ Connected Claude to an Obsidian MCP server
✅ Ran your first natural language tool calls
✅ Know where to go next

This is important to understand….

Talking to an LLM is easy. Getting an LLM to do something useful in the wild?

That’s where it’s a little more complicated and you need an “AI Agent.”

In cloud security, when you want one service or tool to communicate with another, you usually use an API. For example, a Lambda function might query NIST data and store the results in an S3 bucket.

However, as systems scale and every tool “speaks” a different API, integrating them with an AI becomes tangled. You end up writing custom code for each service, handling different authentication flows, and digging through inconsistent documentation every time. That approach doesn’t scale and is extremely difficult to maintain in an LLM driven setup.

That’s exactly the problem MCP is designed to solve.

Very Quickly, What is MCP?

MCP or Model Context Protocol is a standardised way to connect tools to LLMs.

Instead of writing code to call a tool’s API directly, you spin up an MCP server that sits in the middle. The server handles all the API calls, authentication and endpoint logic, so your LLM doesn’t need to know any of it.

All the LLM needs to do is ask the MCP server to perform a task. The server has the tools, the credentials and the knowledge of how to talk to the endpoint. The LLM stays clean.

This is why it matters: most major company is now exposing their tools via MCP, alongside their traditional API endpoints. It’s becoming the standard layer between AI and software.

The best way to learn is through projects

Here’s what you’ll need to set up your first MCP server locally with Docker

• Docker Desktop (latest version)

• An LLM app Claude Desktop, LM Studio or Cursor all work

• Claude Code (optional but recommended)

Project Time 🚀

I reserve the Projects for community members…Come join the fun! 🌍

Read more

Quick heads Up: The Pre Order pricing on my Cloud Security & DevSecOps Beginners Academy, is coming to an end soon….

🎓 The Full Course

🧭 Career Path Template

📄 CV / Portfolio Template (Built for Technical Roles)

💼 Portfolio Projects That Help Get You Hired

👉 Pre-order here: techtwoforty.com

Simple starter DevSecOps project…

I want to give you a complete walkthrough here and the kind of the content and teaching style that will be in Tech Two Forty.

Let me know what you think

Calm, practical & self paced training to help you break into Cloud Security & DevSecOps

👉 Pre-order here: techtwoforty.com

W J Pearce - Cyber Notes

Quick heads Up: The Pre Order pricing on Tech Two Forty: Cloud Security & DevSecOps Beginners Academy, is coming to an end soon….

✔ Build real Cloud Security & DevSecOps skills from scratch

✔ Follow a clear career roadmap (so you’re not guessing what to learn next)

✔ Create starter portfolio projects recruiters actually care about

✔ Use CV + portfolio templates built for technical roles

✔ Learn Linux, AWS, Containers, CI/CD security, Scripting, AI security and more

Designed for beginners and busy professionals who want a calmer, clearer way into Cloud Security & DevSecOps.

👉 Pre-order here: techtwoforty.com

What is AWS Security Agent?

At a high level, it does three things:

1. Architecture design reviews

2. Code review in pull requests

3. On demand penetration testing

The promise is simple: security feedback early, contextual and inside the workflow engineers already use.

It’s currently in public preview, and it’s AWS attempt at bringing AI assisted security across your entire SDLC.

This weekend I tested the Code Review capability.

Pen testing is powerful too, but that requires verified domains and a bit more setup, so i’ll cover that in a separate project

Project Time 🚀

I reserve the Projects for community members…Come join the fun! 🌍

Read more