Tag: Devops

The problem: httpfs ignores your environment variables

If you work with DuckDB and the httpfs extension to read remote Parquet files, CSVs from S3, or any HTTP resource, you probably assume that the HTTP_PROXY and HTTPS_PROXY environment variables work just like every other tool. Curl respects them. wget respects them. Python requests respects them. Node.js respects them.

DuckDB does not.

I ran into this while working in a corporate environment with a mandatory proxy. I had a script reading Parquet files from Google Cloud Storage using httpfs, and it simply would not work. No clear error, no descriptive timeout, just silence. Meanwhile, a curl to the same resource with the same environment variables returned data without issue.

I recently came across an exceptionally dense technical analysis about container security that’s worth sharing. The author started with a simple hypothesis: container filesystem isolation should be sufficient for multi-tenant workloads without virtual machines, if you sufficiently understand what’s happening at the syscall level.

After thorough investigation, the conclusion is more uncomfortable than expected: the defaults protect you well, but the moment you reach for “advanced” features like bidirectional mount propagation or SELinux relabeling, you’re one misconfiguration away from handing an attacker the keys to your host.

Finally: Modern JavaScript in NGINX (and we can forget about LUA)

When I read the NGINX announcement about QuickJS support in njs, I couldn’t help but smile. Finally I can stop struggling with LUA.

As someone who has configured more NGINX servers than I can remember (from my time at Arrakis to now at Carto), I’ve always been annoyed by the limitation of having to use LUA for complex logic in NGINX. It’s not that LUA is bad, but… why learn another language when I already master JavaScript?

The Problem We All Have (But Solve Poorly)

As a DevOps Manager, I spend more time than I should configuring ways for the team to show their development work. Client demos, webhooks for testing, temporary APIs for integrations… we always need to expose localhost to the world.

Traditional options are a pain:

• ngrok: Works, but ugly URLs, limits on free plan, and every restart generates a new URL
• localtunnel: Unstable, URLs that expire, and often blocked by corporate firewalls
• SSH tunneling: Requires your own servers, manual configuration, and networking knowledge
• Manual Cloudflare Tunnels: Powerful but… God, the manual configuration is hellish

And then I discovered Moley.

With the constant evolution of AI-powered development tools, Claude Code has introduced a revolutionary feature: Hooks. This feature allows developers to customize and automate specific behaviors in the Claude Code lifecycle, transforming suggestions into executable code that works deterministically.

Hooks represent a qualitative leap in the customization of AI development tools, allowing each team and developer to adapt Claude Code to their specific needs and project standards.

What are Claude Code Hooks?

Claude Code Hooks are user-defined shell commands that execute automatically at various specific points in the Claude Code lifecycle. Unlike prompting instructions, hooks guarantee that certain actions always occur, providing deterministic control over the tool’s behavior.