DEV Community: Pascal Matthiesen

I Catch Up a Tesla BLE Library the Way I Run Agents 🚗

Pascal Matthiesen — Tue, 08 Sep 2026 16:41:55 +0000

Hey tech adventurers! 👋

I maintain a little C++ / Arduino library that talks to Teslas over Bluetooth — unlock, climate, charging, the fun stuff. One wrong byte and the car just ignores you. Charming. 🫠

Repo went quiet for a long time. Catching it up by hand? That's weeks of careful suffering. Not because the typing is hard — because you never quite know if you broke something until you're standing next to a real car looking silly.

So I didn't do it by hand.

How I actually work 🐕

Plan first. Get a couple of independent takes so I'm not vibing alone. Make the checks real — automated tests that have to go green — then let an agent grind.

I pointed my Ageent at the library with that shape. Plan the catch-up. Put checks in place. Agent does the busywork. Fail, fix, keep moving. I don't babysit every tiny change.

Same day: what used to feel like weeks became hours.

The Tesla bit is the example 🧾

Before the agent ran wild, I added a small host test suite — known-good messages the car expects, so a change either passes or it doesn't. Short receipts. Just enough so my Agent can fail, fix, and keep going without me re-learning the whole protocol from vibes every time.

Funny part is I finally touched a library I'd been avoiding by refusing to touch it myself. Peak me. 🍕

Repo: https://github.com/pmdroid/tesla-vehicle-command

My Wife’s Steam Deck Is a Server Now. She Doesn’t Know Yet. 🫠

Pascal Matthiesen — Mon, 07 Sep 2026 22:45:01 +0000

Hey tech adventurers! 👋

What if the hardware you already own could become part of your homelab?

That spare Linux box. An old Mac. A mini PC sitting under the TV.

Or, in my case, my wife’s Steam Deck. 😅

She can’t play 24/7, so when the Deck is idle, I figured its CPU might as well do something useful.

So I installed BarkVisor on SteamOS and turned it into another Device in my Home. It can run VMs, join my other Mac and Linux machines, and even run small local AI models with Ollama.

And yes, it still plays games. I’m not that terrible of a husband.

This post is the “I actually did it on a Steam Deck” walkthrough: practical, step-by-step, and no kernel seminar.

The bigger idea, though, is simple:

You probably already have a machine that could run BarkVisor.

What you end up with 🍕

Role	Machine	Listens
Home (UI + control)	Mac/Linux on the LAN	`:7777` HTTP, `:7778` mTLS
Device (this tutorial)	Steam Deck (or similar SteamOS / handheld Linux)	`:7777` API only, `:7778` agent, Ollama `:11434`

Example LAN: Home 192.168.10.10, Deck 192.168.8.133.

You never open the Deck’s :7777 in a browser. Pair once. Then lives in BarkVisor.

Same class of machine: Steam Deck and Lenovo Legion Go–style handhelds running SteamOS / Arch-ish Linux. The unlock + pacman bits below are SteamOS / Deck-specific. Adjust paths (/home/deck) if your user isn’t deck.

1. Prep the Deck (Desktop Mode) 🛠️

Switch to Desktop Mode. Set a sudo password if you haven’t (passwd).

SteamOS root is tiny (~5GB). BarkVisor, models, and VM disks go under /home. Do not fill the root partition. Future-you will thank present-you.

Unlock the OS and trust SteamOS package keys (once — when pacman complains about unknown trust / GitLab CI Package Builder):

Click to expand: SteamOS unlock + pacman keys

sudo steamos-readonly disable
sudo pacman-key --init
sudo pacman-key --populate archlinux
sudo pacman-key --populate holo
sudo pacman-key --lsign-key 889B5EBDDD505A683621900DAF1D2199EF0A3CCF

Install the VM stack. Arch/SteamOS splits QEMU — qemu-base alone is not enough for BarkVisor’s virtio-gpu-pci, and cloud-init needs mkisofs from cdrtools:

Click to expand: QEMU + OVMF + cdrtools + swtpm

sudo pacman -S qemu-base edk2-ovmf \
  qemu-hw-display-virtio-gpu qemu-hw-display-virtio-gpu-pci \
  cdrtools swtpm

Sanity check (you want a line with virtio-gpu-pci and a writable /dev/kvm):

Click to expand: host sanity checks

command -v qemu-system-x86_64 qemu-img mkisofs
qemu-system-x86_64 -device help | grep virtio-gpu-pci
ls /usr/share/edk2/x64/OVMF_CODE.4m.fd
ls -l /dev/kvm

2. Install BarkVisor agent only (no UI) 🐕

Do not pipe install.sh into sudo on SteamOS. Use the Linux tarball under home. Agent mode = no SPA on the Deck. The Deck is a worker, not a kiosk.

Current release at time of writing: 1.0.0-alpha.3 (check GitHub releases if you’re reading this from the future).

Click to expand: download + verify + install agent under ~/.local

VER=1.0.0-alpha.3   # or whatever current release is
PREFIX="$HOME/.local/opt/barkvisor"
mkdir -p "$PREFIX" "$HOME/.local/share/barkvisor" "$HOME/.local/bin" \
  "$HOME/.config/barkvisor" "$HOME/.config/systemd/user"

