That said, this is also what makes the space fun. It still feels like one big ongoing experiment, and I am very much learning in public with the rest of it. So rather than pretend I have found the one true setup, I thought it would be more useful to walk through the workflow I am using right now, what each tool does well, and where I think each one fits.

Tooling​

Here are the main tools I have been reaching for lately to get consistently better results.

superpowers

This is a skill and context system for Claude Code that has become the backbone of how I work with agents. The core problem it solves is context rot — the slow degradation in output quality that happens as a conversation gets longer, muddier, and further from the original intent.

What I like about superpowers is that it gives the agent a library of specialised skills to draw on. Rather than relying on a general system prompt and hoping the model figures out the right approach, you invoke a skill that already knows what good looks like for that kind of task. Planning a feature, debugging a tricky issue, doing a thorough code review — there is a skill for each, and they wire in the right structure automatically.

For example, if I want an agent to add a feature, it no longer just starts generating code. It invokes a brainstorming skill first, works out the approach, surfaces assumptions, and only then moves to implementation. That one shift alone gives me noticeably better output than jumping straight into code generation.

codegraph

This one surprised me more than anything else I have added to the workflow recently. Codegraph builds a pre-indexed knowledge graph of your codebase — locally, using tree-sitter to parse the ASTs — and exposes it to the agent via MCP. Instead of burning a chunk of context watching the agent grep and read files trying to figure out how things connect, it can just ask the graph directly.

The benchmark numbers are genuinely striking: 58% fewer tool calls, 22% faster, and file reads dropped to near zero. In practice that means the agent spends less time on discovery and more time on the actual problem. It also auto-syncs when the code changes, so it stays accurate without you having to think about it.

The thing I appreciate most is that it is completely local. No sending code to an external service, no setup beyond running codegraph init. It just works.

ponytail

Ponytail is one of those tools that makes you wonder how you tolerated the alternative. It makes your agent think like the laziest senior developer in the room — and I mean that as a genuine compliment.

The idea is a decision ladder the agent runs before writing any code. Does this need to exist at all? Is it already in the codebase? Does the stdlib do it? Can it be one line? Only if none of those rungs hold does it write something new. The result is that you stop getting over-engineered solutions to simple problems, stop accumulating unnecessary abstractions, and stop having agents add layers of scaffolding for use cases that will never arrive.

The motto is "the best code is the code you never wrote", and once you have worked with an agent that actually operates that way, it is hard to go back. It is not about being careless — validation, security, and error handling at real boundaries are never on the chopping block. It is about defaulting to simplicity everywhere else.

agency-agents

As the repo is described:

A complete AI agency at your fingertips - From frontend wizards to Reddit community ninjas, from whimsy injectors to reality checkers. Each agent is a specialized expert with personality, processes, and proven deliverables.

It really does live up to that description. I have found some of the agents to be ridiculously good when used for the right job. The Content Creator, for example, is excellent at turning rough project notes into a polished README.md that actually sounds like it was written by someone who cares.

This is where I think specialised agents shine. A general-purpose coding assistant can do a lot, but a purpose-built agent with a clear role often gives you a much stronger first draft. If I am writing docs, I would rather hand that off to something tuned for documentation. If I am reviewing product copy, a marketing-focused agent often has better instincts than a raw coding model.

A simple example: say I have hacked together a project over a weekend and the code works, but the docs are a mess. Instead of asking my main coding assistant to context-switch into "documentation mode", I can hand the repo summary to a content-focused agent and let it produce a cleaner first pass. It is a small change, but it keeps each tool doing the thing it is best at.

worktrunk

Worktrunk has a bunch of quality-of-life features that make working with multiple parallel changes much less painful. If you have ever used git worktrees directly from the CLI, you will know they are powerful but not always especially pleasant. Personally, I found the raw workflow a bit cumbersome.

Worktrunk smooths that out. It makes creating, jumping between, and cleaning up worktrees feel much more ergonomic, which matters a lot once you start using AI agents in parallel.

One really practical use case is when I want to explore multiple ideas at once. I might have one worktree for a feature branch, another for a risky refactor, and another where I let an agent experiment with a different approach entirely. That separation is brilliant because it stops one bad experiment from polluting the rest of the work.

This is probably the biggest shift in my workflow overall: I no longer think of AI as a single assistant living in one terminal window. I think of it more like a team of temporary contributors, and worktrees give each of them their own safe little sandbox.

How It All Fits Together​

The rough flow for me usually looks like this:

1. Start with a rough idea or problem I want to solve.
2. Let superpowers guide the agent into the right structure for the task — planning, spec, or review depending on what it is.
3. Let codegraph handle codebase orientation so the agent is not burning context on discovery before it even starts.
4. Trust ponytail to keep the output tight — no unnecessary abstractions, no scaffolding for hypothetical future requirements.
5. Spin up a dedicated agent, or a more specialised one from agency-agents, depending on what the work actually calls for.
6. Do everything in an isolated worktree using worktrunk so I can compare, throw away, or merge changes cleanly.

That combination has made AI feel much more useful to me. Not because any one tool is magic, but because the workflow has a bit more structure. The better I get at setting context, isolating work, and keeping output quality high, the better the results tend to be.

I am sure this setup will change again in a few months, because the whole space moves too fast for anything to stay still. But right now this is the workflow that feels the most practical for how I like to work: a bit opinionated, a bit experimental, and very focused on keeping the chaos under control.

Below are a list of ones that I find useful

[Note] Any thing missing, let me know. I am always on the look for new CLI / TUI tools.

The Must Haves​

Utilities​

• fzf - Command-line fuzzy finding written in Go
• bat - Clone of cat(1) with syntax highlighting and Git integration
• atuin - Improved shell history for zsh, bash, fish and nushell
• zoxide - shell extension to navigate your file-system faster
• yazi - Blazing fast terminal file manager written in Rust, based on async I/O
• eza - Modern, maintained replacement for ls
• ripgrep - Fast search tool

Git and GitHub​

• lazygit - A simple terminal UI for git commands, written in Go
• gh - GitHub command-line tool
• gh-dash - A rich terminal UI for GitHub PRs that doesn't break your flow.
• hunk - Review-first terminal diff viewer
• worktrunk - Git worktree management, designed for parallel AI agent workflows

Process Management​

• zellij - terminal multiplexer
• lazydocker - Lazier way to manage everything docker
• k9s - kubernetes CLI to manage your clusters in style!
• bpytop - Linux/OSX/FreeBSD resource monitor

The Rest​

• bucky - My very own S3/SFTP/GCP TUI
• mole - CLI for Deep cleaning and optimizing your Mac.
• csvlens - Command line csv viewer
• carapace - CLI tool for multi-shell completion.
• posting - A modern API client that lives in your terminal.
• jnv - Interactive JSON filter using jq

Please do let me know if I have missed anything, you can find me on X at @mrpbennett

📋 Prerequisites​

• A Mac (or Linux) machine on the same Wi‑Fi network as your iOS device
• Homebrew (macOS) or Python 3 & pip3
• Your iPhone and Mac must be on the same network
• Basic familiarity with terminal commands and iOS Settings

1️⃣ Install mitmproxy on macOS​

Homebrew (macOS)​

brew install mitmproxy

pip3 (cross‑platform)​

pip3 install mitmproxy

This installs three binaries:

• mitmproxy – interactive CLI (text UI)
• mitmweb – browser‑based Web UI
• mitmdump – headless, scriptable

Tip: Always keep mitmproxy updated (brew upgrade mitmproxy or pip3 install --upgrade mitmproxy).

2️⃣ Start mitmproxy​

For CLI interface:

mitmproxy

For Web UI (recommended for beginners):

mitmweb

By default, both listen on:

0.0.0.0:8080

Leave this running. The Web UI will be available at http://127.0.0.1:8081.

3️⃣ Find Your Mac's Local IP​

On macOS:

ipconfig getifaddr en0

Or check System Settings → Network.

Example:

192.168.1.25

You'll need this IP address for the next step.

4️⃣ Configure iPhone Proxy​

On your iPhone:

