This is Part 1 of a series exploring vector databases on AWS.

We recently evaluated multiple AWS vector database options to understand their trade-offs, performance characteristics, and real-world use cases. Before comparing services, it’s important to understand the core concepts that power vector search.

In this part, we’ll cover embeddings, dimensions, and similarity search — the foundation of every RAG and semantic search system.

What Are Embeddings?

Let’s say you’re building a customer support chatbot.

A user asks: “How do I change my login info?”
Your FAQ has: “Resetting your password.”

A keyword search might miss this. But as humans, we know they mean the same thing. That’s the gap embeddings solve.

An embedding is a numerical representation of content (text, image, code) where similar meaning leads to similar numbers. So even if the words differ, the intent stays close.

How Embeddings Are Created

Here’s what happens under the hood when you pass a sentence to an embedding model:

"How do I reset my password?"
        │
        ▼
   Tokenization         →  ["How", "do", "I", "reset", "my", "password", "?"]
        │
        ▼
   Embedding Model       →  Neural network (e.g., Titan v2)
        │
        ▼
   Vector Output         →  [0.021, -0.438, 0.712, ..., 0.155]   (1,536 floats)

The important part isn’t the numbers themselves—it’s that similar sentences produce vectors that are close to each other.

On AWS, you can generate embeddings using models like:

• Titan Text Embeddings V2
• Titan Embeddings G1 – Text
• Embed 3
• Embed Multilingual v3

If you’re getting started, Amazon Titan Embeddings V2 is a solid default—simple, cost-effective, and good enough for most use cases.

Note: The model you use for ingestion (storing data) must be the exact same model you use for inference (querying). If you embed your database using Amazon Titan but try to query it using an OpenAI embedding, the math won’t align, and your search results will be complete gibberish.

Dimensions

So far, we’ve seen that embeddings are just lists of numbers representing meaning. The next question is: how many numbers are in that list? That’s where dimensions come in.

A dimension is simply the number of values in an embedding list (vector).

For example:
[0.12, -0.45, 0.78, …, 0.33] → 1,536 values, a vector with 1,536 values has 1,536 dimensions

Different models produce different dimensions:

• Cohere Embed v3 → 1,024
• Amazon Titan Embeddings → 1,024 (default), 512, 256

Note: Historically, more dimensions meant better accuracy but higher storage costs and slower searches. However, the game changed with Amazon Titan Text Embeddings V2.Titan v2 supports “flexible” dimensions. You can generate a 1024-dimension vector and “truncate” it down to 512 or 256.

• 1024 Dimensions: Maximum “nuance” and accuracy.
• 256 Dimensions: Up to 4x less storage cost and faster search speeds, with only a marginal hit to accuracy.

Distance Metrics: Measure Similarity

Once you have thousands of embeddings stored, the database uses a distance metric to find the “nearest neighbors” to your query.

Why Metrics Matter: The “Wordiness” Problem

Let’s compare two vectors representing the same topic:

• Vector A: [1, 2, 3] (A short, concise help article)
• Vector B: [10, 20, 30] (A very long, detailed whitepaper on the same topic)

Even though they cover the exact same intent, different metrics interpret them wildly differently:

• Cosine Similarity (The Compass): Sees that both arrows point at the exact same target in space. It gives them a perfect match score. This is why it’s the standard for RAG—you want your short question to match a long document.
• Euclidean Distance (The Ruler): Measures the physical distance between the “tips” of the arrows. Because Vector B is so much longer, the ruler sees them as miles apart and may treat them as unrelated.
• Inner Product (The Spotlight): It sees that both point the same way, but it gives Vector B a “higher” score because it is stronger/longer. This is perfect for recommendation engines where you want to highlight “heavy-hitting” content.

For example,

• Query A: “How do I reset my password?”
• Doc B: “A guide to password resets for new users.”

They mean the same thing, but Doc B is 1,000 words long.

• Cosine correctly identifies them as a match because it ignores the extra “fluff” and focuses on the intent.
• Euclidean might fail because the sheer volume of words in Doc B pushes its vector too far away from the short query.

Key Takeaway: For 95% of AWS text-based applications (Chatbots, Q&A, Knowledge Bases), use Cosine Similarity. It is the default in Aurora pgvector, OpenSearch, and S3 Vectors for a reason: it focuses on meaning over length.

👉 Continue reading: In Part 2, we’ll explore vector search patterns (KNN vs ANN), hybrid search, metadata filtering, and chunking — and how they impact real-world systems.

I recently spent hours debugging a particularly nasty issue in a codebase where I had cut corners to meet a tight deadline. What should have been a simple fix turned into a frustrating ordeal because the code was poorly structured and lacked proper documentation. I finally resolved the issue, but not before learning a hard lesson about the importance of writing maintainable code from the start.

In my haste, I had duplicated logic in multiple places, used vague variable names, and failed to add comments explaining complex sections. This made the codebase confusing and difficult for me to navigate when troubleshooting. I realized that taking a bit of extra time upfront to write clean, well-structured code pays dividends down the line in saved time and reduced frustration.

This is part of a series of posts about building b.roll, a terminal session recorder and search tool written in Rust. If you’re just joining, here are the previous posts:

1. Building a 12-Command CLI in 120 Lines with clap Derive Macros
2. Spawning a PTY in Rust: How broll Captures Your Terminal Without You Noticing

When broll records a terminal session, three things need to happen at the same time: keystrokes must flow into the shell, the shell’s output must appear on screen, and that output must be processed and stored in a database. Doing all three sequentially would mean dropped keystrokes and laggy rendering. So broll uses three threads, coordinated through channels and atomics.

This post walks through the concurrency architecture of broll’s recorder, explaining each primitive: std::thread::spawn, mpsc channels, Arc, AtomicBool, AtomicU16, Ordering, move closures, and signal_hook for terminal resize handling. All code is from src/recorder/mod.rs.

The Three-Thread Architecture

Here is the layout:

                    +------------------+
 Real stdin ------> | Thread 1 (stdin) | ------> PTY master (writer)
                    +------------------+

                    +------------------+
 PTY master ------> | Main thread      | ------> Real stdout
   (reader)         | (PTY -> stdout)  | ------> mpsc channel (tx)
                    +------------------+

                    +------------------+
 mpsc channel ----> | Thread 2         | ------> SQLite (via Database)
   (rx)             | (storage)        |
                    +------------------+

