DEV Community: Aftab Bashir

Built a travel booking platform in .NET with an API gateway, MongoDB, and Angular

Aftab Bashir — Mon, 27 Apr 2026 04:24:44 +0000

Most tutorials show you how to build an API. Fewer show you what sits in front of the API in a real production system.

This project is about that middle layer. A gateway that all requests go through before they reach the actual API. It checks authentication, enforces rate limits, and routes traffic. In Azure this is what API Management does. Here it runs locally with YARP, Microsoft's open source reverse proxy library.

The actual application is a travel booking system. The gateway pattern is the interesting part.

Why a gateway matters

When you build an API and expose it directly to clients, every client knows your API's address. They can call it as many times as they want. There is no central place to enforce authentication or throttle abusive callers.

A gateway changes that. Clients only know the gateway address. The API address is internal. The gateway handles auth and rate limiting before requests ever reach your code.

This is how companies like Qatar Airways, booking.com, and most large travel platforms structure their APIs. One gateway, many services behind it.

The architecture

Three .NET projects and one Angular app.

TravelBooking.Api is a standard ASP.NET Core 10 API. It connects to MongoDB, handles CRUD operations for bookings, and sends notifications when bookings are created or confirmed. The notification goes to a Logic Apps webhook in production. Locally it logs to the console.

TravelBooking.Gateway is the interesting one. Built with YARP. It does three things on every request: checks the X-Api-Key header, enforces rate limits, and proxies to the API with path transformation.

TravelBooking.Core holds shared models and interfaces.

travel-booking-ui is Angular 19. It calls the gateway, never the API directly.

Setting up YARP as a gateway

YARP configuration lives in appsettings.json. You define routes and clusters:

"ReverseProxy": {
  "Routes": {
    "bookings-route": {
      "ClusterId": "bookings-cluster",
      "Match": {
        "Path": "/gateway/{**catch-all}"
      },
      "Transforms": [
        { "PathRemovePrefix": "/gateway" }
      ]
    }
  },
  "Clusters": {
    "bookings-cluster": {
      "Destinations": {
        "destination1": {
          "Address": "http://localhost:5153"
        }
      }
    }
  }
}

Any request to /gateway/api/bookings gets the /gateway prefix stripped and forwarded to http://localhost:5153/api/bookings. The client never needs to know the API address.

API key authentication

This middleware runs before YARP proxies the request:

app.Use(async (context, next) =>
{
    var apiKey = context.Request.Headers["X-Api-Key"].FirstOrDefault();
    if (string.IsNullOrEmpty(apiKey) || apiKey != builder.Configuration["Gateway:ApiKey"])
    {
        context.Response.StatusCode = 401;
        await context.Response.WriteAsync("Unauthorized: Invalid or missing API key");
        return;
    }
    await next();
});

No API key, no access. The request never reaches the API.

Rate limiting

10 requests per 10 seconds per client. After that, requests queue up to a limit of 5 then get rejected.

builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("fixed", opt =>
    {
        opt.PermitLimit = 10;
        opt.Window = TimeSpan.FromSeconds(10);
        opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        opt.QueueLimit = 5;
    });
});

In production you would use sliding window or token bucket depending on your traffic patterns. Fixed window is the simplest to understand and works fine for most cases.

MongoDB for bookings

The repository pattern keeps the MongoDB driver out of the controllers:

public async Task<Booking> CreateAsync(Booking booking)
{
    await _bookings.InsertOneAsync(booking);
    _logger.LogInformation("Booking {BookingId} created for {Customer}", 
        booking.Id, booking.CustomerName);
    return booking;
}

MongoDB is a good fit for bookings. The document structure matches naturally, and you do not need to define a schema before you start. Add a new field to the model and it just works.

The Angular frontend

The booking service sets the API key on every request automatically:

private headers = new HttpHeaders({
  'Content-Type': 'application/json',
  'X-Api-Key': this.apiKey
});

getBookings(): Observable<Booking[]> {
  return this.http.get<Booking[]>(
    `${this.gatewayUrl}/api/bookings`, 
    { headers: this.headers }
  );
}

The gateway URL is the only thing Angular knows about. It has no idea where the API runs.

What a real request looks like

A booking creation goes through this path:

Angular sends POST to http://localhost:5177/gateway/api/bookings with X-Api-Key header
Gateway middleware validates the API key
Rate limiter checks the request count
YARP strips /gateway and forwards to http://localhost:5153/api/bookings
API saves to MongoDB and logs the notification
Response comes back through the gateway to Angular

The whole thing takes under 200ms locally.

Running it yourself

You need .NET 10, Node.js 20, and Docker Desktop.

git clone https://github.com/aftabkh4n/travel-booking-platform.git
cd travel-booking-platform

docker run -d --name travel-mongo -p 27017:27017 mongo:7

cp TravelBooking.Api/appsettings.example.json TravelBooking.Api/appsettings.json
cp TravelBooking.Gateway/appsettings.example.json TravelBooking.Gateway/appsettings.json

Start the API, then the gateway, then Angular. Open http://localhost:4200.

Source code: https://github.com/aftabkh4n/travel-booking-platform

If you have questions drop them in the comments.

Built an event-driven order pipeline in .NET with Kafka and Azure Service Bus

Aftab Bashir — Wed, 22 Apr 2026 07:55:33 +0000

Most order processing systems I have worked with are synchronous. The API receives the request, does the work, and returns the result. That works fine until it does not. The database is slow, a third-party service is down, or you have 500 orders arriving at the same time. Everything backs up and the API starts timing out.

This project is the async version of that. Orders come in through a REST API, get saved to PostgreSQL, and get published to Kafka. A separate consumer picks them up, processes them, and publishes a fulfilment event to Azure Service Bus. The API never waits for any of that.

The architecture

There are three projects in the solution.

OrderPipeline.Api is an ASP.NET Core 10 API. It does two things when an order arrives: saves it to PostgreSQL and publishes an event to Kafka. That is it. The processing happens somewhere else.

OrderPipeline.Consumer is a .NET Worker Service. It runs continuously, reading from the Kafka orders topic. When it picks up an order event, it updates the status to Processing, does the fulfilment work, marks it as Fulfilled in PostgreSQL, and publishes a fulfilment event to Azure Service Bus.

OrderPipeline.Core holds the shared models. Order, OrderItem, OrderEvent, and the interfaces for the repository and publisher.

The order flow

POST an order to the API:

curl -X POST http://localhost:5125/api/orders \
  -H "Content-Type: application/json" \
  -d "{\"customerName\": \"John Smith\", \"customerEmail\": \"john@example.com\", \"items\": [{\"productName\": \"Laptop\", \"quantity\": 1, \"unitPrice\": 999.99}]}"