cd /tmp
curl -fL -O "https://github.com/pmdroid/barkvisor/releases/download/v${VER}/barkvisor-${VER}-linux-x86_64.tar.gz"
curl -fL -O "https://github.com/pmdroid/barkvisor/releases/download/v${VER}/barkvisor-${VER}-linux-x86_64.tar.gz.sha256"
sha256sum -c "barkvisor-${VER}-linux-x86_64.tar.gz.sha256"

tar -xzf "barkvisor-${VER}-linux-x86_64.tar.gz"
SRC="barkvisor-${VER}-linux-x86_64/root/usr/local"
install -m 0755 "$SRC/bin/barkvisor" "$PREFIX/bin/barkvisor"
ln -sfn barkvisor "$PREFIX/bin/barkvisor-agent"
cp -a "$SRC/lib/barkvisor" "$PREFIX/lib/"
# skip share/barkvisor/frontend — agent mode, no SPA

CLI wrapper (sets the bundled Swift LD_LIBRARY_PATH — yes, Swift on a Steam Deck, we’re living deliciously):

Click to expand: ~/.local/bin/barkvisor wrapper + PATH

cat > "$HOME/.local/bin/barkvisor" << 'EOF'
#!/usr/bin/env bash
PREFIX="${HOME}/.local/opt/barkvisor"
export LD_LIBRARY_PATH="${PREFIX}/lib/barkvisor/swift:${PREFIX}/lib/barkvisor/compat${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
exec -a "$(basename "$0")" "${PREFIX}/bin/barkvisor" "$@"
EOF
chmod +x "$HOME/.local/bin/barkvisor"
ln -sfn barkvisor "$HOME/.local/bin/barkvisor-agent"

grep -q '.local/bin' ~/.bashrc || echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
export PATH="$HOME/.local/bin:$PATH"

Env + user systemd service (data on home, no frontend dir):

Click to expand: barkvisor.env + barkvisor-agent.service

cat > "$HOME/.config/barkvisor/barkvisor.env" << EOF
BARKVISOR_PORT=7777
BARKVISOR_DATA_DIR=$HOME/.local/share/barkvisor
BARKVISOR_SOCKET_DIR=$XDG_RUNTIME_DIR/barkvisor
HOME=$HOME
LD_LIBRARY_PATH=$HOME/.local/opt/barkvisor/lib/barkvisor/swift:$HOME/.local/opt/barkvisor/lib/barkvisor/compat
EOF

cat > "$HOME/.config/systemd/user/barkvisor-agent.service" << EOF
[Unit]
Description=BarkVisor API-only Device daemon
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
WorkingDirectory=$HOME/.local/share/barkvisor
EnvironmentFile=-$HOME/.config/barkvisor/barkvisor.env
ExecStart=$HOME/.local/opt/barkvisor/bin/barkvisor-agent
Restart=on-failure
RestartSec=3
TimeoutStopSec=8
KillMode=mixed
RuntimeDirectory=barkvisor
LimitNOFILE=65536

[Install]
WantedBy=default.target
EOF

systemctl --user daemon-reload
systemctl --user enable --now barkvisor-agent.service
curl -sS http://127.0.0.1:7777/api/health
barkvisor-agent doctor

Health should be "status":"ok". GET http://127.0.0.1:7777/ returning JSON 404 is correct for agent-only. You’re not broken. You’re disciplined.

SteamOS / Desktop Mode note: Desktop Mode already has a user session, so the service starts with that session. It will not start in Game Mode unless you enable lingering (loginctl enable-linger deck, needs root).

3. Pair the Deck to Home 🔗

On Home (the machine that already finished BarkVisor setup):

Open http://<home-ip>:7777
Settings → Pairing → Add a Device
Pick the LAN address the Deck can reach (e.g. 192.168.10.10)
Copy the full offer: barkvisor://pair/v1?code=…&host=…&port=7777&agentPort=7778&hostId=…&fp=…

The short printed code is not enough. Ask me how I know. 😅

On the Deck, with the agent already up:

Click to expand: join with full barkvisor:// offer

barkvisor-agent join --code 'barkvisor://pair/v1?code=…&host=192.168.10.10&port=7777&agentPort=7778&hostId=…&fp=…'

Or set BARKVISOR_JOIN_CODE in barkvisor.env before first start only.

With a current build, Home should hop immediately. Refresh Home: the Deck appears reachable, workload counts populate. Join talks HTTP to Home :7777; ongoing control is mTLS to the Deck :7778.

Confirm on the Deck:

Click to expand: confirm 7777 + 7778 listening

ss -ltn | grep -E '7777|7778'
# LISTEN 0.0.0.0:7777 and 0.0.0.0:7778

4. Ollama on the Deck (optional) 🧠

Want Home’s Models UI to point at the handheld? Keep Ollama under ~/.local too — not /usr/local.

Click to expand: install Ollama under ~/.local

mkdir -p ~/.local ~/.ollama/models
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst \
  | tar --zstd -xf - -C ~/.local

Listen on all interfaces so Home and guest VMs can reach it. Example user unit knobs:

Click to expand: ollama.service env hints + start

# ~/.config/systemd/user/ollama.service
# Environment=OLLAMA_HOST=0.0.0.0:11434
# Environment=OLLAMA_MODELS=/home/deck/.ollama/models
# Environment=OLLAMA_IGPU_ENABLE=1
# ExecStart=/home/deck/.local/bin/ollama serve

systemctl --user enable --now ollama.service
curl -sS http://127.0.0.1:11434/api/version
curl -sS http://192.168.8.133:11434/api/version   # use your Deck LAN IP
ollama pull llama3.2   # example

