DEV Community: Animesh Pathak

Why AI Coding Agents Lose Context After the PR, and How to Keep It

Animesh Pathak — Thu, 12 Nov 2026 07:09:47 +0000

TL;DR

AI coding agents need more than repository-level knowledge to deliver reliable software. Combining code context from Augment's Code Context Engine with delivery context from Harness's Software Delivery Knowledge Graph helps agents understand dependencies, production impact, and release risks across the SDLC.
A governed agentic workflow connects context, execution, and governance through automated reviews, policy gates, approvals, and continuous verification, ensuring AI generated changes are safe to ship.
While deeper two-way context sharing is still planned, Harness and Cosmos are building toward an Autonomous SDLC where delivery evidence continuously informs future engineering decisions.

The Context Cliff: What Happens After an AI Agent Opens a PR

An AI coding agent can read a repository, trace its dependencies, edit a dozen files, and open a pull request that passes its own tests. Then the PR enters the delivery pipeline, and much of what the agent learned stays behind.

The pipeline produces evidence the agent never sees: a failed build, a vulnerable dependency flagged by a scan, a latency regression after deployment, an incident traced to a change that looked safe. That evidence could improve the original change and prevent the next failure, but only if something carries it back into the engineering workflow.

Writing code is often no longer the slow part. Moving a change through build, test, security, deployment, and runtime is, and each of those stages is a question of risk. Context engineering across the SDLC is the work of connecting them.

This post covers what context an agent needs, how the Code Context Engine and the Software Delivery Knowledge Graph supply two halves of it, and what works today and what Harness has said is planned.

Context Engineering: The Right Information at the Right Time

Context engineering is the work of selecting, organizing, retrieving, and maintaining what an AI agent knows while it works on a task. It covers more than prompt wording. An agent may need architectural decisions, dependency relationships, repository conventions, test results, security findings, deployment history, and operating constraints.

Agent memory and context engineering do different jobs. Memory stores what might be useful across sessions. Context engineering decides what goes in front of the agent for the current task. A large memory store does not help when the retrieved material is outdated, contradictory, or irrelevant.

Augment Code measured the effect of retrieval quality in its February 2026 Context Engine MCP benchmark. Its most useful finding concerns model choice: a weaker model with great context (Sonnet with the MCP) can outperform a stronger model with poor context (Opus without it). MCP-enabled runs also needed fewer tool calls and conversation turns.

The test ran 300 Elasticsearch pull requests with three prompts each, 900 attempts in total, scored on correctness, completeness, best practices, code reuse, and unsolicited documentation. Adding the Code Context Engine improved results by 80% for Claude Code, 71% for Cursor, and 30% for Cursor with Composer-1. The original post ran these against Opus 4.5, and Augment's product page now lists the same figures under Opus 4.6.

These are Augment's own results on one codebase. They show that retrieval quality moves agent output, and they do not predict the gain on your repository.

Two Halves of the Problem: Code Context and Delivery Context

A repository shows how code works. It does not show which services are business-critical, which environments receive a change, or what the last deployment did. Agents need both kinds of context.

Code context comes from the Code Context Engine, which Harness brought in with the Augment Code assets it acquired. It indexes a codebase so an agent can find relevant code and its relationships instead of grepping files. Harness's governed software factory post describes it as indexing in real time across 100M+ lines, including commit history and which code is still active. The factory post says generic text embeddings help little on code, because similar-looking code is often unrelated, so the Code Context Engine uses embedding models trained on code structure. It is exposed over MCP, so any compatible agent can use it.

Delivery context comes from the Software Delivery Knowledge Graph, a typed model of how software is built, tested, secured, deployed, and operated. Harness's governed software factory post reports 80+ entity types across CI, CD, security, cost, and runtime, and says an agent question costs about 12K tokens through the graph against 250K+ through raw APIs.

The underlying estimate is in Harness's earlier knowledge graph post. For one question, which pipelines have the highest failure rate across services and vulnerabilities, it gives about 250,000 to 350,000 input tokens and 5+ LLM calls through raw MCP API calls, against about 12,000 tokens and 2 to 3 calls through the graph. It labels the source internal benchmarking and does not describe the method, so read the figures as an order-of-magnitude illustration for one query, not a benchmark.

For how Harness checks the graph's answers, see the validation write-up, which reports 22 of 27 scenarios validated, about 81% coverage. The architecture write-up explains how schemas, synchronization, and declarative queries make those answers repeatable.

Code context explains the change. Delivery context explains its consequences.

What Works Today and What Is Planned

On October 8, 2026, Harness announced the acquisition of Cosmos, the Code Context Engine, and related technology. Cosmos is now the Harness Cosmos Software Factory Agent, which automates engineering work from idea to code. It joins the Harness Autonomous SDLC Platform, where the Software Delivery, Security Testing, Runtime Protection, and Cost Management agents take that code to production and beyond.

What the factory post describes today (published October 13, updated October 19):

A scan flags a critical CVE and starts a Cosmos workflow
An Expert uses the Code Context Engine to find where the vulnerable dependency is imported, then queries the Knowledge Graph for the affected services running in production, their business criticality, and remaining SLO budget
Fixes open as PRs, and reviewers and the Verifier check them
Each merge triggers a pipeline, with OPA policy and approval gates set by the service's risk tier
Continuous Verification watches each deployment, and an audit trail records the path

Connecting the Code Context Engine to the Software Delivery Knowledge Graph is described in the announcement as planned work, so read that two-way link as direction and not as a shipped feature. Harness plans three flows:

Delivery context flows into coding, so testing expectations, security requirements, and deployment constraints inform a change before it is written
Codebase understanding flows into delivery, so the Harness agents can make better decisions about dependencies, risk, and the validation a change needs
Findings from review, testing, security checks, and deployment verification flow back to the engineering workflow with the evidence needed to correct and revalidate the change

The practical reading: an agent can use both kinds of context in one workflow today, and the tighter two-way connection between them is the part still being built.

The Agent Harness: Context, Execution, Governance

In this post, the agent harness is the architecture around a coding agent that makes autonomous work dependable. It has three layers:

Context gives agents the codebase, delivery, and runtime information they need to understand the task
Execution coordinates agents and tools to plan, implement, review, test, and deliver a change through repeatable workflows
Governance enforces access controls, security policies, approvals, and audit trails so autonomous work stays inside agreed limits

The Harness agents supply the governance layer. An agent's recommendation grants no permission to deploy: policy as code, RBAC, approval gates, continuous verification, and rollback decide what proceeds. In the governed software factory design, pipeline work runs on Delegates inside the customer's own network, and a Zero Trust Service checks every task before it runs. Shell scripts are parsed into an AST and checked against a command allowlist, container images against a registry allowlist, and each step against the resolved pipeline YAML. The service fails closed, so nothing executes if it is unreachable.

AI code review and governed pipelines answer different questions. Review tells you whether a diff looks correct. A governed pipeline decides whether the change may ship and checks how it behaved once it did.

One CVE, One Context Loop

A critical CVE in a shared library shows how the two kinds of context combine. The steps follow the flow Harness describes in its governed software factory post.

The diagram shows four stages, and steps 5 and 6 below are the return path through the Knowledge Graph. Solid arrows show a change moving to production and its results landing in the Software Delivery Knowledge Graph. The dashed arrow is the planned link that lets delivery context inform the next change.