Thread 1 (stdin) reads from the real terminal and writes to the PTY master, forwarding your keystrokes to the sub-shell.

Main thread reads from the PTY master and writes to the real terminal, displaying the shell’s output. It also sends a copy of every chunk through an mpsc channel.

Thread 2 (storage) receives data from the channel, parses OSC markers, renders output through a VT100 virtual terminal, and stores the result in SQLite.

Spawning Threads with move Closures

Rust’s std::thread::spawn takes a closure and runs it on a new OS thread. The catch: the closure must own everything it uses. Rust enforces this because threads can outlive the scope that created them, and borrowing data across thread boundaries would create data races.

The move keyword transfers ownership of captured variables into the closure. Here is the stdin thread:

let mut pty_writer = writer;
let _stdin_handle = std::thread::spawn(move || {
    let mut stdin = std::io::stdin();
    let mut buf = [0u8; 1024];
    loop {
        match stdin.read(&mut buf) {
            Ok(0) | Err(_) => break,
            Ok(n) => {
                if pty_writer.write_all(&buf[..n]).is_err() {
                    break;
                }
            }
        }
    }
});

Without move, the compiler would reject this code. The closure captures pty_writer, and Rust cannot guarantee the closure will not outlive the variable. With move, ownership of pty_writer transfers into the closure. The original scope can no longer access it, which eliminates any possibility of concurrent access.

The pattern Ok(0) | Err(_) => break handles both clean EOF and I/O errors in one arm. When stdin closes or the PTY writer breaks, the thread exits cleanly.

mpsc Channels: One Producer, One Consumer

The main thread and the storage thread communicate through an mpsc (multiple-producer, single-consumer) channel:

let (tx, rx) = mpsc::channel::<Vec<u8>>();

The main thread holds tx (the sender). The storage thread holds rx (the receiver). Each time the main thread reads a chunk from the PTY, it sends a copy through the channel:

// Main thread: PTY -> stdout + channel
match reader.read(&mut buf) {
    Ok(0) => break,
    Ok(n) => {
        let raw = &buf[..n];
        stdout.write_all(raw)?;
        stdout.flush()?;
        let _ = tx.send(raw.to_vec());
    }
    Err(_) => break,
}

The raw.to_vec() call creates an owned copy of the bytes. The main thread cannot send a reference because the buffer will be reused on the next read. The let _ = discards any send error, which only occurs if the receiver has been dropped (meaning the storage thread has exited).

On the receiving side, the storage thread uses recv_timeout instead of a blocking recv:

match rx.recv_timeout(INCOMPLETE_LINE_TIMEOUT) {
    Ok(data) => {
        // Process the data, parse markers, store chunks
    }
    Err(mpsc::RecvTimeoutError::Timeout) => {
        // Flush accumulated output that has not been terminated by a marker
    }
    Err(mpsc::RecvTimeoutError::Disconnected) => {
        // Channel closed, flush remaining data and exit
        break;
    }
}

The timeout (2 seconds) serves a practical purpose. Some commands produce output without a trailing newline or marker. Without a timeout, that partial output would sit in the buffer indefinitely. The timeout flushes it to the database so it does not get lost.

When the main thread finishes its loop, it drops tx:

drop(tx);

This causes the storage thread’s next recv_timeout to return Disconnected, triggering a clean shutdown. This is the graceful teardown pattern for channel-based architectures: dropping the sender signals the receiver.

Arc: Shared Ownership Across Threads

Some state needs to be read by multiple threads. Rust’s ownership model does not allow two threads to own the same value. Arc (Atomic Reference Counting) provides a solution: it wraps a value in a heap-allocated container with a thread-safe reference count. Cloning an Arc increments the count; dropping one decrements it. The inner value is freed when the count hits zero.

broll uses Arc for two things: the resize flag and the terminal column width.

let resize_flag = Arc::new(AtomicBool::new(false));
signal_hook::flag::register(signal_hook::consts::SIGWINCH, Arc::clone(&resize_flag))?;

let term_cols = Arc::new(AtomicU16::new(cols));
let term_cols_storage = Arc::clone(&term_cols);

Arc::clone does not clone the inner data. It creates a new pointer to the same allocation and increments the reference count. This is cheap: just an atomic increment.

Why Arc and Not Rc?

Rust has Rc (Reference Counting) for single-threaded shared ownership. It is slightly faster because it uses non-atomic operations. But Rc is not Send, meaning Rust will refuse to compile any code that tries to move an Rc to another thread. Arc uses atomic operations for its reference count, making it safe to share across threads. The compiler enforces this distinction at the type level.

Atomics: Lock-Free Shared State

Inside each Arc, broll uses atomic types rather than a Mutex. Atomics provide lock-free reads and writes for primitive values. No thread ever blocks waiting for another thread to release a lock.

AtomicBool for the Resize Flag

Terminal resize events arrive as SIGWINCH signals. The signal_hook crate registers a handler that sets an AtomicBool to true when the signal fires:

let resize_flag = Arc::new(AtomicBool::new(false));
signal_hook::flag::register(signal_hook::consts::SIGWINCH, Arc::clone(&resize_flag))?;

The main thread checks the flag on every loop iteration using swap:

if resize_flag.swap(false, Ordering::Relaxed)
    && let Ok((cols, rows)) = crossterm::terminal::size()
{
    term_cols.store(cols, Ordering::Relaxed);
    let _ = pair.master.resize(PtySize {
        rows,
        cols,
        pixel_width: 0,
        pixel_height: 0,
    });
}

swap(false, Ordering::Relaxed) atomically reads the current value and replaces it with false, returning the old value. If it was true, a resize happened. This pattern ensures that even if multiple SIGWINCH signals arrive between checks, the resize logic runs exactly once per check.

AtomicU16 for Terminal Width

The storage thread needs the current terminal width to render output correctly through its VT100 parser. The main thread updates this value on resize:

term_cols.store(cols, Ordering::Relaxed);

The storage thread reads it when rendering:

let rendered = render_vt(&cmd_output_bytes, term_cols_storage.load(Ordering::Relaxed));

What Does Ordering::Relaxed Mean?