Steam Deck iGPU is ignored unless OLLAMA_IGPU_ENABLE=1. Then from Home: Settings / Models pointed at http://<deck-ip>:11434. Guest VMs on NAT see the Deck as 10.0.2.2:11434.

5. First Ubuntu VM from Home 🚀

On Home, with the Deck selected (or Create VM → this Device):

Images — download Ubuntu 24.04 LTS (or 26.04) cloud image for x86_64. Wait until status is ready.
Create VM / Ubuntu Server template.
Place it on the steamdeck Device.
Disk 16–64 GB; NAT is enough.
Create, wait until provisioning finishes (clone + cloud-init ISO).
Start.

NAT SSH: add a port forward (e.g. host 2222 → guest 22) on that VM, then from your laptop:

ssh -p 2222 ubuntu@192.168.8.133

(Guest default user is ubuntu if you used the Ubuntu template. Swap in your Deck’s LAN IP.)

6. Everyday commands (on the Deck) 🧰

Click to expand: status, logs, doctor, disk usage

systemctl --user status barkvisor-agent ollama
journalctl --user -u barkvisor-agent -f
barkvisor-agent doctor

# disks / images live here
du -sh ~/.local/share/barkvisor/{disks,images,efivars}

Home is the UI: VMs, VNC, serial, images, pairing. The Deck just works (or complains in journalctl).

Good at / not great at ⚖️

Good: extra QEMU capacity on the LAN. Ollama on the Deck iGPU (~16GB visible VRAM on a Z2 Go-class machine). Agent-only so you’re not burning cycles on a SPA nobody will open.

If something looks wrong 🧯

Symptom	Check
Home: TLS handshake failed	`:7778` up; join completed; restart `barkvisor-agent` once if you’re on an older build
`virtio-gpu-pci` is not a valid device	`pacman -S qemu-hw-display-virtio-gpu qemu-hw-display-virtio-gpu-pci`
`mkisofs` / `genisoimage` not found	`pacman -S cdrtools`
BdsDxe no bootable option	Cloud clone must leave GPT EFI PART at LBA 1; never run `sgdisk` on a `.qcow2` file
pacman “unknown trust”	`pacman-key --lsign-key 889B5EBDDD505A683621900DAF1D2199EF0A3CCF`
Ollama only on localhost	`OLLAMA_HOST=0.0.0.0:11434` and restart the user unit

Closing / pizza 🍕
Steam Deck as a headless BarkVisor Device: agent tarball in $HOME, SteamOS QEMU plus virtio-gpu and cdrtools, pair with a full barkvisor:// offer, optional Ollama on 0.0.0.0:11434. Control everything from Home on the LAN. The Deck just runs VMs and models.

Was this a responsible use of a gaming handheld? Debatable. Does it make my LAN slightly more overbuilt? Absolutely. Built with ❤️ and questionable infrastructure decisions.

P.S. Don’t want to click through every step yourself? Paste this post to your agent. They’ll have no problem doing it. 🤖

More: barkvisor.dev · github.com/pmdroid/barkvisor

QEMU Got a Dashboard. Then It Got Out of Hand. 🫠

Pascal Matthiesen — Sun, 06 Sep 2026 17:35:06 +0000

I have too many computers.

A Mac here. A Linux box there. A few VMs. Some local AI models. And apparently I was supposed to SSH into all of them like a responsible adult.

So I built BarkVisor.

It's an open-source QEMU dashboard that lets you turn your Macs and Linux boxes into one Home and manage the whole thing from one place.

They don't need to be identical. They don't even need to run the same OS.

Mac mini in the office? Add it. Linux server in the closet? Add it. Another machine under the TV because you have a problem? Add it.

One Home. One dashboard. All your machines.

And maybe Windows gets invited to the party next. 👀

👉 https://barkvisor.dev

One Home. Different machines. 🏠

This is probably the part I didn't explain well enough before.

A BarkVisor install is a Device.

Your Mac can be a Device. Your Linux server can be another Device. Add both to the same Home, and BarkVisor gives you one place to manage them.

                 🏠 My Home
                      │
          ┌───────────┼───────────┐
          │           │           │
      🍎 Mac mini   🐧 Linux    🍎 MacBook
          │           │           │
        VMs + AI    VMs + AI     VMs

Different hardware. Different operating systems. Same Home.

From there you can create workloads, decide which Device should run them, manage networking, run local models, and see what's happening across the whole setup.

And importantly, Home isn't a cluster.

There's no quorum keeping your machines alive. If the Linux box disappears, your Mac doesn't suddenly care. Workloads stay on the Device where they're running.

BarkVisor just gives all those independent machines a shared control plane.

It's less:

"I have three random computers."

And more:

"Apparently I have infrastructure now." 😅

Local AI across the Home 🧠

This gets more interesting when those Devices have different strengths.

Maybe the Mac mini is always on. Maybe the Linux box has the big GPU. Maybe another Device is mostly there for VMs.

Models can live on different Devices while BarkVisor gives you one front door for completions across the Home.

So instead of remembering:

192.168.1.42:11434
192.168.1.73:11434
wait... which box had Qwen?

you talk to BarkVisor.

One Home. One endpoint. Multiple machines.

Basically a tiny inference router that escaped from my homelab.

Networking with an undo button 🧯

Host networking is where confidence goes to die.