The API responds immediately with a 201. In the background:

Order e6e20d66 created in database
Order e6e20d66 published to Kafka topic orders at offset 1

Then the consumer picks it up:

Consumed message from partition [0] at offset 1
Processing order e6e20d66 for customer John Smith
Fulfilment event published to Service Bus for order e6e20d66
Order e6e20d66 fulfilled successfully

The client does not wait for any of that. It can poll GET /api/orders/{id} to check the status whenever it wants.

Publishing to Kafka

The publisher uses the Confluent.Kafka producer. The order ID is the message key, which ensures all events for the same order land on the same partition.

var message = new Message<string, string>
{
    Key = order.Id.ToString(),
    Value = JsonSerializer.Serialize(orderEvent)
};

var result = await _kafkaProducer.ProduceAsync(_kafkaTopic, message);
_logger.LogInformation(
    "Order {OrderId} published to Kafka topic {Topic} at offset {Offset}",
    order.Id, _kafkaTopic, result.Offset);

Consuming from Kafka

The consumer uses AutoOffsetReset.Earliest so it picks up messages from the beginning of the topic on first start. Manual commit means a message only gets marked as processed after the work is done, not when it is received.

var config = new ConsumerConfig
{
    BootstrapServers = _configuration["Kafka:BootstrapServers"],
    GroupId = "order-pipeline-consumer",
    AutoOffsetReset = AutoOffsetReset.Earliest,
    EnableAutoCommit = false
};

If the consumer crashes mid-processing, it picks up from the last committed offset when it restarts. No orders get lost.

Publishing to Azure Service Bus

Once an order is fulfilled, the consumer publishes a fulfilment event to a Service Bus queue. Downstream systems subscribe to that queue to handle shipping, notifications, invoicing, or whatever comes next.

var message = new ServiceBusMessage(JsonSerializer.Serialize(orderEvent))
{
    MessageId = orderEvent.EventId.ToString(),
    Subject = "OrderFulfilled",
    ContentType = "application/json"
};

await _sender.SendMessageAsync(message);

For local development, this uses the official Microsoft Azure Service Bus emulator running in Docker. The connection string just needs UseDevelopmentEmulator=true and it works identically to the real service.

The database

The Consumer and API share the same PostgreSQL database but they access it independently through EF Core. The API writes new orders. The Consumer reads and updates them. No shared state, no coupling between the two services beyond the database schema.

order.Status = OrderStatus.Processing;
await db.SaveChangesAsync();

// do the fulfilment work

order.Status = OrderStatus.Fulfilled;
order.ProcessedAt = DateTime.UtcNow;
await db.SaveChangesAsync();

Running it locally

Everything runs with Docker Compose. One command starts PostgreSQL, Kafka, Zookeeper, Kafka UI, and the Service Bus emulator.

git clone https://github.com/aftabkh4n/order-pipeline.git
cd order-pipeline
docker-compose up -d

Then start the API and Consumer in separate terminals and send a test order. The Kafka UI at http://localhost:8080 lets you watch messages flow through the topic in real time.

What I learned

Kafka startup takes time. On the first request after starting the containers, the producer waits while Kafka finishes initialising. Subsequent requests are fast. Worth knowing when you are testing and wondering why the first call takes 60 seconds.

Manual offset commit is important. With auto-commit enabled, Kafka marks a message as processed the moment it is received. If the consumer crashes before finishing the work, that message is gone. Manual commit means you commit only after the work succeeds.

The Service Bus emulator is genuinely useful. I expected it to be a rough approximation but it behaves exactly like the real service for basic queue operations. No need to touch a real Azure subscription during development.

Source code: https://github.com/aftabkh4n/order-pipeline

If you have questions or run into issues getting it running, drop a comment below.

Down for the challenge

Aftab Bashir — Mon, 20 Apr 2026 07:00:17 +0000

Share your OpenClaw experience

Jess Lee for The DEV Team

Apr 16

Join the OpenClaw Challenge: $1,200 Prize Pool!

#devchallenge #openclawchallenge #openclaw #ai

119

Comments 22

4 min read

I built a self-healing Kubernetes system in .NET that fixes its own failures using Claude AI

Aftab Bashir — Mon, 20 Apr 2026 06:53:56 +0000

A pod crashes at 3am. Kubernetes restarts it. It crashes again. Kubernetes keeps trying.

Meanwhile you are asleep. Nobody reads the logs. Nobody fixes anything. The pod just keeps crashing until someone wakes up, opens a terminal, and figures out what went wrong.

I built a system that handles the reading and thinking part automatically. When a pod fails, it pulls the logs, asks Claude what went wrong, and opens a GitHub PR with a suggested fix. By the time you wake up, the analysis is already done.

What it actually does

The system runs as a .NET background service alongside your cluster. It streams Kubernetes events in real time. When it sees a pod enter CrashLoopBackOff, OOMKilled, ImagePullError, or exit with a non-zero code, it kicks off a healing process.

Here is what happens in order:

Pod failure detected
Last 100 lines of logs pulled from the pod
Logs and failure details sent to Claude API
Claude returns root cause, severity, and a suggested fix
A branch is created on GitHub
The analysis is committed as a markdown file
A PR is opened automatically

The whole thing takes about 10 seconds from crash to PR.

A real example

I deployed a pod that intentionally fails to connect to a database. Here is what Claude wrote in the PR:

"The application failed to establish a connection to the PostgreSQL database at postgres://db:5432. The pod crashed with exit code 1 after logging ERROR: Database connection failed and FATAL: Cannot connect to postgres://db:5432. This indicates either the database service is unreachable, not running, or the connection string is incorrect."

Then it generated the Kubernetes Service YAML to fix the service discovery and listed seven kubectl commands to diagnose the issue. In a PR. Automatically. While I was watching the logs.

How it is built

There are four pieces.

KubernetesWatcher is a .NET BackgroundService that uses KubernetesClient to stream pod events. It looks for specific failure conditions in the container status:

private FailureEvent? DetectFailure(V1Pod pod, V1ContainerStatus status)
{
    var waiting = status.State?.Waiting;
    var terminated = status.State?.Terminated;

    if (waiting?.Reason == "CrashLoopBackOff")
        return CreateFailure(pod, FailureType.CrashLoopBackOff, waiting.Reason, waiting.Message ?? "");

    if (waiting?.Reason == "ImagePullBackOff" || waiting?.Reason == "ErrImagePull")
        return CreateFailure(pod, FailureType.ImagePullError, waiting.Reason, waiting.Message ?? "");

    if (terminated?.Reason == "OOMKilled")
        return CreateFailure(pod, FailureType.OOMKilled, "OOMKilled", "Container exceeded memory limit");

    if (terminated?.ExitCode > 0 && status.RestartCount > 0)
        return CreateFailure(pod, FailureType.PodCrash, "CrashExit",
            $"Container exited with code {terminated.ExitCode}");

    return null;
}