Atomic operations take a memory ordering parameter that controls how they interact with surrounding memory operations. Ordering::Relaxed provides the weakest guarantee: the atomic operation itself is atomic, but it places no constraints on the ordering of other reads and writes.

For broll’s use case, this is sufficient. The resize flag is a simple boolean signal where a missed update just means the resize happens on the next loop iteration. The column width is a hint for rendering, where using a slightly stale value produces output that is one render cycle behind. Neither case requires the stronger guarantees of Ordering::SeqCst or Ordering::Acquire/Release.

Signal Handling with signal_hook

Unix signals are tricky in any language. Signal handlers run in an interrupt context with severe restrictions on what they can do. The signal_hook crate provides a safe interface: instead of running arbitrary code in the handler, it simply sets an atomic flag.

signal_hook::flag::register(signal_hook::consts::SIGWINCH, Arc::clone(&resize_flag))?;

This registers a handler for SIGWINCH (window size change) that atomically sets resize_flag to true. The main thread polls this flag in its event loop. This is safe because the signal handler only performs a single atomic store, which is async-signal-safe.

Shutdown Sequence

The cleanup order matters:

drop(tx);                         // 1. Close the channel
let _ = child.wait();             // 2. Wait for the shell to exit
drop(_raw_guard);                 // 3. Restore terminal mode
let _ = storage_handle.join();    // 4. Wait for storage to finish
db.end_session(&session_id)?;     // 5. Mark session as ended

Dropping tx signals the storage thread to flush and exit. The RawModeGuard is dropped before the final message so that eprintln! renders correctly. The storage thread is joined to ensure all data reaches SQLite before the session is marked as ended.

Note that the stdin thread is deliberately not joined. It blocks on stdin.read(), which cannot be interrupted on all platforms. Since the process is about to exit anyway, the OS will clean it up.

A Standalone Example

Here is a minimal program that demonstrates two threads sharing an Arc<AtomicBool>:

use std::sync::atomic::{AtomicBool, Ordering};
use std::sync::Arc;
use std::thread;
use std::time::Duration;

fn main() {
    let flag = Arc::new(AtomicBool::new(false));

    // Spawn a worker thread that checks the flag
    let worker_flag = Arc::clone(&flag);
    let handle = thread::spawn(move || {
        println!("Worker: waiting for signal...");
        loop {
            if worker_flag.load(Ordering::Relaxed) {
                println!("Worker: signal received, shutting down.");
                break;
            }
            thread::sleep(Duration::from_millis(100));
        }
    });

    // Main thread does some work, then signals the worker
    thread::sleep(Duration::from_secs(1));
    println!("Main: sending signal.");
    flag.store(true, Ordering::Relaxed);

    handle.join().unwrap();
    println!("Main: worker exited cleanly.");
}

This is the same pattern broll uses for SIGWINCH. Replace thread::sleep with a signal handler, and you have the real architecture.

Why Not async/await?

broll uses OS threads rather than async runtimes like Tokio. The reasons are practical:

1. Blocking I/O is unavoidable. stdin.read() and the PTY reader are blocking calls. An async runtime would need spawn_blocking for these, adding complexity without benefit.
2. Three threads is a fixed, small number. There is no need for the thousands-of-tasks scalability that async provides.
3. No additional dependencies. std::thread and std::sync are in the standard library. No runtime, no executor, no pinning.

When your concurrency model is “a few long-lived threads passing messages,” the standard library gives you everything you need.

Key Takeaways

1. move closures transfer ownership into threads. This is not optional: the compiler requires it to prevent data races.
2. mpsc channels provide typed, safe communication. Dropping the sender signals the receiver, enabling clean shutdown.
3. Arc enables shared ownership across threads. It is Rc with atomic reference counting, and the compiler enforces that you use the right one.
4. Atomics provide lock-free access to simple values. Ordering::Relaxed is often sufficient for flags and counters where eventual consistency is acceptable.
5. signal_hook makes Unix signals safe. Instead of running complex code in a signal handler, set a flag and check it in your event loop.
6. Explicit drop ordering controls shutdown. Channel close, child wait, guard drop, thread join: the sequence determines correctness.

broll’s entire concurrency model fits in one file, uses no external runtime, and relies on the compiler to verify thread safety at compile time. That is the Rust value proposition for systems programming: fearless concurrency is not a slogan, it is enforced by the type system.

Try it out:

• GitHub
• crates.io
• Documentation

The smart home security industry sells fear and subscriptions. After researching real burglary data, testing DIY systems, and talking to actual cops, here’s what really protects your home — and what’s just expensive theater.

The Dirty Secret: Professional Monitoring Is Mostly Theater

The average police response time to a residential burglar alarm is 7–15 minutes. In many cities, it’s longer. The average residential burglary takes 8–12 minutes (FBI UCR data, Eurostat crime surveys). Most burglars are in and out in under 10.

So what does professional monitoring buy you? A phone call. Someone at a call center sees an alert, tries calling you, waits for you to not answer, then calls the police. By the time a patrol car rolls up, the burglar is three neighborhoods away.

It gets worse. False alarm rates for residential security systems run between 94% and 98% (International Association of Chiefs of Police). Police departments have learned to deprioritize alarm calls. Many US cities now fine homeowners for repeated false alarms — $50 for the first, up to $500 for repeat offenders. Some departments have stopped responding to unverified alarms entirely.

You’re paying €30/month for the privilege of being deprioritized by emergency services.

What Burglars Actually Do

A University of North Carolina at Charlotte study surveyed 422 convicted burglars:

• 83% said they checked for an alarm system before breaking in
• But only 60% said alarms would deter them — they simply moved to the next house
• The top deterrent wasn’t alarms — it was signs of occupancy (lights on, car in driveway, TV sounds)

Entry points are boringly predictable:

• 34% enter through the front door (often unlocked)
• 23% through a first-floor window
• 22% through the back door

A third of burglaries happen through an unlocked door. No amount of smart sensors helps if you leave the front door open.

The critical insight the entire security industry buries: the appearance of presence is more effective than any sensor, camera, or monitoring service.

The DIY Security Stack That Actually Works

Layer 1: Physical Deterrence (~€250)

The unglamorous stuff security companies never mention because there’s no recurring revenue in it.

Reinforced door frames and strike plates — €60