Bridges are useful right up until the moment you accidentally remove the network connection you're currently using to configure the bridge.

Ask me how I know.

So BarkVisor assumes you're going to do something stupid and gives you a way back before the change sticks.

NAT is there when you want boring.

Bridges are there when you want power.

And rollback is there when you discover you wanted boring after all.

Alpha on top. QEMU underneath. 🪨

BarkVisor itself is Alpha.

The dashboard will change. The API will change. I will probably rename something five minutes after you learn it.

But the actual virtualization layer isn't an experiment.

QEMU is QEMU.

Battle-tested virtualization. Real VMs. Boring, reliable infrastructure.

BarkVisor is the opinionated layer I bolted on top because apparently typing ssh one more time was my breaking point.

And yes, there's a phone app 📱

Because obviously this got out of hand.

There's a native SwiftUI console aimed at Mac and iOS, and phone sign-in already works.

I'm not giving you an App Store date.

"Soon" is the most accurate unit of time available.

This is only the beginning 🛠️

The idea behind BarkVisor isn't really "put a UI on QEMU."

It's:

make the computers you already own feel like one Home.

Today that's macOS + Linux.

Tomorrow? Maybe Windows joins too. 👀

And the roadmap gets progressively more unreasonable from there: failover, live migration, distributed storage, backups, cross-Device networking, portable workloads, Tailscale/WireGuard and more.

No promises on dates. Plenty of questionable ideas.

👉 See the roadmap

Try it. Break it. Add another box. 🚀

BarkVisor is open source, MIT licensed, and very much being built in public.

If you've got a Mac, a Linux machine, or preferably both, give it a spin.

Install BarkVisor on them.

Put them in the same Home.

Create a VM. Run a model. Add another Device. Break the networking. Hopefully recover the networking.

Then open an issue and tell me what I got wrong.

👉 https://barkvisor.dev

Built with ❤️, QEMU, and the kind of overengineering that starts with:

"I just want one dashboard."

My Agents Don't Get to Vibe 🤖

Pascal Matthiesen — Sat, 05 Sep 2026 04:15:48 +0000

Hey tech adventurers! 👋

I use coding agents a lot. Probably an irresponsible amount.

My current favorite is Grok Build. 🤖❤️

But I don't want my workflow tied to one agent. Models change, shiny new robots appear, benchmarks go brrrr, and everyone changes their mind by Tuesday. 😂

So my setup is intentionally boring and agent agnostic:

Skills describe the workflow. Hooks enforce it.

Plan before you cook 🏛️

I don't like giving an agent:

"Build feature X."

That's how you get 2,000 lines of beautifully implemented misunderstanding. 🫠

Instead, I use a council skill. Multiple agents independently look at the problem, challenge the architecture, and turn the result into a technical issue.

And I mean technical:

SQL schemas • migrations • structs • types • classes • APIs • files • edge cases • acceptance criteria

If we need a table, put the schema in the issue.

CREATE TABLE pizzas (
    id UUID PRIMARY KEY,
    topping TEXT NOT NULL,
    delicious BOOLEAN NOT NULL DEFAULT true
);

No:

"Build a robust and scalable pizza management solution."

Ah yes. Robust and scalable. Now I know exactly what to build. 😂

Let the agents argue while changing the architecture is still cheap.

Then let the robot cook 👨‍🍳🤖

Once the issue is sharp, I hand it to the builder.

Right now that's usually Grok Build.

The architecture is there. The types are there. The acceptance criteria are there.

Go cook. 🍕

After implementation comes autoreview:

review → findings → fix → review

Much better than letting the same robot write the code, review itself, congratulate itself, and ship.

I use variations of this across things I'm building like acpbot.app, gegenlesen.app, and barkvisor.dev.

Different projects. Same little robot factory. 🏭🤖

No receipt, no ship 🧾🚢

This is probably the most useful thing I've added lately.

Agents love saying:

Tests pass. Should work. ✅

Should. 🫠

So I stopped asking them to verify.

I enforce proof before they can push.

Each project has a verification skill that knows how to prove the real thing works:

run it • click it • call it • query it • screenshot it • show evidence

Tests are great.

But "tests pass" and "I used the thing and here is proof it works" are not the same thing.

Then a hook enforces it.

No proof?

No push. 🚫🤖

Preflight runs before pushing or opening the PR too.

The robot can be creative while working. When it approaches the exit, we check the luggage. 🛂

That's basically my loop 🔁

💡 Idea → 🏛️ Council → 📝 Technical issue → 👨‍🍳 Build → 🛡️ Review + fix → 🧾 Verify + proof → 🛂 Preflight → 🚀 PR

That's it.

I'm not trying to build the perfect mega-agent.

I'm trying to make the process around the agent reliable.

Agents are replaceable. Skills are portable. Hooks keep the minions honest. 🤖

Credit where credit is due 🙌

A lot of this workflow is inspired by Lauren Tan, Peter Steinberger, and Matt Pocock.

Lauren's work around skills and agent workflows, Peter's autoreview approach, and Matt's work around planning, specs, and engineering skills all heavily influenced my setup.

I mostly mixed the parts I liked with my own questionable engineering decisions and added the rule that's been most useful lately:

No proof? No push. 🧾🚫

Clickjitsu: The Art of Delegating Browser Tasks to AI Minions 🤖

Pascal Matthiesen — Thu, 14 Aug 2025 11:13:00 +0000

