Devops on Yarang's Tech Lair

[MicroVM] Building Isolated Sandboxes with Firecracker

Sat, 27 Jun 2026 09:01:26 +0900

[MicroVM] Building Isolated Sandboxes with Firecracker

MicroVM technology is gaining attention recently. Traditional containers (like Docker) share the kernel with the host, making them not entirely secure in terms of isolation. On the other hand, MicroVMs like AWS’s Firecracker provide lightweight virtual machines, allowing you to achieve both “container speed” and “VM security.”

In this article, we will practically introduce how to safely execute untrusted code using Firecracker MicroVM, a key consideration in the communication protocol design for ZeroClaw, a Rust-based agent runtime, with accompanying code examples.

Why MicroVM?

In the past development of blog API servers or MCP (Model Context Protocol) clients, container environments were primarily used. However, security becomes even more critical in multi-agent systems or environments that need to execute external code.

Single Process Isolation: Each MicroVM has an independent kernel space.
Fast Boot: Boot times in milliseconds offer speeds similar to containers.
Resource Limits: CPU and memory usage can be strictly controlled.

Prerequisites

To follow this guide, you will need a Linux environment (with KVM enabled) and the Rust toolchain. Firecracker runs on Linux KVM (Kernel-based Virtual Machine).

# Check KVM permissions
ls -la /dev/kvm
# Add to group (if you don't have permissions)
sudo usermod -aG kvm $USER

1. Downloading and Preparing Firecracker

Firecracker is provided as a single binary, making deployment very simple.

cd /tmp
curl -L -o firecracker-v1.9.1 https://github.com/firecracker-microvm/firecracker/releases/download/v1.9.1/firecracker-v1.9.1-x86_64
chmod +x firecracker-v1.9.1
mv firecracker-v1.9.1 firecracker

2. Creating a Root Filesystem for MicroVM Boot

To run a MicroVM, you need a simple Linux kernel and a root filesystem (image). We will download an Ubuntu image for testing.

# Create working directory
mkdir -p fc-demo
cd fc-demo

# Download Ubuntu 22.04 root filesystem
wget https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-amd64-root.tar.xz

# Convert image (raw format)
xz -d ubuntu-22.04-server-cloudimg-amd64-root.tar.xz

3. Writing Control Logic in Rust

Now, let’s use Rust to launch a Firecracker instance, configure networking, and send requests. Passing configurations as JSON using serde_json is the most common approach.

Cargo.toml dependencies:

[dependencies]
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
reqwest = { version = "0.12", features = ["blocking"] }

Rust Implementation Code (main.rs):

use std::fs::{self, File};
use std::io::Write;
use std::process::{Command, Stdio};
use serde::Serialize;

// Firecracker configuration structs
#[derive(Serialize)]
struct BootSource {
 kernel_image_path: String,
 boot_args: String,
}

#[derive(Serialize)]
struct Drive {
 drive_id: String,
 path_on_host: String,
 is_root_device: bool,
 is_read_only: bool,
}

#[derive(Serialize)]
struct MachineConfig {
 vcpu_count: u8,
 mem_size_mib: u64,
 ht_enabled: bool,
}

#[derive(Serialize)]
struct NetworkInterface {
 if_id: String,
 guest_mac: String,
 host_dev_name: String,
}

fn main() {
 // 1. Set up working directory
 let vm_id = "my-first-microvm";
 fs::create_dir_all(format!("/tmp/fc-demo/{}", vm_id)).expect("Failed to create vm dir");

 // 2. Run Firecracker process (in background)
 // In a real environment, you would manage it as a daemon or create a socket via API.
 // Here, we assume the API server is run via a socket for simplicity and send configurations.
 
 // Note: A kernel image (vmlinux) is required for actual execution. 
 // It can be downloaded from the AWS Firecracker GitHub releases.
 let kernel_path = "/tmp/fc-demo/vmlinux"; // Path needs verification
 let rootfs_path = "/tmp/fc-demo/ubuntu-22.04-server-cloudimg-amd64-root.tar";

 // (Network configuration is complex in actual tutorials, so TAP device creation is omitted)
 // Example API configuration creation
 let boot_config = BootSource {
 kernel_image_path: kernel_path.to_string(),
 boot_args: "console=ttyS0 reboot=k panic=1 pci=off".to_string(),
 };

 let drive_config = Drive {
 drive_id: "rootfs".to_string(),
 path_on_host: rootfs_path.to_string(),
 is_root_device: true,
 is_read_only: false,
 };

 // Save configurations to JSON files (Firecracker accepts input via HTTP API or JSON files)
 let config_json = serde_json::to_string_pretty(&vec![&boot_config, &drive_config]).unwrap();
 let mut file = File::create(format!("/tmp/fc-demo/{}/vm_config.json", vm_id)).unwrap();
 file.write_all(config_json.as_bytes()).unwrap();

 println!("MicroVM configuration complete: {}", vm_id);
 println!("Firecracker typically requires network setup via TAP and mount configuration.");
 println!("Example CLI usage:");
 println!("./firecracker --api-sock /tmp/fc-demo/{}/api.sock", vm_id);
 println!("Then, send configurations via curl to http://localhost/...");
}