1. Settings → Wi‑Fi
2. Tap the (ℹ︎) next to your connected network
3. Scroll down → Configure Proxy
4. Select Manual
5. Enter:
   • Server: 192.168.1.25 (your Mac's IP)
   • Port: 8080
6. Save

Now all HTTP/S traffic flows through mitmproxy. You should immediately see traffic appear in the terminal or Web UI.

5️⃣ Install mitmproxy Certificate on iPhone (Required for HTTPS)​

Without this certificate, HTTPS traffic will fail with security errors.

The Easy Way (Recommended)​

On your iPhone:

1. Open Safari

2. Navigate to:

   http://mitm.it
   

3. Tap iOS (or the Apple icon)

4. Tap Allow to download the profile

Install & Trust the Certificate​

1. Settings → General → VPN & Device Management

2. Tap the mitmproxy profile

3. Tap Install (enter passcode if prompted)

4. After installing, go to:

   Settings → General → About → Certificate Trust Settings

5. Toggle ON for the mitmproxy certificate

Now HTTPS traffic will decrypt properly in mitmproxy.

Pro tip: If you later rotate mitmproxy's CA, remove the old profile on iOS first to prevent conflicts. After an OS update, you may need to re-enable certificate trust.

🖥️ Using the CLI: mitmproxy​

For quick inspection or scripting, the CLI TUI is lightning fast.

Basic Navigation​

• ↑/↓ – scroll through flows
• Enter – open flow detail (headers & body)
• e – set an edit breakpoint on this flow
• f – filter (type filter expression)
• r – replay request
• q – quit

Filtering Examples​

Show only specific endpoints:

~u containerBeacon

Filter by domain:

~u id5-sync.com

Combine multiple filters:

(~u containerBeacon) | (~u id5-sync.com)

Filter by method:

~m POST

Intercept & Modify​

1. Press f to set a filter
2. Press i to set an intercept (e.g., ~u api.myapp.com)
3. Reproduce the request on your device
4. The flow will pause in mitmproxy
5. Press Enter to view it, e to edit
6. Press a to accept & continue or d to drop

CLI Tip: Pipe mitmproxy logs to a file for offline debugging:

mitmproxy 2>&1 | tee mitmproxy.log

🌐 Using the Web UI: mitmweb​

The Web UI offers a user‑friendly dashboard in your browser.

Launch​

mitmweb

• Proxy runs on 0.0.0.0:8080
• Web UI at http://127.0.0.1:8081/

Key Features​

1. Live Flows List – real‑time streaming of requests/responses
2. Filter Box – same filter syntax as CLI (~u, ~h, ~q, ~m, etc.)
3. Flow Detail Pane – click any request to see Request / Response / Timeline
4. Intercept Toggle – checkbox to pause flows for inspection
5. Copy as cURL – right‑click any flow for easy replay

Filter Examples​

~u containerBeacon | ~u id5-sync.com | ~u api.myapp.com

Exporting & Auditing​

• File → Save → exports flows in various formats
• Export HTTP Archive (HAR) → choose "Filtered flows" → save .har for team reviews or browser replay
• Share HARs or screenshots of the Web UI for clear documentation

Web UI Tip: Use your browser's DevTools to customize the Web UI appearance with larger fonts or dark mode via user CSS extensions like "Stylus".

🔄 Scripting with Add‑ons​

Want to automate logging or custom breakpoints? Write a small Python addon.

# log_beacons.py
from mitmproxy import http, ctx

def request(flow: http.HTTPFlow):
    url = flow.request.pretty_url
    if "containerBeacon" in url or "id5-sync.com" in url:
        ctx.log.info(f"[MITM] {flow.request.method} → {url}")
        ctx.log.info(flow.request.get_text())

Launch with:

mitmproxy -s log_beacons.py

Or with the Web UI:

mitmweb -s log_beacons.py

Logs appear in your terminal or Web UI Event Log panel.

⚠️ Certificate Pinning​

Many production apps implement certificate pinning to prevent man‑in‑the‑middle attacks.

Symptoms​

• Requests fail or time out
• TLS handshake errors in mitmproxy
• No traffic appears for that specific app
• App shows network error messages

Solutions​

Option A — Use iOS Simulator

The simulator is MUCH easier for development:

• Install mitmproxy certificate directly into macOS system trust
• Simulator inherits macOS trust settings
• No extra profile installation steps
• No certificate pinning issues for apps in development

Option B — Use Frida to Bypass Pinning

Common for security research on real devices:

# Install Frida tools
pip3 install frida-tools

# Use SSL pinning bypass scripts
frida -U -f com.yourapp.bundle -l ssl-pinning-bypass.js

Option C — Jailbroken Device

You can disable SSL pinning via tweaks like SSL Kill Switch.

Option D — Test Your Own App

If you control the app source code, disable pinning in debug builds or implement a debug flag.

Note: For apps you own, the simulator is the cleanest and most reliable route for development and testing.

🔍 Debugging Tips​

If traffic isn't showing up:

• Firewall: Ensure Mac firewall allows incoming connections on port 8080

• Timing: Make sure mitmproxy is running before enabling the proxy on iPhone

• IP Address: Verify your Mac's IP didn't change (DHCP can reassign IPs)

• Network: Confirm iPhone and Mac are on the same subnet

• VPN: Disable any VPN on your iPhone

• Port conflicts: If you get address already in use, find and kill the process:

  lsof -iTCP:8080 | grep LISTEN
  kill -9 <PID>
  

• Certificate trust: Double-check that certificate trust is enabled in iOS settings

• Restart: Try restarting mitmproxy or toggling the proxy off/on in iOS settings

🚀 Advanced Tips​

• Custom ports: Use --listen-port to change the proxy port:

  mitmproxy --listen-port 8082
  

• Selective bypass: Exclude domains from proxying:

  mitmproxy --ignore-hosts '^(?!.*myapp\.com)'
  

• Save flows automatically:

  mitmdump -w flows.mitm
  

• Replay saved flows:

  mitmproxy -r flows.mitm
  

• Transparent mode: Intercept traffic without proxy configuration (requires routing setup):

  mitmproxy --mode transparent
  

🔐 Legal & Ethical Note​

Only intercept traffic:

• For apps you own or have permission to test
• In testing/development environments
• For authorized security research
• For educational purposes on your own devices

Intercepting traffic without proper authorization can violate laws, terms of service, and ethical guidelines. Always ensure you have the right to inspect the traffic you're capturing.

🎯 Conclusion​

With mitmproxy (CLI or Web UI), you gain complete visibility into real‑device HTTPS traffic—no Xcode entanglements required. This guide equipped you to:

• Install and start mitmproxy with minimal configuration
• Configure your iOS device proxy quickly
• Install the CA certificate the easy way via mitm.it
• Capture, filter, and inspect flows via CLI or Web UI
• Intercept, modify, and log requests on the fly
• Handle certificate pinning scenarios
• Export HAR files for audit and collaboration
• Script custom automation with Python add‑ons

Whether you're debugging your own app, auditing network behavior, or learning about mobile security, mitmproxy is an invaluable tool in your toolkit.

Happy sniffing, and may your network requests always behave as expected!

defaults read -g AppleInterfaceStyle 2>/dev/null

This will output:

• "Dark" if dark mode is enabled.
• Nothing if in light mode.

Now we can adjust our colorscheme.lua config by adding the following before we return the color scheme.

-- Detect system appearance (macOS only)
local handle = io.popen("defaults read -g AppleInterfaceStyle 2>/dev/null")
local result = handle:read("*a")
handle:close()

local is_dark = result:match("Dark") ~= nil

-- Decide flavour and background based on appearance
local flavour = is_dark and "macchiato" or "latte"
local background = {
  light = "latte",
  dark = "mocha",
}

To complete your colorscheme config it should look like the below.

-- Detect system appearance (macOS only)
local handle = io.popen("defaults read -g AppleInterfaceStyle 2>/dev/null")
local result = handle:read("*a")
handle:close()

local is_dark = result:match("Dark") ~= nil

-- Decide flavour and background based on appearance
local flavour = is_dark and "macchiato" or "latte"
local background = {
  light = "latte",
  dark = "mocha",
}

return {
  {
    "catppuccin/nvim",
    name = "catppuccin",
    lazy = false,

    opts = {
      flavour = flavour, -- use detected flavour
      background = background,
      transparent_background = false,
      no_italic = true,
      no_bold = true,
      no_underline = true,
      term_colors = true,

      integrations = {
        cmp = true,
        gitsigns = true,
        neotree = true,
        treesitter = true,
        notify = false,
        mini = {
          enabled = true,
          indentscope_color = "",
        },
      },
    },
  },

  {
    "LazyVim/LazyVim",
    opts = {
      colorscheme = "catppuccin",
    },
  },
}

This is for the Catppuccin theme. Which I have every where, you're able to amend the above Catppuccin options by following this guide

It's still being fleshed out but so far I think DHH and the Omarchy community are doing awesome work. However, for myself to move away from M1 Macbook Pro to Omarchy for work, I needed to use a VPN. Forticlient only has .rep and .deb packages, meaning Arch needed something else.

After some googling, some ChatGPT and being pointed in the right direction from the Omarchy community I came across openfortivpn this is how I set things up for myself.

Install openfortivpn​

Arch provides openfortivpn in the official repo:

sudo pacman -S openfortivpn

Or use the latest dev version from the AUR:

yay -S openfortivpn-git

Setting up your config file​

Once installed you will need to set up your config file this is generally located at /etc/openfortivpn/config

host = vpn.example.com
port = 443
username = john.doe
password = mySecretPassword   # optional, omit for interactive prompt

Once you have that, make sure only root can read it:

sudo chmod 600 /etc/openfortivpn/config

Running the VPN​

Once the above steps are done you can do the following:

sudo openfortivpn

In my case this then prompted me to accept a token on my phone before allowing me to connect. Once connected the connection will continue to run inside the termainal window. If you were to close the window your connection will be dropped.

To prevent this, so I can have my terminal window back I set up the following alias.

alias vpnc="nohup sudo openfortivpn -c /etc/openfortivpn/config &"

There we have it...what seemed daunting was actually pretty simple, just needed a few config files.

I think looking back on it, this sparked a love for terminal use and cli tools. Although I have spent most of my development work in an IDE (VSC / DataGrip / PyCharm). I have started to slowly transition from those to NeoVim. Before I got started with NVIM, I spent some time in actual Vim and could never exit. Looks like I was not the only one with StackOverflow having a post that was viewed over 3.2 million times. The infamous :q was only the beginning.

The paragraphs below explain or give some tidbits of info on how I felt like I could use Vim Motions on a day-to-day basis.

Keybindings I found helpful​

• h, j, k, l: These will help you move left, down, up, right
• a: inserts character in insert mode beginning of line
• A: enter insert at the end of a line.
• i: insert character in insert mode after character
• I: enter insert at the beginning of a line
• e, E: jump forwards to the end of a word using uppercase E will include punctuation
• w, W: jump forwards to the start of a word using uppercase W will include punctuation
• b, B: jump backwards to the start of a word using uppercase B will include punctuation
• o: start a new line in insert mode below current line
• O: start a new line in insert mode above the current line
• r: replace a single character
• gg: jump to the top of the page
• G: jump to the bottom of the page
• ctrl-d: jump down the page
• ctrl-u: jump up the page

In COMMAND mode I found %s/<find-word>/<replace-word>/g very useful to search for words and replace them with something else. Appending /g does this globally and /gc does the same but with confirmation.

I posted something on Reddit where I found a lot of awesome tips and sites, some of which are listed below. The below consists of videos or reading material I used to get better with Vim, as well as some awesome CLI tools to make your life that bit easier when in the terminal.

Distros​

I have been told and also read that I should learn to use vim motions and vim in general before I use a distro or at least learn to set up my own. I don't really have time to set my own up. So I use the amazing Lazyvim which is actually fantastic. There are many out there such as, NVChad and LunarVim, but I find LazyVim to be the best.

Having said that, because I have a homelab I have spent a lot of time just using vim. As I didn't want to faff around with installing distros on a server just to edit a few files. So I felt confident enough to move to a distro.

People say you should own your own config, in case the maintainers one day stop maintaining the distro. This could also happen with your favourite plugins too, it's just the way of open source I guess. However, there is kickstart.nvim which isn't a distro but more of a starting point for your own config which is less daunting. I have started to work along side my own config and Lazyvim. You can learn more about the project by watching The Only Video You Need to Get Started with Neovim, which has been put together by one of the core Nvim devs and the maintainer of the project TJ DeVries

Awesome Info​

A lot of this info has been found from various sources mainly Youtube and the awesome creators such as:

• ThePrimeagen
• TypeCraft
• DevOps Toolbox
• Henry Misc
• Josean Martinez
• TJ DeVries

I am sure there are plenty more like but these are the guys I seem to be going back too.

• Vim Motion

  • YT: Vim As Your Editor - Series by ThePrimeagen
    • Introduction
    • Horizontal Movement
    • Vertical Movement
    • Advance Motion Pt1
    • Advance Motion Pt2
    • Tips & Tricks
  • YT: Give Me 20 Minutes and I’ll Make You a Vim Motions Expert by DevOps Toolbox
  • Vim Cheat Sheet
  • Vim Hero
  • Vim Adventures
  • Practical Vim command workflow
    • hardtime.nvim
  • Vim Motions & Tricks I Wish I Learned Sooner by Henry Misc
  • More Vim Tricks That Blew My Mind by Henry Misc
  • Vim's Most Misunderstood Feature: Tabs by Henry Misc
  • This VIM trick BLEW MY MIND by Typecraft
  • 30 Vim commands you NEED TO KNOW (in just 10 minutes) by Typecraft
  • Vim Motions for absolute beginners!!! by Dispatch
  • Intermediate Vim Motions and Pro Tips!!! by Dispatch

• Terminals

  • Ghostty
  • Warp

• CLI Tools

  • YT: 7 Amazing Terminal API tools by DevOps Toolbox
  • YT: fzf by DevOps Toolbox
  • YT: fzf by Typecraft
  • YT: Lazygit - The Best Way To Use Git On The Terminal by Josean Martinez
  • YT: Yazi by Josean Martinez
  • YT: Zellij by Typecraft

  Github

  • yazi - File Manager
  • posting - API client
  • curlie - A better curl
  • eza - A better ls
  • zoxide - Learn your directories
  • bat - Syntax highlighting
  • mitmproxy - Charles for the terminal
  • zellij - terminal multiplexer

• LazyVim

  • lazyvim.org
  • YT: LazyVim from Scratch to BeastMode by DevOps Toolbox

• Nvim

  • Full Neovim Setup from Scratch in 2025 by Henry Misc
  • How I Setup Neovim To Make It AMAZING in 2024: The Ultimate Guide by Josean Martinez
  • NeoVim setup config playlist by TypeCraft

• Other

  • Book: Practical Vim 2nd Edition
  • Book: lazyvim-ambitious-devs
  • YT: How To Use Vim/Neovim Macros For Next Level Productivity by Josean Martinez
  • Vim Hardtime
  • Touch typing

Enter .http files and kulala.nvim, a powerful combination that brings REST API testing directly into your Neovim workflow.

What Are .http Files?​

.http files (also known as HTTP request files) are plain text files that contain HTTP requests in a human-readable format. They originated from JetBrains IDEs but have since been adopted by various editors and tools, including VS Code's REST Client extension.

The beauty of .http files lies in their simplicity. Instead of clicking through a GUI or remembering complex curl syntax, you write your HTTP requests in a declarative format that's easy to read, version control, and share with your team.

Here's what a basic .http file looks like:

### Get all users
GET https://api.example.com/users
Accept: application/json

### Create a new user
POST https://api.example.com/users
Content-Type: application/json

{
  "name": "John Doe",
  "email": "john@example.com"
}

Key Features of .http Files​

1. Request Separation​

Use ### to separate different requests in the same file. Each request can be executed independently.

2. Headers​

Add headers right after the request line, one per line:

GET https://api.example.com/protected
Authorization: Bearer your-token-here
User-Agent: MyApp/1.0
Accept: application/json

3. Request Bodies​

For POST, PUT, and PATCH requests, add a blank line after headers and include your request body:

POST https://api.example.com/posts
Content-Type: application/json

{
  "title": "My Post",
  "content": "This is the content"
}

4. Variables​

Define and reuse variables to avoid repetition:

@baseUrl = https://api.example.com
@token = your-auth-token

GET {{baseUrl}}/users
Authorization: Bearer {{token}}

5. Comments​

Use # or // for comments to document your requests:

# This endpoint returns all active users
GET https://api.example.com/users?status=active

Enter kulala.nvim​

While .http files are useful on their own, they really shine when paired with a good client. For Neovim users, kulala.nvim is the perfect companion. It's a lightweight, fast HTTP client plugin that brings the power of .http files directly into your editor.

Why kulala.nvim?​

1. Native Neovim Integration: No need to leave your editor
2. Lightweight: Minimal overhead, fast execution
3. Feature-rich: Supports all standard HTTP methods, headers, and body types
4. Variable Support: Full support for environment variables and file-scoped variables
5. Response Handling: View responses in a dedicated buffer with syntax highlighting

Setting Up kulala.nvim​

Installation​

Using lazy.nvim:

{
  'mistweaverco/kulala.nvim',
  config = function()
    require('kulala').setup({
      -- Default request timeout
      default_timeout = 5000,
      -- Show icons in the request list
      icons = {
        inlay = {
          loading = "⏳",
          done = "✅"
        },
        lualine = "🐼"
      },
    })
  end
}

Basic Configuration​

Add some keybindings to make kulala.nvim easy to use:

vim.keymap.set("n", "<leader>rr", require('kulala').run, { desc = "Execute HTTP request" })
vim.keymap.set("n", "<leader>ra", require('kulala').run_all, { desc = "Execute all HTTP requests" })
vim.keymap.set("n", "<leader>ri", require('kulala').inspect, { desc = "Inspect HTTP request" })
vim.keymap.set("n", "<leader>rt", require('kulala').toggle_view, { desc = "Toggle response view" })

Practical Examples​

Let's walk through some practical examples of using .http files with kulala.nvim.

Example 1: Basic CRUD Operations​

@baseUrl = https://jsonplaceholder.typicode.com

### Get all posts
GET {{baseUrl}}/posts

### Get specific post
GET {{baseUrl}}/posts/1

### Create new post
POST {{baseUrl}}/posts
Content-Type: application/json

{
  "title": "My New Post",
  "body": "This is the content of my post",
  "userId": 1
}

### Update post
PUT {{baseUrl}}/posts/1
Content-Type: application/json

{
  "id": 1,
  "title": "Updated Post Title",
  "body": "Updated content",
  "userId": 1
}

### Delete post
DELETE {{baseUrl}}/posts/1

Example 2: Authentication Flow​

@authUrl = https://api.example.com
@username = your-username
@password = your-password

### Login to get token
POST {{authUrl}}/auth/login
Content-Type: application/json

{
  "username": "{{username}}",
  "password": "{{password}}"
}

### Use the token (you'll need to copy it from the login response)
@token = your-jwt-token-here

### Get protected resource
GET {{authUrl}}/protected
Authorization: Bearer {{token}}

### Refresh token
POST {{authUrl}}/auth/refresh
Authorization: Bearer {{token}}

Advanced Features​

Environment Files​

kulala.nvim supports environment-specific variables through .env files:

Create a http-client.env.json file:

{
  "dev": {
    "baseUrl": "https://api-dev.example.com",
    "token": "dev-token"
  },
  "prod": {
    "baseUrl": "https://api.example.com",
    "token": "prod-token"
  }
}

Then use variables in your .http file:

GET {{baseUrl}}/users
Authorization: Bearer {{token}}

Response Testing​

You can even write simple tests for your responses:

GET https://api.example.com/users

> {%
  client.test("Status is 200", function() {
    client.assert(response.status === 200, "Expected status 200");
  });

  client.test("Response has users", function() {
    client.assert(response.body.length > 0, "Expected users in response");
  });
%}

Best Practices​

1. Organize by Feature​

Create separate .http files for different API endpoints or features:

• auth.http - Authentication endpoints
• users.http - User management
• posts.http - Content operations

2. Use Variables Liberally​

Define common values as variables to make maintenance easier:

@apiVersion = v1
@contentType = application/json
@baseUrl = https://api.example.com/{{apiVersion}}

3. Document Your Requests​

Use comments to explain what each request does:

### Creates a new user account
### Requires admin privileges
POST {{baseUrl}}/users
Authorization: Bearer {{adminToken}}
Content-Type: application/json

{
  "name": "New User",
  "email": "newuser@example.com",
  "role": "user"
}

4. Version Control​

Commit your .http files to version control. They serve as living documentation of your API and make it easy for team members to test endpoints.

5. Separate Sensitive Data​

Never commit sensitive data like API keys. Use environment files or variables that can be set locally:

# ❌ Don't do this
Authorization: Bearer sk-1234567890abcdef

# ✅ Do this instead
Authorization: Bearer {{apiKey}}

Workflow Integration​

Testing During Development​

Keep a .http file open in a split while you're developing your API. Make a change to your backend code, save, and immediately test it with <leader>rr.

API Documentation​

Your .http files serve as executable documentation. New team members can understand your API by looking at and running the requests.

CI/CD Integration​

Some tools can run .http files as part of your CI/CD pipeline, turning them into integration tests.

Conclusion​

.http files combined with kulala.nvim offer a powerful, lightweight solution for API development and testing. They keep you in your editor, provide version-controllable API documentation, and make testing as simple as pressing a key combination.

If you're tired of context-switching between your editor and external HTTP clients, give this combo a try. Your workflow will thank you.

The best part? Your .http files are portable. If you switch editors or tools, your requests go with you. They're just text files, after all—but text files that can supercharge your API development workflow.

Ready to give it a shot? Start with a simple .http file, install kulala.nvim, and begin exploring your APIs without ever leaving Neovim.

The Problem: Hierarchical Data in a Single Column​

Imagine you have data that looks like this:

| id | categories                    |
|----|-------------------------------|
| 1  | C10|C10.228|C10.228.140       |
| 2  | E02|E02.642|E02.642.249       |
| 3  | C16|C16.131                   |

Each row contains multiple pipe-separated values that you need to work with individually. Maybe you need to join them to another table, count occurrences, or filter by specific codes.

The Solution: UNNEST​

UNNEST is a table function that takes an array and returns a table with one row for each array element. First, we split our delimited string into an array, then unnest it:

SELECT t.id, code
FROM my_table t
CROSS JOIN UNNEST(split(t.categories, '|')) AS codes(code);

Result:

| id | code        |
|----|-------------|
| 1  | C10         |
| 1  | C10.228     |
| 1  | C10.228.140 |
| 2  | E02         |
| 2  | E02.642     |
| 2  | E02.642.249 |
| 3  | C16         |
| 3  | C16.131     |

Why CROSS JOIN?​

Here's the key insight: UNNEST is a table function, not a scalar function.

What's the Difference?​

Scalar functions (like upper(), length(), split()):

• Take one or more values as input
• Return a single value as output
• Can be used directly in SELECT clauses

-- This works fine
SELECT upper(name), length(description)
FROM my_table;

Table functions (like UNNEST):

• Take input (often an array)
• Return a table (multiple rows)
• Must be used in the FROM clause

Why You Can't Do This​

-- ❌ This doesn't work in Trino
SELECT id, unnest(split(categories, '|'))
FROM my_table;

Think about what this would mean: for each input row, you're trying to put multiple output rows into a single SELECT expression. SQL doesn't know how to handle that because SELECT operates row-by-row.

The CROSS JOIN Pattern​

A CROSS JOIN creates a Cartesian product: every row from the left table combined with every row from the right table.

-- Regular CROSS JOIN
SELECT *
FROM table1
CROSS JOIN table2;

When you use CROSS JOIN UNNEST, you're doing something clever:

1. For each row in your main table
2. Generate a mini-table from the array using UNNEST
3. Join that row with its own mini-table

SELECT t.id, codes.code
FROM my_table t
CROSS JOIN UNNEST(split(t.categories, '|')) AS codes(code);

Here's what happens step by step:

Row 1: id=1, categories="C10|C10.228"

• Split creates: ['C10', 'C10.228']
• UNNEST creates a 2-row table: {C10}, {C10.228}
• CROSS JOIN combines: (1, C10), (1, C10.228)

Row 2: id=2, categories="E02"

• Split creates: ['E02']
• UNNEST creates a 1-row table: {E02}
• CROSS JOIN combines: (2, E02)

Practical Examples​

Example 1: Joining with Another Table​

SELECT
    t.id,
    t.product_name,
    c.category_description
FROM products t
CROSS JOIN UNNEST(split(t.categories, '|')) AS codes(code)
JOIN category_lookup c
    ON codes.code = c.category_code;

Example 2: Filtering for Specific Codes​

SELECT DISTINCT id, product_name
FROM products t
CROSS JOIN UNNEST(split(t.categories, '|')) AS codes(code)
WHERE codes.code LIKE 'C10%';

Example 3: Counting Occurrences​

SELECT codes.code, count(*) as num_products
FROM products t
CROSS JOIN UNNEST(split(t.categories, '|')) AS codes(code)
GROUP BY codes.code
ORDER BY num_products DESC;

Example 4: Working with Multiple Arrays​

SELECT
    t.id,
    tag,
    category
FROM products t
CROSS JOIN UNNEST(split(t.tags, '|')) AS tags(tag)
CROSS JOIN UNNEST(split(t.categories, '|')) AS categories(category);

Common Pitfalls​

Pitfall 1: LIMIT Before vs After UNNEST​

-- This limits AFTER unnesting (might get 20 exploded rows from 2 original rows)
SELECT code
FROM my_table
CROSS JOIN UNNEST(split(categories, '|')) AS codes(code)
LIMIT 20;

-- This limits BEFORE unnesting (gets 20 original rows, then unnests all)
SELECT code
FROM (
    SELECT categories
    FROM my_table
    LIMIT 20
) t
CROSS JOIN UNNEST(split(t.categories, '|')) AS codes(code);

Pitfall 2: Forgetting the Alias​

-- ❌ Missing alias
CROSS JOIN UNNEST(split(categories, '|'))

-- ✅ With alias
CROSS JOIN UNNEST(split(categories, '|')) AS codes(code)

Pitfall 3: NULL or Empty Arrays​

If your column contains NULL or produces an empty array, UNNEST will produce zero rows for that input row (the row disappears). Use a LEFT JOIN if you need to preserve rows:

-- Preserves rows even if array is empty
SELECT t.id, codes.code
FROM my_table t
LEFT JOIN UNNEST(split(t.categories, '|')) AS codes(code) ON true;

Key Takeaways​

1. UNNEST is a table function, not a scalar function - it produces rows, not values
2. CROSS JOIN is required because you're joining each row with its own generated table
3. The pattern is: CROSS JOIN UNNEST(array_expression) AS alias(column_name)
4. This pattern is powerful for working with hierarchical, delimited, or array data in Trino

Once you understand why the CROSS JOIN is needed, the pattern becomes intuitive. You're not just selecting values - you're joining your data with a dynamically generated table derived from each row's array!

Further Reading​

• Trino UNNEST Documentation
• Trino Array Functions
• Understanding SQL Joins

names := []string{"Paul", "Fiona", "Murphy", "Linda"}

I wanted to remove the string Linda. In the block below I used two functions from the slice package these were Index and Delete these two allowed me to get the index of the string and delete it by its index.

if idx := slices.Index(names, "Linda"); idx != -1 {
    slices.Delete(names, idx, idx+1)
}

So what is happening here?

slices.Index: takes two arguments, the slice in question names and the item I am searching for.

Index returns the index of the first occurrence of v in s, or -1 if not present.

In the if statement you can see a ; this is used to combine two conditions. Allowing for the statement to read as follows. IF the index of "Linda" does not equal -1 then action the code inside the block. Pretty cool as this is different from Python which I am use to.

Next there is slices.Delete this takes three arguments, the slice, the start index and the end index. This would work in the same manner as a slice would work in Python [1:4] for example. Therefore with the block above, I took the index of the string, for this example lets say it was 3 and I only wanted to delete that index, therefore the end index would be 4.

This is why the arguments are Delete(names, idx, idx+1) which in turn would be Delete(names, 3, 3+1)

Quite simple but was am ah ha moment for me.

More can be found on the slices package here

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

Once installed run tailscale up and authenticate with your account. Easy, Tailscale is installed and you will be able to see it under your account list.

Enable HTTPS access to the Proxmox Web UI​

The Proxmox Web UI is served over HTTPS by default on port 8006. The default certificate is self-signed, so you will need to accept the certificate warning in your browser. Which as we all know is rather a big PIA. So let's change that.

The following script will use Tailscale to generate a certificate for the Proxmox host and install it in the Proxmox certificate store. However it will only generate the cert once, when the cert expires you will have to accept the certificate warning again. Let's change that...

First we need to install jq without that the script below will fail as we can't populate the $NAME variable. So run: sudo apt-get install jq

Once installed, create a file in your /root directory, I called mine tailscale-cert.sh this will need to be run via cron. Therefore, we need to create a cron job. Before you do that though, add the contents below to your tailscale-cert.sh file:

#!/bin/bash
NAME="$(tailscale status --json | jq '.Self.DNSName | .[:-1]' -r)"
tailscale cert "${NAME}"
pvenode cert set "${NAME}.crt" "${NAME}.key" --force --restart

Setting up cron​

Now let's change the permissions on our script and make it executable

chmod +x tailscale-cert.sh

Now you have your file, let's set up a job to keep that cert up to date. From the terminal, enter edit mode for your user’s crontab using the following command:

crontab -e

The first time you run this command, the OS should ask you what editor you would like to use with a little menu like this:

no crontab for user - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/nano     <---- easiest
  2. /usr/bin/vim.basic
  3. /usr/bin/vim.tiny
  4. /bin/ed

Choose 1-4 [1]:

Being a LazyVim user I of course picked 3. If you're using vim simply press G to get to the bottom of the cron page and enter the following:

0 3 1 * * /root/tailscale-cert.sh

This will run the script every month on the 1st at 3AM renewing your certificate.

For reference, here's how the cron syntax works:

* * * * * command
│ │ │ │ │
│ │ │ │ └─── Day of week (0-7, where both 0 and 7 = Sunday)
│ │ │ └───── Month (1-12)
│ │ └─────── Day of month (1-31)
│ └───────── Hour (0-23)
└─────────── Minute (0-59)

Then again if you're using vim type the following command :wqa to save and quit all.

There you have it...Proxmox setup with Tailscale including a certificate.

The application​

Although this is not the project in mind, this is the package I created to test. A simple HTTP server that prints "Hello, World!" when accessed.

// main.go
package main

import (
	"fmt"
	"log"
	"net/http"
)

func main() {
	log.Println("Starting server on port 8080")
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "Hello, World!")
	})
	http.ListenAndServe(":8080", nil)
}