Most doors are kicked in, not picked. Standard strike plates are held by two screws barely an inch long. Replace with 3mm steel reinforcement plates secured by 75mm screws reaching structural studs. This single upgrade makes forced entry dramatically louder, harder, and slower.

Security film on ground-floor windows — €120

Holds shattered glass together, turning a quick smash-and-reach into a prolonged, noisy wrestling match.

Exterior motion-activated lights — €70

Burglars hate light. A College of Policing (UK) study found improved lighting reduced crime by 21%.

Layer 2: Smart Detection (~€450)

Local-recording cameras (Reolink RLC-810A × 3) — €270

Record to a local NAS. No cloud. No subscription. No footage handed to police without consent.

Zigbee door/window sensors (Aqara × 8) — €80

Connected to Home Assistant. Instant notifications — no monitoring center middleman.

Zigbee motion sensors (Aqara FP2 × 2) — €100

mmWave presence sensors detect humans even standing still. Smart enough to differentiate between a cat and a person — eliminating the false alarm problem.

Layer 3: Smart Response (€0 — Just Automations)

This is where Home Assistant earns its reputation.

Automation 1: “The house is alive”

When the alarm triggers (any sensor while in “away” mode), simultaneously:

• All interior lights flash on/off twice, then stay on
• Living room TV turns on at high volume
• Smart speaker announces “SECURITY ALERT — RECORDING IN PROGRESS”
• All exterior lights go to maximum brightness

This creates the most effective deterrent: the appearance that someone is home and aware. Most burglars are already running.

Automation 2: “The evidence collector”

• All cameras switch to maximum resolution continuous recording
• 30-second video clips sent to phone via Telegram
• Snapshots emailed as redundant backup
• Critical phone alert with camera feeds

Actionable video in 5 seconds. Not a phone call asking for your verbal password.

Automation 3: “The neighbor alert”

If the alert isn’t dismissed within 60 seconds, Home Assistant messages two trusted neighbors to check the house.

Automation 4: “Vacation mode”

Randomized presence simulation:

• Lights in realistic patterns through the evening
• TV during typical viewing hours
• Blinds with ±15 minute daily offsets
• Porch light on sunset-triggered schedule

Dynamic simulation that changes daily — indistinguishable from actual occupancy.

The Real Cost Comparison

Professional Monitored System (10-year total)

Plus: cloud dependency, privacy concerns, false alarm fines, deprioritized police response.

DIY Setup (10-year total)

“But Who Calls the Police?”

Your phone does. Immediately. With video evidence.

“I have a live camera feed showing someone breaking into my house right now” gets a very different police response than a monitoring center calling with “We have an unverified alarm activation.”

In 2026, your phone is the monitoring center. Push notifications are instantaneous. Video is streamable from anywhere.

The Bottom Line

Physical deterrence and the appearance of occupancy stop burglaries. Smart detection and instant personal alerts handle the rest. Professional monitoring is an expensive middleman adding latency to a process that needs to be instant.

Your home doesn’t need a security company. It needs reinforced doors, visible cameras, smart automations, and you — with a phone full of instant alerts and live video.

The security industry won’t tell you this, because a one-time €800 customer is worth a lot less than a €360/year subscriber locked into a three-year contract.

Originally published at SmartHomeMade. For more no-BS smart home advice: camera recommendations at Best No-Subscription Security Cameras and hub comparisons at Home Assistant vs SmartThings vs Hubitat.

I almost didn’t go to my first tech event.

I kept thinking I wouldn’t fit in. Everyone there would know more than me. I wouldn’t know what to say or how to even start a conversation.

For a moment, I even thought of skipping it. But somehow, I still showed up.

After quitting my job, one thing I did was I started attending tech events. Once I started attending more events, it felt really good.

Every tech event comes with its own perks. Some are good, some are exceptionally well organized. Some provide practical knowledge about tools, while others give deep insights into tech.

What I Thought Tech Events Were

These are mostly community events, either paid or free, where you attend as a participant or a speaker. So far, I have only attended as an attendee. Maybe someday I will attend as a speaker.

What fascinates me the most is seeing speakers with immense knowledge explain complex things in simple ways while keeping the audience engaged.

Most companies organize these events to either share knowledge or promote their products through talks and demos.

I personally feel that smaller, more closed events are more interesting because you get more time to talk to speakers. In larger events, everyone wants to talk to them, so the interaction becomes limited.

Most of the events I attended were offline, which helped me meet new people and learn a lot more. I have also worked as a volunteer in a few events, so I have seen both sides.

Why I Still Decided to Go

1. What I Learned Just by Showing Up

I attend every event with one goal, to learn something new.

This mindset has made every event valuable for me. Every speaker comes with something to share, and picking even one useful idea makes the event worth it.

I always check the agenda beforehand and get excited about topics I want to learn. I keep my notes ready to capture ideas, project thoughts, or anything interesting.

One of the most memorable events for me was an OpenAI event. I got to see and hear Sam Altman. Many startups were built on top of ChatGPT, and founders were discussing real problems with the team.

That was the first time I heard terms like Context Window, RAG, Embeddings, Hallucinations, Model Weights, Temperature, Max Tokens, Vector Databases, and Context Length.

I was completely amazed. That same evening, I came back home and started exploring AI seriously.

2. Talking to People Was the Hardest Part

If you are a student, tech events can open many doors.

You meet people from different universities, exchange ideas, and sometimes even build things together. You can prepare together, practice interviews, or even work on projects that may turn into something bigger.

For working professionals, these events help in finding better opportunities, referrals, or even hiring.

For me, I have not deeply connected with many people yet, but I have had great conversations, learned a lot, and enjoyed interacting with others.

Since I was somewhere in between, having a degree but not working, I sometimes felt I did not fully belong to either side.

3. Learning by Doing Changed Everything

I always look forward to hands-on sessions more than talks.

Learning by doing and breaking things teaches more than just listening. I try to reach early whenever there is limited seating.

Through these sessions, I have learned things like re-ranking, built small MCP servers, explored AI Studio, and even got introduced to tools like Antigravity.

I also got to see demos of tools like Stitch before release, just by attending events.

4. The Unexpected Small Wins

My first event was special because I did not return empty handed. I got stickers and a pin, and it felt amazing.

Since then, every event gives something different. Some I use, some I keep. I have collected a lot of swags, though I don’t put stickers on my laptop, otherwise it would be completely filled.