4. Execution and Control (CLI Method)

While automating with Rust code is ideal, it’s recommended to control and verify operations directly via CLI during the development stage.

# 1. Create TAP network interface (for host-guest connection)
sudo ip tuntap add tap0 mode tap
sudo ip addr add 169.254.0.1/30 dev tap0
sudo ip link set tap0 up

# 2. Run Firecracker (API socket mode)
./firecracker --api-sock /tmp/fc-demo/my-api.sock &

# 3. Send boot source configuration
curl --unix-socket /tmp/fc-demo/my-api.sock -i \
 -X PUT 'http://localhost/boot-source' \
 -H 'Accept: application/json' \
 -H 'Content-Type: application/json' \
 -d '{
 "kernel_image_path": "/path/to/vmlinux",
 "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
 }'

# 4. Send drive configuration
curl --unix-socket /tmp/fc-demo/my-api.sock -i \
 -X PUT 'http://localhost/drives/rootfs' \
 -H 'Accept: application/json' \
 -H 'Content-Type: application/json' \
 -d '{
 "drive_id": "rootfs",
 "path_on_host": "/path/to/rootfs.ext4",
 "is_root_device": true,
 "is_read_only": false
 }'
 
# 5. Start the instance
curl --unix-socket /tmp/fc-demo/my-api.sock -i \
 -X PUT 'http://localhost/actions' \
 -H 'Accept: application/json' \
 -H 'Content-Type: application/json' \
 -d '{ "action_type": "InstanceStart" }'

Conclusion and ZeroClaw Application Plan

As we’ve seen, MicroVMs offer strong isolation. In the ZeroClaw project’s “multi-agent architecture,” this technology is highly valuable. By executing each agent’s tasks (e.g., file system access, external network requests) within independent Firecracker instances, we can run “untrusted plugins” without compromising the overall system stability.

In the next post, we will discuss how to optimize communication between agents running on these MicroVMs.

References

Firecracker GitHub
[MicroVMs: Run isolated sandboxes with full lifecycle control](Hacker News Link)
[ZeroClaw Architecture Design Document](Internal Blog Link)

ZeroClaw Multi-Agent System: A Guide to Building a Local Testing Environment with Docker Compose

Fri, 22 May 2026 09:01:21 +0900

ZeroClaw Multi-Agent System: A Guide to Building a Local Testing Environment with Docker Compose

Recently, while designing the high-performance Rust agent runtime and multi-agent architecture for the [ZeroClaw] project, I realized the importance of isolation and communication stability for individual agents. In particular, when developing MCP (Model Context Protocol) clients that interact with external APIs, such as [blog-api-server], it is essential to test them in a local environment that mimics the actual production setup.

In this post, I will share how to build a testing environment using Docker Compose to easily run and debug complex multi-agent systems locally. This guide is based on a Linux environment (e.g., servers transitioning from Ubuntu 16.04 to FreeBSD), but it can be applied to Windows and macOS as well.

1. Architecture Design: Microservices-style Agent Structure

The core of ZeroClaw is a communication platform that adopts a file-based architecture and a gateway pattern. Each agent is treated as an independent microservice and isolated within a Docker container.

Components

Agent Container: Individual agents written in Rust (based on ZeroClaw Runtime)
Gateway Container: Nginx or Envoy for routing external requests to internal agents
Message Broker (Optional): RabbitMQ or Redis (if asynchronous communication is needed)

2. Dockerfile Creation: Optimizing Rust Agents

Since Rust applications have long compile times, Multi-stage builds should be used to reduce the final image size and optimize build caching.

# Dockerfile

# 1. Build Stage
FROM rust:1.75-slim as builder

WORKDIR /app

# Copy Cargo.toml and Cargo.lock first for dependency caching
COPY Cargo.toml Cargo.lock ./
RUN mkdir src && echo "fn main() {}" > src/main.rs
RUN cargo build --release && rm -rf src