Hey tech adventurers! 👋 Ready to turn the mundane world of browser automation into something that would make science fiction jealous? Let's dive into Clickjitsu - a project that proves sometimes the best ideas come from the most questionable engineering decisions! 🚀

The Abstract Vision 🔮

Challenge 🤔: You need to automate web tasks, but traditional browser automation is about as secure as leaving your front door open with a "Free Stuff Inside" sign.

Solution 💡: Spawn completely fresh, isolated browser environments in Kubernetes, hand control to AI agents, and watch the digital magic unfold with military-grade security.

Why You'll Love This:

Watch AI work in real-time via WebRTC streaming 📺
Zero security contamination between sessions 🛡️
Scalable cloud-native architecture that handles enterprise workloads 📈
Fresh browser instances for every single task 🧹

Imagine saying "go buy me those fancy headphones" and watching a completely isolated browser environment materialize in the cloud, execute your mission, and vanish without a trace. That's Clickjitsu – where browser automation meets paranoid-level security! 🕵️‍♂️

The Security-First Philosophy 🛡️

Here's where things get seriously smart: Every single session creates a brand new browser instance from scratch. No cookies, no history, no digital fingerprints from previous adventures. It's like having a perfectly clean rental car for every trip, except the car also self-destructs when you're done! 🚗💥

Why This Security Model Is Genius:

Zero Cross-Contamination: Your Amazon shopping spree can't accidentally leak into your banking session 🏦
Fresh Identity Every Time: Each AI agent starts with a completely blank slate 🧹
Isolated Kubernetes Namespaces: Every browser session lives in its own fortress 🏰
Ephemeral by Design: When the task ends, everything vanishes like it never existed 💨
Observable Operations: Real-time streaming means you can supervise your AI minions 👁️

The Technical Magic Behind the Curtain 🎭

Architecture That Actually Makes Sense 🏗️

Fresh Browser Request → Isolated K8s Namespace → Virgin Browser + AI Agent
                              ↓
                    Live Stream ← WebRTC ← Secure Monitoring  
                              ↓
                         Results + Cleanup + Self-Destruct

Each session is like hiring a digital temp worker who:

Gets a completely clean computer 💻
Follows your exact instructions 📋
Reports back with results 📊
Shreds everything when done 🗂️

The Tech Stack That Makes It Possible ✨

🎬 browser-use: The AI agent doing all the clicking wizardry
📺 neko: Streams the browser chaos via WebRTC so you can watch the show
☸️ Kubernetes: Because why make things simple when you can make them distributed and bulletproof?
🐹 Go: The glue holding this beautiful controlled chaos together
🧠 OpenAI: Powers the AI that (hopefully) won't accidentally order 500 rubber ducks
🗄️ Redis: Session state management that doesn't judge your automation choices

Code That Makes You Go "Wow" ⚙️

The session manager is where the real magic happens. Check out this beautiful orchestration:

func (m *Manager) CreateSession(ctx context.Context, req *models.CreateSessionRequest) (*models.Session, error) {
    sessionID := uuid.New().String()
    namespace := fmt.Sprintf("browser-session-%s", sessionID)

    session := &models.Session{
        ID:          sessionID,
        ExternalURL: fmt.Sprintf("https://%s.%s?usr=neko&pwd=neko&embed=1&volume=1", 
                                sessionID, m.config.BrowserDomain),
        Status:      models.StatusCreating,
        Prompt:      req.Prompt,
        ExpiresAt:   time.Now().Add(m.config.BrowserSessionTTL),
    }

    go m.createSessionResources(context.Background(), session)
    return session, nil
}

Each session gets its own Kubernetes namespace – talk about resource isolation! It's like giving every AI agent their own private mansion that gets demolished after the party 🏰

The AI Runner: Where Dreams Meet Reality 🤖

The Python runner executing inside each pod is delightfully elegant:

agent = Agent(
    task=os.environ["PROMPT"],
    llm=ChatOpenAI(model="o4-mini", temperature=1.0),
    browser_session=browser_session,
)
history = await agent.run()
result = history.final_result()

It's literally: "Hey AI, here's a pristine browser and a task. Go nuts, but do it securely!" 🥜

Real-World Applications (That Actually Matter) 🌍

Enterprise Use Cases That'll Impress Your Boss:

Automated Testing: Fresh browsers for every test run, eliminating flaky tests caused by session contamination 🧪
Market Research: Clean environments for competitive analysis without revealing your digital fingerprints 🔍
Compliance Checking: Isolated sessions for regulatory verification with complete audit trails ✅
Data Gathering: Secure web scraping without contamination or detection 🕷️
Form Automation: Fill repetitive enterprise forms without data leakage 📝

Personal Use Cases That'll Change Your Life:

Price Monitoring: AI checks deals without accumulating tracking cookies 💰
Research Tasks: Clean browsing for sensitive investigations 🔬
E-commerce Automation: Let AI handle your shopping without compromising your privacy 🛒
Social Media Management: Automate posts and interactions with complete isolation 📱

The "What Could Go Right" Scenarios 🎯

Unlike traditional browser automation that accumulates digital baggage like a hoarder's basement, Clickjitsu's ephemeral approach means:

No Session Hijacking: Fresh browser = fresh start every time 🔄
No Data Persistence: Sensitive info never lingers around like a bad smell 🚫
No Cross-Task Interference: Yesterday's shopping can't affect today's banking 🏪➡️🏦
Perfect Audit Trail: Every session is logged, isolated, and traceable 📊
Scalable Security: Want 100 AI agents? Just scale the pods without security concerns! 📈