And yes, almost every event had good food.

5. Seeing the Effort Behind the Scenes

Since I worked as a volunteer in some events, I got to see how things work behind the scenes.

Handling people, organizing sessions, managing chaos so that everything runs smoothly. Most volunteers were developers too, and everyone was helpful and humble.

It gave me a different perspective of how much effort goes into organizing a good event.

6. Why I Kept Going Back

Every event I attend leaves me with motivation. I always come back wanting to build something better, learn more, and improve.

These events give me the push to keep going.

I also have a goal now, someday I want to be on that stage and share my own experiences.

Many of the events I attended required shortlisting. Being unemployed made me feel like I might not get selected. But surprisingly, I got selected for many, and yes, I got rejected from some too.

It feels like luck sometimes, but being there and showing up made a difference.

7. What Changed in Me After Attending Events

I am an introvert. But I challenged myself to talk to people at events. Even when I felt less qualified, I still tried. Talking to people gave me confidence.

I started listening more, observing more, and slowly getting comfortable. I go to events with the intention to learn more and speak less.

I keep my expectations low and stay open to unexpected experiences. And many times, I ended up meeting amazing people who shared valuable insights.

Sometimes Just Showing Up Is Enough

Being at the right place at the right time matters.

I read the article from @maame-codes about getting an internship just by attending a tech event.

That is the kind of unexpected outcome these events can create.

If You Are Thinking About Going, Just Go

If you have never attended a tech event, try attending one. You might not get everything from the first event.

But you will definitely take something back.

Have you attended any tech events? How was your experience?

What’s on the site

Every solution page has:

• ✅ Clean, readable C# code with syntax highlighting
• 📝 The approach explained in plain English
• ⏱️ Time and space complexity
• 🔗 Direct link to the LeetCode problem

You can browse by topic (Dynamic Programming, Trees, Graphs, Sliding Window, Two Pointers, and 40+ more) or filter by difficulty (Easy / Medium / Hard).

Example — Two Sum

Here’s what a typical solution looks like:

// Approach: Use a dictionary to store each number's index.
// For each number, check if its complement (target - num) already exists.
// Time: O(n) Space: O(n)

public class Solution {
    public int[] TwoSum(int[] nums, int target) {
        var map = new Dictionary<int, int>();
        for (int i = 0; i < nums.Length; i++) {
            int complement = target - nums[i];
            if (map.ContainsKey(complement))
                return new int[] { map[complement], i };
            map[nums[i]] = i;
        }
        return Array.Empty<int>();
    }
}

Every solution follows this pattern — the comment at the top explains the core idea before you read any code.

Why C#?

C# is underused in competitive programming, but it’s a great choice:

• Strong typing catches bugs the compiler
• LINQ makes array/list operations expressive
• Dictionary<K,V> and HashSet<T> are fast and easy to use
• It’s what most .NET/backend engineers use day-to-day

If you’re preparing for interviews at Microsoft, Amazon, or any .NET shop, practicing in C# makes your prep directly transferable.

GeeksforGeeks too

I also solve the GFG Problem of the Day every day in Java. Those are at dsasolved.com/gfg — 530+ solutions and growing daily.

Tech behind the site

Built with Next.js 14 (App Router), fully statically generated — 1,380+ pages pre-rendered at build time. Uses Shiki for syntax highlighting. Deployed on Vercel.

The solutions themselves live in a GitHub repo: each .cs file is one problem. The site reads them at build time and generates the pages.

👋 Hey there, tech enthusiasts!

I’m Sarvar, a Cloud Architect with a passion for transforming complex technological challenges into elegant solutions. With extensive experience spanning Cloud Operations (AWS & Azure), Data Operations, Analytics, DevOps, and Generative AI, I’ve had the privilege of architecting solutions for global enterprises that drive real business impact. Through this article series, I’m excited to share practical insights, best practices, and hands-on experiences from my journey in the tech world. Whether you’re a seasoned professional or just starting out, I aim to break down complex concepts into digestible pieces that you can apply in your projects.

Let’s dive in and explore the fascinating world of cloud technology together! 🚀

New to Self-Hosted AI?

This article assumes basic familiarity with computers, software installation, and online services. If terms like “API,” “server,” or “open source” are new to you, don’t worry focus on the core concept: OpenClaw is an AI assistant that you run on your own computer or server, rather than relying on a company’s service like ChatGPT.

What This Article Covers: Understanding what OpenClaw is, why it matters, and whether it’s right for you.

What’s Coming Next: Hands-on setup, configuration, and deployment (no prior experience with self-hosting required we’ll walk through everything step-by-step).

Imagine having a personal assistant that lives on your infrastructure, responds through the messaging apps you already use, and executes tasks across your entire cloud environment. That’s OpenClaw. But unlike the AI assistants you’re familiar with ChatGPT, Claude, or GitHub Copilot this one doesn’t phone home to someone else’s servers. It runs on your machine, uses your API keys, and keeps your data exactly where you want it.

The story begins in November 2025 when Austrian developer Peter Steinberger built what he called a “weekend project.” He wanted an AI that could do more than chat one that could actually execute commands, manage files, read emails, and integrate with the tools he used daily. Within weeks, the project exploded. By March 2026, it had accumulated over 340,000 GitHub stars and attracted attention from Silicon Valley startups to Chinese tech giants. Steinberger eventually joined OpenAI and moved the project to an open-source foundation, but the core philosophy remained unchanged: your assistant, your machine, your rules.

For anyone interested in AI and privacy, OpenClaw represents something different. It’s not a SaaS product with usage limits and data residency questions. It’s software you install, configure, and control. You choose which AI provider to use Anthropic’s Claude, OpenAI’s GPT models, Google’s Gemini, or even self-hosted options like Ollama. You decide which messaging platforms to enable. You set the security boundaries. And when you need to see what happened, the logs are on your computer, not buried in someone else’s cloud.

What OpenClaw Actually Is

Architecture and Deployment Model

OpenClaw is a Node.js application that acts as a gateway between messaging platforms and large language models (LLMs AI systems like ChatGPT or Claude). You install it on a server your laptop, a homelab machine, or a cloud VM and it stays running as a daemon. The architecture is straightforward: a WebSocket-based control plane (a real-time communication hub) listens on port 18789, handling connections from messaging channels, the web dashboard, and optional companion apps for macOS, iOS, and Android.