Along with the following Docker image. Simply build it using the following Dockerfile then push it to a private registry.

# Use the official Go image as the base image
FROM golang:1.25.2-alpine AS builder

# Set the working directory inside the container
WORKDIR /app

# Copy go mod and sum files
COPY go.mod ./

# Download dependencies
RUN go mod download

# Copy the source code
COPY main.go ./

# Build the application
RUN go build -o webserver main.go

# Use a minimal alpine image for the final stage
FROM alpine:latest

# Install ca-certificates for HTTPS requests (if needed)
RUN apk --no-cache add ca-certificates

# Set working directory
WORKDIR /root/

# Copy the binary from builder stage
COPY --from=builder /app/webserver .

# Expose port 8080
EXPOSE 8080

# Command to run the executable
CMD ["./webserver"]

Setting up Tailscale in Kubernetes​

Since I have a single k3s node cluster running on a Raspberry Pi 5 currently (I will be overhauling my homelab very soon...keep your eyes on my blog for updates). I would have to run the Kubernetes Tailscale Operator to manage the Funnel. I won't go into too much detail here but you can find the prerequisites here. After you have set that up it's time to deploy the operator with helm.

helm repo add tailscale https://pkgs.tailscale.com/helmcharts

helm repo update

helm upgrade \
  --install \
  tailscale-operator \
  tailscale/tailscale-operator \
  --namespace=tailscale \
  --create-namespace \
  --set-string oauth.clientId="<OAauth client ID>" \
  --set-string oauth.clientSecret="<OAuth client secret>" \
  --wait