Scope in code. The Security Testing Agent's scan names the dependency and the vulnerable version. An Expert uses the Code Context Engine to find where the dependency is imported, which functions call it, and which tests cover it.
Scope in production. The Software Delivery Knowledge Graph shows which affected services run in production, which are business-critical, and how much SLO budget each has left. The same library in an internal utility and in a customer-facing authentication service gets different priority.
Fix and review. Agents propose the upgrade, update code and tests, and open a pull request in each affected repository. Reviewers and the Verifier check correctness, security, and maintainability.
Gate. The Software Delivery Agent's pipeline applies policy and approval gates by the service's risk tier. A change that fails a mandatory check does not proceed.
Verify in production. Continuous Verification compares each deployment with a baseline captured when the deployment starts. If behavior deviates, the pipeline rolls the deployment back with the anomalous metrics and logs attached as evidence.
Learn (planned). Failed checks, deployment results, and runtime findings should become inputs to the next change. Harness's announcement names returning that evidence directly to the engineering workflow as its next step.

The loop reads detect, understand, fix, verify, deliver, learn. Governance decides which steps run without a person. The same pattern applies to a failed deployment, a regression, or a recurring incident.

What the Pieces Look Like in Practice

One small example per layer. The first two come from the vendors' docs. The third was tested locally.