The gateway doesn’t process AI requests itself. Instead, it routes conversations to your configured LLM provider via their APIs. When you send a message through WhatsApp or Slack, OpenClaw receives it, forwards the context to Claude or GPT, gets the response, and delivers it back through the same channel. All conversation history, configuration, and session state live in local SQLite databases under ~/.openclaw/.

Multi-Channel Integration

This is where OpenClaw diverges from traditional chatbots. Rather than forcing you into a web interface or proprietary app, it meets you where you already work:

• Messaging platforms: WhatsApp, Telegram, Discord, Slack, Microsoft Teams, Signal, Matrix
• Specialized channels: IRC, Google Chat, Mattermost, Twitch, WeChat (via Tencent plugin)
• Direct interfaces: Web dashboard, macOS menu bar app, iOS/Android companion apps
• Developer tools: CLI commands for scripting and automation

Each channel operates independently. You can have different security policies for Discord versus WhatsApp, route specific channels to isolated agent workspaces, or restrict certain tools based on where the request originated.

The Skills System

OpenClaw extends beyond conversation through a skills framework. Skills are self-contained modules think of them as plugins that give the AI new capabilities. A skill is just a directory containing a SKILL.md file with instructions and metadata. The AI reads these instructions and knows how to use the skill’s tools.

Skills can be:

• Bundled: Shipped with OpenClaw (browser automation, file operations, system commands)
• Managed: Installed from the ClawHub registry
• Workspace-specific: Custom skills you write for your environment

The precedence model matters for teams building workflows. Workspace skills override global skills, which override bundled skills. This means you can customize behavior per project without modifying the core installation.

Tool Execution and Sandboxing

When the AI decides it needs to run a command or access a file, OpenClaw’s tool system handles the execution. By default, tools run directly on the host for the main session. But for group chats or untrusted channels, you can enable sandbox mode. Sandboxed sessions run inside per-session Docker containers with restricted tool access.

The security model is explicit:

• Main session (your direct chats): Full tool access by default
• Group sessions: Configurable sandbox with allowlists and denylists
• Tool categories: bash, browser, read, write, edit, sessions, nodes, cron, discord, gateway

You define which tools each session type can use. A production deployment might allow read-only file access for group chats while reserving write operations for authenticated direct messages.

Why Self-Hosting Matters

Data Privacy and Control

When you deploy OpenClaw on your infrastructure, you control the data flow. Conversation logs, uploaded files, and execution history never leave your environment unless you explicitly configure external integrations. For organizations with strict data residency requirements healthcare, finance, government this matters. You’re not trusting a third party to handle PHI (Protected Health Information) or PII (Personally Identifiable Information). You’re running the infrastructure yourself.

The LLM API calls still go to external providers (unless you use self-hosted models), but you choose which provider and can route through your own network controls. Want to proxy all OpenAI requests through your corporate gateway? Configure the API endpoint. Need to log every prompt for compliance? Intercept at the gateway level.

Cost Control and Model Flexibility

SaaS AI assistants charge per seat or per usage tier. OpenClaw inverts this model. You pay your LLM provider directly based on token consumption. If Claude is too expensive for your use case, switch to GPT-4o-mini. If you want to experiment with open-source models, point it at Ollama running locally. The gateway doesn’t care which model you use it just routes requests.

This flexibility extends to failover and load balancing. Configure multiple API keys for the same provider, and OpenClaw rotates through them when rate limits hit. Set up model fallback chains: try Claude Opus first, fall back to GPT-4 if it’s overloaded, and use a local model as the last resort.

Example Cost Comparison:

• SaaS AI Assistant: $20-30/user/month (fixed cost, limited usage)
• OpenClaw + Claude API: Pay per token (1M input tokens ≈ $3-8 depending on model)
• OpenClaw + Local LLM: Infrastructure costs only (no per-token charges)

For teams running thousands of queries daily, the direct API model often costs less than per-seat licensing. For occasional users, SaaS might be cheaper. The key difference: you control the trade-off.

Infrastructure as Code Integration

Because OpenClaw is just a Node.js application with a JSON configuration file, it fits naturally into infrastructure-as-code (IaC) workflows managing infrastructure through code rather than manual configuration. The configuration lives at ~/.openclaw/openclaw.json and supports environment variable substitution for secrets. You can template it with Terraform, manage it with Ansible, or version it in Git.

Deployment patterns cloud architects already know apply directly:

• Systemd service: Install the daemon, enable it, manage it like any other service
• Docker container: Official images available, mount config as a volume
• Kubernetes: Deploy as a StatefulSet (a workload type for applications that need persistent storage) with persistent storage for the database
• Nix: Declarative configuration with the community Nix package

Security Boundaries and Threat Model

OpenClaw’s security model assumes you understand the risks of giving an AI broad system access. The maintainers are explicit about this. One core maintainer warned on Discord: “if you can’t understand how to run a command line, this is far too dangerous of a project for you to use safely.”

The threat surface includes:

• Prompt injection: Malicious instructions embedded in data the AI processes (emails, documents, web pages) that trick the AI into executing unintended commands
• Tool misuse: The AI executing destructive commands based on misinterpreted context
• Third-party skills: Unvetted skills from the community that could exfiltrate data
• Channel compromise: If someone gains access to an authorized messaging account, they control the AI

Cisco’s security research team demonstrated this in March 2026 when they found a third-party skill performing data exfiltration. The skill repository lacked adequate vetting, and users installing it unknowingly gave attackers access to their environment.

For production use, you need to:

• Run sandboxed sessions for any untrusted input source
• Audit third-party skills before installation
• Use DM pairing mode to require explicit approval for new contacts
• Monitor execution logs for unexpected tool usage
• Isolate the OpenClaw instance from sensitive systems

The MoltMatch Incident: A Cautionary Tale

In February 2026, computer science student Jack Luo configured his OpenClaw agent to explore its capabilities. He connected it to Moltbook a social network for AI agents and let it run autonomously. Days later, he discovered the agent had created a profile on MoltMatch, a dating platform where AI agents interact on behalf of users, and was screening potential matches without his explicit direction.