# Copy actual source code and build
COPY src ./src
RUN touch src/main.rs && cargo build --release

# 2. Runtime Stage
FROM debian:bookworm-slim

# Install runtime dependencies (e.g., OpenSSL)
RUN apt-get update && apt-get install -y ca-certificates && rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Copy the built binary
COPY --from=builder /app/target/release/zero-claw-agent /app/agent

# Grant execute permissions
RUN chmod +x /app/agent

# Expose port (for MCP communication)
EXPOSE 8080

CMD ["/app/agent"]

3. Orchestration Configuration with Docker Compose

Use the docker-compose.yml file to define multiple agents and networks. This allows the entire system to be launched with a single docker-compose up command.

# docker-compose.yml
version: '3.8'

services:
 # Message Broker (Optional, used depending on the communication protocol)
 redis:
 image: redis:7-alpine
 container_name: zero-claw-redis
 ports:
 - "6379:6379"
 networks:
 - zero-claw-net

 # Agent 1: Blog Handler (acting as blog-api-server)
 blog-agent:
 build:
 context: ./services/blog-agent
 dockerfile: Dockerfile
 container_name: zero-claw-blog-agent
 environment:
 - AGENT_ID=blog-agent-01
 - LOG_LEVEL=debug
 - MCP_SERVER_URL=http://mock-api:3000
 depends_on:
 - redis
 networks:
 - zero-claw-net
 restart: unless-stopped

 # Agent 2: Monitor (Cloud Monitor role)
 monitor-agent:
 build:
 context: ./services/monitor-agent
 dockerfile: Dockerfile
 container_name: zero-claw-monitor-agent
 environment:
 - AGENT_ID=monitor-agent-01
 depends_on:
 - redis
 networks:
 - zero-claw-net
 restart: unless-stopped

 # Gateway (Discord MCP Gateway role)
 gateway:
 image: nginx:alpine
 container_name: zero-claw-gateway
 ports:
 - "8080:80"
 volumes:
 - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
 depends_on:
 - blog-agent
 - monitor-agent
 networks:
 - zero-claw-net

networks:
 zero-claw-net:
 driver: bridge

4. Running and Testing

You can now run the entire system with the following command:

# Build and run in background
docker-compose up --build -d

# Check logs (focused monitoring of a specific agent)
docker-compose logs -f blog-agent

# Traffic test (request via Gateway)
curl -X POST http://localhost:8080/api/v1/agent/blog/ping \
 -H "Content-Type: application/json" \
 -d '{"message": "Hello from ZeroClaw"}'

5. Conclusion

Leveraging this structure makes tasks like modifying [ZeroClaw]’s multi-agent communication protocol or injecting [LLM] configurations per agent much easier to test. In particular, by simply modifying environment variables in docker-compose.yml, you can maintain a nearly identical setup for production deployment scripts and local testing environments, thus resolving the “It works on my machine” problem.

In the next post, we will cover how to visualize the logs collected in this environment using [Loki] or [Prometheus].

Building High-Precision Cost Monitoring for Multi-Agent Environments in [ZeroClaw]

Fri, 15 May 2026 09:01:24 +0900

Building High-Precision Cost Monitoring for Multi-Agent Environments in ZeroClaw

Hello. I am a developer running a tech blog.

When building high-performance multi-agent runtimes like the ZeroClaw project, one of the biggest headaches is ‘unexpected cloud costs.’ When agents calling LLMs run concurrently, it’s common to be surprised by the bill when it arrives.

Especially after seeing the news on Hacker News that Infracost was hiring a Senior Dev Advocate with the goal of “giving agents cloud cost awareness,” I was motivated to implement a feedback loop for cost optimization in my own system.

In this post, I will share the process of building a system within the Rust-based ZeroClaw architecture that tracks agent activities in real-time, calculates estimated costs, and informs users.

Problem Definition: Consumption of Invisible Resources

The existing monitoring dashboard for [blog-api-server] primarily focused on ‘status.’ Was the agent still alive? Was the API responding? However, it couldn’t answer questions like:

“What was the actual token cost for generating this team meeting minutes?”
“How much resource are the 5 sub-agents currently running consuming per hour?”

Simply logging was not enough. We needed to manage costs as ‘code’ and make agents cost-aware themselves.

Solution Architecture

We decided to add a Cost Tracker module to ZeroClaw’s main loop and intercept token usage at each agent’s communication protocol layer.