Context. Add the Context Engine to Claude Code over MCP in local mode (Augment's quickstart):

npm install -g @augmentcode/auggie@latest

auggie login

claude mcp add-json auggie --scope user '{"type":"stdio","command":"auggie","args":["--mcp","--mcp-auto-workspace"]}'

For CI and other non-interactive environments, the quickstart adds an env block with AUGMENT_SESSION_AUTH, set from the output of auggie token print.

Delivery context. The Knowledge Graph takes questions in plain language. Harness's docs give examples such as "Which production deployments of payment-api failed policy evaluation during the last seven days?" For structured queries, the Harness CLI runs HQL:

harness execute hql:run --query 'find entity "platform:project" | select { * } | limit 10'

Entity names for deployments and policy evaluations come from hql:grammar.

Governance. This policy denies any deployment stage that has no approval step, so a change an agent wrote cannot reach an environment without a person signing off. It follows the pattern in Harness's Policy as Code quickstart:

package pipeline

deny[msg] {
  input.pipeline.stages[i].stage.type == "Deployment"
  not stages_with_approval[i]
  msg := sprintf("Deployment stage '%s' has no HarnessApproval step", [input.pipeline.stages[i].stage.name])
}

stages_with_approval[i] {
  input.pipeline.stages[i].stage.spec.execution.steps[_].step.type == "HarnessApproval"
}

Add it to a Policy Set on the Pipeline entity, evaluated On Run, with Error and exit as the failure behavior. Against a pipeline whose deployment stage has only a ShellScript step, it returns the deny message. With a HarnessApproval step added to that stage, it returns an empty list. We checked both cases with OPA 0.70.

What Teams Should Evaluate Before Trusting an Agent

A coding agent can produce a plausible patch without understanding production risk. A pipeline can report success without proving the application meets its operating goals. An incident agent can propose a root cause from a correlation. Each gap comes from missing context or missing verification, and a stronger model alone closes neither.

A dependable autonomous workflow answers three questions:

Can the agent understand the situation? It needs current code and delivery context.
Can it act within boundaries? Permissions, policies, and approval rules limit what it may do.
Can the organization verify the outcome? Tests, deployment checks, runtime signals, and audit trails supply the evidence.

The risk tier decides how much autonomy a change gets. In the Cosmos design, a low-risk PR can be routed to policy-gated auto-approval, and a higher-risk one waits for a person. Auto-approval can be widened one class of change at a time.

The factory post has the exact auto-approval rules and the Cosmos team's own merge and revert numbers. Those are internal, vendor-reported figures, so read them with that in mind. Judge an AI coding agent by more than how fast it produces a patch. Ask whether it can:

Retrieve the architectural and repository context a change touches
Identify the services and dependencies a change affects
Use security and delivery evidence to prioritize work
Operate inside explicit permissions and policy boundaries
Produce changes that can be tested, reviewed, and traced
Use verification outcomes to improve later work

A strong model, a large context window, and specialized agents cover only part of the problem. The rest is an architecture that connects context, execution, governance, and evidence across the SDLC.

Where to Start

Cosmos is available now. Pick one workflow, such as turning a ticket into a reviewed pull request, and run it against the delivery pipeline you already have. The Harness agents take a change to production, whichever coding tools wrote it, and the Harness Developer Hub covers the delivery side.

To try the Context Engine with your own agent, Augment's February 2026 post describes two MCP modes. Local mode runs the Auggie CLI as an MCP server and suits active development. Remote mode connects to a hosted MCP for context across all your repositories. Setup is in Augment's MCP docs.

I Turned My Claude Code History Into an SAO-Style Floating Castle

Animesh Pathak — Sun, 24 May 2026 09:53:55 +0000

A few weeks ago, I was trying to find an old Claude Code session where I had built a small automation script.

I remembered the idea.
I remembered the project.
I even remembered the vibe of that late-night debugging session.

But finding it? Impossible.

Just endless chat history. That’s when I had a stupid but fun idea:

What if my chats looked like Sword Art Online’s Aincrad instead of a sidebar?

And somehow… that turned into a real thing.

So What Is This?

I built a custom Claude Code skill that converts my latest 20 sessions into a floating anime-style castle.

Every session becomes a floor. The newest chat becomes the top “boss floor.” Older conversations sit lower in the tower like the earlier levels of Aincrad. But the best part is this:

The floors don’t look random. They change depending on what I created during that session.
- If I worked mostly on Python scripts, the floor becomes this darker tech-dungeon style area.
- If I created presentations, the floor feels more like a glowing crystal hall.

Documentation-heavy sessions become giant archive-style floors filled with “scroll” vibes. It honestly started feeling less like chat history and more like walking through old projects.

The Moment It Started Feeling Cool

The first time I opened the tower, I clicked one of the upper floors and immediately recognized the session.

Not because of the title. Because of the atmosphere. That floor had:

database migration scripts
markdown docs
pipeline files

and the whole thing looked like some underground engineering archive.

Another floor had slide decks and diagrams, so it looked brighter and more polished.

Without even reading much, I already knew what kind of work I had done there.

That’s when I realized this was actually useful.

How It Works?

The whole thing runs from a single Python script. The script scans Claude Code session files stored locally:

~/.claude/projects/*/*.jsonl

Those files already contain everything:

prompts
messages
tool calls
edited files
generated resources

So instead of using AI guesses, the script reads actual session activity. It checks for tools like:

Write
Edit
MultiEdit
NotebookEdit

and collects the files created during the conversation.

That’s how it figures out the “theme” of each floor.

A session with lots of .py files feels different from one full of .pptx or .md files.

The Castle UI Was the Hardest Part

At first, the output looked boring. Just stacked cards.

It worked, but it didn’t feel like Aincrad. So I rebuilt the entire UI around a floating castle image.

Now the castle sits in the center of the screen with glowing floor markers connected by animated paths.

Clicking a floor opens a smooth SAO-style side panel with:

session details
created files
project info
animations
floor transitions

Even keyboard navigation works. Arrow keys move between floors like climbing the tower. That small detail made it feel surprisingly immersive.

One Unexpected Thing I Loved

Some sessions had no files at all.Just thinking, planning, or debugging discussions.
Instead of forcing themes onto them, I turned those into peaceful “safe-zone” floors. Almost like rest areas inside the castle.

That tiny design choice ended up making the whole thing feel more human. Not every session needs to be productive chaos. Some are just thinking spaces.

The Funniest Part

The current conversation became the newest boss floor automatically.

So while building the system… the system was already adding itself into the castle.

That felt very SAO somehow.

Performance Was Wild

I also tested what happens without the custom skill. Claude could still build a tower from scratch… but it took several minutes and massive token usage.

With the skill, the whole thing builds almost instantly because the logic is already structured.

The difference was huge. It went from:
“generate everything manually”
to:
“load my world.”

Why I Think This Matters

This project made me realize something important. AI chats are slowly becoming our real creative workspace.

We:

write code there
design systems there
build presentations there
brainstorm products there
debug production issues there

But the interfaces still treat everything like disposable messages.

That feels wrong.

I think AI workspaces should feel alive.

More visual.
More personal.
More memorable.

This project was my weird anime-inspired attempt at that idea.

Final Thoughts

I originally built this just because I thought it would look cool.

But now I genuinely use it. Sometimes I open the tower just to remember what I worked on during the week.

And honestly?

Seeing your projects as floors inside a floating castle is way more fun than scrolling through old chat tabs.

If you use Claude Code a lot, try building weird personal tools like this. Those are usually the projects that end up teaching you the most.

How diffChangelog and Snapshots Work Together

Animesh Pathak — Thu, 12 Feb 2026 04:01:24 +0000

When I started formalizing Database DevOps practices, one recurring issue kept surfacing: schema drift.

Development was ahead of staging. Production had emergency hotfixes. QA sometimes had “just one small tweak” that never made it back to version control. Keeping schemas aligned across environments wasn’t just operational hygiene, it became foundational for reliability.

That’s where Liquibase OSS and specifically diffChangelog became a core part of my schema syncing strategy.

This article explains two things:

How I use diffChangelog for database schema synchronization
How it actually works internally using snapshots

Because understanding the mechanics changes how confidently you automate it.

The Schema Sync Problem

In practice, schema syncing usually looks like one of these scenarios:

Dev schema contains new tables not yet in staging
Production has an index created manually during incident mitigation
A column datatype differs across environments
Constraints exist in one environment but not another

Traditional approaches involve manual inspection or ad-hoc SQL comparison scripts. Both are error-prone. With Liquibase OSS, I approach this differently. Instead of comparing raw SQL, I compare database states.

The Command That Powers Schema Sync

Here’s the command I typically use:

liquibase diffChangelog \
  --referenceUrl=jdbc:postgresql://localhost:5432/dev \
  --url=jdbc:postgresql://localhost:5432/prod \
  --changeLogFile=schema-sync.xml

Conceptually:

Reference database → Desired schema
Target database → Actual schema
Output → ChangeLog needed to align target with reference

But what’s happening under the hood?

How diffChangelog Actually Works?

The power of diffChangelog lies in Liquibase’s snapshot engine. It does not compare SQL files. It does not parse DDL text. Instead, it performs a structured, object-level comparison.

Step 1: Snapshot Creation

Liquibase generates a snapshot of each database. A snapshot is an in-memory representation of schema metadata. This includes:

Schemas
Tables
Columns
Indexes
Primary keys
Foreign keys
Unique constraints
Sequences
Views
Data types

Here’s the lifecycle:

flowchart TD
    A[Reference Database] --> B[Snapshot Generator]
    C[Target Database] --> D[Snapshot Generator]
    B --> E[Reference Snapshot Object]
    D --> F[Target Snapshot Object]

Liquibase queries database metadata (e.g., information_schema in PostgreSQL) and converts it into structured objects. Instead of raw SQL text, it now has two object graphs representing each schema.

Step 2: Object Graph Comparison

Once both snapshots are built, Liquibase runs its diff engine.

flowchart TD
    E[Reference Snapshot] --> G[Diff Engine]
    F[Target Snapshot] --> G
    G --> H[Difference Classification]

Differences are categorized as:

Missing → Exists in reference, not in target
Unexpected → Exists in target, not in reference
Changed → Exists in both but attributes differ

For example:

A table in dev but not prod → Missing
An index in prod but not dev → Unexpected
Column length differs → Changed

This classification becomes the foundation for changelog generation.

Step 3: ChangeLog Generation

Liquibase then converts differences into changeSets.

flowchart TD
    H[Difference Classification] --> I[ChangeLog Generator]
    I --> J[Generated ChangeLog File]

Example outputs:

If a table is missing:

<createTable tableName="orders">
   ...
</createTable>

If a datatype changed:

<modifyDataType tableName="users" columnName="email" newDataType="varchar(255)"/>

The result is a deployable changelog that synchronizes the target schema.

How I Use This for Schema Syncing?

Understanding the internal mechanics allows me to apply it confidently in real workflows.

1. Environment Alignment (Dev → Staging → Prod)

When dev is the source of truth:

flowchart LR
    A[Dev Schema] --> B[Snapshot]
    C[Prod Schema] --> D[Snapshot]
    B --> E[Diff Engine]
    D --> E
    E --> F[Sync ChangeLog]
    F --> G[Apply to Prod]

This ensures production moves forward predictably.

2. Drift Detection in CI

I often run diffChangelog during CI to detect unauthorized drift :

Deploy known changelog to temp DB
Snapshot production
Compare
Fail pipeline if differences exist

flowchart TD
    A[Git Controlled Schema] --> B[Temp DB]
    C[Production DB] --> D[Snapshot]
    B --> E[Snapshot]
    D --> F[Diff Engine]
    E --> F
    F --> G{Drift Detected?}
    G -->|Yes| H[Fail Build]
    G -->|No| I[Continue]

This gives me governance without slowing velocity.

3. Legacy Database Onboarding

For existing systems not yet version-controlled:

Snapshot production
Generate baseline changelog
Commit to Git
Transition into controlled migration model

diffChangelog becomes a bridge between unmanaged and managed schemas.

Important Practical Lessons

Over time, I’ve learned several nuances.

Snapshot Scope Matters

For large schemas, snapshot generation can be heavy. I use filters like:

--schemas=public
--includeObjects=table:users,index:users_email_idx

This keeps comparisons focused and performant.

Not Every Difference Should Be Deployed

Auto-generated constraint names can differ across environments. Index naming strategies may vary. I always review generated changeLogs before applying them. Schema syncing is powerful but it must be deliberate.

Snapshots Enable Determinism

The biggest realization for me was this - “diffChangelog is not comparing SQL text”. It is comparing structured schema models. That abstraction layer is what makes:

Cross-database comparison possible
CI automation reliable
Drift detection accurate
Schema syncing deterministic

Without snapshots, diffing would be brittle and vendor-specific.

Why This Matters in Database DevOps?

Schema syncing is not just about keeping environments tidy. It enables:

Predictable deployments
Audit traceability
Reduced incident risk
Environment parity
Controlled rollback strategies

Liquibase OSS gives me:

Snapshot generation
Object-level diffing
ChangeLog generation
Automated synchronization

All without requiring enterprise extensions.

Final Thoughts

When I think about database schema syncing today, I no longer see it as a manual reconciliation process. I see it as:

Snapshot state
Compare object graphs
Generate delta
Apply controlled synchronization

diffChangelog, powered by snapshots, turns schema comparison into a structured, automatable workflow. And once I understood how it works internally, I stopped treating it as a convenience command and started treating it as a foundational component of my Database DevOps architecture.

Observability for Databases in CI/CD

Animesh Pathak — Mon, 08 Sep 2025 09:36:44 +0000

When organizations think about continuous integration and continuous delivery (CI/CD), the focus often centers on application code: unit tests, build pipelines, automated deployments, and monitoring for microservices. But there’s a blind spot that frequently gets overlooked - “the database.”

Databases aren’t just another service; they are the backbone of modern applications. A schema change, performance regression, or even a small migration error can bring an entire release to a halt. This is why observability for databases in CI/CD pipelines has become critical, though it often remains under-prioritized.

In this blog, we’ll explore why observability matters for databases, what unique challenges it presents, and how teams can begin embedding observability into their database delivery workflows.

Why Observability Matters for Databases ?

When we think about observability in modern engineering, it often conjures up images of dashboards filled with service metrics, traces, and logs. But databases demand a different lens. They are stateful systems, deeply intertwined with application logic, and they evolve in ways that are more delicate and often riskier than application code itself.

A typical software deployment can be rolled back with relative ease. If an API misbehaves, the deployment can be reverted, and the system is usually restored quickly. Databases, however, do not follow this forgiving pattern. Schema changes are not simply “versioned” like code; they alter the shape of the data itself. Once an ALTER TABLE or a DROP COLUMN runs in production, undoing it can be slow, painful, and in some cases impossible without a full restore from backups. This makes the stakes of database delivery inherently higher.

Another reason observability matters is performance. Many organizations have faced situations where a release seemed successful, only to discover days later that a single schema tweak had increased query latency across the board. The application monitoring tools might show a spike in response times, but tracing that back to the exact migration can be like finding a needle in a haystack. With proper observability, the connection between “deployment event” and “query performance regression” becomes visible and actionable.

Finally, there’s the matter of speed versus safety. The promise of CI/CD is agility, faster releases, quicker iterations, and reduced time to market. Yet, rushing database deployments without adequate visibility is like driving a car at top speed with no dashboard indicators. You don’t know if you’re running low on fuel, if the engine is overheating, or if a tire is about to burst. Observability provides that feedback loop, enabling teams to move quickly while still protecting data integrity and system reliability.

In short: observability isn’t a “nice to have” for databases; it’s the foundation that makes modern database delivery feasible at scale.

Common Observability Challenges Unique to Databases

Adding observability for databases isn’t as straightforward as reusing traditional APM tools. Databases behave differently than stateless services. Here are a few pain points:

Black Box Migrations – Most teams treat migrations as fire-and-forget scripts. When they fail, root cause analysis is often tedious.
Drift Detection – Environments fall out of sync easily, leading to inconsistencies and unpredictable behavior in production.
Metrics Granularity – Beyond CPU and memory, teams need visibility into query execution times, index usage, and lock contention.
Tooling Fragmentation – Application monitoring stacks rarely integrate cleanly with database-native metrics.

Adding Observability in Database CI/CD Pipelines

So, how do we solve this? The answer lies in shifting observability left side, i.e. adding it into the pipeline rather than treating it as an afterthought.

Pre-Deployment Checks – Validate schema compatibility and dependencies before deploying.
Migration Visibility – Capture execution times, before/after states, and log outputs for every migration. Interestingly, migration strategies themselves can influence observability. For example, whether teams adopt a state-based or script-based model directly impacts how changes are tracked and monitored.
Real-Time Performance Monitoring – Extend existing observability stacks to monitor query latency and slow queries after deployment.
Drift Alerts – Automate schema comparison across environments to catch unapproved changes.
Feedback Loops – Build dashboards for developers and DBAs alike, encouraging shared ownership.

The Payoff: Faster, Safer Releases

By investing in observability, organizations gain:

Confidence in Deployments: Teams know changes are safe before they hit production.
Fewer Firefights: Early detection reduces late-night incidents and downtime.
Shared Responsibility: Observability bridges the gap between DevOps engineers and DBAs.
Better Business Outcomes: Faster releases, less downtime, and improved customer experience.

In other words, observability doesn’t just protect your database; it accelerates your delivery pipeline.

Conclusion

Database DevOps is no longer optional. As organizations adopt trunk-based development and rapid release cycles, databases must keep pace. Observability is the missing piece that ensures every schema change, migration, or deployment is executed with confidence.

Start small: integrate migration visibility, add drift detection, and connect your databases to your observability stack. The sooner you embed observability, the sooner your pipeline becomes both faster and safer.

Smarter Database DevOps with AI: From Changelogs to Intelligent Pipelines

Animesh Pathak — Thu, 04 Sep 2025 10:02:34 +0000

Databases have always been the “final boss” of DevOps. You can automate your CI/CD pipelines all you want, but when it comes to database deployments, teams often slow down. Manual changelogs, risky rollbacks, schema drift sound familiar?
But what if AI could help?
That’s exactly what we’re experimenting with in my side project based on Harness Database DevOps.

Why Databases Lag Behind in DevOps

Unlike application code, database changes are stateful and persistent. If you mess up a deployment, you can’t just roll back by redeploying a container. The cost of errors is high, and the tooling hasn’t always kept up with the speed of modern CI/CD.
Some common pain points:

Writing and maintaining changelogs is tedious.
Keeping environments (dev, staging, prod) in sync is tough.
Rollbacks are not always straightforward.
Drift happens, and often you catch it too late.

Where AI fits in?

This is where AI and intelligent agents come into play. Imagine describing your database change in plain English i.e. “Add a created_at column to the users table” and getting back a production ready changelog file.
Or even better: pasting your existing changelog, and asking the AI to insert new changes in the correct order while preserving history.
Some of the things we’ve been exploring:

AI-generated changelogs: From natural language to YAML/XML/JSON.
Editing existing changelogs: Insert new changesets without breaking old ones.
Environment-specific changes: Generate context-aware migrations for dev, staging, or prod.
Conflict detection: Use AI to flag duplicates or risky changes before deployment. Here’s a sneak peek of the prototype in action 👇

Beyond Changelogs: Towards Intelligent Pipelines

Changelogs are just the start. Once you bring AI into the Database DevOps loop, the possibilities get exciting:

Rollback strategy suggestions → Learn from past patterns to recommend safer rollbacks.
Conversational approvals → Approve or reject deployments via chat with natural language.

This isn’t about replacing DBAs or developers, it’s about giving them better tools, automating the repetitive parts, and reducing the risk of human error.

Try It Out

We’re still experimenting, but you can try the AI Changeset Generator on Hugging Face. And if you’re already deep into Database DevOps, we’d love to hear how you’d want AI to fit into your workflow. Would you trust it to write migrations? Spot drift? Recommend rollbacks?

[Boost]

Animesh Pathak — Wed, 30 Jul 2025 08:34:32 +0000

Animesh Pathak

Jul 30 '25

Why Your Git Branching Strategy Is Breaking Your Database Deployments

#git #database #devops #tooling

2 min read

Why Your Git Branching Strategy Is Breaking Your Database Deployments

Animesh Pathak — Wed, 30 Jul 2025 08:33:41 +0000

As DevOps and GitOps practices evolve, one area remains notoriously fragile: database deployments.

While application delivery has matured with CI/CD, many teams still struggle with schema changes, rollbacks, and environment consistency. One hidden reason? Poor Git branching strategies.

Many teams default to a "branch-per-environment" model (main → dev → qa → prod). It feels logical… until it isn't. Merge conflicts spike. Hotfixes drift. QA stops reflecting production. Your pipeline becomes a patchwork of manual interventions.

This approach creates drift, increases cognitive overhead, and slows down delivery. For stateful systems like databases, that risk multiplies.

Without a clean GitOps model, visibility is lost and rollbacks become nightmares.

🧠 The Better Approach: Trunk-Based GitOps for DBs

Adopt trunk-based development:

One main branch as the source of truth
Use contexts (e.g., dev, qa, prod) to control deployment per environment
Manage environments declaratively via metadata, not folders or branches
Promote via pipeline stages, not Git merges

✅ A Better Way: Trunk-Based GitOps for Databases

Instead of long-lived branches, adopt a trunk-based development model with GitOps principles:

Use a single main branch to track all database changes.
Apply contexts (dev, qa, prod) to control environment targeting.
Promote through environments using pipelines, not merges.
Keep your Git history clean and auditable.

This creates cleaner workflows, simplifies automation, and keeps all environments aligned with the same deployment logic.

🧰 Tools to Make It Work

We’re using this strategy with Harness Database DevOps, which supports:

Liquibase-native changelogs with context-based targeting.
CI/CD pipelines that pull from main and apply changes declaratively.
Rollbacks using rollback blocks, backups, or roll-forward techniques.
Git as the single source of truth.

The result? Database deployments that are safe, scalable, and reproducible.

💡 Conclusion

Avoiding per-environment branching is critical in modern Database DevOps. While it may appear organized at first, this approach often results in drift, merge conflicts, and inconsistent environments over time. Instead of creating separate branches for dev, qa, and prod, consolidate your workflow into a single mainline development branch.

By tagging changelogs with appropriate contexts, you can control where and how changes are applied—without duplicating files or relying on directory structures like /dev or /prod.

Maintaining all database changelogs in a single branch ensures consistency, traceability, and a reliable source of truth. Promotions between environments should be handled through automated pipelines, not Git merges.

Ultimately, embracing GitOps brings visibility, policy enforcement, and rollback control to database workflows. By combining declarative tooling with robust pipeline orchestration, teams can ship database changes as confidently as application code.

What’s Happening Inside Your Linux Kernel?

Animesh Pathak — Sat, 17 May 2025 10:18:06 +0000

Have you ever wondered how exactly your Linux system knows when a program is running, a file system is being mounted, or a new module is being loaded? It’s all happening deep inside the Linux kernel, and most of the time, we’re completely blind to it.

But what if I told you there’s a way to peek inside, without rebooting the system, installing special software, or breaking anything?

Welcome to the world of "kprobes", where you can trace important kernel events in real-time, like a system detective 🕵️‍♂️.

Let’s dive in.

Why Should You Care? 🤔

Let’s say you’re running containers in production. One day, something feels off—a container might be doing something it shouldn’t.

Is it spawning weird processes?
Is it trying to mount a new filesystem?
Is it trying to gain extra privileges?
Is someone loading a sketchy kernel module?

These are early warning signs of something going wrong—maybe a misconfigured app, maybe an attack. Kprobes let you catch these signs early.

What kernel functions we can trace?

Linux is full of functions, but we’ll focus on four powerful ones that reveal a lot about what’s going on:

1. `do_execve`: Process Launch Tracker 🚀

Whenever you run a program like ls, python, or a shell script, the Linux kernel calls a function named do_execve. This function is the gateway to launching any new executable in the system. Why is this important? Because if you're monitoring for suspicious activity, like an unexpected script suddenly running on your server:do_execve is your best friend. It's essentially a signal that something new is being executed. Think of it like someone opening a door and entering a new room in a secure building. Naturally, you’d want to know who just walked in and whether they belong there.

2. `security_capable`: Permission Checkpoint 🛡️

The security_capable function is called whenever a process tries to perform an action that requires special privileges like changing network configurations, modifying system time, or accessing restricted resources. It's a key part of Linux's internal permission checking system. In essence, this function asks: Does this process have the right capabilities? Monitoring this can reveal when processes are trying to act like an admin or escalate privileges. Imagine someone attempting to unlock the admin panel in a web app. Wouldn’t you want to know who they are and whether they should be allowed?

3. `security_sb_mount`: Filesystem Mount Auditor 🗂️

Every time a filesystem is mounted whether it’s an external drive, a virtual filesystem, or a container volume, the security_sb_mount function is called. Mount operations are usually routine, but they can also be exploited to access unauthorized data or escape from container environments. From a security perspective, this function lets you keep tabs on what’s being attached to your system and by whom. Think of it like plugging a USB stick into a laptop. What’s on it? Is it safe? Who’s doing it? eBPF can help you find out.

4. `load_module`: Kernel Code Gatekeeper 🧩

Linux is modular, and the kernel allows dynamic loading of new code modules, like drivers or extensions at runtime. This is managed by the load_module function. While many modules are harmless or necessary, some can introduce vulnerabilities or even backdoors. By tracing load_module, you can detect whenever new kernel code is being added. It’s like someone installing an app on your phone. Is it coming from a trusted source? Should it be there at all? Keeping an eye on this function gives you insight into what’s being added to the core of your OS.

How Do We Trace These Functions?

This is where kprobes come in. Think of kprobes as little spy cameras inside the kernel. You can place them at any function and they’ll quietly record what’s happening.

Here’s how the flow works:

You choose a kernel function, like do_execve.
You set a kprobe on it, which says: “Whenever this function is called, tell me.”
The system logs each call, including key details like PID, UID, and arguments.
You read the trace from a special file: /sys/kernel/debug/tracing/trace_pipe.

💬 Final Thoughts

Think of kernel tracing like having X-ray vision into your Linux system. You don’t need to guess what your containers or processes are doing, you will be able to see it.

Kprobes give you power, visibility, and control especially when something feels off but you don’t know where to start looking.

Ready to try it out? Start small, trace one function, and see what insights pop up. The Linux kernel is full of secrets it’s time to uncover them.

FAQs

1. What is `do_execve`, and why trace it?

The do_execve function is the kernel’s internal handler for the execve system call, responsible for loading a new program into a process’s address space and starting its execution. Tracing do_execve reveals exactly when and how processes are launched, making it invaluable for detecting unauthorized or unexpected binaries running on a system.

2. What does `security_capable` check?

The security_capable function is part of the Linux Security Modules (LSM) framework and is invoked whenever a process requests a privileged capability (e.g., CAP_SYS_ADMIN). Tracing this hook shows when processes attempt actions that require elevated privileges, helping to catch privilege escalations or policy violations.

3. What is `security_sb_mount`, and why is it important?

security_sb_mount is the LSM hook called whenever a filesystem is mounted (including container volumes). Monitoring this function can detect unauthorized mounts—which may indicate container escapes or illicit data access—by reporting details such as device path and filesystem type.

4. How do kprobes attach hooks to kernel functions?

Kprobes dynamically insert breakpoints into almost any kernel routine. You define a probe by writing a line like:

echo 'p:myprobe do_execve' > /sys/kernel/debug/tracing/kprobe_events

This tells the kernel to invoke your handler whenever do_execve runs. The recorded data is then read from /sys/kernel/debug/tracing/trace_pipe for live monitoring.

How to Effectively Vet Your Supply Chain for Optimal Performance

Animesh Pathak — Thu, 15 May 2025 09:09:50 +0000

In today’s world, software projects often rely on many open source libraries. While these libraries speed up development, they can also bring hidden risks if they are not checked carefully. A single unsafe library can compromise an entire project. SafeDep’s vet tool helps you guard your software supply chain by checking every library you use. Below is a detailed, step-by-step guide to understanding, installing, and using vet in your projects. But why is Supply Chain Security matter?

Understanding the Risk of Supply Chain Attacks

A supply chain attack happens when an attacker hides bad code in a library or package that many developers download. When you add that library to your project, the bad code can:

Steal sensitive information
Break parts of your application
Spread malware to users

Beyond Traditional Scanning

Supply chain attacks have surged, leveraging tactics such as malicious code injection, dependency confusion, and typosquatting. Conventional scanners focus narrowly on known CVEs, leaving blind spots in popularity, maintenance status, license compliance, and more. Modern organizations require a holistic solution that codifies and automates risk evaluation across multiple dimensions.

Introducing vet: Policy-Driven Supply Chain Protection

vet transforms security requirements into executable policies using the Common Expression Language (CEL). By treating security guardrails as code, you achieve:

Automated Compliance: Define rules once and enforce them across every build, pull request, and release.
Customizable Risk Tolerance: Craft filters for critical vulnerabilities, unacceptable licenses, low adoption, or missing maintenance.
Extensible Metadata: Leverage OSV vulnerability feeds, popularity metrics, maintenance indicators, extended license attributes, and OpenSSF Scorecards for third-party risk assessment.

Key Features

Capability	Description
Code Analysis & Filtering	Focus on high-impact risks using CEL filters to target critical issues only.
Direct OSV Integration	Pull up-to-date vulnerability data from the OSV ecosystem.
Popularity & Maintenance Checks	Block unvetted or unmaintained packages before they enter your codebase.
License & Compliance Controls	Enforce acceptable license policies automatically.
OpenSSF Scorecard Insights	Incorporate third-party security posture into approval workflows.
Transitive Dependency Coverage	Analyze both direct and transitive components for end-to-end visibility.
Filter Suites	Group multiple CEL filters into a single policy suite for complex guardrails.

Installation and Setup

Getting started with vet is straightforward:

Local CLI Installation

brew tap safedep/tap
brew install safedep/tap/vet

Initial Configuration

Create a policy.yml defining your filter suites:

filter_suites:
  default:
    filters:
      - block_high_severity
      - require_popularity
      - enforce_scorecard

Repository Scan

vet scan -D . --filter-suite default --fail-on-filter

Integrating vet into CI/CD Workflows

Seamless CI/CD integration is critical for “shift-left” security. vet offers native GitHub Action support, enabling policy execution on every pull request, commit, and release:

name: Supply Chain Security

on:
  pull_request:
    paths:
      - '**/*.go'
      - '**/*.js'

jobs:
  vet_scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: safedep/vet-action@v1
        with:
          filter-suite: default
          fail-on-filter: true

Upon policy violation, vet automatically annotates pull requests with inline comments, detailing the failed filters and suggesting remediation steps. For teams using GitLab or Jenkins, vet can be executed via CLI in pipeline stages, with exit codes controlling build success. Furthermore, vet can emit SARIF output, integrating with security dashboards and code scanning interfaces for unified visibility.

Real-World Case Studies

Scenario: A global bank with hundreds of Java microservices sought to harden its supply chain against high-severity vulnerabilities and unmaintained packages.

Baseline Vulnerability Exposure: Prior to vet, the bank’s DevSecOps team found that, on average, 52% of pulled dependencies contained at least one high- or critical-severity CVE.
Policy Implementation:
- Block High-Severity CVEs: dependency.osv.vulnerabilities.any(v | v.severity in ["HIGH","CRITICAL"])
- Maintenance Check: Reject libraries with zero commits or releases in the last 12 months.
Integration: Embedded vet into the GitHub Actions pipeline across 120 repositories, running scans on every pull request.
Results Over Three Months:
- 85% reduction in dependencies with high-severity CVEs
- 70% fewer unmaintained packages entering the codebase, compared to a 30% industry average for mature banking organizations generating SBOMs and enforcing security policies
- Mean Time to Remediation (MTTR) for critical vulnerabilities improved from 72 hours pre-vet to 18 hours, outpacing the 66% of organizations that remediate within a day

Key Takeaways: By codifying high-severity and maintenance policies in CEL and automating enforcement, the bank not only slashed vulnerable dependencies but also accelerated remediation workflows, aligning with top-quartile performance in financial services.

Conclusion

SafeDep’s vet redefines software supply chain security through a policy-as-code approach that integrates seamlessly into development workflows. By consolidating metadata from OSV, OpenSSF Scorecards, popularity and maintenance indicators, and license attributes, vet provides a comprehensive, real-time defense against diverse supply chain threats.

Organizations can codify their security and compliance requirements in CEL filters, enforce them automatically in CI/CD pipelines, and empower developers with immediate, actionable feedback. Embracing vet enables teams to balance innovation and risk, ensuring only secure, compliant open source components advance through their pipelines - ultimately fostering resilient, trustworthy software delivery.

FAQ’s

What policies can I define with vet?

You can express any security or compliance requirement as CEL filters—critical CVEs, banned licenses, low popularity thresholds, end-of-life projects, or OpenSSF Scorecard minima—and group them into reusable filter suites.

How does vet obtain vulnerability data?

vet integrates directly with the OSV ecosystem, pulling the latest vulnerability feeds and mapping them to your dependencies in real time.

Can I scan transitive dependencies?

Yes. vet analyzes both direct and transitive dependencies to ensure end-to-end supply chain visibility and enforcement.

How do I integrate vet into my CI/CD pipeline?

Use the safedep/vet-action for GitHub Actions (or analogous steps for other systems) to run vet scan on every pull request and build, automatically blocking policy violations before code merges.

Is vet extensible to custom metadata sources?

While vet natively supports OSV, popularity, maintenance, license, and OpenSSF Scorecard data, the CEL-based architecture allows you to incorporate additional metadata feeds or internal risk indicators as needed.

References -

Visit SafeDep - https://safedep.io
Explore about SafeDep on GitHub - https://github.com/safedep/vet

How Liquibase Makes Life Easy for DB Admins

Animesh Pathak — Wed, 07 May 2025 06:30:00 +0000

Let’s be honest - managing database changes can sometimes feel like juggling fire. You’ve got multiple developers making updates, environments to manage, rollbacks to worry about, and let’s not forget those late-night “It worked on dev!” surprises.

But guess what? There's a tool that can help you stay ahead of the chaos. It’s called Liquibase, and it's like having a helpful assistant who always remembers what changes were made, who made them, and when. Today, we're going to break it down - what Liquibase is, how it works (especially with YAML), why it's useful, and how it's being used in real projects like mux-sql.

So grab your favourite cup of coffee ☕️, and let’s dive in!

What is Liquibase?

Liquibase is an open-source database change management tool. Think of it as version control, but for your database.

Just like Git helps developers manage changes in their code, Liquibase helps you manage changes in your database schema. It keeps track of all the changes you've made (like adding tables, modifying columns, or creating indexes) and applies them in a controlled, consistent way across different environments - dev, test, staging, production.

And yes, it works with most major databases: MySQL, PostgreSQL, Oracle, SQL Server, and many others.

Why Should You Care?

You might be thinking, “My team already handles DB scripts manually. Why switch?”

Here’s why Liquibase can make your life easier:

No More Manual Scripts: Say goodbye to writing and tracking V1__create_table.sql, V2__add_column.sql, and so on.
Tracks What’s Been Applied: It keeps a changelog and logs every change in a special table (DATABASECHANGELOG) inside your DB.
Works with CI/CD: Automate your DB updates during deployments.
Supports Rollbacks: Made a mistake? You can roll back changes with a command.
Clear Audit Trail: Know who changed what and when.

In short, Liquibase gives you control, clarity, and confidence when managing DB updates.

How Does It Work?

Liquibase works using something called a changelog. This is a file where you define all your database changes using a format like YAML, XML, JSON, or SQL. Each change is grouped into a changeset—a small, trackable unit of change.

Here's an example from the mux-sql app's Liquibase YAML file:

databaseChangeLog:
  - includeAll:
      path: sql
      relativeToChangelogFile: true
  - changeSet:
      id: product-table
      author: claude
      labels: products-api 
      comment: Creating product table for REST API
      changes:
        - createTable:
            tableName: products
            columns:
              - column:
                  name: id
                  type: SERIAL
                  constraints:
                    primaryKey: true
              - column:
                  name: name
                  type: VARCHAR(100)
                  constraints:
                    nullable: false
              - column:
                  name: price
                  type: NUMERIC(10,2)
                  constraints:
                    nullable: false
                  defaultValue: 0.00

This snippet says: “Hey, create a table called users with id, username, and email columns. The id is the primary key and cannot be null.”

Once you run Liquibase, it reads this changelog, checks which changes haven’t been applied yet (based on the DATABASECHANGELOG table), and runs the SQL under the hood to make the changes. Easy, right?

YAML + Liquibase: A Perfect Match made in heaven

Many DBAs are familiar with SQL, but YAML might feel new. Don’t worry - YAML is just a human-readable way to structure data. It’s like writing your changes in plain English.

Why use YAML?

It’s clean and readable.
Great for code reviews.
Less error-prone than long SQL scripts.
Supported natively by Liquibase.

If you’ve ever worked with configuration files in Kubernetes, Docker Compose, or CI tools like GitHub Actions - you’ve already used YAML. You’re ahead of the game!

A Real-World Example: Mux + PostgreSQL

Let’s talk about something real.

The mux-sql project uses Liquibase with a YAML changelog to manage its database schema. It's a backend app built with Go, and like many projects, it needs to manage a growing database as new features are added.

Here’s how they’ve set things up:

They use a liquibase.yml file in the root of their project.
All database changes (like new tables, updates) are defined inside it.
Developers make schema changes by adding new changesets.
When the app is deployed, Liquibase applies only the new changes.
The team doesn’t have to guess what version the database is on—Liquibase handles it.

This approach keeps things clean, consistent, and avoids the “Did we run that script on staging?” drama.

CI/CD and Liquibase = New Power Duo

Now, let’s level up, iIf your team is using a CI/CD pipeline (like GitHub Actions, GitLab CI, or Jenkins), you can run Liquibase automatically whenever you deploy. Imagine this:

A developer creates a new table.
They add a new changeset to the YAML changelog.
They push their code.
Your CI pipeline runs, and Liquibase applies the new schema changes as part of the deploy.

Boom! Database updated, and everyone’s happy. No more hunting down SQL scripts or forgetting to run migrations.

But what About Rollbacks?

Mistakes happen. Maybe a changeset dropped the wrong column. Don’t worry—Liquibase has rollback support.

You can define a rollback inside your changeset like this:

databaseChangeLog:
  - includeAll:
      path: sql
      relativeToChangelogFile: true
  - changeSet:
      id: product-table
      author: claude
      labels: products-api 
      comment: Creating product table for REST API
      changes:
        - createTable:
            tableName: products
            columns:
              - column:
                  name: id
                  type: SERIAL
                  constraints:
                    primaryKey: true
              - column:
                  name: name
                  type: VARCHAR(100)
                  constraints:
                    nullable: false
              - column:
                  name: price
                  type: NUMERIC(10,2)
                  constraints:
                    nullable: false
                  defaultValue: 0.00
      rollback:
        - dropTable:
            tableName: products

Now, if something goes wrong, you can just run:

liquibase rollbackCount 1

And it will undo that change. Peace of mind, built-in.

Best Practices for DB Admins Using Liquibase

Here are a few tips to make the most of Liquibase:

Use descriptive id and author in each changeset helps trace who did what.
Keep changelogs in version control (Git) treat schema as code.
Test locally before pushing changes always!
Use Liquibase commands to validate before applying changes: liquibase validate
Modularize your changelogs if your project gets big. You can include files.

The Learning Curve? Not So Steep!

Some folks might worry that using Liquibase adds complexity. But in practice, it actually reduces complexity. No more guesswork. No more broken SQL files. No more “It worked on my machine.”

Instead, you get:

A single source of truth.
Audit history of every change.
Easy rollbacks and repeatable deploys.

Once you use it on a few projects, it becomes second nature.

Conclusion

Liquibase is like the superhero sidekick you didn’t know you needed. It helps you:

Track database changes.
Apply them in a consistent way.
Roll them back when things go sideways.
Work better with your team and CI/CD pipelines.

If you’re a DB Admin tired of manual SQL chaos, it’s worth giving Liquibase a try. The mux-sql project shows just how clean and simple a YAML-based changelog can be. You’ve already got the skills - Liquibase just helps you use them smarter. So go ahead - set up that liquibase.yml, commit it to Git, and start managing your database like a boss.

❓ FAQs

1. Do I need to know Java to use Liquibase?

Nope! Liquibase is built in Java, but you don’t need to write any Java code to use it. You just need the Java Runtime Environment (JRE) installed to run the Liquibase CLI. Everything else like - YAML, SQL, or XML changelogs is what you already know.

2. Can I use Liquibase with my existing database?

Yes. Liquibase can integrate with an existing database by using the generateChangeLog command to capture the current state. From there, you can start tracking future changes incrementally with changesets.

3. What if I accidentally apply the wrong changeset?

That’s where rollback comes in. If you’ve defined a rollback block inside the changeset, you can undo changes safely using a simple command like:

liquibase rollbackCount 1

Without a defined rollback, you’ll need to handle it manually—but Liquibase will still show you what was applied and when.

4. Can multiple developers work on the same changelog?

Yes, but with structure. Each developer should add their own changesets with unique ids and authors. Keeping changelogs in version control (like Git) and modularizing them with include files helps avoid merge conflicts.

Further Resources

Running WebAssembly with ContainerD + CRUN + WasmEdge

Animesh Pathak — Mon, 21 Apr 2025 11:30:00 +0000

WebAssembly (Wasm) isn’t just for the browser anymore. It’s conquering the cloud too — and if you're feeling adventurous, let's plug it into container runtimes like containerd, run it with crun, and power up workloads in Kubernetes like a boss. Oh, and yes — we'll even touch on KubeVirt to show Wasm's flexibility in a virtualized world.

🛠️ Step 1: Install WasmEdge (The Wasm Runtime Hero)

Let’s kick things off by installing WasmEdge — a blazing-fast Wasm runtime optimized for cloud-native.

curl -sSf https://raw.githubusercontent.com/WasmEdge/WasmEdge/master/utils/install.sh | bash
source $HOME/.wasmedge/env

✅ Verify Installation

wasmedge --version

Expected output:

wasmedge version 0.13.5

Now that you’re equipped with Wasm superpowers, let’s bring in the container orchestration party.

🧱 Step 2: Set Up ContainerD, CRUN, and Kubernetes

One-liner to install everything you need:

wget -qO- https://raw.githubusercontent.com/sonichigo/wasmedge-demo-example/main/install.sh | bash

This script handles:

Installing containerd
Configuring crun as the runtime
Patching containerd for Wasm support
Setting up a local Kubernetes cluster

Expected terminal logs include:

> Installing ContainerD and CRUN
<==============================>
...
Local Kubernetes cluster is running. Press Ctrl-C to shut it down.

Boom. That’s your Wasm-ready k8s cluster firing up 🎉

☁️ Step 3: Run a Wasm Container in Kubernetes

Switch into Kubernetes source and set up your config:

cd kubernetes && git checkout v1.22.4

export KUBERNETES_PROVIDER=local

sudo cluster/kubectl.sh config set-cluster local --server=https://localhost:6443 --certificate-authority=/var/run/kubernetes/server-ca.crt
sudo cluster/kubectl.sh config set-credentials myself --client-key=/var/run/kubernetes/client-admin.key --client-certificate=/var/run/kubernetes/client-admin.crt
sudo cluster/kubectl.sh config set-context local --cluster=local --user=myself
sudo cluster/kubectl.sh

Check cluster status:

sudo cluster/kubectl.sh cluster-info

You should see your cluster nodes happily registered.

🌐 Step 4: Deploy a WebAssembly HTTP Service

Time to run a Wasm image in the cluster!

sudo cluster/kubectl.sh run --restart=Never http-server \
  --image=wasmedge/example-wasi-http:latest \
  --annotations="module.wasm.image/variant=compat-smart" \
  --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork": true}}'

Then hit it with:

curl -d "name=WasmEdge" -X POST http://127.0.0.1:1234

Expected output:

echo: name=WasmEdge

🥳 Success! You just ran a Wasm container natively in Kubernetes.

🧪 Bonus: Run This on KubeVirt!

Want to get even fancier? Try this in a KubeVirt virtualized environment. Since KubeVirt can run Kubernetes inside virtual machines, you can embed this Wasm-ready containerd setup inside those VMs — making it super versatile for hybrid environments and edge deployments.

Steps are similar, but inside a KubeVirt VM with Ubuntu or Fedora base image. After that, follow this same guide within that VM and enjoy full Wasm-k8s magic, powered by KubeVirt's virtualization layer.

3 Ways to Run WASM with OCI & Container Runtimes

There’s more than one way to cook this goose. Here's a breakdown of the 3 main approaches:

🧩 With `containerd-shim` (runwasi)

Detects Wasm images via target platform (wasm32)
Uses runwasi for Wasm, runc for regular containers
Backed by Docker, Microsoft
Powering Docker+WASM preview releases

⚙️ Option #2: With `crun`

A C-based OCI runtime (from Red Hat)
Detects Wasm via annotations (module.wasm.image/variant)
Supports full k8s stack: CRI-O, containerd, Podman, kind, microk8s

🦀 Option #3: With `youki`

A Rust-based OCI runtime
Also annotation-based detection
Can power CRI-O, containerd, Podman, kind, microk8s, and k8s

All of these can be visualized via their respective integration diagrams — worth including one if you're making this into a slide deck or dev talk!

🔚 Final Thoughts

WebAssembly isn’t the future - it’s the present. With WasmEdge, CRUN, and Kubernetes (even in KubeVirt), we now have the flexibility to run lightweight, fast, and secure applications anywhere. Whether you're targeting the cloud, the edge, or somewhere in between — you’re set up for success.

FAQs

1. Why use Wasm instead of Linux containers?

Wasm provides faster startup, smaller size, and better isolation — ideal for microservices and edge computing.

2. Do I need to change my Kubernetes setup to run Wasm?

Nope! With runtimes like crun or youki and proper annotations, it plugs right into your existing Kubernetes flow.

3. What languages can I use to build Wasm apps?

Rust, Go (with TinyGo), C/C++, Python (via Pyodide), and even JavaScript!

4. Can I run Wasm apps alongside Linux containers?

Yes, mixed workloads are totally supported — just annotate your Wasm images and the runtime handles the rest.

5. How does this differ from running containers in Docker?

Docker (via containerd) supports Wasm via runwasi, but this approach goes deeper into Kubernetes and custom runtime integrations using crun/youki.

🔥 Google Launches Firebase Studio: A New Era for AI App Development

Animesh Pathak — Fri, 11 Apr 2025 10:11:18 +0000

Google has just introduced Firebase Studio, a revolutionary cloud-based development environment tailored for building full-stack AI applications. This new toolset seamlessly integrates with Firebase services and leverages Gemini AI, creating a smart, collaborative, and agentic workspace for developers, all accessible via the cloud.

🚀 What’s Firebase Studio All About?

Firebase Studio reimagines the development workflow, combining AI-driven tools with a visual interface to make app building faster, smarter, and more collaborative. Whether you're prototyping ideas or deploying production-ready apps, Firebase Studio covers it all - no switching between multiple platforms or environments.

🔑 Key Features at a Glance

Multimodal Prototyping: Build app prototypes using natural language, images, and even hand-drawn sketches. This makes it incredibly easy for developers to bring ideas to life, especially during early-stage brainstorming and MVP creation.
AI-Powered Development: Refine your application in real-time with an integrated AI assistant. The Gemini-powered chat experience helps you iterate quickly, answer questions, suggest code, and improve UX—all within the Studio.
Seamless Code + Visual Workflow: Firebase Studio bridges the gap between visual prototyping and hands-on coding. Developers can dive into code whenever needed without disrupting the visual flow—perfect for teams with diverse skill sets.
Live Preview on Multiple Devices: Preview your app across different screen sizes and devices instantly. This ensures responsiveness and design consistency from the get-go.
Effortless Deployment: Once your app is ready, publish it with a click using Firebase App Hosting. The integration cuts down manual steps and gets your product to users faster.
Built-in Real-Time Collaboration: Work on the same project with teammates in real-time. Whether it's pair programming, design reviews, or debugging, Firebase Studio supports seamless collaboration.

💡 Why It Matters

Firebase Studio isn't just another development tool—it’s a leap toward making AI app development more accessible and agile. With real-time collaboration, AI support, and end-to-end deployment tools baked in, it simplifies what used to be a fragmented and time-consuming process.

This launch positions Firebase Studio as a must-watch tool for devs working in the AI, startup, and rapid prototyping space. Whether you’re a solo founder, product engineer, or part of a large dev team, Firebase Studio offers a unified platform to build, iterate, and launch smarter.

👉 Ready to try it out?
Check out the official announcement and dive into Firebase Studio here.

DEV Community: Animesh Pathak

Why AI Coding Agents Lose Context After the PR, and How to Keep It

TL;DR

The Context Cliff: What Happens After an AI Agent Opens a PR

Context Engineering: The Right Information at the Right Time

Two Halves of the Problem: Code Context and Delivery Context

What Works Today and What Is Planned

The Agent Harness: Context, Execution, Governance

One CVE, One Context Loop

What the Pieces Look Like in Practice

What Teams Should Evaluate Before Trusting an Agent

Where to Start

I Turned My Claude Code History Into an SAO-Style Floating Castle

So What Is This?

The Moment It Started Feeling Cool

How It Works?

The Castle UI Was the Hardest Part

One Unexpected Thing I Loved

The Funniest Part

Performance Was Wild

Why I Think This Matters

Final Thoughts

How diffChangelog and Snapshots Work Together

The Schema Sync Problem

The Command That Powers Schema Sync

How diffChangelog Actually Works?

Step 1: Snapshot Creation

Step 2: Object Graph Comparison

Step 3: ChangeLog Generation

How I Use This for Schema Syncing?

1. Environment Alignment (Dev → Staging → Prod)

2. Drift Detection in CI

3. Legacy Database Onboarding

Important Practical Lessons

Snapshot Scope Matters

Not Every Difference Should Be Deployed

Snapshots Enable Determinism

Why This Matters in Database DevOps?

Final Thoughts

Observability for Databases in CI/CD

Why Observability Matters for Databases ?

Common Observability Challenges Unique to Databases

Adding Observability in Database CI/CD Pipelines

The Payoff: Faster, Safer Releases

Conclusion

Smarter Database DevOps with AI: From Changelogs to Intelligent Pipelines

Why Databases Lag Behind in DevOps

Where AI fits in?

Beyond Changelogs: Towards Intelligent Pipelines

Try It Out

[Boost]

Why Your Git Branching Strategy Is Breaking Your Database Deployments

Why Your Git Branching Strategy Is Breaking Your Database Deployments

🧠 The Better Approach: Trunk-Based GitOps for DBs

✅ A Better Way: Trunk-Based GitOps for Databases

🧰 Tools to Make It Work

💡 Conclusion

What’s Happening Inside Your Linux Kernel?

Why Should You Care? 🤔

What kernel functions we can trace?

1. do_execve: Process Launch Tracker 🚀

2. security_capable: Permission Checkpoint 🛡️

3. security_sb_mount: Filesystem Mount Auditor 🗂️

4. load_module: Kernel Code Gatekeeper 🧩

How Do We Trace These Functions?

💬 Final Thoughts

FAQs

1. What is do_execve, and why trace it?

2. What does security_capable check?

3. What is security_sb_mount, and why is it important?

4. How do kprobes attach hooks to kernel functions?

How to Effectively Vet Your Supply Chain for Optimal Performance

Understanding the Risk of Supply Chain Attacks

Beyond Traditional Scanning

Introducing vet: Policy-Driven Supply Chain Protection

Key Features

Installation and Setup

Integrating vet into CI/CD Workflows

Real-World Case Studies

Conclusion

1. `do_execve`: Process Launch Tracker 🚀

2. `security_capable`: Permission Checkpoint 🛡️

3. `security_sb_mount`: Filesystem Mount Auditor 🗂️

4. `load_module`: Kernel Code Gatekeeper 🧩

1. What is `do_execve`, and why trace it?

2. What does `security_capable` check?

3. What is `security_sb_mount`, and why is it important?

🧩 With `containerd-shim` (runwasi)

⚙️ Option #2: With `crun`

🦀 Option #3: With `youki`