Security Wins That Actually Matter 🏆

Container-Level Fort Knox 🏰

Network Segmentation: Kubernetes networking keeps sessions separated like VIP sections at a concert 🕸️
Resource Limits: AI can't consume infinite resources or accidentally bankrupt you 💸
Clean Slate Guarantee: Every session starts with zero previous context, like digital amnesia 🧼
Real-Time Monitoring: Watch exactly what your AI agent is doing, no surprises! 👁️

Taking Security to Ludicrous Speed 🚀

For Production Environments, you could take this paranoia to the next level with some seriously hardcore isolation:

gVisor: Run containers in a user-space kernel for that extra "nope, you're not touching my host OS" feeling 🛡️
Kata Containers: Each container gets its own lightweight VM because why trust anything? 🏰
Firecracker MicroVMs: AWS-style microVMs that boot faster than your morning coffee ☕

# Because regular containers are for peasants
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
spec:
  runtimeClassName: kata-containers  # Or gvisor, or firecracker
  containers:
  - name: paranoid-browser
    image: clickjitsu/browser:latest
EOF

Why Go Full Paranoid? 🕵️‍♂️

Kernel-Level Isolation: AI agent escapes? Still trapped in VM-land!
Hardware-Assisted Security: CPU features working overtime to keep you safe
Compliance Gold Star: Auditors will weep tears of joy at your isolation levels ⭐
Sleep Better at Night: Because knowing your AI can't accidentally root your cluster is priceless 😴

Infrastructure Patterns That Impress 🎯

# Each session gets its own isolated environment
apiVersion: v1
kind: Namespace
metadata:
  name: browser-session-uuid-here
---
# Browser container with Chrome DevTools + MicroVM isolation
# AI runner container with browser-use + gVisor sandboxing
# All ephemeral, all secure, all magnificently over-engineered

The Infrastructure Wins That Matter 🚀

Despite being born from "questionable life choices," Clickjitsu showcases serious cloud-native patterns:

Ephemeral Workloads: Each session is completely isolated and self-cleaning 🧹
Horizontal Scalability: Want 100 AI shoppers? Just scale the pods! 📈
Resource Management: Proper CPU/memory limits prevent AI shopping sprees from breaking your cluster 💳
WebRTC Streaming: Real-time browser viewing because watching AI click buttons is surprisingly addictive 👁️
GitOps Ready: Infrastructure as code that would make your DevOps team weep with joy 😭

Warning Labels and Disclaimers ⚠️

This is a one-day hack that turned into something surprisingly robust – use responsibly! Side effects may include:

Mysterious charges on your credit card (set those spending limits!) 💳
AI developing sentience and judging your browsing habits 👨‍⚖️
Kubernetes bills that make you question life choices 💸
Your browser automation having better security than most enterprise systems 🏢
Colleagues asking "how the hell did you build that?" 🤯

The Future of Secure Automation 🔮

This isn't just about letting AI click buttons – it's about creating a paradigm where automation meets paranoid-level security. Imagine:

Corporate AI Assistants: Safely handling sensitive business processes without data leakage 💼
Personal Digital Butlers: Managing your online life without privacy nightmares 🏠
Research Automation: Gathering competitive intelligence without leaving digital footprints 🕵️
Compliance Automation: Meeting regulations with verifiable isolation and audit trails ✅
Zero-Trust Browsing: Every web interaction happens in a disposable, monitored environment 🗑️

Try It Yourself (If You Dare) 🎮

Want to watch AI navigate the web while you sip coffee in your security-hardened ivory tower? The project is open source and ready for your own questionable experiments!

Getting Started:

# Clone the madness
git clone https://github.com/pmdroid/clickjitsu

# Deploy to your K8s cluster
# Watch AI do your bidding
# Profit (securely)

Just remember: with great AI power comes great responsibility (and the need for really good monitoring) 🕷️

Key Takeaways That'll Stick 🎯

Security Through Isolation: Fresh environments eliminate contamination risks better than hand sanitizer 🛡️
Observable AI: Real-time streaming lets you supervise your digital minions like a benevolent overlord 👀
Scalable Architecture: Cloud-native design handles enterprise workloads without breaking a sweat 📈
Zero Persistence: What happens in the container, stays in the container (and then gets obliterated) 🔒
Infrastructure as Entertainment: Who knew watching AI browse the web could be this addictive? 🍿

The Bottom Line 💰

Clickjitsu proves that sometimes the most useful innovations come from solving problems you didn't know you had. It's browser automation for the age of zero-trust architecture, where every click is monitored, every session is isolated, and every result is achieved without compromising your digital soul.

Ready to delegate your browser tasks to AI agents while keeping everything locked down tighter than Fort Knox? Your secure automation journey starts here! 🚀

Built with ❤️ and questionable engineering decisions that somehow resulted in enterprise-grade security. Because in 2025, even our browser automation needs better security than most banks 😅🏦

P.S. - Yes, it actually works. No, we can't be held responsible for what your AI decides to buy. Please set spending limits. I'm not kidding about this one! 💸

Cloudflare Logs: Not Just for Breakfast Anymore 🥞

Pascal Matthiesen — Tue, 05 Aug 2025 07:38:47 +0000