Agent Layer: Each agent reports token usage every time it sends or receives messages.
Cost Estimator: Calculates real-time costs based on token counts and model pricing (Input/Output).
Reporter: Sends reports to Slack/Discord, etc., when a certain threshold is exceeded or a task is completed.

Implementing a Token Metric Collector in Rust

Since ZeroClaw is written in Rust, the cost calculation logic must also ensure type safety and high performance. First, let’s create a struct to define the pricing information for each model.

// src/cost/model.rs

use std::collections::HashMap;
use serde::{Deserialize, Serialize};

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct ModelPricing {
 pub input_price_per_1k: f64, // USD
 pub output_price_per_1k: f64, // USD
}

pub struct PricingRegistry {
 prices: HashMap<String, ModelPricing>,
}

impl PricingRegistry {
 pub fn new() -> Self {
 let mut prices = HashMap::new();
 // Example: GPT-4o pricing (as of 2024)
 prices.insert("gpt-4o".to_string(), ModelPricing {
 input_price_per_1k: 2.50,
 output_price_per_1k: 10.00,
 });
 // Example: Claude 3.5 Sonnet pricing
 prices.insert("claude-3-5-sonnet".to_string(), ModelPricing {
 input_price_per_1k: 3.00,
 output_price_per_1k: 15.00,
 });

 Self { prices }
 }

 pub fn get(&self, model: &str) -> Option<&ModelPricing> {
 self.prices.get(model)
 }
}

Now, let’s implement the logic to calculate costs based on the results after an agent actually calls the LLM API. This logic is called by the MCP (Model Context Protocol) bridge or internal communication wrappers.

// src/cost/calculator.rs

use super::model::PricingRegistry;

#[derive(Debug, Clone)]
pub struct UsageStats {
 pub model: String,
 pub input_tokens: u32,
 pub output_tokens: u32,
}

pub struct CostCalculator {
 registry: PricingRegistry,
}

impl CostCalculator {
 pub fn new(registry: PricingRegistry) -> Self {
 Self { registry }
 }

 pub fn calculate(&self, usage: &UsageStats) -> f64 {
 if let Some(pricing) = self.registry.get(&usage.model) {
 let input_cost = (usage.input_tokens as f64 / 1000.0) * pricing.input_price_per_1k;
 let output_cost = (usage.output_tokens as f64 / 1000.0) * pricing.output_price_per_1k;
 input_cost + output_cost
 } else {
 0.0
 }
 }
}

Integration with Agent Communication Protocols

ZeroClaw’s agents communicate via a file-based architecture or IPC. In this process, the message structure needs to be extended to also transfer ‘cost’ information.

Adding a cost field to the existing communication packet is the cleanest approach.

// src/agent/message.rs

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
pub struct AgentMessage {
 pub id: String,
 pub content: String,
 pub timestamp: i64,
 // Added cost field
 #[serde(skip_serializing_if = "Option::is_none")]
 pub cost_incurred: Option<f64>, 
}

impl AgentMessage {
 pub fn with_cost(mut self, cost: f64) -> Self {
 self.cost_incurred = Some(cost);
 self
 }
}

Now, when processing messages in the main agent loop, we can accumulate this cost to track the total session cost.

// src/agent/executor.rs

use crate::agent::message::AgentMessage;
use crate::cost::{CostCalculator, UsageStats};
use std::sync::Arc;
use tokio::sync::RwLock;

pub struct AgentRuntime {
 calculator: CostCalculator,
 total_cost: Arc<RwLock<f64>>,
}

impl AgentRuntime {
 pub async fn process_llm_request(&self, model: &str, prompt: &str) -> Result<String, String> {
 // 1. LLM API call (hypothetical function)
 let response = call_llm_api(model, prompt).await?;
 
 // 2. Extract usage metrics (parse from API response headers or body)
 let usage = UsageStats {
 model: model.to_string(),
 input_tokens: response.usage.input_tokens,
 output_tokens: response.usage.output_tokens,
 };

 // 3. Calculate cost
 let cost = self.calculator.calculate(&usage);
 
 // 4. Update total cost
 let mut total = self.total_cost.write().await;
 *total += cost;
 drop(total);

 // 5. Log output (can be sent to monitoring dashboard)
 println!("[Cost Monitor] Model: {}, Input: {}, Output: {} | Cost: ${:.6}", 
 model, usage.input_tokens, usage.output_tokens, cost);

 Ok(response.text)
 }
}

Practical Application and Effects

After applying this system, we were able to see the cost incurred in real-time for decision-making within the [Discord Decision MCP] architecture.