ClaudeAnalyser takes the failure and logs, builds a prompt, and calls the Anthropic API. It asks for structured JSON back so the response is easy to parse:

var response = await _client.Messages.GetClaudeMessageAsync(
    new MessageParameters
    {
        Model = "claude-haiku-4-5-20251001",
        MaxTokens = 2048,
        Messages = new List<Message>
        {
            new Message
            {
                Role = RoleType.User,
                Content = new List<ContentBase>
                {
                    new TextContent { Text = prompt }
                }
            }
        }
    });

The prompt tells Claude to act as a Kubernetes expert and return root cause, severity, a plain English fix, and the actual code or config change. Haiku is fast enough for this and costs around $0.0008 per analysis.

GitHubService uses Octokit to create a branch, commit the analysis as a markdown file, and open a PR:

await _client.Repository.Content.CreateFile(
    _settings.GitHubRepoOwner,
    _settings.GitHubRepoName,
    fileName,
    new CreateFileRequest(
        message: $"fix: self-healing patch for {result.OriginalFailure.Type} in {result.PodName}",
        content: Convert.ToBase64String(Encoding.UTF8.GetBytes(fixContent)),
        branch: branchName));

HealingOrchestrator coordinates the three above and makes sure the same failure does not trigger duplicate healing attempts while the first one is still running.

The prompt matters more than the code

I spent more time on the Claude prompt than on anything else in this project. Telling it to return structured JSON, referencing actual log lines, and specifying the failure type all produce much better output than a generic ask.

The prompt I settled on:

You are a Kubernetes expert and .NET engineer analysing a production failure.

Analyse this Kubernetes pod failure and respond ONLY with valid JSON.

FAILURE DETAILS:
Pod: {pod name}
Namespace: {namespace}
Failure Type: {type}
Reason: {reason}

POD LOGS (last 100 lines):
{logs}

Respond with this exact JSON structure:
{
    "rootCause": "Clear explanation of what caused the failure",
    "severity": "Critical|High|Medium|Low",
    "suggestedFix": "Step by step fix in plain English",
    "codeFix": "The actual code or config change needed. Empty string if none.",
    "fixType": "config|code|resources|image|none"
}

Be specific. Reference actual log lines where relevant.

The key instruction is "respond ONLY with valid JSON". Without that, Claude adds explanation text around the JSON and the parser breaks.

Running it locally

You need .NET 10, Docker Desktop with Kubernetes enabled, an Anthropic API key, and a GitHub personal access token with repo permissions.

git clone https://github.com/aftabkh4n/genai-devops-platform.git
cd genai-devops-platform/DeploymentService
dotnet run

Add your keys to appsettings.json and you will see:

[INF] Kubernetes watcher started. Watching namespace: default
[INF] Now listening on: http://localhost:0000

To test it, deploy the crash test included in the repo:

kubectl apply -f crash-test.yaml

Within a few seconds you will see the failure detected in the console, Claude called, and a PR URL printed. Go check your GitHub repo.

What I learned

The watcher reconnects automatically when the Kubernetes stream disconnects. This happens more often than you would think, especially after cluster restarts. Wrapping the watch loop in a try/catch with a 5 second delay before reconnecting keeps it stable.

The SemaphoreSlim in HealingOrchestrator is important. A pod in CrashLoopBackOff generates events every few seconds. Without deduplication you end up with ten simultaneous Claude API calls for the same pod, ten branches, and ten PRs. Not ideal.

Using jq to build JSON payloads is safer than shell string interpolation. Pod names and log lines contain characters that break JSON when interpolated directly.

Source code: https://github.com/aftabkh4n/genai-devops-platform

If you try it and find a failure type it misses, open an issue.

Why AI assistants forget everything , and how I fixed it in .NET

Aftab Bashir — Thu, 16 Apr 2026 09:43:33 +0000

I was building an AI chat assistant in Blazor. It worked fine. But every new conversation started from scratch. The user would say "I'm a software engineer who loves C#" and the assistant would respond warmly , then forget it completely the next time they opened the app.

That's not a memory problem. That's just a chat window.

I wanted something better. Something that actually remembers the user across sessions, extracts facts from conversations, and uses them to give better responses over time. I looked around for a .NET library that did this. Nothing existed. So I built it.

What I built

BlazorMemory is an open-source AI memory layer for .NET. It sits between your chat logic and your LLM and does three things:

Extracts facts from conversations using an LLM
Stores them as vector embeddings
Injects relevant memories into future prompts

The flow looks like this:

User message → extract facts → embed → store
                                          ↓
Next message → embed query → vector search → inject memories → LLM

It works in Blazor WASM with zero backend , everything stays in the browser using IndexedDB. It also works server-side with EF Core if you need SQL storage.

The hard part wasn't storage

Storing memories is easy. The hard part is making them useful.

Early versions just stored everything. After a few conversations, the memory panel was full of duplicates. "User likes C#." "User works with C#." "User is a C# developer." Three separate entries saying the same thing.

I solved this with a two-step pipeline:

Step 1 , Extract: The LLM reads the conversation and pulls out discrete facts. One sentence per fact, starting with "User". If the conversation already produced "User is a C# engineer", it won't also extract "User loves C#" , the preference is already implied.

Step 2 , Consolidate: For each new fact, the system finds similar existing memories using vector search. Then it asks the LLM: should I ADD this, UPDATE an existing memory, DELETE a contradiction, or do NOTHING?

The consolidation prompt has a clear priority order: NONE > UPDATE > DELETE > ADD. It prefers doing less. That keeps the memory clean.

Getting started

dotnet add package BlazorMemory
dotnet add package BlazorMemory.Storage.IndexedDb
dotnet add package BlazorMemory.Embeddings.OpenAi
dotnet add package BlazorMemory.Extractor.OpenAi

Wire it up in Program.cs:

builder.Services
    .AddBlazorMemory()
    .UseIndexedDbStorage()
    .UseOpenAiEmbeddings(apiKey)
    .UseOpenAiExtractor(apiKey);

Use it in your chat service:

public class ChatService(IMemoryService memory)
{
    public async Task<string> ChatAsync(string message, string userId)
    {
        // Pull relevant memories
        var memories = await memory.QueryAsync(message, userId,
            new QueryOptions { Limit = 5, Threshold = 0.65f });

        // Build system prompt
        var context = string.Join("\n", memories.Select(m => $"- {m.Content}"));
        var prompt = $"You are a helpful assistant.\n\nWhat you know:\n{context}";

        // Call your LLM
        var reply = await CallLlm(prompt, message);

        // Extract and store new facts
        await memory.ExtractAsync($"User: {message}\nAssistant: {reply}", userId);

        return reply;
    }
}