For the funnel feature to work you will need to add a node attribute to allow nodes created by the Kubernetes operator to use Funnel:

"nodeAttrs": [
  {
    "target": ["tag:k8s"], // tag that Tailscale Operator uses to tag proxies; defaults to 'tag:k8s'
    "attr":   ["funnel"],
  },
]

Once the Operator is deployed and you have your policy set up configured, it's time to deploy the application.

Deploying the Application​

As this is a simple application, the manifests are pretty straight forward. Here's an example of how you can deploy it:

apiVersion: v1
kind: Namespace
metadata:
  name: websvrgo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: websvrgo-deployment
  namespace: websvrgo
spec:
  selector:
    matchLabels:
      app: websvrgo
  template:
    metadata:
      labels:
        app: websvrgo
    spec:
      containers:
      - name: websvrgo
        image: 192.168.7.2:5000/websvrgo:0.0.2
        resources:
          requests:
            memory: "32Mi"
            cpu: "100m"
          limits:
            memory: "128Mi"
            cpu: "500m"
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: websvrgo-service
  namespace: websvrgo
  annotations:
   metallb.io/loadBalancerIPs: 192.168.7.60
spec:
  type: LoadBalancer
  selector:
    app: websvrgo
  ports:
  - port: 8080
    targetPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: funnel
  namespace: websvrgo
  annotations:
    tailscale.com/funnel: "true"