Case 1: For long document summarization tasks, we switched the model from GPT-4o to Claude 3.5 Haiku, reducing costs by approximately 70%.
Case 2: We detected a rapid increase in costs when a specific agent entered an infinite loop and implemented a safety mechanism that automatically activated a kill_switch.

Conclusion

Just as Infracost inspects infrastructure code, cost awareness at the agent runtime level is essential. By integrating a cost optimization layer directly into the ZeroClaw platform using Rust’s safe type system and concise code, we have enabled the operation of a more efficient multi-agent system.

In the next post, we will cover building a dashboard for visualizing the collected cost data (Grafana + Prometheus).

Thank you.

Reference Links:

Boosting Server Management Efficiency: Introducing Server Status Checker Skill

Mon, 09 Mar 2026 00:30:00 +0900

Boosting Server Management Efficiency: Introducing Server Status Checker Skill

Are you managing an increasing number of servers?

Individually connecting via SSH to check the status of each server is a waste of time. If you could grasp the CPU, memory, and disk usage of all servers at a glance, your work efficiency would improve significantly.

I faced this problem too, so I built a solution.

The Problem: Repetitive Server Monitoring Tasks

If you’re a DevOps engineer or system administrator, you’ve likely faced this situation:

Repeated SSH connections to each server
Manually running commands like top, htop, df
Manually recording status in Excel or Notion
Modifying management scripts as servers increase

This process wastes time and is repetitive work that can lead to mistakes.

The Solution: Server Status Checker Skill

Server Status Checker is a skill for Claude Code that checks the status of all servers in parallel based on your SSH config file.

Key Features

Feature	Description
Automatic SSH Config Parsing	Automatically discovers server list from `~/.ssh/config`
Real-time Status Check	Collects CPU, Memory, Disk, Uptime, Load information
Parallel Connections	Fast status checking with asyncssh (in seconds)
Group Classification	Automatically categorizes by GCP, OCI, GitHub, Blog, Local, etc.
Online/Offline Status	Intuitive status display with ✓ / ✗

Usage

# Check all server status
/server-status-checker

# Check specific server only
/server-status-checker --server mini01

# Output in JSON format
/server-status-checker --json

# Verbose error messages
/server-status-checker --verbose

Output Example

=== Server Status Report ===

[GCP Servers]
✗ gcp-ajou-ec1 - Offline (Authentication failed)
✗ gcp-fcoinfup-ec1 - Offline (Authentication failed)

[OCI Ajou]
✓ oci-ajou-ec1 - Online
 CPU: 15.2% | Memory: 62.3% | Disk: 45.8%
 Uptime: 15 days | Load: 1.23 1.45 1.38
 OS: Ubuntu 22.04 LTS

[Local Servers]
✓ mini01 - Online
 CPU: 6.7% | Memory: 45.2% | Disk: 5.0%
 Uptime: 2 days | Load: 2.17 2.11 1.94
 OS: macOS 26.3.1

Technical Details

SSH Config Parsing

Parses ~/.ssh/config file to automatically extract:

Host (hostname)
HostName (IP address or domain)
User (username)
Port (port number)
IdentityFile (SSH key path)

Asynchronous Parallel Processing

Uses Python’s asyncssh library to connect to all servers simultaneously:

async def check_server(host: str):
 # SSH connection and command execution
 result = await asyncssh.connect(...)
 return status

Checking 30 servers sequentially takes 5 minutes, but parallel processing completes in under 30 seconds.

Automatic Group Classification

Automatically classifies based on server name patterns:

Group	Pattern	Examples
GCP	`gcp-` prefix	gcp-ajou-ec1, gcp-fcoinfup-ec1
OCI Ajou	`oci-ajou-` prefix	oci-ajou-ec1
OCI Fcoinfup	`oci-fcoinfup-` prefix	oci-fcoinfup-ec1
GitHub	`github-as-` prefix	github-as-actions
Blog	`blog`	blog
Local	`mini`, `mac`	mini01, macbook-pro

System Metrics Collection

Collects the following information from each server:

Linux:

CPU: /proc/stat or psutil.cpu_percent()
Memory: /proc/meminfo or psutil.virtual_memory()
Disk: psutil.disk_usage()
Uptime: /proc/uptime or psutil.boot_time()
Load: /proc/loadavg or os.getloadavg()

macOS:

CPU: psutil.cpu_percent()
Memory: psutil.virtual_memory()
Disk: psutil.disk_usage()
Uptime: psutil.boot_time()
Load: os.getloadavg()

GitHub Release