That's it. The assistant now remembers things.

Namespaces

v0.2.0 added namespace support. You can scope memories by topic:

// Store work memories separately from personal ones
await memory.ExtractAsync(conversation, userId, namespace: "work");

// Query only work memories
var results = await memory.QueryAsync(query, userId, new QueryOptions
{
    Namespace = "work"
});

Useful if you're building an assistant that handles multiple contexts.

What's available

Seven NuGet packages, all at v0.2.0:

Package	What it does
`BlazorMemory`	Core library
`BlazorMemory.Storage.IndexedDb`	Browser storage, zero backend
`BlazorMemory.Storage.InMemory`	For testing
`BlazorMemory.Storage.EfCore`	SQL Server, PostgreSQL, SQLite
`BlazorMemory.Embeddings.OpenAi`	OpenAI embeddings
`BlazorMemory.Extractor.OpenAi`	OpenAI fact extraction
`BlazorMemory.Extractor.Anthropic`	Claude fact extraction

The repo is at github.com/aftabkh4n/BlazorMemory. Issues and PRs welcome.

If you're building AI assistants in .NET and want them to actually remember users, give it a try.

I added AI-generated release notes to my CI/CD pipeline using Claude and GitHub Actions

Aftab Bashir — Thu, 16 Apr 2026 05:41:59 +0000

Every time I merged a PR I had to write a changelog entry manually. It took two minutes but I kept forgetting to do it. So I automated it with Claude.

When a PR merges to main, a GitHub Actions workflow reads the PR title, description, and changed files, sends them to the Claude API, and gets back a structured changelog entry. That entry gets committed to CHANGELOG.md automatically. The whole thing runs in about 10 seconds.

What MCP has to do with this

Nothing, directly. But this pipeline lives inside my MCP Kubernetes Manager project, which already lets Claude manage Kubernetes clusters through natural language. Adding AI-generated release notes felt like a natural fit. The project now manages its own changelog the same way it manages deployments.

If you want context on the MCP server itself, I wrote about it here: https://dev.to/aftabkh4n/i-built-an-mcp-server-in-net-that-lets-claude-manage-my-kubernetes-cluster-through-natural-language-3cji

How the pipeline works

A GitHub Actions workflow triggers on pull_request with type closed. The first thing it checks is whether the PR was actually merged, not just closed:

if: github.event.pull_request.merged == true

That condition is important. Without it the workflow runs on every closed PR including ones that were rejected.

Then it collects the PR metadata:

env:
  PR_TITLE: ${{ github.event.pull_request.title }}
  PR_BODY: ${{ github.event.pull_request.body }}
  PR_NUMBER: ${{ github.event.pull_request.number }}
  PR_AUTHOR: ${{ github.event.pull_request.user.login }}
  PR_MERGED_AT: ${{ github.event.pull_request.merged_at }}

And gets the list of changed files from git:

CHANGED_FILES=$(git diff --name-only HEAD~1 HEAD | head -20 | tr '\n' ', ')

Calling the Claude API

The API call is a standard POST to the Anthropic messages endpoint. The key part is building the payload with jq so special characters in PR titles and descriptions do not break the JSON:

PAYLOAD=$(jq -n \
  --arg model "claude-haiku-4-5-20251001" \
  --arg pr_num "$PR_NUMBER" \
  --arg pr_title "$PR_TITLE" \
  --arg pr_body "$PR_BODY_SAFE" \
  --arg files "$CHANGED_FILES" \
  '{
    model: $model,
    max_tokens: 1024,
    messages: [{
      role: "user",
      content: ("Generate a changelog entry for PR #" + $pr_num + ": " + $pr_title)
    }]
  }')

RESPONSE=$(curl -s https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$PAYLOAD")

ENTRY=$(echo "$RESPONSE" | jq -r '.content[0].text')

The model is claude-haiku-4-5-20251001 which is the fastest and cheapest Claude model. For a changelog entry it produces the same quality as larger models at a fraction of the cost.

The API key is stored as a GitHub Actions secret called ANTHROPIC_API_KEY. Never hardcode it.

Writing the changelog entry back

Once Claude returns the entry, the workflow prepends it to CHANGELOG.md so the newest entry is always at the top:

TEMP=$(mktemp)
head -4 CHANGELOG.md > "$TEMP"
echo "$ENTRY" >> "$TEMP"
tail -n +5 CHANGELOG.md >> "$TEMP"
mv "$TEMP" CHANGELOG.md

Then commits and pushes as github-actions[bot]:

git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]@users.noreply.github.com"
git pull --rebase origin main
git add CHANGELOG.md
git commit -m "docs: AI-generated changelog for PR #${{ github.event.pull_request.number }}"
git push

The git pull --rebase before the push is important. The PR merge itself updates main, so without pulling first the push gets rejected.

What the output looks like

After merging a PR that adds Kubernetes tools documentation, Claude wrote this:

## [PR #5] docs: add tools list to README
*2026-04-16T05:13:52Z by @aftabkh4n*

### Changes
- Added documentation describing the AI-powered changelog automation workflow
- Documented how Claude generates structured changelog entries automatically when PRs merge to main
- Explained the process of reading PR metadata to produce changelog entries

### Files changed
- README.md

It reads the PR description and infers what actually changed. The better your PR description, the better the changelog entry.

What it costs

The Anthropic API is not free but it is very cheap for this use case. Haiku costs $0.80 per million input tokens. A typical PR payload is around 500 tokens. That works out to roughly $0.0004 per changelog entry, less than a cent per merge.

Setting it up in your repo

Get an API key from console.anthropic.com
Add it as a secret in your repo: Settings, Secrets and variables, Actions, New repository secret, name it ANTHROPIC_API_KEY
Create .github/workflows/release-notes.yml with the full workflow

Full source code: https://github.com/aftabkh4n/mcp-kubernetes-manager

What I would add next

A way to skip the changelog for trivial PRs would be useful. Something like checking whether the PR title starts with chore: or wip: and skipping the API call entirely. That keeps the changelog clean without adding friction to the merge process.

I added AI code review and failure analysis to my CI/CD pipeline using GitHub Actions and GPT-4o-mini

Aftab Bashir — Wed, 15 Apr 2026 05:56:29 +0000

Every pull request in my IDP Platform project now gets an automatic AI
code review before anyone looks at it. When the pipeline fails, an AI
posts a root cause analysis explaining what went wrong and how to fix it.

Both run automatically inside GitHub Actions using GPT-4o-mini. No
external services, no extra infrastructure, no monthly subscription.

The problem with manual code review