Alright, log lovers, let's get this observability party started 🎉. We're about to turn your Cloudflare logs from wallflowers into the life of the data analysis party 🥳.

Challenge 😕: Cloudflare Logpush delivers valuable data, but it might not be in the most usable format for further analysis.

Solution 💡: Enter Vector and Loki, the dream team 🏆. We'll leverage Vector's built-in HTTP server to accept your Cloudflare log lines, process them, and then ship them off to Loki for storage and analysis 🚀.

Why Bother? 🤔

Find and fix issues faster: Your logs will be organized and searchable, making troubleshooting a breeze.

Optimize performance: Identify bottlenecks and fine-tune your applications like a pro.

Boost security: Detect threats and protect your digital assets.

Get Ready to Geek Out!

We'll dive into the technical details soon, so get your command line fingers ready. You'll learn how to:

Set up Vector to transform and forward your logs.
Get Loki ready to ingest and analyze your data.
Configure Cloudflare Logpush to send logs via HTTP.

These commands give your Kubernetes cluster a VIP backstage pass 🎫 to the hottest logging tool in town: Vector! ✨

helm repo add vector https://helm.vector.dev: This tells Helm (your trusty Kubernetes package manager) where to find Vector's exclusive swag, like adding a secret app store to your phone 🤫.
helm repo update: This command refreshes Helm's knowledge, making sure you have access to the freshest Vector releases. Think of it as checking for those "new app" notifications on your phone 📲.

helm repo add vector https://helm.vector.dev
helm repo update

This Kubernetes Secret ("vector") is the Fort Knox 🔒 of your Vector logging tool, guarding a super-secret HTTP password ("123abc") 🤫. But hold on, Captain Obvious here 🦸 – change that password before some sneaky cyber ninja 🥷 steals your precious logs!

apiVersion: v1
kind: Secret
metadata:
  name: vector
  namespace: vector
stringData:
  HTTP_PASSWORD: "123abc"

This Vector configuration sets up a secure gateway 🚪 for your Cloudflare logs. It grabs the logs, translates them into a format Loki understands 🗣️, and then sends them off for safekeeping 📦. It's like a trusty butler for your website data 🤵.

envFrom:
  - secretRef:
      name: vector
service:
  ports:
    - name: http
      port: 3000
  enabled: true
role: Stateless-Aggregator
customConfig:
  acknowledgements:
    enabled: true
  sources:
    in:
      type: "http"
      address: 0.0.0.0:3000
      strict_path: false
      encoding: text
      path: /ingest
      auth:
        username: cloudflare
        password: "${HTTP_PASSWORD}"
  transforms:
    parse_json:
      type: remap
      inputs:
        - "in"
      source: |
        . = parse_json!(.message)
        .timestamp = from_unix_timestamp!(.EventTimestampMs, unit: "milliseconds")
  sinks:
    out:
      type: "loki"
      tenant_id: "0:0"
      encoding:
        codec: "json"
      remove_timestamp: false
      out_of_order_action: accept
      labels:
        job: cloudflare
      endpoint: http://loki-gateway.monitoring.svc.cluster.local
      inputs:
        - "parse_json"

This command summons the Helm installer 🧙‍♂️ to conjure up Vector on your Kubernetes cluster:

helm install vector vector/vector \
  --namespace vector \
  --create-namespace \
  --values values.yaml

It's like giving Helm a magic spell book 🪄, pointing to the Vector spell page, and telling it where to build Vector's cozy little home 🏡 (in the "vector" namespace) with the customizations you specified in the "values.yaml" file. Now you're ready to wrangle those logs! 🧹🪵

Now, let's teach Cloudflare to share those juicy logs with Vector! 🤝 Just replace the placeholders and run this command in your terminal:

curl -X POST "https://api.cloudflare.com/client/v4/accounts/<YOUR_CF_ACCOUNT_ID>/logpush/jobs" \
  -H "Authorization: Bearer <YOUR_CF_API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
      "name": "vector-logs",
      "destination_conf": "<YOUR_VECTOR_ENDPOINT>?header_Authorization=Basic%20<BASE64_ENCODED_AUTH>",
      "dataset": "workers_trace_events",
      "enabled": true
  }'

Replace these placeholders:

: Your Cloudflare account ID 🔢
: Your Cloudflare API token 🗝️
: The full URL to your Vector's HTTP endpoint (e.g., https://vector.yourdomain.com/ingest) 🌐
: Your Vector username and password encoded in Base64 format 🔒 (echo -n "$username:$password" | base64)

That's it! Cloudflare will start pushing logs to Vector, and Vector will whisk them off to Loki for safekeeping and analysis. 💨 Now you're a log analysis wizard! 🧙‍♂️

And with that, the logs have been tamed... for now. 😈 But rest assured, they'll be back with a vengeance, just like my insatiable craving for pizza. 🍕 If you enjoyed this wild ride through log analysis, join me next time as I tackle more tech challenges, share hilarious startup fails, and maybe even reveal my secret pizza recipe (just kidding...or am I? 😉).

GitOps Made Easy: Building the Ultimate Kubernetes Testing Lab 🚀

Pascal Matthiesen — Tue, 05 Aug 2025 07:33:27 +0000

Hey Kubernetes warriors! 👋 Ever wanted to spin up a complete, production-like environment faster than you can say "microservices"? Well, buckle up because we're about to explore flux-e2e - a GitOps repository that'll make your infrastructure dreams come true!