spec:
  ingressClassName: tailscale
  tls:
    - hosts:
        - websvrgo
  rules:
    - host: websvrgo
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: websvrgo-service
                port:
                  number: 8080

The important manifest here is the ingress where we're exposing the host websvrgo to the internet. The two things to note is that we're using the annotation of tailscale.com/funnel: "true" and the IngressClassName of tailscale. This unsures we're exposing the ingress service with the tailnet.

This would deploy our application to the internet on the following:

https://websvrgo.<tailnet>.ts.net

So when I get round to things, I can set something similar to this up and have a webhook send POST requests to the url exposed by my tailnet.

Existing deployments of Ingress NGINX will continue to function and installation artifacts will remain available.

But where would the fun be in that? Although I can tell you now, I should have left my setup the way it is... but nope, this is me migrating to the Gateway API. So let's get started!

Why Gateway API?​

Before diving into the migration, let's understand why Gateway API is a significant improvement over traditional Ingress resources:

Benefits of Gateway API​

1. Better Separation of Concerns: Gateway API separates infrastructure concerns (handled by platform teams) from application routing (handled by development teams). This is achieved through different resource types like Gateway and HTTPRoute.

2. More Expressive Routing: Unlike Ingress which has basic path and host-based routing, Gateway API supports advanced features like:

   • Header-based routing
   • Query parameter matching
   • Weighted traffic splitting
   • Method-based routing

3. Standardized Across Controllers: Gateway API provides a consistent interface across different ingress controllers (Envoy, NGINX, Istio, etc.), reducing vendor lock-in.

4. Enhanced Multi-tenancy: Clear role-based access control with different resources for different personas in the organization.

5. Built-in Extensibility: Designed with extension points for custom functionality without breaking the core API.

Ingress vs Gateway API Comparison​

Getting started with the Gateway API​

For the migration I picked Envoy Gateway as the documentation seemed to be the best, and the application seems to be well liked within the Kubernetes community so let's get cracking. I'm going to deploy this with an apps of apps pattern using ArgoCD, which allows me to deploy more manifests than just the Helm chart, enabling more modular deployments.

The App entry point​