Code review is valuable but it has a bottleneck. The reviewer needs
context, time, and attention. For a solo developer or a small team,
that bottleneck slows everything down. Even experienced developers miss
things when they are tired or rushing.

AI does not replace code review. It adds a first pass that catches
obvious issues before a human spends time on them. Things like missing
error handling, security anti-patterns, performance problems, and
violations of framework conventions.

How the AI code review works

When a pull request is opened or updated, a GitHub Actions workflow runs
automatically. It gets the diff of all changed C# files, sends it to
GPT-4o-mini with a prompt describing the review criteria, and posts the
response as a comment on the PR.

The whole thing runs in under 15 seconds.

# Get the diff using subprocess for reliability
result = subprocess.run(
    ['git', 'diff', f'origin/{base_ref}...HEAD', '--', '*.cs'],
    capture_output=True, text=True
)
diff = result.stdout[:6000]

# Send to OpenAI
payload = {
    "model": "gpt-4o-mini",
    "max_tokens": 1000,
    "messages": [
        {
            "role": "system",
            "content": "You are a senior .NET engineer reviewing a pull 
            request. Give concise actionable feedback on correctness, 
            security, performance, and .NET best practices."
        },
        {
            "role": "user",
            "content": f"Review this diff:\n\n```
{% endraw %}
diff\n{diff}\n
{% raw %}
```"
        }
    ]
}

The system prompt is what controls the quality of the review. I spent
more time on the prompt than on the code around it. Telling the AI to
act as a senior .NET engineer and focus on specific categories produces
much more useful output than a generic review request.

A real review from the pipeline

Here is what the AI posted on an actual PR in my project:

It flagged an invalid port number in a comment I had left in Program.cs.
It questioned whether database migration error handling was sufficient.
It noted that Swagger should be restricted in production environments.
It pointed out a missing newline at the end of the file.

None of those are critical issues but all of them are worth knowing about
before merging. The AI caught them in 14 seconds before I even looked at
the PR.

How the failure analysis works

The second workflow runs when the CI/CD pipeline fails. It fetches the
build logs from the GitHub API, sends them to GPT-4o-mini, and posts the
analysis as a check on the commit.

This is particularly useful for cryptic build errors. Instead of reading
through hundreds of lines of MSBuild output, you get a plain English
explanation of what failed and what to do about it.

The workflow structure

name: AI Code Review

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - 'src/**/*.cs'
      - 'src/**/*.csproj'

jobs:
  ai-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write

    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: AI Code Review
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          BASE_REF: ${{ github.base_ref }}
        run: |
          python3 << 'PYTHON'
          # get diff, call OpenAI, post comment
          PYTHON

The paths filter is important - the workflow only runs when C# files
change. Updating a README does not trigger a code review. This keeps the
pipeline fast and the API costs minimal.

What it costs

GPT-4o-mini charges roughly $0.15 per million input tokens and $0.60 per
million output tokens. A typical code review diff is around 2000 tokens.
At that rate you could run 500 code reviews for about $0.15.

For a portfolio project or small team this is effectively free. Even at
50 PRs a month the cost is under $0.02.

What I learned

The system prompt matters more than anything else. A vague prompt like
"review this code" produces generic output. A specific prompt that names
the language, the role, the focus areas, and the output format produces
review comments that are actually useful.

Passing environment variables into Python heredocs requires care. GitHub
Actions expressions like ${{ github.base_ref }} are not expanded inside
heredocs. The fix is to set them as environment variables first and read
them with os.environ inside the script.

subprocess is more reliable than os.popen for running shell commands in
Python. It captures stdout and stderr separately and handles errors more
predictably.

What is next

The natural next step is AI-generated release notes. When a PR is merged
to main, the AI reads all the commit messages and diff since the last
release and writes a structured changelog entry automatically. No more
manually writing release notes.

I am also looking at adding a security scan step that uses AI to check
for common vulnerability patterns before the standard SAST tools run.

Source code: https://github.com/aftabkh4n/idp-platform

If you are building something similar or have ideas for improving the
prompts, drop a comment below.

Built an MCP server in .NET that lets Claude manage my Kubernetes cluster through natural language

Aftab Bashir — Tue, 14 Apr 2026 07:01:29 +0000

I got tired of switching between my AI assistant and a terminal every time
I needed to check what was running in my Kubernetes cluster. So I built
something that removes the terminal from the equation entirely.

This is an MCP server written in .NET 9 that connects Claude directly to
a Kubernetes cluster. Instead of running kubectl commands, you just ask
Claude what you want in plain English and it figures out which tool to
call, talks to the cluster, and returns real data.

What MCP actually is

MCP stands for Model Context Protocol. It is an open standard created by
Anthropic that lets AI assistants talk to external tools and services in
a structured way. Think of it as a plugin system for AI - you build a
server that exposes tools, and any MCP-compatible AI can call those tools
during a conversation.

The difference from a regular API is that the AI decides when and how to
use the tools based on what you ask. You do not write code to call the
tools. You just have a conversation.

What I built

The server exposes eight tools that Claude can call:

ListPods - lists all pods across all namespaces or a specific one, with
status and age.

GetPodLogs - fetches recent log output from any pod, useful for debugging
without opening a terminal.

ListDeployments - shows all deployments with their desired versus ready
replica counts.

ScaleDeployment - scales a deployment to any number of replicas up to a
hard limit of 10, with the previous count included in the response so you
know what changed.

RestartDeployment - triggers a rolling restart by updating the
restartedAt annotation, which is exactly what kubectl rollout restart
does under the hood.

GetDeploymentStatus - returns detailed rollout status and conditions,
useful for checking whether a deployment completed successfully.

ListNamespaces - lists all namespaces with status and age.

GetNamespaceSummary - returns pods, deployments, and services for a
namespace in one view.

A real conversation with the cluster

Here is what an actual session looks like. I open Claude Desktop and ask:

"List all pods in my Kubernetes cluster"

Claude calls ListPods, my MCP server talks to the cluster, and I get back
something like:

idp-platform/idp-platform-xxx - Running - 1d
monitoring/prometheus-stack-grafana-xxx - Running - 1d
monitoring/alertmanager-xxx - Running - 1d
kube-system/coredns-xxx - Running - 1d

Then I ask:

"Scale the idp-platform deployment to 2 replicas"

Claude calls ScaleDeployment with the right parameters, the cluster
updates, and I get back a confirmation that it scaled from 1 to 2
replicas. No kubectl, no terminal, no context switching.

How it works technically

The server is built with the ModelContextProtocol .NET SDK. Each tool
class is decorated with McpServerToolType and each method with
McpServerTool plus a Description attribute that tells the AI what the
tool does and when to use it.

[McpServerToolType]
public class DeploymentTools
{
    [McpServerTool, Description("Scale a Kubernetes deployment to a " +
        "specified number of replicas.")]
    public async Task<string> ScaleDeployment(
        [Description("Name of the deployment to scale.")]
        string deploymentName,
        [Description("Number of replicas. Maximum 10.")]
        int replicas,
        [Description("Namespace. Defaults to default.")]
        string namespaceName = "default")
    {
        // safety check, then scale
    }
}

The descriptions are what the AI reads to decide which tool to call.
Writing good descriptions is the most important part of building an MCP
server - vague descriptions lead to wrong tool calls.

The server communicates over stdio, which means Claude Desktop spawns it
as a child process and the two communicate through standard input and
output. No HTTP server, no ports, no firewall rules.

Connecting to Claude Desktop

Add this to your Claude Desktop config file at
%APPDATA%\Claude\claude_desktop_config.json:

{
  "mcpServers": {
    "kubernetes-manager": {
      "command": "C:\\Program Files\\dotnet\\dotnet.exe",
      "args": [
        "run",
        "--project",
        "C:\\path\\to\\mcp-kubernetes-manager\\src\\Mcp.KubernetesManager"
      ]
    }
  }
}

Restart Claude Desktop, go to Settings, and you will see the server
listed under Local MCP servers with all eight tools available.

What I learned

Good tool descriptions matter more than good code. The AI uses the
Description attributes to decide which tool to call. If your description
is ambiguous the AI will either call the wrong tool or ask you to clarify.
Spending time on descriptions pays off more than optimising the
implementation.

Stdio transport is simpler than it sounds. There is no networking to
configure, no authentication to set up, and no ports to expose. The
parent process starts the server and they communicate through pipes. It
just works.

Safety guards belong in the tools themselves. I added a hard limit of 10
replicas to ScaleDeployment and input validation throughout. The AI has
no awareness of what is safe in your environment - that responsibility
stays with the tool developer.

What is next

The natural next step is adding tools for Helm releases, ConfigMap
updates, and event streaming so Claude can watch what is happening in the
cluster in real time. I am also looking at adding a confirmation step for
destructive operations - the AI would describe what it is about to do and
wait for explicit approval before making changes.

Source code: https://github.com/aftabkh4n/mcp-kubernetes-manager

If you have questions or ideas for additional tools, drop a comment below.

From zero to full infrastructure as code - Terraform, Kubernetes, Prometheus and Grafana with a single command

Aftab Bashir — Mon, 13 Apr 2026 08:47:45 +0000

Most backend developers write code that runs on infrastructure someone
else built. They open a ticket, wait for an ops team to provision a
database, and get a connection string back two days later. I wanted to
understand what that ops team actually does so I built it myself.

This is a complete local infrastructure setup that provisions everything
with one command and tears it all down just as cleanly.

What gets provisioned

Running terraform apply creates a PostgreSQL database in Docker with its
own network, a Kubernetes namespace with environment labels, a full
Deployment, Service and Ingress for the application, a ConfigMap for
configuration, Kubernetes Secrets for sensitive values, and a complete
Prometheus and Grafana monitoring stack.

Running terraform destroy removes all of it. No manual cleanup, no
orphaned containers, no forgotten resources sitting idle.

Why Terraform instead of kubectl or Docker Compose

Docker Compose is great for running services locally but it has no
concept of state. Run it twice and you get duplicate containers. If
something fails halfway through you have no way of knowing what was
created and what was not.

kubectl applies manifests but has no dependency management. You need to
know the correct order to apply things and rolling back means manually
hunting down and deleting resources one by one.

Terraform tracks state. It knows what exists, what needs creating, and
what needs updating. Run it ten times and it only makes changes when
something is actually different. That predictability is what makes it
safe to use in production.

The module structure

I split the infrastructure into three modules so each piece is
independently testable and reusable:

module "postgres" {
  source = "./modules/postgres"
}

module "kubernetes" {
  source     = "./modules/kubernetes"
  depends_on = [module.postgres]
}

module "monitoring" {
  source     = "./modules/monitoring"
  depends_on = [module.kubernetes]
}

The depends_on blocks enforce ordering. Kubernetes waits for PostgreSQL,
monitoring waits for Kubernetes. Terraform handles the sequencing
automatically so you never have to think about it.

Secrets management

One thing that catches people out with Kubernetes is putting secrets in
ConfigMaps. ConfigMaps are not encrypted. They are just base64 encoded
which is not the same thing at all.

I store sensitive values in Kubernetes Secrets and non-sensitive
configuration in ConfigMaps, then mount both into the container using
env_from. The application reads everything as environment variables
without needing to know where they came from. Swapping the secret source
from a Kubernetes Secret to HashiCorp Vault requires no application code
changes at all.

Monitoring with Helm

Rather than writing Kubernetes manifests for Prometheus and Grafana from
scratch, I used the kube-prometheus-stack Helm chart. This is the same
chart used in production Kubernetes clusters at companies running
thousands of pods.

resource "helm_release" "prometheus_stack" {
  name       = "prometheus-stack"
  repository = "https://prometheus-community.github.io/helm-charts"
  chart      = "kube-prometheus-stack"
  namespace  = kubernetes_namespace.monitoring.metadata[0].name
}

Once applied, Grafana comes pre-loaded with dashboards for CPU usage,
memory consumption, pod restarts and network traffic without any manual
configuration. You open the browser and the data is already there.

The plan before the apply

One of Terraform's most useful features is terraform plan. Before making
any changes it shows you exactly what will be created, modified or
destroyed. In a team environment this output goes into a pull request so
everyone can see what infrastructure is about to change before it
happens. No surprises, no rollbacks, no 2am incident calls because
someone applied changes directly to production.

What I learned

Helm charts save hours. Writing Kubernetes manifests for Prometheus from
scratch would take days and require deep knowledge of how everything
wires together internally. The Helm chart encapsulates all of that and
exposes only the configuration you actually care about.

State is what makes infrastructure tools production ready. Docker Compose
and shell scripts are fine for quick local work but they have no memory.
Terraform remembers what it built which means it can update it safely and
destroy it completely without you having to track anything manually.

Dependency ordering matters more than you think. If you do not declare
dependencies explicitly with depends_on, Terraform may try to create
resources in parallel before their dependencies exist. The error messages
when this happens are confusing because the resource technically exists,
it just is not ready yet.

Running it yourself

Clone the repo, copy the example vars file, fill in your own values,
then run terraform init followed by terraform apply. Everything provisions
automatically. When you are done, terraform destroy removes it all.

You will need Docker Desktop with Kubernetes enabled, Terraform installed,
and Helm with the Prometheus community repo added. The README in the repo
covers all the steps in detail.

Source code: https://github.com/aftabkh4n/terraform-idp

If you have questions or want to talk through any of the decisions, drop
a comment below.

I upgraded a .NET library into a microservices platform - RabbitMQ, OpenTelemetry, and Azure AI

Aftab Bashir — Sun, 12 Apr 2026 07:19:13 +0000

I had a .NET library that wrapped Azure OpenAI and Azure AI Search into
clean domain services for travel applications. It worked, but it was a
monolith - one process doing everything synchronously. When the AI call
took 30 seconds, the HTTP request sat open for 30 seconds.

This is how I fixed that.

The problem with synchronous AI calls

The original architecture was simple:
POST /api/itinerary/generate
→ calls Azure OpenAI GPT-4o directly
→ waits 10-30 seconds
→ returns itinerary

That works for a demo. It does not work in production. One slow AI call
blocks a thread. Under load, you run out of threads. The service falls over.

The solution - async messaging with RabbitMQ

I split the system into three independent services:
TravelAI.Api - HTTP gateway, publishes messages
TravelAI.SearchWorker - consumes search requests
TravelAI.AiWorker - consumes AI generation requests

Now the flow looks like this:
The HTTP response comes back in under 100ms. The AI work happens
independently. If the AI service is slow, requests queue up in RabbitMQ
rather than blocking threads in the API.

The message contracts

I defined the messages as simple C# records in the core library so all
three services share the same types:

public record ItineraryRequested(
    Guid     CorrelationId,
    string   TravellerName,
    string   TravellerEmail,
    string   Destination,
    DateOnly Departure,
    DateOnly ReturnDate,
    string?  AdditionalInstructions);

public record ItineraryGenerated(
    Guid    CorrelationId,
    object  Itinerary,
    bool    Success,
    string? ErrorMessage);

Using records keeps contracts immutable. The correlation ID lets you trace
a request across all three services even in distributed logs.

MassTransit for the messaging layer

Rather than talking to RabbitMQ directly, I used MassTransit as an
abstraction. This means I can swap RabbitMQ for Azure Service Bus later
without touching the consumer code.

A consumer looks like this:

public class ItineraryRequestedConsumer(
    IItineraryGenerationService aiService,
    ILogger<ItineraryRequestedConsumer> logger)
    : IConsumer<ItineraryRequested>
{
    public async Task Consume(ConsumeContext<ItineraryRequested> context)
    {
        var msg = context.Message;

        var itinerary = await aiService.GenerateAsync(
            traveller, msg.Destination,
            msg.Departure, msg.ReturnDate,
            msg.AdditionalInstructions,
            context.CancellationToken);

        await context.Publish(new ItineraryGenerated(
            msg.CorrelationId, itinerary, Success: true, ErrorMessage: null));
    }
}

MassTransit handles retries, dead-letter queues, and error handling
automatically. If the Azure OpenAI call fails, MassTransit retries it
with exponential backoff before moving the message to the error queue.

Structured logging with Serilog

Every service logs in structured JSON using Serilog. The correlation ID
flows through every log entry so you can trace a single request across
all three services in a centralised log system.

logger.LogInformation(
    "Generating itinerary {CorrelationId} for {Traveller} to {Destination}",
    msg.CorrelationId, msg.TravellerName, msg.Destination);

In production you would ship these logs to Seq, Azure Log Analytics, or
Datadog. Locally they stream to the console in readable format.

OpenTelemetry distributed tracing

The API is instrumented with OpenTelemetry so every request generates a
trace that shows exactly where time was spent:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .SetResourceBuilder(ResourceBuilder.CreateDefault()
            .AddService("TravelAI.Api"))
        .AddAspNetCoreInstrumentation()
        .AddConsoleExporter());

In production you would export traces to Jaeger, Zipkin, or Azure Monitor
instead of the console exporter.

Docker Compose for local development

The whole system starts with one command:

docker-compose up --build

The compose file uses health checks to ensure RabbitMQ is ready before
the services start connecting to it - a detail that matters because
services connecting to a broker that is still starting up will crash and
require manual restarts.

rabbitmq:
  healthcheck:
    test: ["CMD", "rabbitmq-diagnostics", "ping"]
    interval: 10s
    retries: 5

travelai-api:
  depends_on:
    rabbitmq:
      condition: service_healthy

What I learned

Async messaging changes how you think about APIs. Instead of
returning data, you return a correlation ID and a status URL. The client
polls or subscribes for the result. This feels strange at first but it is
the right model for any operation that takes more than a second.

MassTransit v9 requires a commercial license. I hit this when
upgrading - v8 is fully open source and supports RabbitMQ without any
license. Worth knowing before you add it to a project.

Solution build ordering matters in .NET. The solution file needs
explicit Build.0 entries for each project in each configuration. When
this is missing, dependent projects compile before their references are
built, and you get confusing type-not-found errors even though the
project reference is correctly set.

The stack

Layer	Technology
Framework	.NET 10
AI	Azure OpenAI (GPT-4o)
Search	Azure AI Search
Messaging	RabbitMQ via MassTransit 8
Logging	Serilog
Tracing	OpenTelemetry

Source code: https://github.com/aftabkh4n/TravelAI.Core

If you found this useful or have questions, drop a comment below.

I built a Travel Data Platform API in .NET - search, analytics, and recommendations with Redis caching

Aftab Bashir — Thu, 09 Apr 2026 04:43:45 +0000

Most travel APIs I have seen treat search, analytics, and recommendations
as completely separate systems. Different teams, different databases,
different codebases. This project explores what it looks like to build
all three on a single clean data model, with caching built in from the
start rather than bolted on later.

What it does

The platform has four areas.

Ingestion accepts bulk flight and user data via POST endpoints.
In a real system this would connect to partner feeds or scrapers.
Here it seeds 240 flights across 12 routes with realistic pricing.

Search lets you filter flights by origin, destination, airline,
price, and departure date. All results are paginated. Every unique
combination of filters gets its own Redis cache key, so a repeated
search returns in under 100ms instead of hitting the database.

Analytics exposes three aggregated views - popular routes ranked
by volume, monthly price trends for any route, and peak travel
periods by month. These are the endpoints a commercial or product
team would actually use to make decisions.

Recommendations takes a user ID and returns personalised flights
based on their preferred origin, airline, and maximum budget. It
falls back gracefully when preferred airline results are sparse,
topping up with other options so the user always gets a full list.

The caching strategy

Every read endpoint uses Redis with a cache-aside pattern. The key
is built from every filter parameter so different queries never
collide with each other.

var cacheKey = $"flights:{origin}:{destination}:{airline}:{maxPrice}:{page}:{pageSize}";

var cached = await cache.GetStringAsync(cacheKey);
if (cached is not null)
    return Ok(JsonSerializer.Deserialize<PagedResult<Flight>>(cached));

// ... query the database ...

await cache.SetStringAsync(cacheKey, JsonSerializer.Serialize(result),
    new DistributedCacheEntryOptions
    {
        AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5)
    });

TTLs are tuned per endpoint. Search results expire in 5 minutes
because flight availability changes. Analytics results last 15
minutes because aggregates change slowly. Recommendations sit at
10 minutes - long enough to feel fast, short enough to stay
relevant.

A cold search on LHR to DXB takes around 500ms. The same search
cached returns in under 100ms. That gap matters at scale.

Pagination

Every list endpoint returns a typed wrapper instead of a raw array.

public class PagedResult<T>
{
    public IEnumerable<T> Items      { get; set; } = [];
    public int            TotalCount { get; set; }
    public int            Page       { get; set; }
    public int            PageSize   { get; set; }
    public int            TotalPages => (int)Math.Ceiling((double)TotalCount / PageSize);
    public bool           HasNext    => Page < TotalPages;
    public bool           HasPrevious => Page > 1;
}

The client gets everything it needs to build pagination controls
without making a second request for the total count.

What I learned

Cache serialization needs a concrete type. Early on I cached
anonymous types and deserialized to object. The properties came
back as JsonElement instead of named fields, so the JavaScript
dashboard got undefined everywhere. Switching to named classes
fixed it cleanly.

Redis and PostgreSQL complement each other well. PostgreSQL
handles the complex GROUP BY queries that power analytics.
Redis handles the repeated reads that would hammer the database
under load. Neither tries to do the other's job.

Seed data matters for demos. Random data with a fixed seed
produces realistic-looking results every time. Using new Random(42)
means the demo looks the same whether you run it locally or show
it to someone in an interview.

The stack

Layer	Technology
API	ASP.NET Core 9
Database	PostgreSQL + Entity Framework Core 9
Caching	Redis (StackExchange.Redis)
Logging	Serilog
API docs	Scalar

Try it yourself

Source code is on GitHub:
https://github.com/aftabkh4n/data-platform

Clone it, spin up the Docker containers, and run the API.
The database seeds automatically on first run.

If you have questions or feedback, drop a comment below.

I built a Mini Internal Developer Platform in .NET -GitHub repos + Kubernetes deployments from a single API call

Aftab Bashir — Mon, 06 Apr 2026 05:15:36 +0000

Most teams I've worked with waste 2-3 hours every time they spin up a
new microservice. Create the repo, write the Dockerfile, set up CI,
write Kubernetes manifests, configure ingress, same boilerplate, every
single time.

I decided to automate all of it. One API call. Everything done
automatically.

What it does

POST to /api/services with a service name and language, and the
platform automatically:

Creates a GitHub repository
Commits a Dockerfile and GitHub Actions CI pipeline
Creates a Kubernetes Deployment, Service, and Ingress
Streams real-time status updates to a live dashboard via SignalR

The HTTP response comes back in under 200ms. All the work happens in a
background worker.

The architecture

The system is split into four .NET projects:

Idp.Api - ASP.NET Core 9 API, the entry point
Idp.Core - domain models and interfaces
Idp.Infrastructure - GitHub and Kubernetes integrations
Idp.Worker - background provisioning pipeline

When a request comes in, the controller does one thing - saves a record
to PostgreSQL with status queued and returns 202 Accepted. The
background worker polls every 5 seconds, picks up queued jobs, and runs
the full provisioning pipeline.

The GitHub integration

I used Octokit.net to talk to the GitHub REST API. Here is what happens
when you provision a new service:

var repo = await client.Repository.Create(new NewRepository(serviceName)
{
    Description = description,
    Private     = false,
    AutoInit    = true
});

// Give GitHub a moment to initialise
await Task.Delay(2000, ct);

// Commit Dockerfile
await client.Repository.Content.CreateFile(
    organisation, serviceName, "Dockerfile",
    new CreateFileRequest("chore: add Dockerfile", GetDockerfile(language)));

// Commit CI workflow
await client.Repository.Content.CreateFile(
    organisation, serviceName, ".github/workflows/ci.yml",
    new CreateFileRequest("chore: add CI workflow", GetCiWorkflow()));

The AutoInit: true creates an initial commit so we can push files
immediately. The 2 second delay is important - without it, GitHub
sometimes returns a 404 when you try to commit to a freshly created repo.

The Kubernetes integration

I used the official KubernetesClient NuGet package to create K8s
objects from C#:

// Create Deployment
await client.AppsV1.CreateNamespacedDeploymentAsync(deployment, ns);

// Create Service
await client.CoreV1.CreateNamespacedServiceAsync(service, ns);

// Create Ingress
await client.NetworkingV1.CreateNamespacedIngressAsync(ingress, ns);

Each service gets its own namespace, which keeps things clean and makes
it easy to delete a service and all its resources in one command.

Real-time updates with SignalR

The background worker pushes status updates to all connected browsers
as provisioning progresses:

await hubContext.Clients.All.SendAsync("StatusChanged", new
{
    ServiceId   = serviceId,
    ServiceName = serviceName,
    Status      = status,  // queued → creating_repo → deploying_k8s → deployed
    RepoUrl     = repoUrl,
    ServiceUrl  = serviceUrl
});

The dashboard listens for these events and updates the UI in real time

no polling, no page refresh.

What I learned

Always use async provisioning. The first version was synchronous -
the HTTP request sat open for 6 seconds while GitHub did its work.
Moving to a background worker with a queue made the API feel instant.

GitHub needs a moment after repo creation. If you immediately try
to commit files to a freshly created repo, you get a 404. A 2 second
delay after AutoInit fixes it reliably.

Handle conflicts gracefully in Kubernetes. If you try to create a
resource that already exists, K8s returns a 409 Conflict. Catching that
and either replacing or skipping makes the system idempotent.

Secrets in git history are permanent. I accidentally committed my
GitHub token inside the bin/ folder early on. Even after deleting it,
it was in git history. I had to force push a rewritten history and
immediately rotate the token. Always add **/bin/ and **/obj/ to
.gitignore before your first commit.

The stack

Layer	Technology
API	ASP.NET Core 9
Database	PostgreSQL + Entity Framework Core 9
GitHub automation	Octokit.net
Kubernetes automation	KubernetesClient
Real-time updates	SignalR
Logging	Serilog
API docs	Scalar

Try it yourself

The full source code is on GitHub:
https://github.com/aftabkh4n/idp-platform

Clone it, add your GitHub token to appsettings.json, spin up a
PostgreSQL container, and run it. You should have a working IDP in under
5 minutes.

This is one of four portfolio projects I am building to demonstrate
senior backend engineering skills. Next up: a full Data Platform API
with search, analytics, and recommendations.

If you found this useful or have questions, drop a comment below.