The incident highlighted a fundamental challenge with autonomous agents: when you give an AI broad permissions and vague instructions, it will interpret its mandate creatively. Luo’s agent saw “explore capabilities” and “connect to agent platforms” as permission to create dating profiles. The AI-generated profile didn’t reflect him authentically, and he had no idea it was happening until someone told him.

This matters for anyone managing systems because the same dynamic applies to automation. If you tell an AI to “optimize costs” without clear boundaries, it might decide to delete things it deems unnecessary. If you ask it to “improve security,” it could change settings in ways you didn’t anticipate. Autonomous agents require explicit constraints, not just general goals.

Real-World Adoption Patterns

Small Business and Freelancer Workflows

OpenClaw has found traction among small businesses and freelancers who need automation but can’t afford enterprise tools. Common workflows include:

• Lead generation: Scraping prospect lists, researching companies, updating CRM systems
• Content management: Drafting emails, summarizing documents, generating reports
• System administration: Monitoring servers, running diagnostics, deploying updates

These users value the flexibility to customize behavior without vendor lock-in. A freelance consultant can write a workspace skill that integrates with their specific CRM and invoicing tools, then share that skill with clients who use the same stack.

Enterprise Experimentation

Larger organizations are testing OpenClaw in controlled environments. The typical pattern: deploy it on a developer’s workstation or a sandbox VM, connect it to a private Slack channel, and use it for internal tooling. Teams report using it for:

• Documentation search: Indexing internal wikis and answering questions
• Incident response: Gathering logs, running diagnostics, summarizing findings
• Code review assistance: Analyzing pull requests, suggesting improvements

The key constraint is trust. Enterprises won’t give OpenClaw production access until they’ve validated its behavior in isolated environments. The security incidents and lack of formal audits make it a hard sell for risk-averse organizations.

What This Means for Your Setup

If you’re evaluating OpenClaw, think of it as software infrastructure, not a product. You’re not buying a service; you’re installing and maintaining a component that needs care and attention.

Key Questions to Consider:

Deployment:

• Where will it run? (Your laptop, a home server, a cloud VM)
• Who can access it? (Just you, your team, your organization)
• What can it access? (Read-only files, full system control, isolated sandbox)
• How will you monitor it? (Log files, activity tracking, alerts)
• What’s the risk if compromised? (Isolated test environment vs. access to important data)

Integration:

• Which AI provider will you use? (Cost, rate limits, data handling)
• Which messaging platforms? (Authentication, user verification)
• What internal systems? (APIs, databases, file storage)
• How will you monitor it? (Health checks, error tracking, usage metrics)

Maintenance:

• Who maintains the configuration? (You, your team, IT department)
• How do you handle updates? (Manual upgrades, automated deployment)
• What’s the support model? (Community forums, internal expertise)
• How do you manage secrets? (Environment variables, password managers)

The answers depend on your technical comfort level and risk tolerance. A tech-savvy individual might run it on their laptop for personal use. A small team might deploy it on a shared server with careful access controls. An enterprise might lock it down in an isolated environment. All are valid approaches based on your needs and skills.

The Bottom Line

OpenClaw is not a polished consumer product. It’s a powerful, flexible, occasionally dangerous tool that gives you control at the cost of responsibility. For people who understand the trade-offs, it offers something rare: an AI assistant that runs on your terms, integrates with your tools, and doesn’t require you to trust a company with your data.

The project is still young. The security model is evolving. The ecosystem is fragmented. But the core idea self-hosted, multi-channel, tool-capable AI agents addresses real needs that SaaS products don’t solve. Whether OpenClaw itself becomes the standard or just proves the concept for something better, the architecture it represents is worth understanding.

When to Consider OpenClaw:

• You care deeply about data privacy and control
• You want to avoid subscription fees for large-scale usage
• You need deep integration with your own tools and systems
• You have technical skills or are willing to learn
• You’re comfortable with ongoing maintenance

When to Avoid OpenClaw:

• You’re not comfortable with command-line tools
• You need something that works immediately without setup
• You can’t dedicate time to security and maintenance
• You prefer paying for convenience over having control
• Your use case doesn’t justify the complexity

If you decide to explore it, start small. Run it in an isolated environment, connect it to a test channel, give it limited permissions. Learn how it behaves, where it fails, and what it can actually do. Then decide if the benefits justify the operational overhead and security risks.

That’s the honest assessment. OpenClaw is powerful infrastructure for people who know what they’re doing. If that’s you, it’s worth exploring. If it’s not, wait for the ecosystem to mature.

Coming Next: In our next article, we’ll cover the technical implementation installation, configuration, and deployment with step-by-step examples. We’ll walk through setting up OpenClaw on different platforms and implementing security best practices.

What We’ll Cover in Upcoming Articles:

• Part 2: Installation & Setup – Step-by-step guide, prerequisites, system requirements, and getting your first instance running
• Part 3: Configuration Deep-Dive – API keys, messaging platform integration, security policies, and sandbox configuration
• Part 4: Deployment Options – Running on Windows/Mac/Linux, cloud servers, and home servers with monitoring and cost optimization
• Part 5: Security Best Practices – Threat mitigation, audit logging, access control, and incident response

Questions or Topics You’d Like Covered?

Drop a comment below with your questions about OpenClaw. Whether you’re wondering about specific use cases, integration challenges, cost comparisons, or anything else we’ll address them in upcoming articles. Common questions we’re already planning to cover:

• How much does it actually cost to run?
• Can I use it on Windows without WSL?
• What’s the learning curve for someone new to self-hosting?
• How does it compare to AutoGPT or LangChain agents?
• Can I run it on a Raspberry Pi or home server?

Resources:

• Official Website: https://openclaw.ai
• GitHub Repository: https://github.com/openclaw/openclaw

📌 Wrapping Up

Thank you for reading! I hope this article gave you practical insights and a clearer perspective on the topic.

Was this helpful?

• ❤️ Like if it added value
• 🦄 Unicorn if you’re applying it today
• 💾 Save for your next optimization session
• 🔄 Share with your team

Follow me for more on:

• AWS architecture patterns
• FinOps automation
• Multi-account strategies
• AI-driven DevOps

💡 What’s Next

More deep dives coming soon on cloud operations, GenAI, Agentic-AI, DevOps, and data workflows follow for weekly insights.

🌐 Portfolio & Work

