diff --git a/blogs/2026-07-07-introducing-devops-os-ai-assisted-devops-automation.md b/blogs/2026-07-07-introducing-devops-os-ai-assisted-devops-automation.md
new file mode 100644
index 0000000..8b013ab
--- /dev/null
+++ b/blogs/2026-07-07-introducing-devops-os-ai-assisted-devops-automation.md
@@ -0,0 +1,67 @@
+---
+title: "Introducing DevOps-OS: AI-Assisted DevOps Automation From a Single CLI"
+slug: "introducing-devops-os-ai-assisted-devops-automation"
+description: "DevOps-OS scaffolds production-ready CI/CD pipelines, Kubernetes configs, and SRE dashboards in seconds — from one CLI command or an AI chat prompt."
+topic: "devops-automation"
+tags: ["DevOpsOS", "DevOpsAutomation", "CICD", "PlatformEngineering", "OpenSource"]
+publishedAt: "2026-07-07"
+featured: true
+---
+
+# Introducing DevOps-OS: AI-Assisted DevOps Automation From a Single CLI
+
+Every DevOps team spends the first weeks of a new project doing the same thing: wiring together CI/CD pipelines, Kubernetes manifests, monitoring dashboards, and local development environments. The tooling differs — GitHub Actions, Jenkins, ArgoCD, Prometheus — but the boilerplate is always recognisable.
+
+**DevOps-OS exists to eliminate that boilerplate entirely.**
+
+## What is DevOps-OS?
+
+DevOps-OS is an open-source DevOps automation platform built by [CloudEngine Labs](https://cloudenginelabs.io). It scaffolds production-ready configuration artefacts — CI/CD pipelines, Kubernetes manifests, SRE observability configs, infrastructure hardening baselines, and developer environments — in seconds, from a single CLI command or an AI chat prompt.
+
+```bash
+# Install
+git clone https://github.com/cloudengine-labs/devops_os.git
+cd devops_os
+pip install -r cli/requirements.txt
+
+# Generate a complete GitHub Actions CI/CD pipeline for a Python app
+python -m cli.devopsos scaffold gha --name my-api --languages python --type complete
+# Output: .github/workflows/my-api-complete.yml
+```
+
+That one command produces a fully wired, multi-stage workflow: lint, test, build, Docker push, and Kubernetes deploy.
+
+## The full scaffold surface
+
+| Command | What it generates |
+|---------|-------------------|
+| `scaffold gha` | GitHub Actions workflows (build / test / deploy / complete / reusable) |
+| `scaffold gitlab` | GitLab CI/CD pipeline (`.gitlab-ci.yml`) |
+| `scaffold jenkins` | Jenkinsfile (Declarative Pipeline) |
+| `scaffold argocd` | ArgoCD Application + AppProject, or Flux CD Kustomization |
+| `scaffold sre` | Prometheus alert rules, Grafana dashboard, SLO manifest |
+| `scaffold hardening` | Kyverno policies, InSpec profiles, Checkov checks |
+| `scaffold devcontainer` | `devcontainer.json` for multi-language dev environments |
+| `scaffold unittest` | pytest, Jest, Vitest, Mocha, or Go test configs |
+
+## Use it with AI
+
+DevOps-OS ships with a built-in **MCP (Model Context Protocol) server** that exposes every scaffold tool as a native skill for Claude, ChatGPT, or any MCP-compatible AI assistant.
+
+```bash
+python -m mcp_server.server
+```
+
+Ask your AI assistant: *"Generate a Jenkins pipeline for a Java Spring Boot app with Kubernetes deployment via Kustomize."* It calls DevOps-OS under the hood and hands you a production-ready `Jenkinsfile`.
+
+## Built on Process-First principles
+
+DevOps-OS is not just a code generator. It is built on the **Process-First SDLC philosophy** — the idea that well-defined, repeatable processes must come before tool selection. Every scaffold command encodes a process decision into an immediately usable artefact.
+
+Run `python -m cli.devopsos process-first` in your terminal to explore the philosophy interactively.
+
+## Get started
+
+- GitHub: [cloudengine-labs/devops_os](https://github.com/cloudengine-labs/devops_os)
+- Docs: [cloudengine-labs.github.io/devops_os](https://cloudengine-labs.github.io/devops_os)
+- License: MIT — free for every team
diff --git a/blogs/2026-07-14-process-first-devops-the-philosophy-behind-devops-os.md b/blogs/2026-07-14-process-first-devops-the-philosophy-behind-devops-os.md
new file mode 100644
index 0000000..7becf8f
--- /dev/null
+++ b/blogs/2026-07-14-process-first-devops-the-philosophy-behind-devops-os.md
@@ -0,0 +1,77 @@
+---
+title: "Process-First DevOps: The Philosophy Behind DevOps-OS"
+slug: "process-first-devops-philosophy-behind-devops-os"
+description: "Before you pick a tool, define the process. DevOps-OS is built on the Process-First SDLC philosophy — here is what it means and why it matters for engineering teams."
+topic: "devops-culture"
+tags: ["ProcessFirst", "DevOpsPhilosophy", "SDLC", "DevOpsCulture", "SystemsThinking"]
+publishedAt: "2026-07-14"
+featured: false
+---
+
+# Process-First DevOps: The Philosophy Behind DevOps-OS
+
+> *"Tools are only as good as the processes that govern them."*  
+> — Saravanan Gnanaguru, Founder, CloudEngine Labs
+
+Most teams adopt DevOps in reverse. They buy a tool first — a CI platform, a GitOps operator, an observability stack — and then try to retrofit a process around it. The result is fragile automation that is hard to reason about and even harder to hand off.
+
+**Process-First flips that order.**
+
+## What is Process-First?
+
+Process-First is an engineering philosophy that places well-defined, repeatable SDLC processes at the centre of every engineering decision — before tools, platforms, or frameworks are chosen.
+
+The guiding question is always: **"Do we have the right process before we pick the tool?"**
+
+CloudEngine Labs — the company behind DevOps-OS — is a Process-First SDLC automation company. Every feature in DevOps-OS encodes a process decision first and a configuration artefact second.
+
+## The 5 Core Principles
+
+| # | Principle | In practice |
+|---|-----------|-------------|
+| 1 | **Define before you Build** | Document the why and what of every workflow before writing pipeline code |
+| 2 | **Standardise before you Scale** | Golden-path templates every team can adopt without reinventing the wheel |
+| 3 | **Automate what is Repeatable** | If a process runs more than twice, automate it. Automation should encode the process, not bypass it |
+| 4 | **Observe and Iterate** | Every automated process must produce measurable outcomes — SLOs, error budgets, dashboards |
+| 5 | **Culture over Tooling** | The right culture makes any toolchain succeed; the wrong culture makes the best toolchain fail |
+
+## How these principles map to DevOps-OS commands
+
+| Principle | DevOps-OS command | What it encodes |
+|-----------|-------------------|-----------------|
+| Define before you Build | `scaffold gha / gitlab / jenkins` | Capture intent in an interactive wizard before generating any config |
+| Standardise before Scale | `scaffold gha / gitlab / jenkins` | Golden-path CI/CD templates reviewed by the team |
+| Automate the Repeatable | `scaffold argocd` | GitOps sync process encoded as an ArgoCD Application CR |
+| Automate the Repeatable | `scaffold devcontainer` | Developer environment setup reproducible for every team member |
+| Observe and Iterate | `scaffold sre` | Prometheus + Grafana + SLO manifest closes the measure-improve loop |
+| Culture over Tooling | DevOps-OS MCP server | AI coaches engineers on best practices, not just generates configs |
+
+## Standing on the shoulders of giants
+
+Process-First draws directly from two foundational works:
+
+**Gene Kim, Kevin Behr, and George Spafford** (*The Phoenix Project* / *The DevOps Handbook*) define the **Three Ways of DevOps**. The First Way — Systems Thinking — optimises the performance of the entire system, not a single silo.
+
+**Patrick Debois** (founder of DevOpsDays) showed that cultural and process problems — not technology gaps — are the root cause of slow, unreliable software delivery.
+
+DevOps-OS treats both insights as first-class requirements.
+
+## Try the Process-First CLI command
+
+DevOps-OS ships a built-in `process-first` command so you can explore the philosophy directly in your terminal:
+
+```bash
+# Full overview
+python -m cli.devopsos process-first
+
+# Just the 5 core principles
+python -m cli.devopsos process-first --section what
+
+# Which scaffold command encodes which principle
+python -m cli.devopsos process-first --section mapping
+
+# Best practices by stage: build, test, deploy, sre, security
+python -m cli.devopsos process-first --section best_practices
+```
+
+Process-First is not a certification or a maturity model. It is a mindset: define the process, encode it, observe the outcome, improve. DevOps-OS gives you the tooling to do all four.
diff --git a/blogs/2026-07-21-github-actions-at-scale-with-devops-os.md b/blogs/2026-07-21-github-actions-at-scale-with-devops-os.md
new file mode 100644
index 0000000..28b84c6
--- /dev/null
+++ b/blogs/2026-07-21-github-actions-at-scale-with-devops-os.md
@@ -0,0 +1,101 @@
+---
+title: "GitHub Actions at Scale: Generating Reusable CI/CD Workflows With DevOps-OS"
+slug: "github-actions-at-scale-with-devops-os"
+description: "Stop writing GitHub Actions YAML by hand. DevOps-OS generates complete, reusable CI/CD workflows for any language stack in one command — with Kubernetes support built in."
+topic: "ci-cd"
+tags: ["GitHubActions", "CICD", "DevOpsOS", "PipelineAutomation", "Kubernetes"]
+publishedAt: "2026-07-21"
+featured: false
+---
+
+# GitHub Actions at Scale: Generating Reusable CI/CD Workflows With DevOps-OS
+
+GitHub Actions is powerful — but hand-authoring YAML pipelines for every project is slow, error-prone, and inconsistent across teams. DevOps-OS solves this with a single scaffold command that produces a production-ready, multi-stage workflow tailored to your language stack.
+
+## Generate a workflow in one command
+
+```bash
+# Complete CI/CD pipeline for a Python + JavaScript project
+python -m cli.devopsos scaffold gha \
+  --name my-api \
+  --languages python,javascript \
+  --type complete
+
+# Output: .github/workflows/my-api-complete.yml
+```
+
+The generated workflow includes: dependency caching, lint, unit tests, Docker image build and push, and a Kubernetes deploy stage.
+
+## Workflow types
+
+| Type | What it produces |
+|------|-----------------|
+| `build` | Build and package only |
+| `test` | Test and code-quality gates only |
+| `deploy` | Deploy to Kubernetes only |
+| `complete` | Full build → test → deploy pipeline |
+| `reusable` | A workflow callable from other workflows across repositories |
+
+## Multi-language matrix builds
+
+Covering multiple language versions across operating systems is one command away:
+
+```bash
+python -m cli.devopsos scaffold gha \
+  --name cross-platform \
+  --languages go \
+  --matrix
+```
+
+The `--matrix` flag generates a strategy block that runs your workflow across Ubuntu, macOS, and Windows with the language version combinations you choose.
+
+## Kubernetes deployment — four methods supported
+
+```bash
+# Direct kubectl apply
+python -m cli.devopsos scaffold gha --name my-app --kubernetes --k8s-method kubectl
+
+# Kustomize overlay-based deploy
+python -m cli.devopsos scaffold gha --name my-app --kubernetes --k8s-method kustomize
+
+# GitOps via ArgoCD App sync trigger
+python -m cli.devopsos scaffold gha --name my-app --kubernetes --k8s-method argocd
+
+# GitOps via Flux CD image update
+python -m cli.devopsos scaffold gha --name my-app --kubernetes --k8s-method flux
+```
+
+## Reusable workflows for platform teams
+
+Platform teams maintaining pipelines for dozens of microservices benefit most from the `reusable` workflow type. Generate a shared caller template once, then reference it from every service repo:
+
+```bash
+python -m cli.devopsos scaffold gha --name shared-pipeline --type reusable
+```
+
+The generated workflow accepts `inputs:` for languages, environment, and deploy target — so each service repo calls the shared pipeline with a 10-line caller file instead of duplicating 200 lines of YAML.
+
+## Consistent dev-to-CI parity
+
+DevOps-OS integrates with `devcontainer.env.json` — the same file that drives your local dev container — to keep your CI environment aligned with local development:
+
+```bash
+python -m cli.devopsos scaffold gha --env-file .devcontainer/devcontainer.env.json --name my-app
+```
+
+The scaffold reads your declared language versions, CI tools, and Kubernetes preferences and wires them directly into the generated workflow.
+
+## All options
+
+| Option | Default | Description |
+|--------|---------|-------------|
+| `--name` | `DevOps-OS` | Workflow name |
+| `--type` | `complete` | `build` · `test` · `deploy` · `complete` · `reusable` |
+| `--languages` | `python,javascript` | Comma-separated language list |
+| `--kubernetes` | off | Add K8s deploy stage |
+| `--k8s-method` | `kubectl` | `kubectl` · `kustomize` · `argocd` · `flux` |
+| `--matrix` | off | Matrix strategy across OS + language versions |
+| `--reusable` | off | Generate a reusable/callable workflow |
+| `--output` | `.github/workflows` | Output directory |
+
+Use `python -m cli.devopsos scaffold gha --help` to see all options.
diff --git a/blogs/2026-07-28-gitops-argocd-flux-scaffolding-with-devops-os.md b/blogs/2026-07-28-gitops-argocd-flux-scaffolding-with-devops-os.md
new file mode 100644
index 0000000..b2489bc
--- /dev/null
+++ b/blogs/2026-07-28-gitops-argocd-flux-scaffolding-with-devops-os.md
@@ -0,0 +1,95 @@
+---
+title: "GitOps in Minutes: Scaffolding ArgoCD and Flux CD Configs With DevOps-OS"
+slug: "gitops-argocd-flux-scaffolding-with-devops-os"
+description: "DevOps-OS generates complete ArgoCD Application + AppProject manifests and Flux CD Kustomizations from one CLI command — no YAML editing required."
+topic: "gitops"
+tags: ["GitOps", "ArgoCD", "FluxCD", "Kubernetes", "DevOpsOS"]
+publishedAt: "2026-07-28"
+featured: false
+---
+
+# GitOps in Minutes: Scaffolding ArgoCD and Flux CD Configs With DevOps-OS
+
+GitOps is the gold standard for Kubernetes delivery — every change to a cluster flows through a Git commit, making deployments auditable, reviewable, and reversible. But setting up ArgoCD or Flux CD for the first time involves a non-trivial amount of YAML boilerplate. DevOps-OS removes that friction.
+
+## The Process-First take on GitOps
+
+Before touching any YAML, define your deployment process:
+
+- What is the Git source of truth for your manifests?
+- Which namespace and cluster does each application target?
+- Who can approve changes to production?
+- How does the system handle image tag updates automatically?
+
+Only once those questions are answered does a `scaffold argocd` command produce a configuration that reflects your actual intentions rather than a generic template you have to heavily edit.
+
+## Generate ArgoCD configs
+
+```bash
+# ArgoCD Application + AppProject for a service
+python -m cli.devopsos scaffold argocd \
+  --name payment-service \
+  --repo https://github.com/myorg/payment-service.git
+
+# Output:
+#   argocd/application.yaml
+#   argocd/appproject.yaml
+```
+
+The generated `application.yaml` wires the repository, target revision, destination cluster, and sync policy. The `appproject.yaml` scopes the project to the correct namespace and source repo.
+
+## Generate Flux CD configs
+
+```bash
+# Flux CD GitRepository + Kustomization + ImageUpdateAutomation
+python -m cli.devopsos scaffold argocd \
+  --name payment-service \
+  --method flux \
+  --repo https://github.com/myorg/payment-service.git
+
+# Output:
+#   flux/git-repository.yaml
+#   flux/kustomization.yaml
+#   flux/image-update-automation.yaml
+```
+
+Flux's `ImageUpdateAutomation` file is included by default — it keeps your Kubernetes manifests in sync with the latest image tag pushed to your container registry.
+
+## Combine GitOps with your CI pipeline
+
+DevOps-OS lets you wire GitOps delivery directly into a GitHub Actions pipeline:
+
+```bash
+python -m cli.devopsos scaffold gha \
+  --name payment-service \
+  --kubernetes \
+  --k8s-method argocd
+```
+
+The generated workflow includes an ArgoCD sync step that triggers an application sync after a successful build and image push — closing the loop from commit to production.
+
+## Why GitOps changes incident response
+
+When every production change flows through Git:
+
+1. **Who changed it?** → `git log`
+2. **What changed?** → `git diff`
+3. **Why did it change?** → commit message + linked PR
+4. **How do I roll back?** → `git revert` + sync
+
+No more SSH-ing into production nodes and running `kubectl apply` from a laptop. The GitOps operator reconciles the declared state continuously.
+
+## Cluster topology tip
+
+Use separate ArgoCD `AppProject` resources per environment (dev, staging, production). DevOps-OS generates one project per scaffold run, so you get environment isolation without duplicating application definitions.
+
+```bash
+python -m cli.devopsos scaffold argocd --name payment-service --repo ... # dev project
+python -m cli.devopsos scaffold argocd --name payment-service-prod --repo ... # prod project
+```
+
+## Next steps
+
+- Combine `scaffold argocd` with `scaffold hardening` to enforce Kyverno policies on every sync
+- Use `scaffold sre` to generate the Grafana dashboard that monitors ArgoCD sync health
+- Add the Flux `image-update-automation.yaml` to your GitOps repository to enable automatic image tag promotions
diff --git a/blogs/2026-08-04-sre-bootstrap-prometheus-grafana-slo-with-devops-os.md b/blogs/2026-08-04-sre-bootstrap-prometheus-grafana-slo-with-devops-os.md
new file mode 100644
index 0000000..d808c76
--- /dev/null
+++ b/blogs/2026-08-04-sre-bootstrap-prometheus-grafana-slo-with-devops-os.md
@@ -0,0 +1,103 @@
+---
+title: "SRE Bootstrap: Prometheus, Grafana, and SLOs in Minutes With DevOps-OS"
+slug: "sre-bootstrap-prometheus-grafana-slo-with-devops-os"
+description: "DevOps-OS generates a complete SRE observability stack — Prometheus alert rules, Grafana dashboard, and SLO manifest — from one scaffold command."
+topic: "sre-observability"
+tags: ["SRE", "Prometheus", "Grafana", "SLO", "Observability", "DevOpsOS"]
+publishedAt: "2026-08-04"
+featured: false
+---
+
+# SRE Bootstrap: Prometheus, Grafana, and SLOs in Minutes With DevOps-OS
+
+One of the most expensive parts of launching a new service is wiring up observability from scratch — defining alert thresholds, building a Grafana dashboard, and expressing SLOs in a format your toolchain understands. DevOps-OS does it in one command.
+
+## The command
+
+```bash
+python -m cli.devopsos scaffold sre \
+  --name payment-service \
+  --team platform \
+  --slo-target 99.9
+
+# Output: sre/ directory containing:
+#   sre/prometheus-rules.yaml
+#   sre/grafana-dashboard.json
+#   sre/slo.yaml
+```
+
+Three files, one command. Let's look at what each one does.
+
+## Prometheus alert rules
+
+`sre/prometheus-rules.yaml` is a Kubernetes `PrometheusRule` CRD that defines:
+
+- **Latency alerts** — fires when p99 response time exceeds threshold
+- **Error rate alerts** — fires when HTTP 5xx rate exceeds budget
+- **Availability alerts** — fires when the SLO burn rate is too high
+- **Saturation alerts** — CPU and memory pressure warnings
+
+All alerts are pre-labelled with `team`, `service`, and `severity` so they route cleanly to your on-call tool.
+
+## Grafana dashboard
+
+`sre/grafana-dashboard.json` is an importable Grafana dashboard JSON with panels covering the four golden signals:
+
+| Signal | What it tracks |
+|--------|---------------|
+| **Rate** | Requests per second |
+| **Errors** | HTTP error rate (4xx and 5xx) |
+| **Duration** | Request latency percentiles (p50, p95, p99) |
+| **Saturation** | CPU and memory utilisation |
+
+Import it directly via the Grafana UI or the Grafana API.
+
+## SLO manifest
+
+`sre/slo.yaml` is a [Sloth](https://github.com/slok/sloth)-compatible SLO manifest. It encodes:
+
+- The SLO target (e.g. 99.9% availability)
+- The SLI definition (ratio of successful requests)
+- Multi-window burn rate alerting (short window catches fast burns, long window catches slow burns)
+
+```bash
+# Generate with a custom SLO target
+python -m cli.devopsos scaffold sre --name my-api --slo-target 99.5
+
+# Generate with an error-rate SLO type
+python -m cli.devopsos scaffold sre --name my-api --slo-type error_rate
+```
+
+## Process-First SRE
+
+The Process-First philosophy applied to SRE means: **define your SLOs before your first production deployment, not after your first incident.**
+
+DevOps-OS makes that easy. You define the target (`--slo-target 99.9`) and the scaffold encodes it into Prometheus and Grafana artefacts that start measuring from day one.
+
+Key principles:
+
+- **Alert on symptoms, not causes** — burn rate alerts fire on SLO burn, not raw CPU spikes
+- **Error budgets** give teams a data-driven way to balance reliability with feature velocity
+- **Golden signals** (Rate, Errors, Duration, Saturation) ensure dashboards answer real operational questions
+
+## Integrate with your pipeline
+
+Add SRE config generation to your DevOps-OS pipeline setup:
+
+```bash
+# Generate CI/CD + SRE together for a new service
+python -m cli.devopsos scaffold gha --name my-api --languages python --type complete
+python -m cli.devopsos scaffold sre --name my-api --team backend --slo-target 99.9
+```
+
+Commit both the CI/CD workflow and the SRE configs to your repository. The workflow deploys your service; the SRE configs monitor it from the first request.
+
+## Options reference
+
+| Option | Default | Description |
+|--------|---------|-------------|
+| `--name` | required | Service name |
+| `--team` | `platform` | Owning team label on alerts |
+| `--slo-target` | `99.9` | Availability SLO target as a percentage |
+| `--slo-type` | `availability` | `availability` or `error_rate` |
+| `--output` | `./sre/` | Output directory |
diff --git a/blogs/2026-08-11-infrastructure-hardening-kyverno-inspec-checkov-devops-os.md b/blogs/2026-08-11-infrastructure-hardening-kyverno-inspec-checkov-devops-os.md
new file mode 100644
index 0000000..a87d4dd
--- /dev/null
+++ b/blogs/2026-08-11-infrastructure-hardening-kyverno-inspec-checkov-devops-os.md
@@ -0,0 +1,110 @@
+---
+title: "Infrastructure Hardening Made Easy: Kyverno, InSpec, and Checkov With DevOps-OS"
+slug: "infrastructure-hardening-kyverno-inspec-checkov-devops-os"
+description: "DevOps-OS scaffold hardening generates CIS, STIG, and NSA/CISA-compliant Kyverno policies, InSpec profiles, and Checkov checks — in one command."
+topic: "platform-engineering"
+tags: ["InfrastructureHardening", "Kyverno", "InSpec", "Checkov", "PlatformEngineering", "Compliance"]
+publishedAt: "2026-08-11"
+featured: false
+---
+
+# Infrastructure Hardening Made Easy: Kyverno, InSpec, and Checkov With DevOps-OS
+
+Compliance is one of the most time-consuming activities in platform engineering. Writing Kyverno ClusterPolicies for CIS Kubernetes benchmarks by hand takes days. DevOps-OS compresses that to seconds.
+
+## The command
+
+```bash
+# CIS Kubernetes benchmark — Kyverno policies
+python -m cli.devopsos scaffold hardening \
+  --standard cis-k8s \
+  --type kyverno \
+  --environment production
+
+# Output: hardening/kyverno/cis-k8s/
+```
+
+## Standards supported
+
+| Standard | Target | Tool |
+|----------|--------|------|
+| CIS Kubernetes Benchmark v1.9 | Kubernetes cluster | Kyverno |
+| DISA STIG for Kubernetes | Kubernetes cluster | Kyverno |
+| NSA/CISA Kubernetes Hardening Guide | Kubernetes cluster | Kyverno + NetworkPolicy |
+| CIS Docker Benchmark v1.6 | Container runtime | InSpec |
+| CIS RHEL 9 Benchmark | Operating system | InSpec |
+| CIS Ubuntu 22.04 Benchmark | Operating system | InSpec |
+| Pod Security Standards (Kubernetes) | Pod admission | Kyverno ClusterPolicy |
+| Container Image Signing | CI/CD + admission | Kyverno + Cosign |
+| OWASP ASVS L1 (infra layer) | Application deployment | Kyverno + Checkov |
+| Essential Eight (Australia ASD) | General controls | Checkov |
+
+## Generate multiple standards at once
+
+```bash
+# All Kyverno policies for a production cluster — every supported standard
+python -m cli.devopsos scaffold hardening \
+  --standard all \
+  --type kyverno \
+  --environment production
+
+# OS hardening profile for RHEL 9
+python -m cli.devopsos scaffold hardening \
+  --standard cis-rhel9 \
+  --type inspec
+
+# With compliance framework tagging for audit evidence
+python -m cli.devopsos scaffold hardening \
+  --standard cis-k8s \
+  --compliance-framework pci-dss
+```
+
+The `--compliance-framework` flag adds NIST/PCI-DSS/SOC2 control IDs to every policy so your gap register and audit evidence link back automatically.
+
+## Output structure
+
+```
+hardening/
+├── kyverno/
+│   ├── cis-k8s/
+│   │   ├── 1-master-node-config.yaml
+│   │   ├── 2-etcd-config.yaml
+│   │   ├── 3-control-plane.yaml
+│   │   ├── 4-worker-node.yaml
+│   │   └── 5-policies.yaml
+│   ├── stig-k8s/
+│   │   └── stig-cluster-policies.yaml
+│   └── pod-security-standards.yaml
+└── inspec/
+    ├── docker-cis/
+    └── rhel9-cis/
+```
+
+## Environment-aware policies
+
+The `--environment` flag adjusts Kyverno's `validationFailureAction`:
+
+| Environment | Kyverno action |
+|-------------|---------------|
+| `dev` | `audit` (log violations, never block) |
+| `staging` | `audit` (log violations) |
+| `production` | `enforce` (block non-compliant workloads) |
+
+Start with `audit` in development to understand what your current workloads violate, then switch to `enforce` in production once policies are tuned.
+
+## Options reference
+
+| Option | Default | Description |
+|--------|---------|-------------|
+| `--standard` | `all` | Hardening standard: `cis-k8s`, `stig-k8s`, `nsa-k8s`, `cis-docker`, `cis-rhel9`, `cis-ubuntu22`, `pod-security`, `image-signing`, `asvs-l1`, `essential-eight`, `all` |
+| `--type` | `all` | Output type: `kyverno`, `inspec`, `checkov`, or `all` |
+| `--environment` | `production` | `dev`, `staging`, or `production` |
+| `--compliance-framework` | _(none)_ | Tag with `pci-dss`, `hipaa`, `iso27001`, `nist-800-53`, `soc2` |
+| `--severity` | `medium` | Minimum severity filter: `critical`, `high`, `medium`, `low` |
+| `--output` | `./hardening/` | Output directory |
+
+## Where hardening fits in the platform
+
+Infrastructure hardening belongs in the platform-engineering layer, not the application layer. Use DevOps-OS to generate the policies once, store them in a dedicated Git repository, and apply them via ArgoCD or Flux to every cluster. Application teams never need to know the policies exist — they just get blocked when their workloads violate a control, with a clear error message pointing to the violated policy.
+
+That is the Platform Engineering Internal Developer Platform (IDP) model: encode the standards into automation, expose a self-service scaffold, and let the platform enforce compliance transparently.
diff --git a/blogs/2026-08-18-developer-platform-onboarding-devcontainer-devops-os.md b/blogs/2026-08-18-developer-platform-onboarding-devcontainer-devops-os.md
new file mode 100644
index 0000000..07260ee
--- /dev/null
+++ b/blogs/2026-08-18-developer-platform-onboarding-devcontainer-devops-os.md
@@ -0,0 +1,117 @@
+---
+title: "Developer Platform Onboarding: Multi-Language Dev Containers With DevOps-OS"
+slug: "developer-platform-onboarding-devcontainer-devops-os"
+description: "DevOps-OS scaffolds a fully configured multi-language dev container so every engineer on your team starts from the same reproducible, tool-complete environment."
+topic: "developer-experience"
+tags: ["DevContainer", "DeveloperExperience", "PlatformEngineering", "DevOpsOS", "Onboarding"]
+publishedAt: "2026-08-18"
+featured: false
+---
+
+# Developer Platform Onboarding: Multi-Language Dev Containers With DevOps-OS
+
+"It works on my machine" is not a culture problem. It is a tooling problem. When developers start a project with different Python versions, missing CLI tools, or mismatched Kubernetes clients, the first day of work becomes a debugging session.
+
+DevOps-OS solves this with a single `devcontainer` scaffold that produces a reproducible, pre-configured development environment for the entire team.
+
+## Generate a dev container
+
+```bash
+python -m cli.devopsos scaffold devcontainer \
+  --languages python,go \
+  --cicd-tools docker,terraform \
+  --kubernetes-tools k9s,flux
+
+# Output:
+#   .devcontainer/devcontainer.json
+#   .devcontainer/devcontainer.env.json
+```
+
+Open the folder in VS Code (or any Dev Containers-compatible editor) and click **Reopen in Container**. Every team member gets the same environment — same language versions, same CLI tools, same Kubernetes clients.
+
+## Initialise a new project from scratch
+
+```bash
+python -m cli.devopsos init --dir .
+```
+
+The `init` command adds `devcontainer.json`, `devcontainer.env.json`, and a Dockerfile to the current directory, then generates CI/CD and GitOps scaffolding interactively based on your answers.
+
+## What gets configured
+
+### Languages
+
+```json
+"languages": {
+  "python": true,
+  "java": true,
+  "javascript": true,
+  "go": true
+}
+```
+
+Each enabled language installs the runtime, package manager, linter, and formatter. Versions are pinned in the `versions` block.
+
+### CI/CD and container tools
+
+```json
+"cicd": {
+  "docker": true,
+  "terraform": true,
+  "kubectl": true,
+  "helm": true,
+  "github_actions": true
+}
+```
+
+### Kubernetes tools
+
+```json
+"kubernetes": {
+  "k9s": true,
+  "kustomize": true,
+  "argocd_cli": true,
+  "flux": true,
+  "kind": true,
+  "minikube": true,
+  "kubeseal": true
+}
+```
+
+Every Kubernetes CLI tool the team uses is installed and version-pinned in the container — no more `brew install` archaeology at the start of each sprint.
+
+## Dev-to-CI parity
+
+The `devcontainer.env.json` file is not just for local development. DevOps-OS CI/CD scaffolds read the same file to generate workflows that mirror your local environment:
+
+```bash
+python -m cli.devopsos scaffold gha \
+  --name my-app \
+  --env-file .devcontainer/devcontainer.env.json
+```
+
+The CI workflow uses the same language versions and tool set as the container — eliminating the class of bugs that only appear in CI.
+
+## Onboarding checklist for platform teams
+
+| Step | Command |
+|------|---------|
+| Create dev container | `devopsos scaffold devcontainer --languages python,go` |
+| Generate CI/CD pipeline | `devopsos scaffold gha --name my-app --type complete` |
+| Add GitOps delivery | `devopsos scaffold argocd --name my-app --repo <url>` |
+| Add SRE observability | `devopsos scaffold sre --name my-app --slo-target 99.9` |
+| Add hardening policies | `devopsos scaffold hardening --standard cis-k8s --environment production` |
+
+Five commands. A complete platform-engineering baseline — from developer laptop to production observability.
+
+## VS Code extensions included
+
+The generated `devcontainer.json` pre-installs extensions for every enabled language and tool:
+
+- Python (Pylance, Ruff, debugger)
+- Go (gopls, dlv)
+- Java (Language Support, Debugger)
+- Docker, Kubernetes, YAML, Terraform, HashiCorp
+- GitLens, GitHub Actions
+
+Engineers open the project and are productive from minute one.
diff --git a/blogs/2026-08-25-ai-powered-platform-engineering-devops-os-mcp-server.md b/blogs/2026-08-25-ai-powered-platform-engineering-devops-os-mcp-server.md
new file mode 100644
index 0000000..b49beca
--- /dev/null
+++ b/blogs/2026-08-25-ai-powered-platform-engineering-devops-os-mcp-server.md
@@ -0,0 +1,150 @@
+---
+title: "AI-Powered Platform Engineering: Using DevOps-OS as an MCP Server"
+slug: "ai-powered-platform-engineering-devops-os-mcp-server"
+description: "Connect DevOps-OS to Claude, ChatGPT, or any MCP-compatible AI assistant and generate production-ready DevOps configs directly from natural language prompts."
+topic: "ai-devops"
+tags: ["MCPServer", "AIDevOps", "PlatformEngineering", "Claude", "DevOpsOS", "OpenAI"]
+publishedAt: "2026-08-25"
+featured: false
+---
+
+# AI-Powered Platform Engineering: Using DevOps-OS as an MCP Server
+
+What if you could ask your AI assistant: *"Generate a Jenkins pipeline for a Java Spring Boot app with Docker build, push to GHCR, and Kustomize deployment"* — and receive a production-ready `Jenkinsfile` back in seconds?
+
+With DevOps-OS's built-in MCP server, you can.
+
+## What is MCP?
+
+MCP (Model Context Protocol) is an open standard that lets AI assistants call external tools with structured inputs and receive structured outputs. Claude, GitHub Copilot, Cursor, Windsurf, and Zed all support MCP natively.
+
+DevOps-OS exposes every scaffold generator as an MCP tool — so your AI assistant becomes a DevOps platform engineer.
+
+## Start the MCP server
+
+```bash
+pip install -r mcp_server/requirements.txt
+python -m mcp_server.server
+```
+
+The server runs as a stdio MCP process — the standard integration mode for Claude Desktop, Claude Code, and most MCP clients.
+
+## Connect to Claude Desktop
+
+Add to `~/Library/Application Support/Claude/claude_desktop_config.json`:
+
+```json
+{
+  "mcpServers": {
+    "devops-os": {
+      "command": "python",
+      "args": ["-m", "mcp_server.server"],
+      "cwd": "/path/to/devops_os"
+    }
+  }
+}
+```
+
+Restart Claude Desktop. DevOps-OS tools now appear as native Claude skills.
+
+## Available tools
+
+| Tool | What it generates |
+|------|-------------------|
+| `generate_github_actions_workflow` | GitHub Actions workflow YAML |
+| `generate_jenkins_pipeline` | Declarative Jenkinsfile |
+| `generate_k8s_config` | Kubernetes Deployment + Service manifests |
+| `scaffold_devcontainer` | `devcontainer.json` + `devcontainer.env.json` |
+| `generate_gitlab_ci_pipeline` | GitLab CI/CD pipeline YAML |
+| `generate_argocd_config` | ArgoCD Application and AppProject manifests |
+| `generate_sre_configs` | Prometheus rules, Grafana dashboard, SLO manifest |
+
+## Example prompts
+
+```
+Generate a complete GitHub Actions CI/CD workflow for a Python + Node.js
+project with Kubernetes deployment via Kustomize.
+
+Create a Jenkins pipeline for a Python microservice with Docker build,
+push to GHCR, and deploy to a staging cluster using ArgoCD.
+
+Scaffold a devcontainer for a Go + Python project with Terraform, kubectl,
+k9s, and Flux CD.
+
+Generate Kubernetes manifests for an API service using image
+ghcr.io/myorg/api:v1.2.3 with 3 replicas on port 8080.
+
+Generate SRE configs for payment-service with a 99.95% SLO and PagerDuty routing.
+```
+
+## Use DevOps-OS from the Anthropic API
+
+```python
+import json
+import anthropic
+
+with open("skills/claude_tools.json") as fh:
+    tools = json.load(fh)
+
+client = anthropic.Anthropic()
+response = client.messages.create(
+    model="claude-opus-4-5",
+    max_tokens=4096,
+    tools=tools,
+    messages=[{
+        "role": "user",
+        "content": (
+            "Generate a complete GitHub Actions CI/CD workflow for a "
+            "Python + Node.js project with Kubernetes deployment via Kustomize."
+        ),
+    }],
+)
+```
+
+## Use DevOps-OS from the OpenAI API
+
+```python
+import json
+import openai
+
+with open("skills/openai_functions.json") as fh:
+    functions = json.load(fh)
+
+client = openai.OpenAI()
+response = client.chat.completions.create(
+    model="gpt-4o",
+    tools=functions,
+    messages=[{
+        "role": "user",
+        "content": "Generate a Jenkins pipeline for a Java Spring Boot app."
+    }],
+)
+```
+
+## Custom GPT / GPT Actions
+
+Use `skills/openai_functions.json` as the OpenAPI schema for a Custom GPT Action:
+
+1. Open ChatGPT → Create a GPT → Configure → Actions → Create new action
+2. Paste the contents of `skills/openai_functions.json`
+3. Set the server URL to your deployed MCP server endpoint
+4. Save and test
+
+Platform teams can expose a Custom GPT to their developers as a self-service DevOps assistant — no CLI knowledge required.
+
+## The architecture
+
+```
+AI Assistant (Claude / ChatGPT)
+        │  MCP / function-call request
+        ▼
+DevOps-OS MCP Server
+        │  calls Python scaffold functions
+        ▼
+  Same generators used by the CLI
+        │
+        ▼
+  Generated files returned to AI assistant
+```
+
+The MCP server is a thin protocol adapter — it calls the exact same Python functions as the CLI. Every improvement to the generators benefits both the CLI and the AI integration simultaneously.
diff --git a/blogs/README.md b/blogs/README.md
new file mode 100644
index 0000000..d3e8e2e
--- /dev/null
+++ b/blogs/README.md
@@ -0,0 +1,68 @@
+# DevOps-OS Blog Posts
+
+This folder contains blog articles written about the DevOps-OS project.  
+Posts are published to [gsaravanan.com](https://gsaravanan.com) via the content hub at  
+[chefgs/gsaravanan-content-hub](https://github.com/chefgs/gsaravanan-content-hub/tree/main/src/content/posts).
+
+---
+
+## How to add a new post
+
+1. Create a new `.md` file in this folder.
+2. Name it: `YYYY-MM-DD-your-post-slug.md`  
+   The date prefix drives the publish schedule.
+3. Add the required frontmatter (see template below).
+4. Write the post body in standard Markdown below the closing `---`.
+5. Open a PR — the automated publish workflow picks it up on the `publishedAt` date.
+
+---
+
+## Required frontmatter
+
+```yaml
+---
+title: "Your Post Title Here"
+slug: "your-post-slug-here"
+description: "One or two sentence SEO description (under 160 chars)."
+topic: "devops-automation"
+tags: ["Tag1", "Tag2", "Tag3"]
+publishedAt: "YYYY-MM-DD"
+featured: false
+---
+```
+
+### Field reference
+
+| Field | Required | Notes |
+|-------|----------|-------|
+| `title` | ✅ | Human-readable headline |
+| `slug` | ✅ | URL path — must be unique, lowercase, hyphenated |
+| `description` | ✅ | SEO meta description, ≤ 160 characters |
+| `topic` | ✅ | Top-level category (see list below) |
+| `tags` | ✅ | Array of tags — use PascalCase, 3–6 tags |
+| `publishedAt` | ✅ | ISO date `YYYY-MM-DD` — post goes live on this date |
+| `featured` | ✅ | `true` shows the post in the featured section |
+
+### Approved topics
+
+| Topic slug | Use for |
+|------------|---------|
+| `devops-automation` | General DevOps-OS platform content |
+| `ci-cd` | GitHub Actions, GitLab CI, Jenkins pipelines |
+| `gitops` | ArgoCD, Flux CD, Kubernetes delivery |
+| `sre-observability` | Prometheus, Grafana, SLO, alerting |
+| `platform-engineering` | Hardening, compliance, IDP concepts |
+| `developer-experience` | Dev container, onboarding, tooling |
+| `ai-devops` | MCP server, AI-assisted automation |
+| `devops-culture` | Process-First philosophy, principles |
+
+---
+
+## Automation
+
+A scheduled GitHub Actions workflow (`.github/workflows/publish-blogs.yml`) reads this folder,
+checks `publishedAt` against today's date, and copies eligible posts into the content hub repo.
+Posts already published are tracked to prevent duplicates.
+A run summary is emailed to the configured address after each job.
+
+See the workflow file for setup instructions and required secrets.