Blog¶

Welcome to our technical blog! Here you'll find insights, tutorials, and best practices for cloud-native technologies and DevOps.

Latest Posts¶

Setting Up OpenClaw: Skills, Tailscale, GitHub Config Sync, and Copilot ¶

Published: March 3, 2026 | Author: Surjit Bains

A practical, secure OpenClaw setup guide with model selection, skills, Tailscale, config sync, and Copilot.

How I Standardised Kubernetes Deployments with ArgoCD ¶

Published: March 2, 2026 | Author: Surjit Bains

A platform engineering story of turning inconsistent deployments into a standard, self‑service GitOps pipeline.

Secrets & GitOps: ArgoCD + External Secrets Done Right ¶

Published: March 2, 2026 | Author: Surjit Bains

Implementation patterns, pitfalls, and guardrails for managing secrets in a GitOps workflow.

GitOps as a Product: Building Self‑Service with ArgoCD ¶

Published: March 2, 2026 | Author: Surjit Bains

How to turn ArgoCD into a developer platform with portals, templates, and policy‑as‑code.

Multi‑Cluster GitOps with ArgoCD: The Operational Blueprint ¶

Published: March 2, 2026 | Author: Surjit Bains

Scaling GitOps across clusters using ApplicationSets, cluster registry, and promotion patterns.

Demystifying Model Context Protocol (MCP): AI Gets Smarter About Context ¶

Published: September 3, 2025 | Author: Surjit Bains

Explore how MCP enables AI systems to retain, share, and prioritize context across interactions—improving reliability for assistants, chatbots, and enterprise workflows.

Topics covered: - Context persistence and sharing - Model interoperability - Practical architecture patterns

External Secrets Operator with ArgoCD Best Practices ¶

Published: November 30, 2023 | Author: Surjit Bains

Learn why using External Secrets Operator with ArgoCD is a cloud-native security best practice and how to implement it effectively in your Kubernetes infrastructure.

Topics covered: - Security best practices for GitOps - Enterprise secret management integration
- Step-by-step implementation guide - Common patterns and troubleshooting

More posts coming soon...

March 3, 2026
3 min read

Setting Up OpenClaw: Skills, Tailscale, GitHub Config Sync, and Copilot

This is a practical setup that gets you from “installed” to secure, synced, and productive without over‑engineering it.

Prerequisites

Linux host (VM or bare metal)
Git installed and configured
A GitHub account
Tailscale account (free plan is fine)
GitHub Copilot enabled in your IDE (optional)
OpenClaw installed (see docs)

1) Install OpenClaw (quick path)

Follow the official docs for your environment. If you want a guided Ubuntu setup with scripts, use the walkthrough repo: https://github.com/polarpoint-io/openclaw-setup.

C4 Context diagram

Ubuntu (reference setup)

# Base dependencies
sudo apt-get update
sudo apt-get install -y git curl ca-certificates

# Verify Git
git --version

If you’re using the walkthrough repo, run the scripts:

git clone https://github.com/polarpoint-io/openclaw-setup.git
cd openclaw-setup
chmod +x scripts/*.sh
./scripts/install-ubuntu.sh

Install OpenClaw

Use the official docs for the latest install method:

# OpenClaw installation (see docs for latest)
openclaw status

If openclaw status fails, make sure the gateway service is running:

openclaw gateway status
openclaw gateway start

Once installed, verify:

openclaw status

2) Configure models via onboarding

Onboarding lets you pick models per workload. Think cost control + performance tuning: - Default model → everyday tasks - Lightweight model → background checks/heartbeats - Deep model → long, complex work

If you’re unsure, keep defaults and tune later. If you run lots of automation, pick a cheaper lightweight model for routine checks.

Tip: For heartbeats and simple checks, consider a local/free model via Ollama (low‑latency, no per‑call cost). Use a hosted model only when you need deeper reasoning.

3) Enable your first skills

Installed skills right now: - self-improving-agent — captures learnings from failures and feedback - ddg-web-search — web search without an API key - github — GitHub ops via gh - kubernetes — cluster operations and manifests

List skills:

clawhub list

Install new skills:

clawhub install <skill-name>

Keep skills lean. Add them when the workflow needs them.

4) Secure access with Tailscale

Tailscale gives private, encrypted access to the host without exposing ports publicly.

C4 Container diagram

Minimal setup:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Recommended: - Tag the OpenClaw host - Lock it down with ACLs - Keep access limited to trusted devices

5) Sync config with GitHub

Keep your setup reproducible by storing non‑secret config in GitHub.

Suggested layout:

openclaw-config/
  README.md
  openclaw.json (sanitized)
  skills/
  notes/

Never commit secrets. Use env vars or a secret manager instead.

6) Pair with GitHub Copilot

Copilot helps with: - docs/blog drafts - refactors and cleanup - repetitive config work

Workflow: 1) OpenClaw automates 2) Copilot speeds up edits 3) You review + ship

7) Daily ops checklist

✅ OpenClaw running
✅ Skills installed & updated
✅ Tailscale connected
✅ Config synced (sanitized)
✅ Copilot ready

8) Troubleshooting quick hits

Agent not responding: openclaw status, then restart the gateway
Skills missing: clawhub list, reinstall as needed
Tailscale offline: tailscale status, then re‑auth
GitHub errors: verify SSH/token auth and org permissions

Next up: a follow‑on post on daily content automation (idea scans + skill updates) that stays low‑noise and safe.

March 2, 2026
2 min read

Secrets & GitOps: ArgoCD + External Secrets Done Right

Banner image

Secrets & GitOps: ArgoCD + External Secrets Done Right

The Problem We Had

GitOps worked—until secrets showed up. Teams either committed secrets or blocked releases.

The Outcome We Wanted

A GitOps flow that keeps secrets outside of Git and still automates deployments.

The Blueprint

External secrets context Guardrails flow

The Secure Pattern

Git holds ExternalSecret manifests only
ESO pulls from Vault/SSM/Secrets Manager
ArgoCD syncs manifests, ESO resolves secrets

Walkthrough Files

repo/gitops/secrets/secretstore.yaml
repo/gitops/secrets/externalsecret.yaml

What Changed

Teams can ship GitOps changes without ever touching sensitive data. Security teams gain control without blocking delivery.

March 2, 2026
2 min read

Multi‑Cluster GitOps with ArgoCD: The Operational Blueprint

Banner image

Multi‑Cluster GitOps with ArgoCD: The Operational Blueprint

The Problem We Had

As clusters multiplied, config drift and manual promotion became the norm.

The Outcome We Wanted

A scalable, repeatable way to manage many clusters with one control plane.

The Blueprint

Multi‑cluster context Multi‑cluster flow

Implementation Outline

1) Cluster registry via ArgoCD secrets 2) ApplicationSets for per‑cluster apps 3) Promotion via tags/branches

Walkthrough Files

repo/gitops/multi-cluster/cluster-registry.yaml
repo/gitops/multi-cluster/applicationset.yaml

What Changed

We reduced drift and made promotions predictable—without multiplying the operational burden.

March 2, 2026
2 min read

GitOps as a Product: Building Self‑Service with ArgoCD

Banner image

GitOps as a Product: Building Self‑Service with ArgoCD

The Problem We Had

Teams wanted to ship fast, but every new service required platform tickets and custom YAML.

The Outcome We Wanted

A self‑service model where developers can launch services safely and consistently.

The Blueprint

Self‑service context Self‑service flow

The Building Blocks

Service catalog for onboarding
Templates that generate GitOps config
Policy‑as‑code for guardrails

Walkthrough Files

repo/gitops/self-service/catalog.yaml
repo/gitops/self-service/template-inputs.yaml

What Changed

Developers moved faster without breaking standards. Platform teams reduced toil and gained consistent, observable deployments.

March 2, 2026
3 min read

How I Standardised Kubernetes Deployments with ArgoCD

Banner image

How I Standardised Kubernetes Deployments with ArgoCD

Why this exists

We had multiple teams shipping to multiple clusters, and every team invented their own deployment pattern. It worked—until it didn’t. Rollbacks were manual, promotions were inconsistent, and there was no single place to reason about “what is actually running.”

This post is the blueprint we use to make deployments boring, repeatable, and traceable. It’s a hybrid: short narrative + a practical guide you can apply.

What we standardised on

Single interface: everything deploys through ArgoCD Applications
Environment overlays: dev → staging → prod are explicit
Project + RBAC boundaries: no cross‑team bleed
Promotion in Git: PRs and tags, not click‑ops
Consistent health + rollouts: same signals everywhere

Standardised context Standardised flow

Architecture (repo + layout)

We keep a platform apps repo with a root App‑of‑Apps and a consistent layout:

platform-apps/
  apps/
    root/                # app-of-apps
    workloads/           # team apps
  overlays/
    dev/
    staging/
    prod/

Root app example:

# repo/gitops/app-of-apps/root-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: platform-root
  namespace: argocd
spec:
  project: platform
  source:
    repoURL: https://github.com/polarpoint-io/platform-apps
    targetRevision: main
    path: apps
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

1) ArgoCD Projects + RBAC (don’t skip)

Projects define where apps can deploy and who can touch them.

# repo/gitops/standardised/projects/platform-project.yaml
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: platform
  namespace: argocd
spec:
  sourceRepos:
    - https://github.com/polarpoint-io/platform-apps
  destinations:
    - namespace: platform-*
      server: https://kubernetes.default.svc
  roles:
    - name: team-readonly
      policies:
        - p, proj:platform:team-readonly, applications, get, platform/*, allow
    - name: team-admin
      policies:
        - p, proj:platform:team-admin, applications, *, platform/*, allow

Why it matters: without Projects, every app can deploy anywhere. That’s how drift becomes security incidents.

2) Environment overlays (dev/staging/prod)

Keep environment diffs explicit and small. Example values:

# repo/gitops/standardised/overlays/values-dev.yaml
replicaCount: 1
resources:
  limits:
    cpu: 200m
    memory: 256Mi

# repo/gitops/standardised/overlays/values-prod.yaml
replicaCount: 3
resources:
  limits:
    cpu: 1000m
    memory: 1Gi

Rule: if it can’t be expressed as an overlay, it doesn’t get deployed.

3) Promotion flow (Git, not clicks)

We promote with branches/tags and ArgoCD Applications that point to them:

main → dev
release/* → staging
prod → production (protected)

Example dev/staging/prod apps:

# repo/gitops/standardised/promotion/argocd-app-dev.yaml
spec:
  source:
    targetRevision: main
    helm:
      valueFiles: [values-dev.yaml]

# repo/gitops/standardised/promotion/argocd-app-staging.yaml
spec:
  source:
    targetRevision: release/v1.2.3
    helm:
      valueFiles: [values-staging.yaml]

# repo/gitops/standardised/promotion/argocd-app-prod.yaml
spec:
  source:
    targetRevision: prod
    helm:
      valueFiles: [values-prod.yaml]

4) Health, rollouts, and sync order

We standardise sync waves and health checks so dependencies come up in order.

# repo/gitops/standardised/health/sync-waves.yaml
metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"

Standard rules: - readiness/liveness probes on all deployments - consistent timeouts + retries - health overrides for CRDs if needed

Operational impact

Deployments are auditable Git changes
Rollbacks are a single commit revert
Drift is visible instead of hidden
Teams still ship fast—but on rails

Walkthrough files

repo/gitops/app-of-apps/root-app.yaml
repo/gitops/standardised/projects/platform-project.yaml
repo/gitops/standardised/overlays/values-dev.yaml
repo/gitops/standardised/overlays/values-staging.yaml
repo/gitops/standardised/overlays/values-prod.yaml
repo/gitops/standardised/promotion/argocd-app-dev.yaml
repo/gitops/standardised/promotion/argocd-app-staging.yaml
repo/gitops/standardised/promotion/argocd-app-prod.yaml
repo/gitops/standardised/health/sync-waves.yaml

September 3, 2025
2 min read

Demystifying Model Context Protocol (MCP): AI Gets Smarter About Context

Banner image

Demystifying Model Context Protocol (MCP): AI Gets Smarter About Context

The Problem We Had

LLMs are powerful but fragile when context is missing. They forget decisions, repeat themselves, and produce inconsistent outcomes.

The Outcome We Wanted

A standard way for models and tools to persist, share, and prioritize context across sessions.

The Blueprint

MCP context MCP flow

Core Principles

Context persistence: memory survives beyond a single prompt.
Context sharing: tools and models can publish and consume the same context.
Prioritization: the right context surfaces at the right time.

Walkthrough Files

repo/mcp/context-store/schema.json

What Changed

Once MCP is in place, assistants behave less like stateless chatbots and more like reliable operators—because the context doesn’t vanish every time the prompt ends.

November 30, 2023
2 min read

Store real secrets in a secret manager (AWS/GCP/Vault).
Commit only ExternalSecret manifests.
Let ESO pull and materialize secrets in‑cluster.

Walkthrough Files

repo/gitops/secrets/secretstore.yaml
repo/gitops/secrets/externalsecret.yaml

What Changed

Security improved immediately: no plaintext secrets in Git, fewer manual steps, and a cleaner audit trail.