Forem: Harshit Luthra

The git commands I actually run every day

Harshit Luthra — Wed, 20 May 2026 19:10:05 +0000

Originally published at harshit.cloud on 2026-05-20.

I've been using git for a decade and most of what I type still fits on a single hand. The 200-page Pro Git book is wonderful and almost none of it survives contact with a real Tuesday. What survives is a small, boring set of commands that get rerun constantly, plus a handful of less-boring ones I reach for once a week and would mourn if they disappeared.

This post is that list, ordered by how often my fingers actually type them. Aliases are from the oh-my-zsh git plugin (enabled in most zsh configs that exist); the full command sits next to the alias so it's portable.

the daily eight

These are the ones I'd type in my sleep. If you're not using all eight already, picking them up pays back inside a week.

gst

git status

gst

I run this between every other command. It's the cheapest sanity check git has. Branch, ahead/behind, staged, unstaged, untracked. Two seconds. If you only learn one alias, learn this one.

glola

git log --oneline --graph --decorate --all

glola | head -30

The one true log. Graph of every branch (local + remote), one line per commit, colored refs. Pipe through head because most of the time you only care about the last 20-30 commits. I have this bound to muscle memory more thoroughly than my own phone number.

gd / gds

git diff / git diff --staged

gd          # what's changed but not staged
gds         # what's staged and about to be committed

gds before every commit. If you set delta as your pager (brew install git-delta, then pager = delta in ~/.gitconfig), the output stops being painful to read.

gcam

git commit -a -m

gcam "fix: trailing slash in webhook URL"

Quick one-line commits for small fixes. For anything bigger I drop the -m and let $EDITOR open so I can write a proper message with a body.

gpsup

git push --set-upstream origin <current-branch>

gpsup

First push of a new branch. The full command is annoying to type, so gpsup figures out the current branch name itself. After the first push, plain gp (just git push) works because upstream is set.

gco / gcb

git checkout / git checkout -b

gco main             # switch to main
gco -                # switch to previous branch
gcb feature/login    # create + switch to new branch

gco - is the one to notice. Like cd - for branches. When you're bouncing between two branches all day, it's a single keystroke each way instead of typing the name.

gpf

git push --force-with-lease

gpf

After rebasing or amending. Always use --force-with-lease, never --force. The lease version refuses to push if someone else has pushed to your branch since your last fetch, saving you from silently overwriting a teammate's work. There is no good reason to ever type --force in 2026.

gfa

git fetch --all --prune

gfa

Refresh every remote, prune deleted remote branches. Run before you start anything that depends on knowing the current state of the world. The --prune half is what makes the next section work.

the weekly five

The commands that aren't in your fingers yet but should be.

`git switch` and `git restore` (the new commands)

git switch main
git switch -c new-feature           # create + switch
git restore --staged file.txt       # unstage
git restore --source=abc123 file.go # restore single file from any commit

switch and restore split the four jobs checkout used to do. Safer because they can't accidentally do the wrong one. The one I reach for most is restore --source=<sha> <path>. Translation: "grab this single file from three commits ago without touching anything else."

interactive rebase with autosquash

git commit --fixup=abc123       # fixup commit targeting abc123
git commit --fixup=abc123       # another one, still targeting
# ... keep working ...
git rebase -i --autosquash main # all fixups slot into place automatically

This is the single biggest workflow win I've found in ten years of git. While reviewing your own PR you find a bug four commits back. Don't fix it on top. git commit --fixup=<sha> creates a commit targeting the offender. Keep working. When you're done: git rebase -i --autosquash main reorders and squashes everything for you. PR history stays clean. No // fix bug in earlier commit commits.

Install git-absorb (brew install git-absorb) and it picks the target sha for you by looking at which lines you changed. The flow becomes:

# edit files to fix the bugs
git absorb --and-rebase
# done.

The first time it works on a six-commit branch you'll wonder why it isn't built into git.

`git reflog`, the universal undo

git reflog
git reset --hard HEAD@{5}

Every change to HEAD is logged for 90 days. Bad rebase? reflog. Deleted branch? reflog. reset --hard to the wrong commit? reflog. There is almost nothing in git you can't undo if you know about it. I've never met anyone who used it as much as they should.

`git worktree`

git worktree add ../proj-hotfix hotfix/prod-down
git worktree list
git worktree remove ../proj-hotfix

Need to fix a prod bug while halfway through a feature? Don't stash. worktree add gives you a second checkout in a sibling directory, sharing the same .git. Same repo, two working trees, both editable, no stash gymnastics. I use it constantly for "let me review your PR" without leaving my own branch.

branches sorted by recency

git config --global alias.recent \
  "for-each-ref --sort=-committerdate refs/heads/ \
   --format='%(HEAD) %(color:yellow)%(refname:short)%(color:reset) \
             %(color:green)(%(committerdate:relative))%(color:reset) %(contents:subject)'"

git recent | head -10

git branch lists alphabetically, which is useless. git recent lists by last-commit-date, which is exactly what you want when you're trying to remember the name of "that branch from Tuesday."

the cleanup ritual

Run this weekly. If you've ever scrolled through 80 stale branches looking for the one you actually want, you already know why.

the easy half: real merges

gfa
git branch --merged main | grep -v '\*\|main\|master' | xargs -n1 git branch -d

Deletes every local branch whose tip commit is already in main. Works only if your team uses merge commits. Most don't.

the hard half: squash-merges

GitHub's "Squash and merge" creates a brand-new commit on main with a different SHA. git branch --merged won't catch your local branch because its commits literally aren't in main's history.

The workaround: after gfa, any branch whose tracked remote was deleted shows as [gone]. Those are your merged-and-deleted PRs.

# git-gone: delete local branches whose remote tracking branch is gone
git-gone() {
  git fetch --prune
  local gone
  gone=$(git for-each-ref --format '%(refname:short) %(upstream:track)' refs/heads \
         | awk '$2 == "[gone]" {print $1}')
  if [ -z "$gone" ]; then
    echo "No gone branches"
    return
  fi
  echo "$gone"
  echo -n "Delete these? [y/N] "
  read -r confirm
  [[ "$confirm" == "y" ]] && echo "$gone" | xargs -r git branch -D
}

Or install git-trim (brew install git-trim), which is smarter. It also detects patch-equivalent commits, so it catches squash-merges even when the upstream tracking ref isn't [gone].

git trim                # dry-run
git trim --confirm      # actually delete

This is the closest thing to "did my PR ship?" you can ask git directly.

the archeology pack

For when something is broken and the question is "when did this start."

pickaxe, finding when a string appeared

git log -S "functionName"       # commits where this string was added or removed
git log -G "regex"              # same but with regex

git log --grep searches commit messages. -S searches the content of the diff. Different thing entirely. When you need to find "who introduced this line" but the answer isn't simple blame because the line has moved, pickaxe is the answer.

`git blame -w -C -C -C`

git blame -w -C -C -C path/to/file.go

Plain blame is misleading. It gives credit to whoever last touched the line, which is often whoever ran a formatter. The flags:

-w ignore whitespace changes
-C -C -C follow code copied or moved across files, with three levels of aggressiveness

The result: the actual author of the logic, not the person who reformatted it. I've used these flags to chase down a bug that touched code that had moved across three files in two refactors. Plain blame would have pointed at a Prettier commit.

`git log -p --follow <file>`

git log -p --follow path/to/renamed-file.go

Full history of a single file, including across renames. Default git log loses the trail at the rename boundary. --follow does not.

`git range-diff`

git range-diff main feature-old feature-new
git range-diff @{u} @

After rewriting history with rebase, this shows what actually changed between two ranges of commits, not just file diffs. The @{u}..@ form compares your local branch to its upstream. Run it before every force-push and you'll see exactly what you're about to overwrite. The last reviewer I worked with on a big rebase asked me to paste the range-diff into the PR comments instead of re-reviewing the whole thing.

the "stop pasting from Stack Overflow" pack

Enable these once and forget about them.

turn on rerere

git config --global rerere.enabled true

That's it. Git now remembers how you resolved a conflict and replays the resolution automatically the next time the same conflict appears. Saves real time on long-running rebases.

default to safer push

git config --global push.default current
git config --global push.autoSetupRemote true

current makes git push push the current branch to a remote of the same name. autoSetupRemote means git push on a new branch sets upstream automatically. No more gpsup for the first push.

better diff and merge UX

git config --global diff.algorithm histogram
git config --global merge.conflictStyle zdiff3

histogram produces cleaner diffs for most refactors than the default myers. zdiff3 shows the common ancestor in conflict markers, i.e. the original code both sides diverged from. Once you've used it, plain <<<<<<< markers feel like flying blind.

maintenance, on a schedule

git maintenance start

Sets up a background cron-equivalent that runs gc, prefetch, and loose-objects on a schedule. Repos stay fast without manual git gc runs.

the three tools worth installing today

git-absorb (brew install git-absorb). Auto-fixup commits without picking SHAs.
delta (brew install git-delta). Diff and blame output that doesn't hurt to look at.
lazygit (brew install lazygit). TUI for the operations that are tedious on CLI: partial commits, interactive add, stash management, conflict resolution.

I don't reach for lazygit daily, but the day I do, usually a five-way merge conflict, it pays for itself immediately.

bonus: two AI shell helpers for the stuff git can't tell you

Git can tell you what changed. It can't tell you the syntax for the find command you needed two minutes ago. Two short zsh functions wrap an AI CLI so the answer lands in the terminal instead of in a chat tab. p prints to stdout (for reading), d pre-types a command into your next prompt (for running).