The Challenge 🤔

Picture this: You're building a Kubernetes application, and you need to test it with proper networking, security policies, observability, and all the production bells and whistles. Traditionally, this means hours of YAML wrestling, secret management nightmares, and probably at least three cups of coffee ☕.

The usual pain points:

Setting up proper GitOps workflows 📝
Configuring secure networking without losing your sanity 🔐
Getting observability right from day one 📊
Making it all work together without breaking 💥

The Solution 💡

Enter flux-e2e - a beautifully orchestrated GitOps repository that gives you a complete Kubernetes testing environment with just one command. Think of it as the "easy button" for infrastructure testing!

What Makes This Special? ✨

This isn't just another "hello world" Kubernetes setup. We're talking about a full-stack, production-ready testing environment that includes:

GitOps with Flux CD - Because manual deployments are so 2019 📅
Cilium CNI + Tailscale - Networking that actually makes sense 🌐
Grafana + Loki - Observability that doesn't suck 📈
Network policies + sealed secrets - Security that doesn't give you headaches 🛡️
Proper dependency management - Everything deploys in the right order 🎯

The Architecture That'll Make You Smile 😊

The genius lies in the numbered directory structure:

├── 0-bootstrap/          # Start here - namespaces and basics
├── 1-network-policies/   # Lock it down early
├── 2-secrets/           # Encrypted secrets (no more leaked passwords!)
├── 3-config/            # Configuration management
├── 4-infrastructure/    # The heavy lifting (cert-manager, operators)
├── 5-system/           # Core services (MariaDB, Redis)
├── 6-apps/             # Your actual applications
├── 7-ingress/          # Tailscale funnel magic
└── cluster/            # Flux orchestrates it all

Why this is brilliant: Dependencies flow naturally from 0 to 7. No more "chicken and egg" deployment problems! 🐣

The Magic Script 🪄

Ready for the best part? Getting this entire stack running is literally one command:

export TAILSCALE_API_KEY="tskey-api-xxxxx"
# ... set a few more environment variables
./local.sh

What happens next is pure magic:

Spins up a Kind cluster with Cilium 🎪
Installs Flux CD and points it to your repo 🎯
Deploys everything in the correct dependency order 📋
Sets up Tailscale networking for secure access 🔒
Gives you URLs to access your services! 🌍

The Tailscale Twist 🌟

Here's where things get really cool. Instead of dealing with LoadBalancers or complicated ingress setups, everything is exposed through Tailscale funnel. Your services get URLs like:

https://{random-prefix}grafana.{tailnet}.ts.net
https://{random-prefix}echo.{tailnet}.ts.net

Why this rocks:

Secure by default (only your Tailscale network can access) 🔐
No public IPs or complex firewall rules 🚫
Works from anywhere with proper authentication ✅
Random prefixes prevent conflicts in shared environments 🎲

Under the Hood: Smart Design Patterns 🔧

1. Variable Substitution Magic

Everything is configured through a cluster-vars ConfigMap with variable substitution:

someConfig: ${VARIABLE_NAME}

Change one value, update everything! 🎭

2. Sealed Secrets = Sleep Better at Night

No more secrets in plaintext Git repos. Everything is encrypted with sealed-secrets, so you can commit your secrets safely. Your security team will love you! 💕

3. Network Policies by Default

Every namespace gets restrictive network policies. Because security shouldn't be an afterthought! 🛡️

Real-World Use Cases 🌍

Perfect for:

Local development - Full-stack testing without the cloud bill 💰
CI/CD pipelines - Spin up environments for each PR 🔄
Learning GitOps - See how it all fits together 🎓
Architecture validation - Test your designs before production 🧪

Debugging Like a Pro 🕵️

When things go sideways (they always do), the repo includes helpful debugging commands:

# Check Flux status
flux get kustomizations

# See what's broken
kubectl get pods -A

# Follow the logs
kubectl logs -n flux-system -l app=helm-controller

The Cleanup is Automatic! 🧹

Exit the script, and everything cleans up automatically:

Removes Tailscale devices ✅
Optionally deletes the Kind cluster ✅
No orphaned resources ✅

No more "what was that cluster name again?" moments! 😅

Why This Matters 🎯

In a world where Kubernetes complexity can make grown developers cry, flux-e2e shows us that:

GitOps doesn't have to be hard - Good structure makes all the difference
Security can be baked in - Network policies and sealed secrets from day one
Observability is achievable - Grafana and Loki working out of the box
Local testing can be production-like - No more "works on my machine" 🤷‍♂️

Get Started Today! 🚦

Ready to revolutionize your Kubernetes testing game?

Clone the repo: git clone https://github.com/pmdroid/flux-e2e
Set your environment variables (don't forget the Tailscale API key!)
Run: ./local.sh
Watch the magic happen ✨

Final Thoughts 💭

flux-e2e isn't just a repository - it's a blueprint for how modern Kubernetes deployments should work. It proves that with the right patterns and tools, we can have:

Simplicity without sacrificing functionality 📊
Security without operational overhead 🔒
Observability without complexity 👀
GitOps without the learning curve 📈

Whether you're a GitOps newbie or a Kubernetes veteran, this repo will teach you something new about building resilient, secure, and observable systems.

Now go forth and GitOps responsibly! 🎉

Have you tried flux-e2e? Share your experience in the comments! And if you build something cool with it, we'd love to hear about it! 🗨️