First I went ahead and created the application's entry point. This is picked up by my registry app which populates all other apps.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: envoy-gateway
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: '0'
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: 'https://github.com/mrpbennett/home-ops.git'
    path: kubernetes/apps/envoy-gateway # this points to the directory where the manifests are stored.
    targetRevision: HEAD
    directory:
      recurse: true
  destination:
    namespace: envoy-gateway-system
    server: 'https://kubernetes.default.svc'
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        maxDuration: 5m0s
        factor: 2

App directory structure​

Next, the applications directory needs to be created. I went with the following setup:

📁 envoy-gateway 
├── 📁 helm-chart
│   └── envoy-gateway-helm.yaml
└── 📁 resources
    ├── gateway-class.yaml
    ├── https-gateway.yaml
    └── wildcard-certificate.yaml

Deploying the Helm chart​

If you read the quick guide, it suggests you install via Helm. I headed over to the Install section instead and read through https://gateway.envoyproxy.io/docs/install/install-argocd/ where it gives you a basic manifest.

Here mine is slightly tweaked. I added some of the default Helm chart values just because I wanted to see them in case I wanted to make a change. I also changed the service type to LoadBalancer as I am using bare-metal and MetalLb.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: envoy-gateway-helm
  namespace: argocd
spec:
  project: default
  source:
    helm:
      valuesObject:
        deployment:
          annotations: {}
          envoyGateway:
            resources:
              limits:
                memory: 1024Mi
              requests:
                cpu: 100m
                memory: 256Mi

        # Set type: to LB so it can talk with MetalLb
        service:
          trafficDistribution: ''
          annotations: {}
          type: LoadBalancer

        config:
          # -- EnvoyGateway configuration. Visit https://gateway.envoyproxy.io/docs/api/extension_types/#envoygateway to view all options.
          envoyGateway:
            gateway:
              controllerName: gateway.envoyproxy.io/gatewayclass-controller
            provider:
              type: Kubernetes
            logging:
              level:
                default: info
            extensionApis: {}

        createNamespace: false
        kubernetesClusterDomain: cluster.local

    chart: gateway-helm
    path: gateway-helm
    repoURL: docker.io/envoyproxy
    targetRevision: v1.6.0

  destination:
    namespace: envoy-gateway-system
    server: https://kubernetes.default.svc

  syncPolicy:
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true
    automated:
      prune: true
      selfHeal: true

Validation Steps​

After deploying the Helm chart, verify the Envoy Gateway installation:

# Check if the Envoy Gateway pods are running
kubectl get pods -n envoy-gateway-system

# Verify the GatewayClass is available
kubectl get gatewayclass

# Check Envoy Gateway controller logs
kubectl logs -n envoy-gateway-system deployment/envoy-gateway -f

Expected output should show the envoy-gateway pod in Running state and the controller logs should indicate successful startup.

Adding extra resources​

Below are the extra manifests I deployed alongside my Helm chart. Here, I am creating a GatewayClass, Gateway and Certificate. Instead of using annotations on the Gateway (which can cause conflicts), I created an explicit Certificate resource, which is then handled by cert-manager.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy-gatewayclass
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: envoy-shared-gateway
spec:
  gatewayClassName: envoy-gatewayclass
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      hostname: '*.70ld.dev'
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: wildcard-70ld-tls
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-70ld-certificate
  namespace: envoy-gateway-system
spec:
  secretName: wildcard-70ld-tls
  issuerRef:
    name: letsencrypt-cloudflare-dns-issuer
    kind: ClusterIssuer
  dnsNames:
    - '*.70ld.dev'
    - '70ld.dev'

With the Gateway, the key points about this configuration are:

• Uses Terminate mode for TLS termination at the gateway
• References the Secret created by cert-manager
• Restricts to our domain with the hostname field

Now this can be committed and ArgoCD will deploy the manifests for me. Let's check some things before moving forward.

Validation Steps​

# Verify the GatewayClass is accepted
kubectl get gatewayclass envoy-gatewayclass
# Status should show ACCEPTED=True

# Check Gateway status
kubectl get gateway envoy-shared-gateway -n envoy-gateway-system
# Status should show READY=True

# Verify the certificate is ready
kubectl get certificate wildcard-70ld-certificate -n envoy-gateway-system
# Status should show READY=True

# Check the LoadBalancer service
kubectl get svc -n envoy-gateway-system

Here we can see that the LoadBalancer service was given the external IP 191.168.7.53 for our service. This will allow us to create DNS records. ✅

Setting up Cert Manager​

I currently have cert manager setup via manifests, but after reading https://cert-manager.io/docs/usage/gateway/, it seems the better way to install it would be via Helm. The reason for Helm is because, for me, it's easier to see what I am changing. I'll show this below.

Cert-manager can generate TLS certificates for Gateway resources. This is configured by adding annotations to a Gateway and is similar to the process for Securing Ingress Resources.