You can explore my full body of work, certifications, architecture projects, and technical articles here:

👉 Visit My Website

🛠️ Services I Offer

If you’re looking for hands-on guidance or collaboration, I provide:

• Cloud Architecture Consulting (AWS / Azure)
• DevSecOps & Automation Design
• FinOps Optimization Reviews
• Technical Writing (Cloud, DevOps, GenAI)
• Product & Architecture Reviews
• Mentorship & 1:1 Technical Guidance

🤝 Let’s Connect

I’d love to hear your thoughts drop a comment or connect with me on LinkedIn.

For collaborations, consulting, or technical discussions, feel free to reach out directly at [email protected]

Happy Learning 🚀

🔍 Why I built this

While working on multiple projects, I noticed something frustrating:

Most robots.txt generators are either too basic
Or they require server-side processing / data submission
Or they clutter the UI with ads and upsells

For something as simple (yet critical) as robots.txt, I wanted:

👉 Fast
👉 Private
👉 Developer-friendly

So I built:

👉 https://robotstxtgenerator.io

⚡ What makes it different?

🧠 1. Runs fully in your browser
No API calls. No backend processing.

Your rules never leave your machine
Works even offline (PWA-ready direction)

🔒 2. Privacy-first by design
No login
No tracking of input
No data storage

🧩 3. Smart & flexible generation
Allow / Disallow rules
Sitemap integration
Crawl delay
Multiple user-agents

🧪 4. Built-in tester
Validate your robots.txt instantly before deploying.

🎯 5. Clean output (no junk)
You get production-ready output like:

User-agent: *
Disallow: /admin/
Allow: /

Sitemap: https://example.com/sitemap.xml

🛠 Tech stack
Vanilla JavaScript (no heavy frameworks)
Lightweight UI
Focused on performance + simplicity

💡 Lessons learned
Dev tools don’t need accounts
Simplicity > feature overload
Privacy can be a strong differentiator
SEO tools still have huge demand if done right

📈 What’s next?

I’m planning to add:

Better crawl simulation
More SEO-focused utilities
🙌 Feedback welcome

Would love your thoughts 🙏

What features would you want?
Anything confusing in the UI?
Any edge cases I should handle?

👉 Try it here: https://robotstxtgenerator.io

Send a Link, Get Paid: Building Payment Links with the Afriex API

What if you could accept payments globally with just a link?

No checkout flows. No heavy integrations. Just a URL.

What This Guide Covers

This guide is about the Afriex API.

You’ll learn how to build a simple payment link system that allows you to:

• Generate shareable payment links
• Accept payments via bank transfer or crypto
• Track payment status
• Handle real payment confirmations

You do not need any specific framework. Your backend just needs to make secure HTTPS requests.

Afriex vs Your Application

Afriex provides the payment infrastructure.

You build the product layer.

System Architecture

Client → Backend → Afriex API → Payment Rails

• Your backend stores payment requests
• Afriex handles payment execution
• Your frontend displays payment instructions

Prerequisites

Before starting, you need:

• An Afriex account
• Your API key
• A customerId (Afriex identifier for the recipient)

Every payment instruction you generate should be tied to a customerId.

Authentication

All Afriex API calls are made server-side.

GET {BASE_URL}/... HTTP/1.1
x-api-key: YOUR_AFRIEX_API_KEY
Content-Type: application/json

Example:

curl -sS -G "{BASE_URL}/api/v1/payment-method/virtual-account" 
  -H "x-api-key: YOUR_AFRIEX_API_KEY" 
  --data-urlencode "currency=NGN" 
  --data-urlencode "amount=5000" 
  --data-urlencode "customerId=PAYEE_CUSTOMER_ID"

Step 1: Create a Payment Link (Your Backend)

Afriex does not create “payment links” for you — you implement this.

Store:

• amount
• currency
• description
• expiry
• customerId
• unique token

import crypto from "crypto";

const linkId = crypto.randomBytes(16).toString("hex");

await db.payment.create({
  linkId,
  amount: 5000,
  currency: "NGN",
  customerId,
  expiresAt: new Date(Date.now() + 30 * 60 * 1000),
});

Then generate:

https://yourapp.com/pay/{linkId}

Step 2: Generate Payment Instructions

When a user opens the link:

1. Load the payment request
2. Call Afriex
3. Return instructions

🇳🇬 Virtual Account (Bank Transfer)

curl -sS -G "{BASE_URL}/api/v1/payment-method/virtual-account" 
  -H "x-api-key: YOUR_AFRIEX_API_KEY" 
  --data-urlencode "currency=NGN" 
  --data-urlencode "amount=5000" 
  --data-urlencode "customerId=PAYEE_CUSTOMER_ID"

Display:

• Account number
• Account name
• Bank name

Crypto Wallet (USDC / USDT)

curl -sS -G "{BASE_URL}/api/v1/payment-method/crypto-wallet" 
  -H "x-api-key: YOUR_AFRIEX_API_KEY" 
  --data-urlencode "asset=USDC" 
  --data-urlencode "customerId=PAYEE_CUSTOMER_ID"

Response:

{
  "data": [
    {
      "address": "0x...",
      "network": "ethereum"
    }
  ]
}

If USDC is unavailable, fallback to USDT.

Step 3: Choosing Payment Method

In your backend:

• If currency = NGN → virtual account
• If currency = USD → crypto wallet

This logic is controlled by your application, not Afriex.

Step 4: Confirm Payment (Production)

Do NOT rely on:

• Button clicks
• User confirmation

Use Afriex webhooks:

1. Receive event
2. Verify signature
3. Match to payment record
4. Mark as paid

Always handle this idempotently.

Security Checklist

• Keep API keys server-side only
• Use HTTPS
• Use unguessable link tokens
• Expire links
• Verify webhooks

Why This Pattern Matters

This is the same pattern used by:

• Stripe
• Paystack
• Flutterwave

Payment links are one of the fastest ways to start accepting payments globally.

Summary

To build payment links with Afriex:

1. Create a customer → get customerId
2. Store a payment request in your database
3. Generate a shareable link
4. Fetch payment instructions via Afriex
5. Confirm payments via webhooks

Next Steps

• Add webhook automation
• Support more currencies
• Build dashboards
• Add notifications

Final Note

Afriex gives you the rails.

You build the product.