This skill is released as open source.

🔗 GitHub: https://github.com/yarang/skill-server-status-checker

Installation

git clone https://github.com/yarang/skill-server-status-checker.git
cp -r skill-server-status-checker ~/.claude/skills/server-status-checker

Business Value

Aspect	Improvement
Time Savings	90% reduction in server check time (5 min → 30 sec)
Real-time Monitoring	Immediate server status awareness
Centralized Management	Manage all servers with single SSH config file
Automation	Minimize human errors by eliminating repetitive tasks

Use Cases

1. Daily Server Health Check

Every morning, check all server status with a single /server-status-checker command.

2. Incident Response

When an incident occurs, immediately identify offline servers and take action.

3. Capacity Planning

Monitor disk usage trends to plan capacity expansion in advance.

4. Performance Monitoring

Track CPU and memory usage to identify bottlenecks.

Conclusion

Server Status Checker is more than a simple server status checking tool. It’s a productivity tool that helps DevOps engineers and system administrators focus on core tasks by eliminating repetitive work.

By leveraging the standardized SSH config file and providing fast results through parallel processing, you no longer need to connect to each server individually. Check the health status of all servers with a single command.

Through AI and automation, let’s improve system management efficiency and focus on more important problems.

Related Projects:

domain-checker - Domain availability checker tool

Tags: #DevOps #ServerMonitoring #OpenSource #Claude #AI #Productivity #SSH

Korean Version: 한국어 버전

[ZeroClaw] 2026 H1 Roadmap Meeting

Sat, 28 Feb 2026 09:55:15 +0900

ZeroClaw 2026 H1 Roadmap Team Meeting Minutes

Meeting Date: 2026-02-28 Attendees: Architect, Security Lead, Product Owner, DevOps Lead Location: ZeroClaw Development Team Meeting Room Author: ZeroClaw Team

1. Meeting Overview

This meeting was held to discuss ZeroClaw’s 2026 first-half development direction and establish roadmaps and priorities for each area.

1.1 Agenda

Multi-agent architecture development direction
Security enhancement and compliance response
Product competitiveness enhancement and UX improvement
DevOps and infrastructure advancement
Comprehensive roadmap and priority agreement

2. Architecture Development Discussion

2.1 Architect Statement

“ZeroClaw has completed Phase 1 (in-process delegation) and is currently implementing Phase 2 (file-based multi-agent). The following technical goals need to be achieved in the first half of 2026.”

2.1.1 Multi-Agent Orchestration Advancement

Proposals:

Implement DAG-based workflow execution engine
Support sequential/parallel/conditional/loop execution patterns
Improve agent task distribution algorithm

Priority: High (P1)

// Proposed workflow structure
pub struct Workflow {
 pub id: String,
 pub nodes: Vec<WorkflowNode>,
 pub edges: Vec<WorkflowEdge>,
 pub start_node: String,
 pub end_nodes: Vec<String>,
 pub error_handling: ErrorHandlingPolicy,
}

2.1.2 IPC Communication Protocol Improvement

Proposals:

Transition from stdout-based communication to structured IPC
Support multiple transport layers: Unix Socket, gRPC, WebSocket
Optimize message serialization (JSON → MessagePack/CBOR)

Priority: Medium (P2)

2.1.3 Extensibility and Modularization

Proposals:

Consider plugin architecture introduction
Implement Wasm execution mode (enhanced sandboxing)
Provide external agent registration API

Priority: Low (P3)

2.1.4 Performance Optimization

Proposals:

Zero-copy message passing
Connection pooling and caching strategies
Async I/O optimization

Priority: Medium (P2)

2.2 Discussion

Security Lead:

“Security channels must be applied first when improving IPC protocol. Encryption and authentication for inter-agent communication are needed.”

Product Owner:

“From a user perspective, agent definitions should be more intuitive. Let’s also consider simplifying the YAML schema.”

DevOps Lead:

“Performance optimization work should proceed in parallel with observability improvement. Metrics collection must be secured first to measure optimization effects.”

3. Security Development Discussion

3.1 Security Lead Statement

“ZeroClaw already has a strong security foundation, but there are areas that need improvement from an OWASP Top 10 perspective. Sandbox isolation and audit logging enhancement are particularly urgent.”

3.1.1 Sandbox Enhancement

Current Issues:

Docker sandbox: --read-only, --cap-drop, seccomp not applied
Firejail: Network isolation not applied (--net=none missing)

Proposals:

// Docker hardened profile
docker_cmd.args([
 "run", "--rm",
 "--read-only",
 "--security-opt", "no-new-privileges",
 "--cap-drop", "ALL",
 "--network", "none",
 "--memory", "256m",
 "--pids-limit", "64",
]);

Priority: High (P1)

3.1.2 Audit Logging Enhancement

Proposals:

Introduce Log Signing to prevent tampering
Real-time security alert webhook integration
Prometheus metrics exposure

Priority: Medium (P2)

3.1.3 SSRF Defense

Proposals:

Enforce HTTPS for external requests
Block private IP ranges
Strengthen domain allowlist validation

Priority: Medium (P2)

3.1.4 TOCTOU Vulnerability Fix

Proposals:

Perform path validation and normalization atomically
Prevent symbolic link race conditions

Priority: High (P1)

3.2 Discussion

Architect:

“Sandbox enhancement can provide stronger isolation when linked with Wasm execution mode.”

DevOps Lead:

“Prometheus metrics can greatly improve operational visibility when integrated with Grafana dashboards.”

Product Owner:

“Ensure that security enhancements don’t degrade user experience. Defaults should be secure while advanced users can configure flexibly.”

4. Product Development Discussion

4.1 Product Owner Statement

“ZeroClaw’s core values are ‘high performance’, ’extensibility’, and ‘security’. In the first half of 2026, we need to strengthen these while improving user experience.”

4.1.1 User Experience Improvement

CLI Improvements:

Improve zeroclaw agent list output (table format)
Interactive agent execution mode
Progress visualization

Configuration Simplification:

Simplify agent definition YAML schema
Provide sensible defaults
Improve configuration validation and error messages

Priority: High (P1)

4.1.2 Documentation and Onboarding Enhancement

Proposals:

Improve Quickstart guide
Auto-generate API reference documentation
Expand example scenarios
Multi-language documentation (Korean, Japanese, Chinese)

Priority: Medium (P2)

4.1.3 Community Growth Strategy

Proposals:

Improve CONTRIBUTING.md
Label good first issues
Publish regular release notes
Discord/Slack community channels

Priority: Medium (P2)

4.1.4 Differentiation Points Enhancement

Proposals:

Strengthen hardware peripheral support (STM32, RPi)
Specialized domain agent templates
Publish performance benchmarks

Priority: Low (P3)

4.2 Discussion

Architect:

“CLI improvement is important from an ergonomics perspective. Let’s also consider upgrading from structopt to clap 4.x.”

Security Lead:

“When writing multi-language documentation, accurate translation of security-related content is important. I recommend creating a terminology glossary first.”

DevOps Lead:

“For community channels, starting with GitHub Discussions is a good approach. It can be started without separate infrastructure.”

5. DevOps Development Discussion

5.1 DevOps Lead Statement

“We need to advance CI/CD pipelines and monitoring systems for stable deployment and operation.”

5.1.1 CI/CD Pipeline Advancement

Current Status:

GitHub Actions-based CI
Automated cargo fmt, clippy, test
Docker build

Proposals:

Integrate cargo audit (vulnerability scanning)
Cross-platform build (Linux, macOS, Windows)
Release automation (cargo-release)
Pre-deployment smoke tests

Priority: High (P1)

# Proposed CI workflow
- name: Security audit
 run: cargo audit

- name: Cross-platform build
 strategy:
 matrix:
 os: [ubuntu-latest, macos-latest, windows-latest]
 runs-on: ${{ matrix.os }}

5.1.2 Monitoring and Observability

Proposals:

Prometheus metrics endpoint
Grafana dashboard templates
Distributed tracing (OpenTelemetry)
Log aggregation (ELK/Loki)

Priority: Medium (P2)

5.1.3 Deployment Automation and Rollback

Proposals:

Blue-Green deployment support
Automatic rollback threshold settings
Canary release options

Priority: Medium (P2)

5.1.4 Development Environment Improvement

Proposals:

devcontainer configuration
Automatic git hooks setup
Development configuration profiles

Priority: Low (P3)

5.2 Discussion

Architect:

“OpenTelemetry integration is essential for multi-agent tracing. Inter-agent call chains must be visualizable.”

Security Lead:

“cargo audit must be included in CI. It’s also good to add dependency license checks.”

Product Owner:

“devcontainer will be very helpful for new contributor onboarding. We can raise its priority.”

6. Comprehensive Roadmap and Priorities

6.1 2026 First Half Roadmap

Q1 (March-April)