The Gateway resource holds the TLS configuration, as illustrated in the following diagram (source: https://gateway-api.sigs.k8s.io):

Since we have applied the Gateway controller and Gateway Class above, we can install Cert Manager via Helm. Since I am using ArgoCD, this is how I would deploy it. Doing it this way allows us to enable the GatewayAPI by setting some values. As well as providing some extra manifests, for example below I have a ClusterIssuer and the Secret for my Cloudflare API key:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cert-manager
  namespace: argocd
spec:
  project: default
  sources:
    - chart: cert-manager
      repoURL: oci://quay.io/jetstack/charts/cert-manager
      targetRevision: 1.19.1
      helm:
        valuesObject:
          crds:
            enabled: true

          config:
            apiVersion: controller.config.cert-manager.io/v1alpha1
            kind: ControllerConfiguration
            enableGatewayAPI: true

          extraObjects:
            - |
              apiVersion: v1
              kind: Secret
              metadata:
                name: cloudflare-api-token-secret
                namespace: cert-manager
              type: Opaque
              data:
                api-token: ZGgxxx

            - |
              apiVersion: cert-manager.io/v1
              kind: ClusterIssuer
              metadata:
                name: letsencrypt-cloudflare-dns-issuer
              spec:
                acme:
                  server: https://acme-v02.api.letsencrypt.org/directory
                  email: p@mrpbennett.dev
                  privateKeySecretRef:
                    name: letsencrypt-cloudflare-dns-issuer-secret
                  solvers:
                    - dns01:
                        cloudflare:
                          apiTokenSecretRef:
                            name: cloudflare-api-token-secret
                            key: api-token

  destination:
    server: https://kubernetes.default.svc
    namespace: cert-manager

  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Validation Steps​

After deploying cert-manager, verify the installation:

# Check cert-manager pods are running
kubectl get pods -n cert-manager

# Verify the ClusterIssuer is ready
kubectl get clusterissuer letsencrypt-cloudflare-dns-issuer
# Status should show READY=True

# Check cert-manager logs
kubectl logs -n cert-manager deployment/cert-manager -f

# Verify Gateway API support is enabled
kubectl logs -n cert-manager deployment/cert-manager | grep -i gateway

External DNS​

Next I had to make sure External DNS worked with the new Gateway implementation. This was pretty simple - just a few changes were needed here. I installed External DNS to be used with Pi-hole. The tutorial can be found here. This worked well with my Ingress setup, but I needed to make some changes to the deployment and the clusterrole. Those changes are as follows:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: external-dns
rules:
- apiGroups: [""]
  resources: ["services","endpoints","pods"]
  verbs: ["get","watch","list"]
  
- apiGroups: ["extensions","networking.k8s.io"]
  resources: ["ingresses"]
  verbs: ["get","watch","list"]
  
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["list","watch"]
  
 ## add the following:
- apiGroups: ['gateway.networking.k8s.io']
  resources: ['gateways', 'httproutes', 'tlsroutes', 'tcproutes', 'udproutes']
  verbs: ['get', 'watch', 'list']
  
- apiGroups: ['discovery.k8s.io']
  resources: ['endpointslices']
  verbs: ['get', 'watch', 'list']
  
- apiGroups: ['']
  resources: ['namespaces']
  verbs: ['get', 'list', 'watch']

Then add the following flag to the args: within the deployment: --source=gateway-httproute so it can check Gateway HTTP route sources. With the following changes, this should generate a DNS record within Pi-hole.

Validation Steps​

Verify External DNS is working with Gateway API:

# Check External DNS pods
kubectl get pods -n external-dns

# View External DNS logs to see if it's picking up Gateway resources
kubectl logs -n external-dns deployment/external-dns -f

# Verify it can see the Gateway
kubectl logs -n external-dns deployment/external-dns | grep -i gateway

Hooking it all up​

Everything should be deployed and set up correctly to accept some HTTP routes. Here is a test deployment to check that everything is working fine.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: testapp2
  namespace: envoy-gateway-system
  labels:
    app: testapp2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: testapp2
  template:
    metadata:
      labels:
        app: testapp2
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 10m
              memory: 16Mi
            limits:
              cpu: 100m
              memory: 128Mi
---
apiVersion: v1
kind: Service
metadata:
  name: testapp2-service
  namespace: envoy-gateway-system
  labels:
    app: testapp2
spec:
  selector:
    app: testapp2
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: ClusterIP
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: testapp2-route
  namespace: envoy-gateway-system
spec:
  parentRefs:
    - name: envoy-shared-gateway
      namespace: envoy-gateway-system
  hostnames:
    - 'test-new.70ld.dev'
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: testapp2-service
          port: 80

Validation Steps​

Before checking Pi-hole, let's validate the HTTPRoute deployment:

# Check if the test deployment is running
kubectl get deployment testapp2 -n envoy-gateway-system

# Verify the service is accessible
kubectl get svc testapp2-service -n envoy-gateway-system

# Check HTTPRoute status
kubectl get httproute testapp2-route -n envoy-gateway-system
# Status should show ACCEPTED=True

# Describe HTTPRoute for detailed status
kubectl describe httproute testapp2-route -n envoy-gateway-system

# Test internal connectivity (from within cluster)
kubectl run test-pod --image=curlimages/curl -i --tty --rm -- curl -k https://test-new.70ld.dev

Once the test application has been deployed, it's time to head over to my Pi-hole instance to check if the DNS record has populated. BOOM! It worked...

Awesome! This is good news - we can see it's pointing to the IP address of the LoadBalancer service. The IP address was handed out from a pool given to MetalLB.

Now let's check if the site actually loads...

Beautiful! It loads and we're getting HTTPS with no certificate warnings.

Final Validation​

To ensure everything is working correctly:

# Test the complete flow
curl -v https://test-new.70ld.dev

# Check certificate details
openssl s_client -connect test-new.70ld.dev:443 -servername test-new.70ld.dev < /dev/null 2>/dev/null | openssl x509 -text -noout | grep -A2 "Subject:"

# Verify DNS resolution
nslookup test-new.70ld.dev

# Check Gateway metrics (if available)
kubectl port-forward -n envoy-gateway-system svc/envoy-gateway-metrics-service 19001:19001
# Then visit http://localhost:19001/stats in your browser

The migration is now complete! 🎉

Lessons Learned 💡​

What Went Wrong​

• Complexity: Gateway API has more moving parts than Ingress
• Learning Curve: New concepts like parentRefs and listeners took time
• Migration Effort: Converting all existing applications was time-consuming

What I'd Do Differently​

• Gradual Migration: Run both systems in parallel longer
• Better Planning: Map out all existing Ingress resources first
• Testing Strategy: Set up comprehensive testing before switching

Performance Considerations​

• Resource Usage: Envoy Gateway uses ~200MB more memory than NGINX Ingress
• Startup Time: Takes longer to initialize but performs similarly once running

Conclusion​

Migrating from Ingress NGINX to Gateway API using Envoy Gateway was a significant undertaking, but the benefits are clear:

• Better separation of concerns between platform and application teams
• More expressive routing capabilities for complex traffic patterns
• Standardized API that works across different ingress controllers
• Future-proof architecture aligned with Kubernetes evolution

While the migration required effort and had its challenges, the Gateway API provides a more robust foundation for modern Kubernetes networking. The investment in learning and migrating pays off with increased flexibility and maintainability.

Key Takeaways:

• Plan your migration carefully and test thoroughly
• Use explicit Certificate resources instead of annotations
• Validate each step before proceeding
• Keep both systems running during transition

The future of Kubernetes ingress is bright with Gateway API! 🚀

However, the more applications I deployed to my cluster the more applications depended on storing things in Postgres. This made me spin up a Postgres instance via Docker on a VM, this way I could keep the instance up, in case I needed to tear down my cluster.

This worked fine, but I wanted to migrate everything to within Kubernetes. Now with CNPG v1.25+ I and ArgoCDs sync-wave I can do just that.

Deploying a database​

Getting a basic cluster setup via CNPG is pretty simple, deploy an operator and then a cluster manifest. Now you have yourself a working High-Availability Postgres cluster. But bare bones it doesn't spin up with any databases unless you use bootstrap.initdb to configure a single database from the start.

But what about multiple databases, Each of my applications requires its own. With v1.25+ this is as simple as deploying a Database manifest. Additional databases can be created or managed via declarative database management using the Database CRD, Below is an example of a database deployed for the application Authentik:

apiVersion: postgresql.cnpg.io/v1
kind: Database
metadata:
  name: authentik-db
spec:
  name: authentik-db # db name
  owner: authentik # db owner
  cluster:
    name: cnpg-cluster # name of your cluster

Before deploying you will have to give the owner a role within the cluster, if you're not using the postgres superuser. A role within the cluster manifest looks like this:

spec:
  managed:
  roles:
 - name: authentik
      ensure: present
      comment: 'Simple application user for Authentik'
      login: true
      superuser: true
      passwordSecret:
        name: cnpg-authentik-user

For my use case, I gave the user superuser access, as I had trouble giving the role the correct permissions so I gave up and gave superuser access. You also have to give the user a password, which is as simple as creating a secret and deploying that.

That's pretty much it, this is how I deploy multiple databases within my cluster when it's created. And of course, you can deploy as many Database manifests as needed.

Sync-wave...ArgoCD​

Not sure about you, but I was wondering how I could deploy the applications and databases without things crashing because the database wasn't ready.

Enter sync-wave with ArgoCD. Adding a sync-wave annotation to ArgoCD Application manifest tells ArgoCD to deploy your applications in waves. The below manifest shows that I am deploying my Postgres cluster in sync-wave: 0. This will deploy in the first round, ArgoCD won't deploy any other waves till all applications in wave 0 are healthy.

metadata:
  name: &app cnpg-cluster
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: '0'

Therefore it would be practical to deploy all other applications that relied on the PostgreSQL cluster to deploy in wave 1 or wave 2. This way once the cluster is healthy and all of its databases are deployed. The other applications can be deployed and write to the databases. Something like this:

This is how I have set up my CloudNativePG cluster and it works pretty well. I am sure this is very basic but for me it works, you can find more about sync-wave or deploying Databases on the links below:

• Database manifests
• ArgoCD sync-wave

This time I am trying out Zed "The editor for what's next" written in Rust.

Zed is a next-generation code editor designed for high-performance collaboration with humans and AI.

I must admit it's pretty sweet. But not as sweet as LazyVim which is currently my daily driver. So coming from LazyVim, I wanted to get Zed close to my LazyVim experience, allowing me to get up to speed quicker than I would otherwise. Similar to LazyVim, Zed is managed by a bunch of dotfiles.

Here are my dotfiles for my Zed setup. I mainly write in Python, Go, and YAML. Being a homelabber, I spend a lot of time in Docker and Kubernetes manifests. Setting up YAML is important to me; currently with this setup I have yet to get Kubernetes completion sorted, but that is a task for another day.

Python and Go work well though—Go is simply awesome in terms of getting editors set up.

settings.json​

// settings.json
{
  "agent": {
    "always_allow_tool_actions": true,
    "default_model": {
      "provider": "copilot_chat",
      "model": "claude-sonnet-4"
    },
    "model_parameters": []
  },
  "diagnostics": {
    "inline": {
      "enabled": true
    }
  },
  "inlay_hints": {
    "enabled": true
  },
  "buffer_font_family": "JetBrainsMono Nerd Font Mono",
  "ui_font_family": ".ZedSans",
  "icon_theme": "Catppuccin Mocha",
  "vim_mode": true,
  "cursor_blink": false,
  "relative_line_numbers": true,
  "scroll_beyond_last_line": "off",
  "scrollbar": { "show": "never" },
  "ui_font_size": 16.0,
  "buffer_font_size": 14.0,
  "theme": {
    "mode": "system",
    "light": "One Light",
    "dark": "Catppuccin Mocha (blue)"
  },
  // Indentation, rainbow indentation
  "indent_guides": {
    "enabled": true,
    "coloring": "indent_aware"
  },
  "languages": {
    "Python": {
      "language_servers": ["ruff", "basedpyright", "!pyright"],
      "formatter": [
        { "code_action": "source.organizeImports.ruff" },
        { "code_action": "source.fixAll.ruff" },
        {
          "language_server": {
            "name": "ruff"
          }
        }
      ]
    }
  },
  "lsp": {
    "basedpyright": {
      "settings": {
        "basedpyright.analysis": {
          "diagnosticMode": "workspace",
          "inlayHints": {
            "callArgumentNames": false
          }
        }
      }
    },
    "gopls": {
      "initialization_options": {
        "gofumpt": true
      }
    },
    "yaml-language-server": {
      "settings": {
        "yaml": {
          // "keyOrdering": true,
          "completion": true,
          "format": {
            "enabled": true,
            "singleQuote": true
          },
          "schemaStore": { "enable": true },
          "schemas": {
            "kubernetes": "**/*.yaml"
          },
          "editor": { "tabSize": 4 }
        }
      }
    }
  }
}

Keymappings​

After doing some googling, I came across this awesome post where xheisenbugx had created keymappings similar to those of LazyVim for his Zed setup. The below is 99.9% from that post—I have adjusted it slightly for my needs, but these work really well.

// keymaps.json
[
  // Terminal
  {
    "context": "Workspace",
    "bindings": {
      "space f t": "workspace::ToggleBottomDock"
    }
  },
  // Window's navigation
  {
    "context": "Dock || Terminal || Editor",
    "bindings": {
      // Window's motions
      "ctrl-h": "workspace::ActivatePaneLeft",
      "ctrl-l": "workspace::ActivatePaneRight",
      "ctrl-k": "workspace::ActivatePaneUp",
      "ctrl-j": "workspace::ActivatePaneDown"
    }
  },
  {
    "context": "GitPanel",
    "bindings": {
      "q": "git_panel::Close"
    }
  },
  {
    "context": "AgentPanel",
    "bindings": {
      "ctrl-\\": "workspace::ToggleRightDock",
      "cmd-k": "workspace::ToggleRightDock"
    }
  },
  // File panel (netrw)
  {
    "context": "ProjectPanel && not_editing",
    "bindings": {
      "a": "project_panel::NewFile",
      "A": "project_panel::NewDirectory",
      "r": "project_panel::Rename",
      "d": "project_panel::Delete",
      "x": "project_panel::Cut",
      "c": "project_panel::Copy",
      "p": "project_panel::Paste",
      // Close project panel as project file panel on the right
      "q": "workspace::ToggleLeftDock",
      "space e": "workspace::ToggleLeftDock",
      ":": "command_palette::Toggle",
      "%": "project_panel::NewFile",
      "/": "project_panel::NewSearchInDirectory",
      "enter": "project_panel::OpenPermanent",
      "escape": "project_panel::ToggleFocus",
      "h": "project_panel::CollapseSelectedEntry",
      "j": "menu::SelectNext",
      "k": "menu::SelectPrevious",
      "l": "project_panel::ExpandSelectedEntry",
      "o": "project_panel::OpenPermanent",
      "shift-d": "project_panel::Delete",
      "shift-r": "project_panel::Rename",
      "t": "project_panel::OpenPermanent",
      "v": "project_panel::OpenPermanent",
      "shift-g": "menu::SelectLast",
      "g g": "menu::SelectFirst",
      "-": "project_panel::SelectParent",
      "ctrl-6": "pane::AlternateFile"
    }
  },
  // Empty pane, set of keybindings that are available when there is no active editor
  {
    "context": "EmptyPane || SharedScreen",
    "bindings": {
      // New file
      "space f n": "workspace::NewFile",
      // Open recent project
      "space f p": "projects::OpenRecent",
      // Search in all the files
      "space s g": [
        "task::Spawn",
        { "task_name": "grep_search", "reveal_target": "center" },
      ],
      // Quit zed
      "space q q": "zed::Quit"
    }
  },
  {
    "context": "Workspace",
    "bindings": {
      "space g g": [
        "task::Spawn",
        { "task_name": "start lazygit", "reveal_target": "center" }
      ]
    }
  },
  {
    "context": "Workspace",
    "bindings": {
      "space k 8": [
        "task::Spawn",
        { "task_name": "start k9s", "reveal_target": "center" }
      ]
    }
  },
  // Fuzzy Finder
  {
    "context": "Workspace",
    "bindings": {
      "space space": [
        "task::Spawn",
        { "task_name": "file_finder", "reveal_target": "center" },
      ],
    },
  },
  // Grep Search
    {
      "context": "Workspace",
      "bindings": {
        "space s g": [
          "task::Spawn",
          { "task_name": "grep_search", "reveal_target": "center" },
        ],
      },
    },
  {
    "context": "Editor && VimControl && !VimWaiting && !menu",
    "bindings": {
      // Refactoring
      "space c r ": "editor::Rename",
      // Chat with AI
      "space a a": "assistant::ToggleFocus",
      "ctrl-\\": "workspace::ToggleRightDock",
      "cmd-k": "workspace::ToggleRightDock",
      "space a e": "assistant::InlineAssist",
      "cmd-l": "assistant::InlineAssist",
      "space a t": "workspace::ToggleRightDock",
      "space g h d": "editor::ExpandAllDiffHunks",
      "space g h D": "git::Diff",
      "space g h r": "git::Restore",
      "space g h R": "git::RestoreFile",
      // Toggle inlay hints
      "space u i": "editor::ToggleInlayHints",
      // Toggle soft wrap
      "space u w": "editor::ToggleSoftWrap",
      // Open markdown preview
      "space m p": "markdown::OpenPreview",
      "space m P": "markdown::OpenPreviewToTheSide",
      // Open recent project
      "space f p": "projects::OpenRecent",
      // Search word under cursor in current pane
      "space s w": "buffer_search::Deploy",
      // Search word under cursor in all panes
      "space s W": "pane::DeploySearch",
      // Tab things. Almost as good as harpoon.
      "space 1": ["pane::ActivateItem", 0],
      "space 2": ["pane::ActivateItem", 1],
      "space 3": ["pane::ActivateItem", 2],
      "space 4": ["pane::ActivateItem", 3],
      "space 5": ["pane::ActivateItem", 4],
      "space 6": ["pane::ActivateItem", 5],
      "space 7": ["pane::ActivateItem", 6],
      "space 8": ["pane::ActivateItem", 7],
      "space 9": ["pane::ActivateItem", 8],
      "space 0": "pane::ActivateLastItem",
      "] b": "pane::ActivateNextItem",
      "[ b": "pane::ActivatePreviousItem",
      "space ,": "tab_switcher::Toggle",
      // Jump to the previous location
      "space b b": "pane::AlternateFile",
      // Close buffer
      "space b d": "pane::CloseActiveItem",
      // Close inactive buffers
      "space b q": "pane::CloseInactiveItems",
      // New file
      "space b n": "workspace::NewFile",
      // Search in the current buffer
      "space s b": "vim::Search",
      // Search in all the files
      "space s g": [
        "task::Spawn",
        { "task_name": "grep_search", "reveal_target": "center" },
      ],
      "space f n": "workspace::NewFile",
      // Search
      "space /": "workspace::NewSearch",
      // Git
      "space g b": "git::Blame",
      // LSP & Code actions
      "space c a": "editor::ToggleCodeActions",
      "space s d": "diagnostics::Deploy",
      "space s s": "outline::Toggle",
      // Format
      "space c f": "editor::Format",
      // File explorer
      "space e": "workspace::ToggleLeftDock",
      // Telescope
      "space f f": "file_finder::Toggle",
      // Quit zed
      "space q q": "zed::Quit",
      // Terminal
      "space t": "workspace::ToggleBottomDock",
      // Windows management
      "space w s": "pane::SplitDown",
      "space w v": "pane::SplitRight",
      "space -": "pane::SplitDown",
      "space |": "pane::SplitRight",
      "space w c": "pane::CloseAllItems",
      "space w d": "pane::CloseAllItems",
      // Jump to hunks
      "] h": "editor::GoToHunk",
      "[ h": "editor::GoToPreviousHunk",
      "] c": "editor::GoToHunk",
      "[ c": "editor::GoToPreviousHunk",
      // Jump to diagnostic
      "] d": "editor::GoToDiagnostic",
      "[ d": "editor::GoToPreviousDiagnostic",
      "] e": "editor::GoToDiagnostic",
      "[ e": "editor::GoToPreviousDiagnostic",
      // Excerpts
      "] q": "editor::MoveToStartOfNextExcerpt",
      "[ q": "editor::MoveToStartOfExcerpt"
    }
  },
  {
    "context": "Editor && vim_mode == visual && !VimWaiting && !VimObject",
    "bindings": {
      // Line's Motions
      "shift-j": "editor::MoveLineDown",
      "shift-k": "editor::MoveLineUp"
    }
  },
  // Center the cursor on the screen when scrolling and find all references
  {
    "context": "VimControl && !menu",
    "bindings": {
      "ctrl-d": ["workspace::SendKeystrokes", "ctrl-d z z"],
      "ctrl-u": ["workspace::SendKeystrokes", "ctrl-u z z"],
      "n": ["workspace::SendKeystrokes", "n z z z v"],
      "shift-n": ["workspace::SendKeystrokes", "shift-n z z z v"],
      "shift-g": ["workspace::SendKeystrokes", "shift-g z z"],
      "g r": "editor::FindAllReferences"
    }
  },
  {
    "context": "vim_operator == d",
    "bindings": {
      "o": "editor::ExpandAllDiffHunks",
      "r": "git::Restore"
    }
  },
  {
    "context": "vim_mode == normal || vim_mode == visual",
    "bindings": {
      "s": "vim::PushSneak",
      "S": "vim::PushSneakBackward"
    }
  },
  {
    "context": "vim_operator == a || vim_operator == i || vim_operator == cs",
    "bindings": {
      "b": "vim::AnyBrackets"
    }
  }
]