NodeNV

Context

NodeNV (nodenv.online) is my technical playground. It started as a simple idea: I needed a space to experiment with AI workflows, internal tools, and deployment systems without the constraints of a production portfolio. Every developer should have a lab — a place where ideas can be half-baked, experiments can fail, and prototypes can evolve without pressure.

Why a Separate Domain

I deliberately keep NodeNV on its own domain, separate from klosraf.online. The reason is not technical — it is psychological. When something lives on your main portfolio, it needs to be polished. That pressure kills experimentation. NodeNV is where I try things that might not work: new frameworks, unproven AI integrations, unconventional UI patterns. If they work, they graduate to the main portfolio. If they don't, they stay in the lab as learnings.

The AI Automation Pipeline

The core experiment on NodeNV is an AI automation pipeline that connects: an LLM API (OpenAI/Anthropic) with a task queue, a set of tool-calling functions (web search, file operations, API calls), and a simple web interface for monitoring and manual approval. The idea is to test whether LLMs can reliably orchestrate multi-step business workflows — not just generate text, but actually execute actions and make decisions within defined boundaries.

Key Learning: AI Needs Guardrails, Not Freedom

The biggest lesson from the NodeNV experiments is that raw LLM autonomy does not work for business workflows. Give an AI too much freedom, and it will hallucinate API calls, create files in unexpected places, or interpret instructions in creative but wrong ways. The solution was to add structured guardrails: each workflow step has a defined schema, allowed tool calls are whitelisted, and every external action requires explicit human approval. This slows down the workflow but makes it reliable enough for real use.

Deployment Pattern

NodeNV runs on a separate VPS with Docker Compose. Each experiment is a separate container with its own Dockerfile and compose service. This means: experiments are isolated, rolling back a failed deployment does not affect other services, and resource limits prevent one experiment from starving others. The downside is disk usage — each container images adds to storage, but for a lab environment, the isolation is worth the cost.

Gallery