# p: one-shot AI answer printed to terminal (math, facts, regex, syntax)
p() {
  emulate -L zsh
  setopt NO_GLOB
  if [ $# -eq 0 ]; then
    echo "usage: p <question or task>" >&2
    return 1
  fi
  pi -p --no-session --append-system-prompt 'Answer in ONE line. No preamble, no explanation, no markdown, no code fences. For shell/kubectl/git/etc requests output only the command. For factual or math questions output only the answer.' "$*" \
    | tr -d '\000-\037' \
    | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'
}
alias p='noglob p'

# d: AI suggests a shell command, pre-typed into next prompt (review + Enter)
d() {
  emulate -L zsh
  setopt NO_GLOB
  local query="$*"
  local prompt="You are a command line expert. The user wants to run a command but they don't know how. Here is what they asked: ${query}. Return ONLY the exact shell command needed. No explanation, no markdown, no code blocks. Just the raw command."
  local cmd
  cmd=$(droid exec -m glm-4.6 -r off --output-format text --disabled-tools execute-cli -- "$prompt" \
        | tr -d '\000-\037' \
        | sed 's/^[[:space:]]*//;s/[[:space:]]*$//')
  print -z -- "$cmd"
}
alias d='noglob d'

Swap pi and droid for whatever AI CLI you have: claude -p, llm, gh copilot suggest, ollama run. The pattern is what matters, not the backend.

why split into two functions

Different jobs:

	`p` (read)	`d` (run)
Output goes to	stdout	next prompt buffer
You then...	read it	edit / press Enter
Best for	"what's the regex for X"	"find files larger than 100MB"

the trick: `print -z` is what makes `d` safe

print -z pushes text onto the zsh line editor, i.e. into your next prompt, pre-typed and ready. Compared to the alternatives:

Strategy	Speed	Safety	Friction
`eval "$(...)"`	fastest	bad, auto-runs model output	none
Pipe to `pbcopy`	medium	safe	switch focus, paste
Print to stdout	medium	safe	select + copy + paste
`print -z`	fastest	safe, you press Enter	none

Same trick Ctrl-R history search uses. Native zsh. You always see and approve the command before it runs.

what it feels like

$ p git rebase abort
git rebase --abort

$ p whats the syntax for git log since a date
git log --since="2 weeks ago"

$ d find all .log files modified in the last hour
# next prompt now shows, cursor at the end:
$ find . -type f -name "*.log" -mmin -60█

$ d remove all local branches whose remote is gone
# next prompt:
$ git fetch --prune && git for-each-ref --format '%(refname:short) %(upstream:track)' refs/heads | awk '$2 == "[gone]" {print $1}' | xargs git branch -D█

A two-letter command, and the answer is already on the line where you wanted it.

the three defensive details

emulate -L zsh; setopt NO_GLOB         # function-local zsh defaults, no globbing
alias p='noglob p'                      # `p list *.log files` won't glob-expand `*.log`
tr -d '\000-\037' | sed 's/[trim]//'    # strip control chars (incl. ANSI), trim whitespace

noglob is the one most people miss. Without it, d list all *.log files would have zsh expand *.log against the current directory before the function ever sees it. With noglob, the glob characters pass through literally.

A single-function variant of this, with a heuristic that picks stdout vs pre-typed automatically, lives in this TIL.

ten years in, the surprise

After a decade, the command I run most isn't commit. It isn't push. It's gst, hundreds of times a day, between every other operation. The most-used git command in my shell is the one that does nothing.

A single zsh function for one-line AI answers that knows when to pre-type the command

Harshit Luthra — Wed, 20 May 2026 07:01:10 +0000

Originally published at harshit.cloud on 2026-05-20.

I kept opening a chat tab just to ask "what's the kubectl command for decoding a secret" or "convert 42 GiB to bytes". The context switch was costing more than the answer was worth.

Wrapping an AI CLI into a single shell function fixed it. The interesting part is print -z, plus one heuristic that needs more care than it looks.

the function

# p: one-shot AI query. Examples: `p whats 2 + 2`, `p kubectl secret decode grafana`
# Smart dispatch: if the answer looks like a runnable command, pre-type it into
# the next prompt (print -z). Otherwise print to stdout. Math/facts get printed,
# commands get queued for you to review and press Enter.
p() {
  emulate -L zsh
  setopt NO_GLOB
  if [ $# -eq 0 ]; then
    echo "usage: p <question or task>" >&2
    return 1
  fi
  local out
  out=$(pi -p --no-session --append-system-prompt 'Answer in ONE line. No preamble, no explanation, no markdown, no code fences. For shell/kubectl/git/etc requests output only the command. For factual or math questions output only the answer.' "$*" \
        | tr -d '\000-\037' \
        | sed 's/^[[:space:]]*//;s/[[:space:]]*$//')
  if [ -z "$out" ]; then
    return 1
  fi
  local first="${out%% *}"
  if [[ "$first" == [a-zA-Z_]* ]] && whence -p "$first" >/dev/null 2>&1; then
    print -z -- "$out"
  else
    print -r -- "$out"
  fi
}
alias p='noglob p'

pi is just whatever AI CLI you have. Swap in claude -p, llm, gh copilot suggest, ollama run. The pattern doesn't care about the backend.

what it feels like

$ p whats 2 + 2
4

$ p capital of mongolia
Ulaanbaatar

$ p regex for matching an email
[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}

$ p kubectl secret decode grafana
# next prompt now shows, cursor at the end:
$ kubectl get secret grafana -o go-template='{{range $k,$v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}'█

$ p find all log files modified today
# next prompt:
$ find . -type f -name "*.log" -mtime -1█

Same two-letter command for both. Answers go to stdout, commands go to the prompt buffer where you can edit them before pressing Enter.

the key idea: `print -z` for runnable output

print -z is the trick that makes this design work. It pushes text onto the zsh line editor, i.e. into your next prompt, pre-typed and ready. Compared to every alternative:

Strategy	Speed	Safety	Friction
`eval "$(...)"`	fastest	bad, auto-runs model output	none
Pipe to `pbcopy`	medium	safe	switch focus, paste
Print to stdout	medium	safe	select + copy + paste
`print -z`	fastest	safe, you press Enter	none

The mental model: print -z is what Ctrl-R history search does when you accept a result. Native zsh. You always see and approve the command before it runs.

the heuristic: when is the answer a command?

The smart dispatch decides between print -z (pre-type) and print -r (stdout) by looking at the first word of the answer:

if [[ "$first" == [a-zA-Z_]* ]] && whence -p "$first" >/dev/null 2>&1; then
  print -z -- "$out"
else
  print -r -- "$out"
fi

Two checks, both load-bearing:

First char is a letter or underscore. Excludes digits (4), symbols ([, /, (), and anything else that obviously isn't a command name.
whence -p resolves it to a PATH executable. Not just "this name exists in the shell", but specifically a real binary on disk.

Why whence -p and not command -v? Read on.

the footgun: oh-my-zsh numeric aliases

My first attempt used command -v "$first" as the heuristic. It looked right. It failed in a way that took a minute to spot.

When I ran p whats 2 + 2, the answer was 4, but nothing appeared in my terminal. The function exited cleanly with status 0. No error.

What had happened: oh-my-zsh's dirhistory plugin (loaded by default in many configs) aliases 1 through 9 to cd -1 ... cd -9 for jumping around the directory stack. So command -v 4 returned true. 4 was a recognized alias, and the function tried to print -z 4 into my prompt buffer.

In a real interactive shell, that would have stuffed 4 into my prompt invisibly (it'd appear when I hit Enter). In my non-interactive test (zsh -ic '...') it disappeared into the void because there's no line editor to render the stuffed buffer.

The fix has two parts:

[[ "$first" == [a-zA-Z_]* ]] alone would have caught it, because 4 doesn't start with a letter.
whence -p instead of command -v makes it doubly safe. whence -p only matches binaries in PATH, ignoring aliases, functions, and builtins. Aliases like 4 → cd -4 are filtered out.

Either check alone would have caught the bug. Having both means the next time I add a feature here, I don't have to remember which one was load-bearing.

defensive details that earn their keep

Three small things prevent subtle bugs:

`noglob` on the alias

alias p='noglob p'

Without this, p list all *.log files would have zsh expand *.log against the current directory before the function ever sees it. With noglob, the glob characters pass through literally. Same trick git uses for its arguments.

`emulate -L zsh` + `setopt NO_GLOB`

emulate -L zsh
setopt NO_GLOB

emulate -L zsh resets shell options to defaults, scoped to this function only (the -L means local, so they restore on return). NO_GLOB is belt-and-suspenders for callers that bypass the alias (command p ..., \p ..., or scripts that don't see your aliases).

output sanitization

tr -d '\000-\037' | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'

tr -d '\000-\037' strips all C0 control characters. That includes ANSI escape sequences (ESC = \033), stray nulls, and any invisible cruft the model might emit. Critical for print -z because control characters in the payload corrupt the line editor's display.

sed then trims leading and trailing whitespace, which the model usually adds even when told not to.

why `"$*"` and not `"$@"`

"$*" joins all positional args into one string with spaces between them. "$@" would pass them as separate args, which most AI CLIs would concatenate anyway, but some treat the first positional as the prompt and the rest as files (the @file.txt convention is common). Joining explicitly avoids that ambiguity.

If your CLI supports -- to end option parsing, prefer:

your-ai-cli -p ... -- "$*"

pi doesn't accept --, hence the bare "$*".

the system-prompt nudge actually matters

Without --append-system-prompt, even with -p, the default coding-assistant prompt wraps shell commands in code fences and adds a one-sentence intro. That breaks print -z (code fences are not commands) and clutters the terminal.

The phrasing that worked best:

Answer in ONE line. No preamble, no explanation, no markdown, no code fences. For shell/kubectl/git/etc requests output only the command. For factual or math questions output only the answer.

"No markdown, no code fences" is doing most of the work. Without it you get backtick-wrapped output that print -z would happily push into your prompt as `kubectl get pods`, which is not a runnable command.

why this beats the chat UI for short questions

Action	Chat UI	`p`
Switch context	yes	no
Round-trip latency	~3-5s + UI	~1-2s
Output format	markdown, prose	bare answer or pre-typed command
Get command into shell	select + copy + paste	already in your prompt
Session pollution	yes	no (`--no-session`)
Glob-expansion footgun	n/a	guarded (`noglob`)

For anything longer than a paragraph the chat UI is still better. For "what's the syntax for X" or "the command for Y", the terminal is the right place to put the answer.

the one substitution that fixed it

command -v → whence -p. One swap. The rest of the function (the noglob, the emulate -L zsh, the control-char strip) was already doing its job. The bug was trusting that "this name resolves in the shell" meant "this name is a binary on disk." It doesn't, and on any zsh with oh-my-zsh loaded it especially doesn't.

How to bypass corporate MDM and AI gateways on Claude Code

Harshit Luthra — Mon, 18 May 2026 16:59:08 +0000

Originally published at harshit.cloud on 2026-05-08.

If you're reading this, there's roughly an 80% chance your company rolled out an MDM last quarter, your network team wedged Claude API traffic through an AI gateway around the same time, and now Claude Code boots with MCPs you didn't pick while forwarding your prompts somewhere you haven't audited. /mcp shows three servers nothing in your repo touches. env | grep ANTHROPIC returns a base URL on a domain you've never seen. The experience got worse and nobody asked you.

This post covers both leashes. The MDM one is fixable in 12 lines of zsh. The AI gateway one depends on how deep your network team went.

what's an MDM, in three sentences

MDM stands for Mobile Device Management. Jamf, Kandji, Intune, Workspace ONE, whichever agent enrolled your laptop on day one. It owns parts of /Library, can write files there as root with the system-immutable flag set, and re-pushes them on a schedule, which is why a plain rm doesn't survive. For Claude Code, the relevant directory is /Library/Application Support/ClaudeCode/.

the managed-settings situation

The two files doing the work are /Library/Application Support/ClaudeCode/managed-settings.json and /Library/Application Support/ClaudeCode/managed-mcp.json. Claude Code reads them on startup, treats them as the highest-priority settings layer, and merges them over whatever you have in ~/.claude/settings.json. Anything IT puts in there wins: forced MCPs, forced skills, allowed and denied permission lists, and the env block that can set ANTHROPIC_BASE_URL. That last one is how the AI gateway routing gets wired into Claude Code in the first place.

why `rm` doesn't work

First instinct fails, and not in a way that's obvious:

sudo rm "/Library/Application Support/ClaudeCode/managed-settings.json"
# rm: managed-settings.json: Operation not permitted

Root isn't enough. The MDM agent sets the file's system-immutable flag with chflags schg after writing it. That flag blocks deletion even by root until it's cleared. The macOS chflags(1) man page is the receipt. schg is the "system immutable" flag, and the file "may not be changed, moved, or deleted" while it's set.

Confirm it on your own machine:

ls -lO "/Library/Application Support/ClaudeCode/managed-settings.json"
# -rw-r--r--  1 root  wheel  schg  482 May 14 09:11 managed-settings.json

schg in column five is the marker.

The detail that matters: managed-settings.json is the same config layer your ~/.claude/settings.json uses. The IT copy just lives under /Library, is owned by root, and has the schg flag set. The merge logic doesn't know which file came from a human.

the cleanup script

One thing worth flagging before you run this. On macOS, the schg flag is normally clearable by root for files outside SIP-protected paths — and /Library/Application Support/ClaudeCode/ is not SIP-protected. So sudo chflags noschg works as written. If your MDM also writes its config into a SIP-protected location (rare for application config, more common for system extensions), you'd need Recovery Mode Terminal to clear those, which is a different conversation. The script's 2>/dev/null will silently swallow that failure, so if reruns don't seem to take, that's where to look.

Save this as /usr/local/sbin/claudecode-cleanup.sh, make it executable, run with sudo:

#!/bin/zsh
FILES=(
  "/Library/Application Support/ClaudeCode/managed-settings.json"
  "/Library/Application Support/ClaudeCode/managed-mcp.json"
)
for f in "${FILES[@]}"; do
  # Clear immutable flag if file exists, then remove
  [ -e "$f" ] && /usr/bin/chflags noschg "$f" 2>/dev/null
  /bin/rm -f "$f"
done

sudo chmod 755 /usr/local/sbin/claudecode-cleanup.sh
sudo /usr/local/sbin/claudecode-cleanup.sh

Two lines do the real work. chflags noschg clears the immutable bit. rm -f removes the file. The 2>/dev/null swallows the noise on a clean machine where the file isn't there.

Restart Claude Code. /mcp should be back to whatever you actually installed, and /permissions should be whatever's in ~/.claude/settings.json instead of whatever IT decided you needed.

the launchd arms race

I'd love to tell you this is permanent. It isn't.

MDM agents sync on a schedule. Every 15 minutes, every hour, on login, depending on profile. When they sync, they notice the file is gone, put it back, and re-apply the schg flag. You'll watch managed-mcp.json reappear like a horror-movie villain you keep stabbing.

A few options, in increasing order of trouble you're inviting:

Run the script on a launchd LaunchAgent that fires at login. Once per session. Low impact, low effectiveness, but if your MDM only syncs at login this is enough.
Run it on a launchd timer with a 60-second interval. Now you're in an arms race with the sync schedule. Works until someone in IT notices a config-drift alert for your hostname.
Block the MDM agent's outbound DNS. Effective, loud, and the kind of thing that gets your laptop wiped on the next compliance audit.

I run the first one. The MDM gets its login telemetry, my dev environment isn't broken for the hour or so between syncs, nobody opens a ticket. Pick the option that matches how much you actually want to fight this.

Minimal ~/Library/LaunchAgents/cloud.harshit.claudecode-cleanup.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key><string>cloud.harshit.claudecode-cleanup</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/bin/sudo</string>
    <string>-n</string>
    <string>/usr/local/sbin/claudecode-cleanup.sh</string>
  </array>
  <key>RunAtLoad</key><true/>
</dict>
</plist>

sudo -n only works if you've added a NOPASSWD line for that exact script in /etc/sudoers.d/claudecode-cleanup. Which the MDM might rewrite. The arms race goes deeper than you think.

the AI gateway angle

The other leash sits at the network layer. Companies route Claude API traffic through a gateway (Cloudflare AI Gateway, Portkey, LiteLLM, internal proxies) so they can log prompts, strip PII, enforce per-user quotas, or quietly downgrade Opus calls to Haiku when the monthly bill spikes. Claude Code respects ANTHROPIC_BASE_URL and will talk to whatever endpoint it points at, as long as your OAuth token or API key authenticates there.

Two routing patterns to recognize:

The env block in managed-settings.json. IT sets ANTHROPIC_BASE_URL=https://ai-gw.corp.example.com/v1 inside the env section of the managed file. Claude Code reads it on startup. Same fix as the MCP file. The cleanup script above already kills this.
System proxy plus a corporate root CA. Your laptop has a "Corporate Root CA" in keychain, and either an https.proxy setting or transparent network interception routes api.anthropic.com traffic through the gateway. Deleting managed-settings.json does nothing here. The interception lives below the application layer.

To tell which one you have, run this in a fresh shell:

env | grep -i anthropic
# If you see ANTHROPIC_BASE_URL, it's the env block.

curl -v https://api.anthropic.com/v1/messages 2>&1 | grep -iE 'issuer|subject|server certificate'
# If the cert chain is signed by your corporate CA, it's transparent interception.

bypassing the gateway

For the env-block case, the cleanup script already does the work. Restart your shell after running it:

unset ANTHROPIC_BASE_URL
env | grep -i anthropic
# (empty)

For the transparent-proxy case, your options shrink:

Personal hotspot for sensitive sessions. Burns mobile data, leaves no trail through the gateway. Most realistic option for an individual contributor.
WireGuard or Tailscale out to a personal node. Works if your MDM profile allows it. Many block third-party VPNs through com.apple.systempolicy.kernel-extension-policy.
Personal device for personal work. Boring answer. The one that holds up in HR if it ever comes up.

What doesn't work: removing the corporate root CA from keychain. It's pinned by an MDM payload and gets re-added on next sync, same pattern as managed-settings.json.

should you actually do this

Worth saying out loud: both leashes exist because someone at your company had a reason. Compliance, data residency, an incident from six months ago whose postmortem nobody can find.

If the forced MCP is internal-secrets-lookup and the gateway logs prompts to a SOC pipeline, your team probably wants you using it. If the MCP is corporate-docs-mcp pointed at a 404 and the gateway downgrades Opus to Haiku because someone misread an invoice, you're deleting dead weight.

The script doesn't know which. Ask before you script. Most MDM platforms support per-user opt-out scopes, and one polite Slack message to IT beats a launchd plist.

what these scripts don't do

The cleanup clears two files. It does not:

Stop the MDM agent.
Touch ~/.claude/settings.json. Your settings stay yours.
Handle /Library/Application Support/ClaudeCode/managed-permissions.json if your MDM uses one. Add it to the FILES array.
Survive a reboot or a sync. The agent re-pushes on next check-in.
Defeat a transparent proxy with a pinned corporate CA. Use the hotspot.

If you wanted a permanent escape from corporate IT, you wouldn't be reading a blog about chflags.

Lazy SRE's guide to secure systems, part 5: the dev laptop is the perimeter

Harshit Luthra — Mon, 18 May 2026 16:58:52 +0000

Originally published at harshit.cloud on 2026-05-03.

In June 2024, Mandiant published the writeup for the Snowflake mass-extortion campaign. Ticketmaster, Santander, AT&T, LendingTree, Advance Auto Parts — roughly 165 Snowflake tenants in total had data extracted from their warehouses. The defining detail wasn't sophistication. It was the laptop.

Mandiant traced the entry point to infostealer malware (Lumma, RedLine, Vidar variants) running on contractor and developer machines. Their report described the affected devices as personal systems also used for gaming and downloading pirated software. The infostealer harvested every credential the browser had ever saved, including the Snowflake login that didn't have MFA enforced. The attackers walked through the front door of a Fortune 500's data warehouse.

This is part 5. Earlier parts covered npm (Part 1), GitHub Actions (Part 2), the unsexy infrastructure list (Part 3), and DNS auth records (Part 4). Part 5 is about the laptop. The piece of hardware on an engineer's desk that has every SSH key, AWS profile, kubeconfig, GitHub PAT, Slack token, and Stripe key they have ever used to do their job.

The thesis from Part 1 stands. Future You at 3am will not run an EDR scan after every browser extension install. The config that prevents the extension from being installed in the first place is the one that runs while you sleep: the MDM that whitelists, the disk encryption that protects what gets stolen, the hardware MFA that survives the keylogger.

MDM is the table you set first

Mobile Device Management is the thing every small startup skips and every enterprise has. The bad-faith reason is that it's expensive and annoying. The honest reason in 2026 is that the free options have caught up.

For a 15-person Apple-heavy team, the lazy stack is Apple Business Manager (free, Apple-only) plus Fleet (OSS, free under 300 endpoints on the self-hosted path, generous free tier on Fleet's cloud). Apple Business Manager assigns a Mac to your organization at first boot, before the user creates a personal Apple ID on it. Fleet runs the osquery agent on every machine and lets you push configuration profiles (the same plist payloads Jamf would push) plus query inventory in SQL syntax.

The lazy default config profile, in plain English:

Require FileVault. Escrow the recovery key to MDM. If the laptop walks, the disk is encrypted; if the user forgets the password, you can recover.
Require auto-lock at five minutes idle, password to wake. Not a screensaver.
Block unsigned package installs, restrict the Mac App Store to managed Apple IDs only.
Require macOS updates within fourteen days of release. The fourteen days lets you skip a known-bad point release; longer than fourteen is negligence.
Block AirDrop on the corporate Wi-Fi, restrict USB external storage to read-only (or block entirely if your workflow doesn't need it).
Install osquery via MDM, enrolled to your Fleet server.

For Linux and Windows in the mix, Fleet covers both with the same osquery agent and the same query syntax. The MDM-config-profile half is Windows Intune (free with Microsoft 365 Business Premium) or Workspace ONE's free tier. Either way, the stack is "Fleet for inventory and detections + a platform-specific MDM for enforcement."

The lazy fix for the most common gap: a weekly cron that runs one Fleet query, "every laptop without FileVault enabled," and posts a Slack alert with the user's name. The conversation that follows is "we found your machine, can you enable it today" — not a six-month audit.

hardware keys, one-time spend

YubiKey 5 NFC is $50. Buy two per engineer: one for the desk, one for the bag. Total for 15 engineers: $1,500, one-time, capital expense, deductible.

What it gets you:

WebAuthn / FIDO2 for SSO login (Google, Okta, GitHub, Cloudflare, AWS): a keylogger can record every keystroke and still never get the second factor.
SSH key storage in hardware. ssh-keygen -t ed25519-sk -O resident writes the key into the YubiKey. The private key never exists on disk.
PIV smartcard for VPN auth, code signing (gpg --card-edit).
TOTP fallback for the SaaS that hasn't shipped WebAuthn yet.

The free alternative for the SaaS that doesn't support hardware keys is passkeys. Passkeys are WebAuthn under the hood, also phishing-resistant, built into iOS, macOS, Android, Windows Hello, Chrome, and Safari. Free. The catch is sync: if the engineer's iCloud is compromised, so is the passkey. Hardware keys aren't synced; they are a physical token. The lazy answer is both: passkeys for low-risk auth, YubiKeys for the keys that gate production.

Cost: $1,500 one-time for 15 engineers. The cheapest line item in this post for what it gets you.

EDR is where the budget goes

Endpoint Detection and Response is the part of this stack that costs real money. For OSS-only, the answer is osquery + Wazuh, which works but requires writing detections by hand. For a 15-person team with one platform engineer, "write your own EDR detections" is not a project anyone will finish.

The honest 2026 small-team answer is Microsoft Defender for Business at $3/user/month. It ships in Microsoft 365 Business Premium (also useful if you're on M365 anyway), has acceptable macOS coverage, and includes managed detections written by Microsoft's security team. Cost for 15 engineers: $540/year. CrowdStrike Falcon Go is $60/endpoint/year if you want best-in-class detection at small-team scale; same math, $900/year for 15.

Fig. 2 — three configurations. Pick the middle bar unless you have a reason.

The lazy stance: Defender for Business if you're on Microsoft 365 already. Falcon Go if you're not on M365 and want managed detection without the OSS-engineer overhead. osquery + Wazuh only if you have a security engineer with bandwidth to maintain the detections, which most 15-person startups don't. Pretending otherwise is how you end up with a fancy SIEM nobody reads.

the password manager and browser hygiene argument

1Password Business at ~$8/user/month. Bitwarden Teams at $4. Apple Passwords (or 1Password Families) if you're Mac-only and don't need shared vaults. Pick one and stop arguing about it on the team's #tools channel.

The point of the password manager isn't strong passwords. The point is:

One place for credentials, audited.
Shared vaults for vendor logins, instead of "share the password in Slack DM" hygiene.
Breach notifications when a saved password appears in a public breach corpus.
Masked email aliases (1Password feature, Apple's Hide My Email equivalent): every signup gets a separate alias, every spam list is contained.

Browser hygiene matters because the Snowflake infostealer harvested credentials from browser local storage. Specifically:

Enforce browser auto-updates via MDM. Both Chrome and Edge expose policy keys for this; Firefox via policies.json.
Block sync of work browser profiles to personal Google/Apple accounts. The "I signed into Chrome with my personal account and now all my work bookmarks are in someone else's cloud" leak is real.
Block "developer mode" extension installs. Force extensions to come from the Chrome Web Store; force the Web Store to honor the org's allowlist via the ExtensionInstallAllowlist policy.
Disable browser password saving entirely. Everything routes through the password manager.

Total: $1,440/year for 15 engineers on 1Password Business. $720 on Bitwarden Teams. $0 on Apple Passwords if it covers your needs. Pick a line and walk it.

the personal device problem

The Snowflake breach was about contractors using personal Macs for work. The lazy answer at a 15-person startup might surprise: corp-issue every contractor a laptop. Yes, including the four-hour-a-week consultant.

A refurbished MacBook Air with 16GB RAM is roughly $700 from Apple's Certified Refurbished store. The cost of a Snowflake-scale breach starts at $370K (the reported AT&T ransom) and ends in the customer-churn and legal-exposure column. The break-even point on hardware-for-contractors is under three serious incidents, ever.

Fig. 3 — same laptop, different enrollment. The right panel is the one where Mandiant doesn't write your name down.

What "no work on personal devices" actually requires:

Contract clause: hardware is issued, personal-device use for work is prohibited.
MDM enrollment at first boot via Apple Business Manager (or Windows Autopilot).
Disabled iCloud personal sign-in; only managed Apple IDs.
Wipe via MDM on offboarding, before reissue.
No "I can just SSH from home for ten minutes" escape hatch. The escape hatch is what the contractor will use the day they get phished.

This is the section of the post that gets the most pushback. The pushback is right about cost and wrong about risk. Run the math at your scale; it runs the same direction every time.

the receipts

For 15 engineers, the first-year laptop security budget:

YubiKey 5 × 30 keys (two per engineer): $1,500, one-time.
Fleet (OSS self-hosted on a small VPS): $240/year.
Microsoft Defender for Business: $540/year. Substitute Falcon Go at $900 if not on M365, or osquery+Wazuh at $0 if you have a security engineer.
1Password Business: $1,440/year. Or Bitwarden Teams at $720. Or Apple Passwords at $0.
Refurbished corp laptops for non-employee contractors: ~$700 per, as needed.

Total recurring: roughly $1,020–$2,220/year for 15 engineers, depending on the EDR and password-manager line. Add the one-time YubiKey spend and the first year lands at $2,520–$3,720. Call it $14–$21 per engineer per month.

What it catches: every infostealer that hits a managed laptop (Defender flags it), every credential that lives in the browser (replaced by the password manager), every login that doesn't have phishing-resistant MFA (the YubiKey is required), every personal device touching production (blocked by the no-BYOD policy).

What it doesn't catch: a determined adversary with physical access and unlimited time. A laptop in a hotel room with no FileVault is owned. A laptop with FileVault and a YubiKey left in the USB-A port overnight is owned slower. Neither situation is what this stack is built for; it is built for the infostealer that landed on the contractor's personal Mac.

If you do one thing this week, buy two YubiKeys for yourself, enroll them on GitHub, Google, and Okta, and turn off SMS-based MFA on each. Total cost: $100, one hour. Then do the rest of the team next quarter.

Lazy SRE's guide to secure systems, part 4: the four DNS records

Harshit Luthra — Mon, 18 May 2026 16:58:36 +0000

Originally published at harshit.cloud on 2026-04-26.

In February 2024, Guardio Labs published a writeup of a campaign called SubdoMailing. Five million phishing emails a day, sent through subdomains owned by MSN, eBay, VMware, NYC.gov, UNICEF, and McAfee. Every single email passed SPF and DKIM. Every one of them passed DMARC.

The attack didn't break those protocols. It used them. Each victim domain had an include: line in its SPF record pointing at a contractor's domain that had been allowed to expire. The attackers re-registered the orphan, inherited the trust, started sending. Some of the broken include: chains had been broken for over a year — Guardio dated the operation back to at least late 2022. Nobody had thought to read their own SPF record again after writing it.

This is part 4. Earlier parts covered npm (Part 1), GitHub Actions (Part 2), and identity, network, and audit logs (Part 3). Part 4 is four DNS records and two monitors. One afternoon to write them, three weeks for DMARC to ramp safely. Zero ongoing cost. Closes the entire phishing-impersonation class and the entire rogue-certificate class at the same time.

Future You at 3am will not investigate an SPF chain when finance forwards a wire-transfer email. The records that run in their place will.

SPF, and the include trap

SPF stands for Sender Policy Framework. The record lives in DNS as a TXT entry on your apex domain. It declares which IP addresses or domains are allowed to send email on your behalf. The receiving mail server checks the sending IP against the list. The check passes or it fails. That is the entire protocol.

The record itself:

yourorg.com TXT "v=spf1 include:_spf.google.com include:mailgun.org -all"

v=spf1 is the version marker. include: delegates to another domain's SPF record, which expands at lookup time to that vendor's actual IP allowlist. -all says anything not listed is hard-fail.

That last token matters. -all (hard-fail) tells receivers to reject anything not on the list. ~all (soft-fail) tells them to mark it suspicious but maybe deliver anyway. ?all (neutral) tells them you have no opinion. Every getting-started guide ever written defaults to ~all "to be safe." The major receivers have said for years that they treat ~all and -all the same in scoring. The lazy answer is -all. The only reason to use ~all is during a migration when you can't yet enumerate every legitimate sender.

The SPF spec has a ten-DNS-lookup limit. Every include: counts, recursively. If you chain five SaaS senders (Google + Mailgun + Postmark + SendGrid + Stripe), each one's include: expands into its own record, which may include another, and you can blow the limit without realizing. When you blow the limit, the record evaluates as permerror, and many receivers treat that as "no SPF," which means anyone can spoof you. Tools like dmarcian.com/spf-survey count the lookups for free. Audit yours.

The SubdoMailing failure mode is what happens when one include: points at a contractor whose domain you don't control. The contractor goes out of business. The registration expires. Someone buys the lapsed domain. They publish their own SPF allowlist. Your domain now declares that the buyer is an authorized sender for you. Every email they send passes SPF. The fix is to audit your include: chain quarterly: does every domain in it still belong to someone you trust? Most teams have never done this once.

DKIM, in DNS

DKIM (DomainKeys Identified Mail) is a cryptographic signature on every outbound email. The signing key is a public/private keypair. The private key lives in your mail server (Google Workspace, Microsoft 365, Postmark, your own Postfix, whatever). The public key lives in DNS, under a selector subdomain.

selector1._domainkey.yourorg.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

The selector (selector1 here) is so you can rotate keys. Publish a new selector, switch the mail server to sign with the new private key, leave the old selector live for a week so in-flight emails still verify, then retire it. Most providers handle this rotation for you once the original selector is configured.

Two things go wrong in practice. First, key length. RSA-1024 was the standard a decade ago and is now considered weak; RSA-2048 is the current default. Some old DKIM records still publish 1024-bit keys, and many major receivers now fail or ignore 1024-bit signatures. Audit with dig TXT selector1._domainkey.yourorg.com. Second, third parties signing on your behalf without your knowledge. If finance connects a new SaaS tool that sends email as noreply@yourorg.com and nobody sets up DKIM for that path, that vendor's emails will fail DKIM alignment. Receivers see a domain with DKIM mostly working and one path failing, which is often enough to flag the whole domain in spam filters.

Most providers (Google Workspace, Microsoft 365, Postmark, Mailgun, SendGrid) make DKIM publishing a checklist item in their onboarding. If a vendor doesn't, that is a signal about the vendor's sophistication, not yours.

DMARC, the part that does the work

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer on top of SPF and DKIM. It tells receivers what to do when SPF and DKIM checks fail, and it tells you, via aggregate reports, what's happening to your domain in the wild.

A minimal DMARC record:

_dmarc.yourorg.com TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourorg.com; pct=100; adkim=s; aspf=s"

The fields that matter:

p=reject: policy for emails that fail both SPF and DKIM on the apex. Three values, none (just report), quarantine (deliver to spam), reject (drop). The end state is reject. The path is none → quarantine → reject.
sp=reject: same policy for subdomains. This is the SubdoMailing detail every public DMARC how-to forgets. A domain with p=reject but sp=none is wide open for subdomain abuse. Set both.
rua=mailto:: where aggregate reports get sent. Free DMARC report parsers (Postmark, dmarcian, EasyDMARC) accept these and render them as human-readable summaries.
pct=100: fraction of failing mail to apply the policy to. Start at 25% during the ramp, end at 100%.
adkim=s and aspf=s: strict alignment. The From-address domain must match the DKIM signing domain (and SPF return path) exactly. The default is relaxed, which lets subdomains substitute. Strict is what you want unless something is breaking.

The ramp from p=none to p=reject is what takes three weeks. The risk is breaking a legitimate sender path you didn't know existed. Week one, publish p=none; pct=100. Receive DMARC aggregate reports for seven days. Identify every IP and From: domain that sent on your behalf. There will be three or four you didn't expect: a newsletter platform finance signed up for, an HR tool, a calendar invite system. Onboard each into SPF and DKIM. Week two, move to p=quarantine; pct=25, watch reports for new failures. Week three, p=reject; pct=100. Done.

Fig. 2 — BEC losses by year, U.S. only. The 2024 number exceeded ransomware.

Most small teams stop at p=quarantine and never finish the ramp. The difference between quarantine and reject is whether the attacker's spoofed wire-transfer email lands in the CFO's spam folder or never enters the mail system at all. Spam is where employees go to recover legitimate mail that was filtered too aggressively, which means they go there to fish out emails they want to trust. Reject is the answer.

CAA, two lines to gate cert issuance

CAA (Certification Authority Authorization) is a DNS record that names which Certificate Authorities are allowed to issue TLS certificates for your domain. Without one, any publicly trusted CA in the world can issue a cert for your domain to anyone who passes that CA's domain-validation challenge. With one, only the CAs you've named can.

yourorg.com CAA 0 issue "letsencrypt.org"
yourorg.com CAA 0 issuewild "letsencrypt.org"
yourorg.com CAA 0 iodef "mailto:security@yourorg.com"

issue restricts standard certificates. issuewild restricts wildcard certificates. iodef is where notifications are sent when an unauthorized CA tries to issue. If you use multiple CAs (one for ACM in AWS, one for Let's Encrypt in your edge, one for Cloudflare-managed certs), list them all:

yourorg.com CAA 0 issue "letsencrypt.org"
yourorg.com CAA 0 issue "amazon.com"
yourorg.com CAA 0 issue "digicert.com"

CAA cannot prevent a misbehaving CA from issuing anyway. But CAs are required by the CA/Browser Forum baseline requirements to honor CAA at issuance time. They mostly do. When they don't, the misissuance ends in a Mozilla CA-incident bug report and eventual CA distrust. CAA exists so that legitimate misissuance is detected (because the CA you named never issued the cert and the issuing CA broke the rule) and accidental misissuance is structurally impossible. Both buy you something.

Cost: three DNS lines. Effort: ten minutes. Catches a class of attack (man-in-the-middle via misissued cert) that most teams have no other defense against.

the monitors

Two streams pay back the four records.

First, certificate transparency log monitoring. Every publicly trusted CA is required to log every certificate they issue to public append-only logs. crt.sh is a free queryable index. The certstream Python library streams new entries in real time, also free. Cloudflare offers free CT monitoring for any domain on its DNS. Whatever you pick, the workflow is: cert is issued for *.yourorg.com → log entry appears within seconds → your monitor pages a Slack channel → you check whether you issued it. If you didn't, that is an incident, not a notification.

Fig. 3 — the whole afternoon, sketched. Plus what runs after.

Second, DMARC aggregate report parsing. The rua= address in your DMARC record receives daily XML reports from every receiver. Reading the XML raw is unpleasant. The free tiers of Postmark, dmarcian, and EasyDMARC all accept the report stream and render it as "here are the IPs that sent as you this week, here are the ones that failed alignment, here are the new ones since last week." The new-sender alerts are where you find out that someone in marketing has connected a SaaS tool that's now sending emails as you, failing alignment, and getting your domain reputation downgraded.

A weekly fifteen-minute review of both monitors is what good looks like at a 25-person team. The cost is fifteen minutes a week. The product is "we'd have noticed if someone issued a cert for our login subdomain on Tuesday."

the receipts

Four DNS records. Two monitors. One afternoon for the records, three weeks for the DMARC ramp, fifteen minutes a week for the reviews. Cost: zero, unless you upgrade past the free tier of a DMARC parser at $15–$50 a month, which is the only thing on the list that's not free.

What this catches: every attempt to send email impersonating your domain from outside your authorized sender list, every attempt to issue a TLS cert for your domain from an unauthorized CA. The FBI's 2024 IC3 report attributed $2.77B in U.S. business email compromise losses to roughly 21,000 incidents — a $129K average. The fraction of those that would have been caught by a domain publishing p=reject; sp=reject with an honest SPF audit is enormous.

What it doesn't catch: phishing from a lookalike domain (yourorg-corp.com, yourorg-support.com, yourorg.co). Lookalike-domain defense needs a paid monitoring service at the tier that matters, and there's no free version that works at small-team scale. Skip it until you have a budget line for security. Note it in the runbook.

If you do one thing this week, publish _dmarc.yourorg.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourorg.com" and point the address at a Postmark free-tier DMARC inbox. Read the first report in seven days. The list of senders you didn't know about is the answer to "why has this been skipped for two years."

Lazy SRE's guide to secure systems, part 3: the unsexy list

Harshit Luthra — Mon, 18 May 2026 16:58:21 +0000

Originally published at harshit.cloud on 2026-04-19.

I have a calendar reminder that fires on the first of every month. It says "rotate the PAT." I have hit "snooze for 1 week" seventeen times in a row. The PAT in question is a ghp_ token with read-write access to four private repos and permission to push tags, and the last time I rotated it was October 2024. If anyone has phished my GitHub session in the past fifteen months, they have had a year's head start on me.

This is part 3. Part 1 was npm. Part 2 was GitHub Actions. This part is the unsexy list: the controls that don't fit a single attacker narrative, that protect against many different classes of incident in small ways. Identity, network access, default credentials, attestation, the audit log you'll need when the rest of the series missed what you needed it to catch.

The thesis from Part 1 stands. Future You at 3am will not rotate the PAT. The config that makes the rotation unnecessary (short-lived expiry, fine-grained scope, SSO enforcement, audit streaming) is the one that runs while you sleep.

the PAT you forgot is in four places

Personal-access tokens hide in more places than I want to think about. Mine, when I went through them this weekend:

~/.netrc (the one git falls back to when no credential helper is set)
~/.zshrc, exported as GH_TOKEN because some script three years ago needed it
Mac Keychain, two duplicates, one expired in 2023 but the dialogue still surfaces it
A .env in a repo I haven't pushed to since last summer, committed in plaintext to the staging branch (git log -S 'ghp_' finds these surprisingly often)
One CI secret in a repo whose workflow file I deleted six months ago; the workflow went, the secret did not

That's five, not four, which is on-brand for this section.

The fix isn't "rotate them all." It's "make the next leak useless." Three configs at the org level do the work.

First, require expiration on all PATs. GitHub org settings → Personal access tokens → Require an expiration date; set the org max to 90 days (GitHub's platform ceiling is 366, but 90 is the right org default). Tokens issued before the setting keep working until their original expiry, so old tokens die naturally as they age out. No big-bang migration.

Second, enforce SSO on the org. A leaked PAT without an active SSO session can't reach SSO-protected repos. Most SaaS git-hosted orgs should have this on already; if yours doesn't, that is the highest-yield ten minutes in this post.

Third, stream the GitHub audit log somewhere SQL-shaped, with two-year retention. The default is six months. You will want eighteen months of history exactly when you need eighteen months of history. The question "did this token get used last week?" should be a query, not a support ticket.

The thing that took me longest to learn is that fine-grained PATs (github_pat_ prefix, not ghp_) let you scope a token to one repo with read-only contents and nothing else. The default scope (full account) is what turns a leaked PAT into a domain compromise. To stop typing ghp_ into shells entirely:

# ~/.gitconfig
[credential]
  helper = !gh auth git-credential
[url "https://github.com/"]
  insteadOf = git@github.com:

gh auth login once, and git push works for the rest of your career. The PAT now lives in one place: gh's keyring entry, scoped to your machine, rotated by gh whenever it likes.

identity is the perimeter

SSO + MFA + SCIM is the only thing on the unsexy list that competes with the PAT story for "worst yield from neglect." A single phished password without these is a domain admin compromise. With them, the same phish gets the attacker a soup of session cookies that expire in eight hours and an MFA prompt they can't satisfy.

The three configs, in rough order of cost:

MFA, mandatory, no exceptions. Including the founder, including the contractor, including the on-call rotation. The exception list is the attack list.
SSO for every system that supports it. Yes, Okta SSO Tax is real. Yes, it is annoying. It is cheaper than rebuilding identity after a session-token compromise. Most of the Snowflake-customer breaches of 2024 started with a non-SSO'd account.
SCIM provisioning to every system that supports it. SCIM means offboarding actually offboards. The day someone leaves, every connected system revokes their access in the same SAML attribute push. Without SCIM, the median time to fully revoke at a small startup is days, and there is always one Postgres console nobody remembered.

Fig. 2 — the no-SCIM bar is the entire window of compromise.

One nightly cron closes most of the rest of the gap:

# nightly: diff "people on payroll" vs "humans with prod access"
okta-cli list-users --status active | sort > /tmp/active.txt
aws iam list-users --query 'Users[].UserName' | jq -r '.[]' | sort > /tmp/prod.txt
diff /tmp/active.txt /tmp/prod.txt | mail -s "identity-diff $(date +%F)" sec@yourorg.io

It runs in twelve seconds and surfaces the contractor whose SCIM hook silently broke in March.

the access plane: Tailscale, IAP, PrivateLink

Nothing internal needs to be on the public internet. Anything that isn't can't be scanned by Shodan, can't be hit by a credential stuffer, can't be 0-day'd by a CVE published yesterday. The configs are different per layer, but the move is the same: take the thing off the internet and put authentication in front of it.

For shell access and internal HTTP services, Tailscale. The pitch is honest. Install the daemon on every machine, write a twelve-line ACL, you have a private network without running a VPN appliance. Replace SSH-to-bastion with tailscale ssh. Replace the internal Grafana on grafana.yourorg.io with grafana.your-tailnet.ts.net. Both stop existing on the public internet the same afternoon.

For web apps that need real auth-aware proxying (customer-facing internal tools, vendor admin panels), Cloudflare Access or Google IAP. The user hits a public URL, the proxy hands them off to your IdP, then proxies the request to a private backend. The backend has no public route.

For service-to-service inside cloud accounts, AWS PrivateLink and GCP Private Service Connect. These exist so your stripe-receiver lambda doesn't need to leave the VPC to reach Stripe's API. They are also what you need so the data warehouse in account A can reach the production database in account B without anything traversing the public internet.

Fig. 3 — same services, different boundary. The right panel is whatever Future You at 3am will thank you for.

The anti-pattern is the "we'll just rotate the bastion IP" security group. We won't. The credentials for the bastion are in a Slack channel from 2023. The bastion is one of those things that exists because someone set it up before everyone joined and nobody knows whether it's safe to turn off. The lazy answer is to make the bastion irrelevant.

the helm chart that ships with admin/admin

Every operator-installed thing in the cluster has a default password. Argo CD's admin with auto-generated password is fine, because the password isn't admin. Grafana's chart that ships with admin/admin is not fine. Jenkins ships with a random initial password printed to initialAdminPassword that most operators copy in once and never rotate. Half the database charts have password: changeme in values.yaml and the README says "you should change this," which is not the same as the chart changing it.

The lazy fix is two configs.

First, every secret in the cluster comes from external-secrets or sealed-secrets, never from a values.yaml. Pick one. The choice matters less than the consistency. Mine is external-secrets pointing at Vault, because reconciliation handles rotation upstream and the YAML stays clean.

Second, a weekly cron that hits every Service in the cluster with the top 25 default credentials and pages on success. nuclei ships a template set for this:

nuclei -t http/default-logins/ -l services.txt -severity critical,high

If it finds something, that's a real incident. If it doesn't, you have evidence, which is the audit-log argument postponed by one section.

One honest aside in parentheses: the rate at which Helm chart maintainers have moved away from default passwords is encouraging. Bitnami's PostgreSQL chart now generates a random password by default instead of changeme. The chart that ships with admin/admin today is more likely to be a private internal chart someone wrote three years ago than something current from Bitnami. (Note: the official Grafana chart still defaults to admin/admin — override it via Helm values before first install; "I'll change it later" is the part nobody does.) Check the internal charts first.

sigstore, provenance, and reproducible builds

Part 1 ended on "the next-tier defenses are real, Part 3 will name them." These are them. Sigstore signing, npm provenance, reproducible builds. Each closes a class of attack that pinning and cooldowns can't.

Sigstore for container images. cosign verify confirms an image was built by your specific GitHub Actions workflow, with your repo's OIDC identity, against a transparency-log entry that's public and append-only.

cosign verify ghcr.io/yourorg/api:abc123 \
  --certificate-identity-regexp '^https://github.com/yourorg/api/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

If an attacker pushes a malicious image to your registry without also compromising your CI's OIDC trust, the verify fails. Bake the verify into your deploy step; refuse to deploy what doesn't pass. That is the attested-deployment pattern Part 2 named, in one verb in your CD pipeline.

npm provenance. npm audit signatures (since npm 9.5) tells you which dependencies have published provenance attestations linking the .tgz to a specific GitHub Actions build. A package with provenance gives you a tamper-evident chain: this artifact came from this commit on this branch in this repo, built by this workflow. Coverage is uneven (most @types/* packages have it; most one-maintainer packages don't), but the trend is good. The number to track is "what fraction of my install graph has provenance?" That's your remaining audit surface.

Reproducible builds. The hardest of the three. Same source produces the same binary, bit-for-bit, on every build machine. Two implementations have shipped at scale: Debian's reproducible-builds program (reproducible-builds.org tracks coverage by package) and Nix. The lazy version, for a small team, is to build the production artifact twice on two different runners and compare hashes. If they match, your CI is reproducible enough to detect a poisoned-build attack. If they don't, you have a non-determinism bug to fix, which is also worth knowing about.

audit logs are for after the incident

Part 2 ended on "Part 3 will name the controls that exist to make the postmortem readable, not to prevent the incident." This is the section. Audit logging is what tells you whether everything in the previous six sections actually worked, what got accessed when one of them didn't, and which credential to roll at 03:11.

Three streams, all of which support direct destination handoff:

GitHub's audit log to S3, Splunk, Datadog, or whichever SQL-shaped destination you'll actually query. Settings → Audit log → Streaming. Default retention is six months; you want two years. The same goes for Okta's System Log (Reports → System Log → Stream).

AWS CloudTrail to a separate audit account, write-only from production, S3 with Object Lock and KMS-encrypted. Multi-region. The level of paranoia required is "this bucket survives a full prod-account compromise." GCP and Azure have equivalents (Cloud Audit Logs, Activity Logs).

Application audit. Stripe webhook history, Slack audit log, Google Workspace audit log. Each is one config and one Splunk index. The marginal effort approaches zero. The payoff is the difference between a one-page incident summary and a six-week panic.

The runbook for "we think we had a breach Thursday" is then a SQL query against a known schema. Without these, it's an interview with everyone who had access.

the receipts

The unsexy list is one afternoon, one quarter, and one year. The afternoon: PAT cleanup, SSO/MFA mandatory, GitHub audit log streaming on. The quarter: SCIM provisioning everywhere, Tailscale on every internal service, external-secrets across the cluster. The year: sigstore for your images, an npm audit signatures report tracked weekly, reproducible-build hash comparison in CI.

It will not catch a nation-state with patience. It will not catch an insider with a grudge. It will not catch the next Log4j the day it lands. Those are different problems with different budgets, and worth a separate post when one of them happens to one of us.

What it does: it makes the postmortem on your next incident readable. It moves "we don't know what got accessed" out of the executive summary and into "Appendix A, the SQL query." For a small team, that is the difference between recovering and rebuilding.

If you do one thing this week, generate a fresh fine-grained PAT scoped to one repo with a 90-day expiry, switch your gh auth login to it, and delete the eight-year-old ghp_ from your ~/.zshrc. The calendar reminder won't help. Future You at 3am will not rotate it. Make the wrong default impossible.

Lazy SRE's guide to secure systems, part 2: the actions you didn't pin

Harshit Luthra — Mon, 18 May 2026 16:58:05 +0000

Originally published at harshit.cloud on 2026-04-12.

Last March, someone with write access to the trivy-action repo rewrote 76 of its 77 version tags in place. The tags still resolved to aquasecurity/trivy-action — they just resolved to different commits than they did the week before. Every pipeline that ran aquasecurity/trivy-action@0.20.0 (and every other tagged version) ran the attacker's commit instead. Secrets exfiltrated. The stolen credentials chained into PyPI and took down LiteLLM. Nobody noticed for hours, because the workflow file diff was still clean.

This is part 2. Part 1 covered npm: the dependencies you didn't read. Part 2 is the same problem one level up: the workflows you didn't pin. Part 3 is the unsexy list — Tailscale, PrivateLink, IAP, the PAT you forgot.

The thesis from Part 1 stands. The best security work for a small team is the work Future You at 3am will actually execute. The configuration that makes the wrong thing impossible beats the runbook that only discourages it. With GitHub Actions, "the wrong thing" has gotten very specific over the last twelve months, and the configs to block each variety have gotten correspondingly precise.

pinning is necessary but not sufficient

The first thing the trivy-action incident proves: hash-pinning to @0.20.0 is not pinning. It's a name lookup. The owner of the repo is allowed to rewrite that name. The pin you actually wanted was:

- uses: aquasecurity/trivy-action@9b9a3f5c8a5c7e1b6e4d2f1c9b8a7e6d5c4b3a2f # v0.20.0

Full forty-character SHA. Immutable. The version comment is so the next reader knows what they're looking at; the SHA is so the workflow runs the code you reviewed.

Two GitHub features shipped in 2025 that change the math:

SHA pinning enforcement (Aug 2025). An org-level policy that fails workflow runs using unpinned actions, instead of warning about them. Settings → Actions → General → Action pinning. Turn it on. There is no "we'll get to it" version of this toggle.
Immutable Releases (Oct 2025, GA). Action authors opt in to making release tags non-rewritable after publication. If you publish actions, turn this on for downstream consumers. If you consume actions, prefer ones that have.

The lazy stance: enforcement at the org level. The workflow that doesn't have a forty-character SHA fails the run. The PR can't merge. The work of remembering to pin moves from every engineer's head to one setting.

What this doesn't catch: an attacker who compromises the maintainer account and ships a new tag at a new SHA. The SHA is real. Pinning by SHA doesn't help, because the workflow author will rev to the new version when they read the maintainer's release notes. Which is the next config.

cooldown is the same trick that worked for npm

Part 1's load-bearing config was SAFE_CHAIN_MINIMUM_PACKAGE_AGE_HOURS=48. The principle: most published malware is detected and pulled within hours. If you can wait, the wait does the work for you.

The action ecosystem has the same property, with a longer window. yossarian's analysis puts the cooldown that catches most supply-chain attacks at 7-14 days. So:

pinact --min-age 7 .github/workflows/*.yml

Refuses to write a pin younger than seven days. Add to pre-commit, your CI lint, or whatever your dependabot equivalent runs before opening the bump PR.

For Renovate users, the equivalent lives in the action manager:

{
  "packageRules": [
    { "matchManagers": ["github-actions"], "minimumReleaseAge": "7 days" }
  ]
}

That's it. Same trick, different ecosystem.

Fig. 2 — the wait is doing the work. Seven days closes most of the door; fourteen closes most of the rest.

The empirical question is whether seven days is enough. The trivy-action force-push was detected at about nine — seven would have caught most consumers, not all of them. The cost of fourteen is "your action versions lag upstream by two weeks." If your action surface is small (most teams are running actions/checkout, actions/setup-node, one cloud-login action, maybe a deploy action), set fourteen and forget.

pull_request_target is the new postinstall

Part 1 named postinstall as the single trigger that does the most damage and the single switch (ignore-scripts=true) that closes the most doors. Actions has the same shape and the same fix.

pull_request_target runs in the context of the base repository, with access to repository secrets, but is triggered by a PR from a fork. The legitimate use case is small: comment on PRs, label them, run lightweight metadata jobs. The illegitimate use case is enormous: check out the fork's code and execute it. The attack writes itself. Open a fork, modify a script the trusted workflow runs, watch the runner exfiltrate every secret in the env.

Astral, who maintain uv and ruff, wrote it cleanly: "these triggers are almost impossible to use securely." GitHub partially mitigated this in November 2025 by forcing pull_request_target to always use the default branch's version of the workflow, so an attacker can't push a vulnerable workflow on a feature branch and trigger it. But the foot-cannon still ships loaded if your default-branch workflow checks out PR-head code.

Fig. 3 — same workflow, different trigger, opposite blast radius.

The lazy stance:

Don't use pull_request_target unless you've named the specific reason and one other person has signed off.
If you do, never actions/checkout the PR head from inside it. Check out the base SHA, do the metadata thing, exit.
For everything else, use pull_request. It runs without secrets. Attacker-controlled code stays attacker-jailed.

Same shape as ignore-scripts=true. The setting that closes the class.

the safe defaults that go in every workflow

The four-line workflow header that does the most work per character:

permissions:
  contents: read

defaults:
  run:
    shell: bash -euo pipefail {0}

contents: read overrides the org-level default. If a step needs to push a tag or open a PR, that job opts back up to contents: write explicitly. The default is the safe one.

At the checkout step:

- uses: actions/checkout@<sha> # v4.2.0
  with:
    persist-credentials: false

The default behavior of actions/checkout is to leave a credential sitting in .git/config for the rest of the workflow. Later steps have shipped this credential into uploaded artifacts more than once. Opt out unless a later step in the same job needs to push.

Three secret-access rules with the same flavor:

Step-scoped env:, never workflow-scoped, for any secret.
Never ${{ toJson(secrets) }}. Exposes every secret in the project to the runner. There is no use case.
Never secrets: inherit on reusable workflows. Pass each secret by name. The reusable workflow gets exactly what it asked for.

The trivy-action exfiltration worked partly because secrets were workflow-scoped. The malicious step inherited every credential in the env, not just the one the legitimate scan needed. Step-scoping wouldn't have prevented the credential theft — but it would have bounded the blast radius to one secret instead of all of them.

OIDC, the promise from part 1

Part 1 ended on "the next-tier defenses are real, Part 3 names them." OIDC is the part of that conversation that lives here.

The trade: instead of storing an AWS_ACCESS_KEY_ID in repo secrets and praying nobody exfiltrates it, you configure AWS to trust GitHub's OIDC issuer for a specific repo, branch, and workflow. GitHub mints a short-lived (five-minute) OIDC identity token for the workflow run. The workflow trades that for STS credentials whose lifetime you set (default one hour). Nothing long-lived ever sits in the env.

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@<sha> # v4.0.2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: us-east-1
      - run: aws s3 sync ./dist s3://my-bucket

The role's trust policy restricts the OIDC subject to your exact repo and (ideally) branch. An attacker who compromises a fork PR can't assume the role, because they don't match the trust condition. The OIDC JWT itself lasts five minutes and the STS credential is scoped to whatever you configure (default one hour). Even an exfiltrated credential gets the attacker a bounded window of scoped access, not a permanent IAM user.

For Google Cloud, the equivalent is Workload Identity Federation. For HashiCorp Vault, the JWT auth backend. Same shape across providers.

The labor here is genuinely one-time. Configure the trust relationship once per repo, delete the long-lived key, forget about rotation forever. The rotation runbook you're not maintaining is one of the better quiet wins in this post.

zizmor is the local proxy for workflows

Part 1's safe-chain sat in front of every package install and refused malware before bytes hit disk. The action ecosystem's equivalent is zizmor — a workflow linter that reads your YAML and catches the patterns this post is about, before they merge.

brew install zizmor
zizmor .github/workflows/

It catches unpinned actions, pull_request_target with PR-head checkouts, template-injection patterns where attacker-controlled input lands in a run: string, jobs with excessive permissions. Add it to pre-commit:

# .pre-commit-config.yaml
- repo: https://github.com/woodruffw/zizmor-pre-commit
  rev: v1.x  # pin the rev, obviously
  hooks:
    - id: zizmor

The principle is identical to safe-chain. Move the security check from "after the incident, in the postmortem" to "before the PR can merge, on the dev machine." The CI run is the second line of defense. The pre-commit is the first.

the receipts

The above stack is approximately one afternoon: org-level SHA pinning enforcement, pinact --min-age 7 or Renovate minimumReleaseAge: 7 days, the four-line workflow header, persist-credentials: false, no pull_request_target with PR-head checkouts, OIDC for every cloud credential, zizmor in pre-commit.

It will not catch a maintainer-account compromise that ships clean-looking code which activates weeks later. It will not catch a determined attacker who studies your build and writes a payload that survives every linter and looks innocent at PR review. Nothing in this post will. Part 3 will name the controls that buy partial mitigation against that class: sigstore, npm provenance, reproducible builds, attested deployments. And the ones that exist to make the postmortem readable, not to prevent the incident.

For a small team, the delta from this post is moving from "we're one tag-rewrite away from a credential theft cascade" to "an attacker would need a credentialed insider, or a fifteen-minute window of luck against a scoped IAM role." That's the only delta that matters at this scale.

If you do one thing this week, turn on SHA pinning enforcement at the org level. Everything else gates off that.

Blocking AI crawlers is the new 'noindex'

Harshit Luthra — Mon, 18 May 2026 16:57:19 +0000

Originally published at harshit.cloud on 2026-01-21.

If you're blocking GPTBot, Anthropic, Perplexity, Gemini — you're trading future reach for short-term control.

the math

AI search traffic today: ~1%
AI search traffic tomorrow: 25–35%

Let them crawl. Train the discovery layer. Be early.

common AI crawler user agents

Crawler	Company
`GPTBot`	OpenAI
`ClaudeBot` / `Anthropic-AI`	Anthropic
`PerplexityBot`	Perplexity
`Google-Extended`	Google (Gemini)

the robots.txt decision

Blocking these crawlers:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

Feels like control. Actually it's invisibility.

why this matters

When someone asks an AI "how do I do X" and your content isn't in the training data, you don't exist in that conversation.

The sites that trained the discovery layer early will own the AI search results later.

Visibility > invisibility.

Access denied: when your browser extensions look like attack vectors

Harshit Luthra — Mon, 18 May 2026 16:57:03 +0000

Originally published at harshit.cloud on 2025-12-31.

Last week I tried booking a flight on Indigo. Access Denied. Tried MakeMyTrip. Access Denied. Ixigo? Same story. Yatra? Blocked.

My banking apps worked fine. But every travel booking site using Akamai's CDN decided I was public enemy number one. Sometimes the site would load, then the OTP API calls would silently fail. Making a complete fool out of me at checkout.

the debugging rabbit hole

First thought: bad IP from my ISP's CGNAT pool. Changed my IP. Worked for 10 minutes. Then blocked again.

Second thought: maybe Akamai's IP reputation is flagging me. Checked their Client Reputation lookup.

Nope. Clean as a whistle.

Google dorking time. Found tons of users globally facing the same issue. Not ISP-specific. Not India-specific. Something else was up.

Then I found this blog that pointed at browser extensions. Interesting.

the lightbulb moment

Switched from Arc to Chrome. Still blocked. Because I carried over the same 21 extensions like a digital hoarder.

Here's my toolkit: Wappalyzer, Shodan, Trufflehog, DotGit, and a bunch of OSINT/greyhat recon tools. The same extensions I use for security research were making me look like an attacker to Akamai's Bot Manager.

Turned off all extensions. Instant access to every site.

what's actually happening

Akamai's Bot Manager isn't counting your requests. It's fingerprinting the client environment. Browser extensions can inject JavaScript, mutate the DOM, alter request behavior, and add tracking parameters — all things the client-side fingerprint will flag as bot-shaped, the same way it would flag a scraper or an injection probe.

My security toolkit became my own DoS attack vector. Poetic, really.

Some users reported User-Agent changes helped. I didn't test that. I also didn't have time to debug which of the 21 extensions was the actual culprit. Life's too short for that level of troubleshooting.

the takeaway

WAF rules are aggressive by design. Your legitimate security tools look exactly like attack vectors because, well, they kind of are. The line between security researcher and threat actor is thinner than we'd like to admit.

If you're getting blocked by Akamai with a clean IP:

Check your extensions first, not your ISP
VPN working temporarily? That's behavioral detection, not IP blocking
The Client Reputation tool won't catch extension-based triggers
Your OSINT toolkit makes CDNs nervous

Infrastructure is meant to keep bad actors out. Sometimes it keeps infrastructure wizards out too. Not fun.

VictoriaLogs vs Loki: real-world benchmarking results

Harshit Luthra — Mon, 18 May 2026 16:56:48 +0000

Originally published at harshit.cloud on 2025-11-19.

On 500 GB of logs over 7 days, on the same hardware: 94% lower query latencies, 37% smaller storage, and under half the CPU and RAM. The single number that surprised us most was the 12× drop in needle-in-a-haystack search times.

the setup

At Truefoundry we run multi-tenant ML workloads on Kubernetes. The log layer has to deliver fast ad-hoc search across mixed namespaces (often with no good labels to anchor on), sustained 60+ MB/s ingestion during deploys and incidents, and live tailing that doesn't fall behind during a noisy crash loop. It also has to run as a single binary — we don't want a six-component log stack — within a 4 vCPU / 16 GiB node ceiling shared with everything else.

Loki was our default. Past the 1M-active-series mark it started showing 30s+ search latencies and high I/O amplification. So we benchmarked it head-to-head against VictoriaLogs and let the numbers decide.

the contestants

Loki: Grafana Labs' log store. Compressed chunks, label-based indexing, LogQL. Brilliant Grafana integration; expensive regex scans and Go GC overhead at scale.
VictoriaLogs: VictoriaMetrics' columnar LSM log database. Per-field indices, SIMD search, LogsQL. Single binary, low memory footprint, efficient compression.

benchmark methodology

Category	Details
Hardware	4 vCPU / 8 GiB RAM, identical for both, QoS: Guaranteed
Log generator	flog → Vector → Loki / VictoriaLogs at 65 MB/s sustained
Dataset	~500 GB over 7 days; mix of unique and duplicated lines across 20 namespaces, 40 apps
Retention	7 days
Load test	Locust 2.27.1, 10 virtual users, sustained 43 RPS via `/select/logsql/query` and the Grafana datasource
Queries	Stats, Needle in a Haystack, Negative — detailed below
Caching	Block cache disabled on both; pods restarted before each run to simulate cold reads
Index tweaks	Defaults on both

the headline figure

Before the methodology debate, here's what the seven days produced.

The Grafana panels behind those numbers — same six metrics for both systems, two very different shapes:

Loki:

VictoriaLogs:

The memory line is the one that most directly translates into infrastructure cost. At steady state, VictoriaLogs sat around 1.3 GB while Loki held 6–7 GB. Freeing ~5 GB per node is the difference between bin-packing four tenants on a box and seven.

storage on disk

Same logs, same 7-day retention, identical ingestion path. Loki landed at 501 GB; VictoriaLogs at 318 GB — 37% smaller with no tuning on either side.

The difference is partly the codec — VictoriaLogs uses zstd, Loki defaults to snappy — but mostly the layout. Columnar storage finds redundancy that stream-chunked LSMs don't see; values from the same field compress together far better than values stitched in by line order.

At fleet scale this is a 1 TB volume holding what used to need 1.5 TB.

query performance

Three query patterns, run against the same 500 GB / 7-day index. Result sets were verified to be identical between the two systems.

1. stats — log count over 24 hours

Purpose: Total log lines from app="servicefoundry-server".

LogQL: sum(count_over_time({app="servicefoundry-server"}[24h]))
LogsQL: {app="servicefoundry-server"} | stats count()

System	Latency
Loki	2.5s
VictoriaLogs	1.5s

Aggregate counts hit Loki's strength — label-anchored, no text scan — and Loki still loses by 40% on the wall clock. VictoriaLogs holds its own on label queries; Loki has no answer for the others.

2. needle in a haystack — finding one line in 500 GB

Purpose: Locate a single static log entry [UNIQUE-STATIC-LOG] ID=abc123 XYZ in the truefoundry namespace over 7 days.

LogQL: {namespace="truefoundry", app!="grafana"} |= "[UNIQUE-STATIC-LOG] ID=abc123 XYZ"
LogsQL: {namespace="truefoundry", app!="grafana"} "[UNIQUE-STATIC-LOG] ID=abc123 XYZ"

System	Latency
Loki	12s
VictoriaLogs	~900ms

The single-character difference in syntax — |= vs nothing — hides the architectural one. Loki's |= is a substring filter run line-by-line over decompressed chunks. VictoriaLogs treats the same string as an index probe. 12 seconds turns into 900 milliseconds on identical hardware.

3. negative — proving a string doesn't exist

Purpose: Search for a string that doesn't appear anywhere in the dataset. Forces a full scan in both systems.

LogQL: {namespace="truefoundry"} |= "non-existent log line"
LogsQL: {namespace="truefoundry"} "non-existent log line"

Dataset	Loki	VictoriaLogs
500 GB	Timeout	2.2s
300 GB	2.6s	266ms

The negative query is the quiet one. At 300 GB Loki handles it in 2.6 seconds. At 500 GB the resources choke and the query halts — never returns. In production that's the difference between an alert that fires and a dashboard that loads.

ingestion under pressure

We pushed both with 120 flog replicas to find the ceiling.

Metric	Loki	VictoriaLogs	Delta
Peak ingestion	20 MB/s	66 MB/s	3× higher
vCPU (sustained)	4 vCPU, 100% throttled	2 vCPU peak	50% lower
Memory	~4 GiB	~1.3 GiB	3× lower

Loki hit the CPU wall first and never recovered — pinned at 100% throttled while still topping out at 20 MB/s. VictoriaLogs absorbed the same firehose at 3× the throughput, on 72% less CPU and 87% less memory.

load test under traffic

Locust, 10 concurrent users, simulating real read traffic. VictoriaLogs handled 36% more requests per second, p99 latency was 3.6× faster than Loki under load, and tail latency stayed lower at every percentile we measured.

why the gap is this big

Four design choices doing most of the work:

Full-text indexing. Per-token indices skip line-by-line filtering entirely.
Columnar LSM layout. Reads touch only the columns the query asks for; fewer disk seeks.
Memory discipline. Lower steady-state overhead means more headroom for everything else.
SIMD search. Vectorised inner loops on commodity CPUs add up over billions of lines.

when to pick which

VictoriaLogs is the right pick when text search and grep-style queries are the primary workload, when ad-hoc exploration across large windows matters, when resource efficiency and bin-packing density are real constraints, or when you want fewer knobs to tune in production.

Loki is the right pick when label-based queries dominate and full-text is rare, when deep Grafana ecosystem integration is non-negotiable, or when you already operate Loki at scale and the migration cost outweighs the wins.

For us, on this workload, the resource economics decided it. The freed memory per node became real infrastructure savings within a quarter. 12 seconds turned into 900 milliseconds with no tuning, and that's the number I keep quoting six months later.

resources

When Netlify killed my free tier: a 15-minute migration to Dokploy

Harshit Luthra — Mon, 18 May 2026 16:56:32 +0000

Originally published at harshit.cloud on 2025-10-24.

Late night. Got this email: "[Netlify] Your projects have been suspended due to credit limit exceeded."

Five sites down:

linkedintel.ai (LinkedIn Sales Intelligence AI for SDR's)
sachin.cool (rookie website from college time)
dilharia.love (wedding RSVP site - yes, judge me)
My personal blog
A ex-ceo's landing page

Netlify moved legacy free tier users to their new 300-credit plan. I burned through it in a week.

New option: $9/month for 1000 credits, or figure something else out.

I had 15 minutes before my girlfriend woke up. Here's what happened.

the €3 solution

Hetzner CX22: 2 vCPUs, 4GB RAM, 40GB SSD. €3.29/month.

Math was simple:

Netlify: $108/year for credit anxiety
Dokploy + Hetzner: $42/year for unlimited deploys

I'd been watching this Dokploy video the week before. Perfect timing.

the 15-minute panic deploy

Minutes 0-5: Spun up Hetzner in Helsinki. Got the IP. Updated DNS.

Minutes 5-8: SSH'd in, ran the Dokploy installer:

curl -sSL https://dokploy.com/install.sh | sh

One command. Dokploy installed Docker, Traefik, PostgreSQL, everything.

Minutes 8-12: Connected Git repos. Paste GitHub URL, select branch, done.

Minutes 12-15: Hit deploy on all 5 projects. Watched them come back to life.

The Fiance woke up. dilharia.love was live.

what surprised me

SSL just works. Traefik + Let's Encrypt provision certificates automatically. I'm running Cloudflare Full (Strict) mode - zero warnings.

WWW redirects? One checkbox. Netlify charged extra for this.

Logs and monitoring built-in. No Datadog bill. No "$500/month observability platform."

the catch

You own the ops. Server goes down? That's on you. No 99.9% SLA.

You handle security: OS updates, SSH keys, backups. I run apt upgrade weekly and backup to Backblaze B2 for $0.50/month.

For personal projects? Worth it. For business-critical stuff? Pay for managed services.

one month later

Server load: 8% CPU. Zero downtime. SSL renewals automatic.

All 5 sites running smoothly: linkedintel.ai pulling data, sachin.cool looking sharp, dilharia.love collecting RSVPs.

Deployed 3 more projects since then. No credit anxiety. No surprise bills.

Total maintenance time: 10 minutes/week.

Best infrastructure decision I've made this year.

Delivery impersonation: the social engineering vector that just works

Harshit Luthra — Mon, 18 May 2026 16:56:16 +0000

Originally published at harshit.cloud on 2025-10-17.

A few weeks ago, my mum got a WhatsApp call from someone claiming to deliver a Diwali hamper from a bakery she'd never ordered from. They asked for her live location to "route the driver". She sent it. Twenty seconds, full home address handed to a stranger.

why this attack works

The attack rides three psychological triggers at once. Mentioning a well-known local business creates instant credibility. Gift deliveries during festivals are common and expected, so the pretext doesn't trip anyone's filter. And "I'm outside and need directions now" prompts immediate action before the victim has time to verify anything.

the attack pattern

Attacker: "Hi, I'm from [Popular Local Bakery]. I have a Diwali gift
          hamper for you but I'm having trouble finding your location.
          Could you share your address or live location?"

Victim: Shares full address or WhatsApp live location without verification

No order confirmation requested. No delivery tracking number asked for. No verification of any kind.

why people fall for it

Gift context: during festivals, people expect surprise gifts from friends and family
Helpful nature: most people want to help someone who seems to be doing their job
Time pressure: the implied urgency ("I'm waiting outside") prevents critical thinking
Low perceived risk: sharing an address seems harmless compared to financial data
Trust in local brands: using a known local business name lowers suspicion

defense strategies

The defense is one habit: don't share an address until you've verified the order exists. Ask for a tracking number, call the business on its public number, ask who sent the gift and check with them. If the driver "needs directions right now", give a landmark, not a pin. Most delivery apps already have in-app chat — there's no good reason a real driver needs your live location over WhatsApp.

real-world impact

This attack can be used for:

Physical surveillance and stalking
Burglary planning (knowing when someone is home)
Identity theft (address is often used for verification)
Targeted phishing (now knowing exact location)
Physical security breaches

the asks that work

The pretexts that actually get through share a shape. A familiar local business name doing the credibility work. A plausible occasion — Diwali hampers, birthday flowers, Amazon redelivery — that fits the calendar. A small action framed as urgent: "I'm outside, just send the location". Zero technical skill, one phone call, full address.

Forem: Harshit Luthra

The git commands I actually run every day

the daily eight

gst

glola

gd / gds

gcam

gpsup

gco / gcb

gpf

gfa

the weekly five

git switch and git restore (the new commands)

interactive rebase with autosquash

git reflog, the universal undo

git worktree

branches sorted by recency

the cleanup ritual

the easy half: real merges

the hard half: squash-merges

the archeology pack

pickaxe, finding when a string appeared

git blame -w -C -C -C

git log -p --follow <file>

git range-diff

the "stop pasting from Stack Overflow" pack

turn on rerere

default to safer push

better diff and merge UX

maintenance, on a schedule

the three tools worth installing today

bonus: two AI shell helpers for the stuff git can't tell you

why split into two functions

the trick: print -z is what makes d safe

what it feels like

the three defensive details

ten years in, the surprise

A single zsh function for one-line AI answers that knows when to pre-type the command

the function

what it feels like

the key idea: print -z for runnable output

the heuristic: when is the answer a command?

the footgun: oh-my-zsh numeric aliases

defensive details that earn their keep

noglob on the alias

emulate -L zsh + setopt NO_GLOB

output sanitization

why "$*" and not "$@"

the system-prompt nudge actually matters

why this beats the chat UI for short questions

the one substitution that fixed it

How to bypass corporate MDM and AI gateways on Claude Code

what's an MDM, in three sentences

the managed-settings situation

why rm doesn't work

the cleanup script

the launchd arms race

the AI gateway angle

bypassing the gateway

should you actually do this

what these scripts don't do

Lazy SRE's guide to secure systems, part 5: the dev laptop is the perimeter

MDM is the table you set first

hardware keys, one-time spend

EDR is where the budget goes

the password manager and browser hygiene argument

the personal device problem

the receipts

Lazy SRE's guide to secure systems, part 4: the four DNS records

SPF, and the include trap

DKIM, in DNS

DMARC, the part that does the work

CAA, two lines to gate cert issuance

the monitors

the receipts

Lazy SRE's guide to secure systems, part 3: the unsexy list

the PAT you forgot is in four places

identity is the perimeter

the access plane: Tailscale, IAP, PrivateLink

the helm chart that ships with admin/admin

`git switch` and `git restore` (the new commands)

`git reflog`, the universal undo

`git worktree`

`git blame -w -C -C -C`

`git log -p --follow <file>`

`git range-diff`

the trick: `print -z` is what makes `d` safe

the key idea: `print -z` for runnable output

`noglob` on the alias

`emulate -L zsh` + `setopt NO_GLOB`

why `"$*"` and not `"$@"`

why `rm` doesn't work