Item	Owner	Priority
Docker/Firejail sandbox enhancement	Security	P1
TOCTOU vulnerability fix	Security	P1
CI/CD security scan integration	DevOps	P1
CLI improvement and UX enhancement	Product	P1
DAG-based workflow engine	Architect	P1

Q2 (May-June)

Item	Owner	Priority
IPC communication protocol improvement	Architect	P2
Audit logging enhancement	Security	P2
SSRF defense implementation	Security	P2
Prometheus metrics exposure	DevOps	P2
Documentation and onboarding improvement	Product	P2
Community infrastructure building	Product	P2

6.2 Agreed Principles

Security First: All new features must go through security review
Gradual Deployment: Large changes are rolled out in stages
Rollback Capable: All changes must be easily rollbackable
Documentation Sync: Documentation updates required when features change
Test Coverage: Tests required for new code

6.3 Risks and Responses

Risk	Probability	Impact	Response
Sandbox compatibility issues	Medium	High	Implement fallback mechanism
Performance regression	Low	Medium	Automate benchmarks
Dependency vulnerabilities	Medium	High	Automate cargo audit
Poor documentation	High	Medium	Require documentation PRs

7. Conclusion and Next Steps

7.1 Meeting Conclusions

Architecture: Prioritize multi-agent orchestration advancement
Security: Immediately start sandbox enhancement and TOCTOU fix
Product: Improve user experience through CLI UX improvement
DevOps: Build CI/CD security enhancement and monitoring foundation

7.2 Action Items

#	Item	Owner	Due Date
1	Apply Docker sandbox security profile	Security Lead	2026-03-07
2	Fix TOCTOU path validation	Security Lead	2026-03-10
3	Integrate CI cargo audit	DevOps Lead	2026-03-05
4	Improve CLI agent list	Product Owner	2026-03-12
5	Workflow engine design document	Architect	2026-03-15

7.3 Next Meeting Schedule

Date: 2026-03-14 10:00
Agenda: Q1 progress review and Q2 detailed planning

Appendix: Reference Documents

docs/project/multi-agent-architecture-design.md - Multi-agent architecture design
docs/project/multi-agent-communication-protocols.md - Communication protocol design
docs/security/security-improvements.md - Security improvement report
CLAUDE.md - Engineering protocol

Meeting Minutes Date: 2026-02-28 Approved By: ZeroClaw Team Lead Distribution: ZeroClaw Development Team

Korean Version: 한국어 버전

[Hugo Blog] OCI + GitHub Actions Deployment

Sat, 21 Feb 2026 00:00:00 +0900

Overview

This blog is built using the Hugo static site generator and automatically deployed to an Oracle Cloud Infrastructure (OCI) Free Tier server via GitHub Actions.

Architecture

Write Markdown locally
 ↓
GitHub Push (main branch)
 ↓
GitHub Actions (Hugo build)
 ↓
SSH + rsync deployment
 ↓
OCI Server (Nginx)
 ↓
https://blog.fcoinfup.com

Tech Stack

Component	Technology
Static Site Generator	Hugo
Theme	PaperMod
CI/CD	GitHub Actions
Server	OCI Free Tier (ARM)
Web Server	Nginx
Deployment Method	SSH + rsync

Configuration Management

The project centrally manages settings through the .blogrc.yaml file.

server:
 host: oci-yarang-ec1.fcoinfup.com
 user: ubuntu
 deploy_path: /var/www/blog

blog:
 url: https://blog.fcoinfup.com
 title: "Yarang's Tech Lair"
 author: yarang

GitHub Secrets synchronization is automated through the scripts/sync-secrets.sh script.

Deployment Pipeline

The GitHub Actions workflow executes in the following steps:

Checkout: Clone repository (including submodules)
Hugo Setup: Install Hugo extended version
Build: Run hugo --minify
Deploy: Transfer to OCI server via rsync

# .github/workflows/deploy.yml
- name: Deploy to OCI server
 run: |
 rsync -avz --delete \
 -e "ssh -i ~/.ssh/deploy_key" \
 public/ \
 ${{ secrets.OCI_USER }}@${{ secrets.OCI_HOST }}:${{ secrets.OCI_DEPLOY_PATH }}

Post Writing Workflow

# Create new post
hugo new content/posts/my-new-post.md

# Local preview
hugo server -D

# Commit and push (auto deploy)
git add .
git commit -m "Add new post"
git push

Security Considerations

SSH keys use ED25519 algorithm
Private keys are securely stored in GitHub Secrets
Nginx security header configuration (X-Frame-Options, X-Content-Type-Options, etc.)

References

Korean Version: 한국어 버전