DEV Community

Why We Built a Managed Platform for OpenClaw Agents (And What We Learned)

Tijo Gaucher — Mon, 13 Apr 2026 02:41:43 +0000

We spent six months wrestling with deploying AI agents before we decided to just build the thing ourselves. This is that story — the ugly parts included.

The Problem Nobody Talks About

Everyone's building AI agents right now. The demos look incredible. You wire up some tools, connect an LLM, and suddenly you've got an agent that can research, plan, and execute tasks autonomously.

Then you try to put it in production.

Suddenly you're dealing with container orchestration, secret management, scaling workers up and down, monitoring token spend, handling failures gracefully, and figuring out why your agent decided to retry the same API call 47 times at 3am.

We were building on OpenClaw — an open-source agent framework that we really liked because it didn't try to do too much. It gave you the primitives and got out of the way. But "getting out of the way" also meant we were on our own for everything else.

What Running Agents in Production Actually Looks Like

Here's a simplified version of what our deploy pipeline looked like before RapidClaw existed:

# Our old "deploy an agent" workflow (simplified, but not by much)
steps:
  - name: Build agent container
    run: docker build -t agent-${{ agent.name }} .

  - name: Push to registry
    run: docker push $REGISTRY/agent-${{ agent.name }}

  - name: Update k8s deployment
    run: |
      kubectl set image deployment/$AGENT_NAME \
        agent=$REGISTRY/agent-${{ agent.name }}:$SHA

  - name: Configure secrets
    run: |
      kubectl create secret generic agent-secrets \
        --from-literal=OPENAI_KEY=${{ secrets.OPENAI }} \
        --from-literal=ANTHROPIC_KEY=${{ secrets.ANTHROPIC }} \
        # ... 12 more provider keys

  - name: Set up monitoring
    run: |
      # Prometheus config, Grafana dashboards, 
      # alerting rules, log aggregation...
      # This alone was 200+ lines of YAML

That's the happy path. We're not even talking about rollback strategies, canary deployments, or what happens when your agent starts hallucinating and burning through your API budget at 2x the normal rate.

We had an incident early on where an agent got stuck in a loop generating images. By the time we noticed, it had burned through about $400 in API calls in under an hour. That was our wake-up call.

Why OpenClaw

We evaluated a bunch of agent frameworks. Most of them wanted to own your entire stack — your prompts, your tool definitions, your execution model, everything.

OpenClaw was different. It's more like a protocol than a framework. You define your agent's capabilities, wire up your tools, and it handles the execution loop. But it's deliberately minimal about infrastructure opinions.

That minimalism is what attracted us, and also what made us realize there was a gap. OpenClaw gives you a great way to build agents. It doesn't give you a great way to run them.

What RapidClaw Does Differently

RapidClaw is basically the managed infrastructure layer that sits underneath your OpenClaw agents. Think of it as the platform that handles all the boring-but-critical stuff:

Deploy flow (what it looks like now):

┌─────────────┐     ┌──────────────┐     ┌─────────────────┐
│  Your Agent  │────▶│  RapidClaw   │────▶│   Production    │
│  (OpenClaw)  │     │   Platform   │     │   Environment   │
└─────────────┘     └──────────────┘     └─────────────────┘
       │                    │                      │
       │              ┌─────┴─────┐          ┌─────┴─────┐
       │              │ Secrets   │          │ Auto-scale │
       │              │ Mgmt      │          │ Monitor    │
       │              │ Isolation  │          │ Cost caps  │
       │              │ Versioning │          │ Rollback   │
       │              └───────────┘          └───────────┘
       │
  rapidclaw deploy my-agent --env production
  # That's it. One command.

The whole point is that you focus on your agent logic — what tools it has, how it reasons, what it's good at — and we handle the infrastructure. Secrets get injected securely, scaling happens automatically, and if your agent starts going off the rails, cost caps kick in before your cloud bill becomes a horror story.

You can dig into the security model if you want the details on how we handle isolation and secret management. It was one of the hardest parts to get right.

What We Learned (The Honest Version)

1. Agents fail in weird ways.

Traditional software fails predictably. API returns 500, you handle it. Database times out, you retry. Agents fail creatively. They'll find edge cases in your tools you never imagined. They'll interpret instructions in ways that are technically correct but completely wrong. Building good guardrails is less about error handling and more about understanding the problem space deeply enough to anticipate creative failures.

2. Cost management is a first-class concern.

This isn't like running a web server where your costs are roughly proportional to traffic. Agent costs can spike 10x in minutes if the agent decides it needs to "think harder" about something. We built per-agent budgets, per-session caps, and anomaly detection into the platform from day one. Should have done it from day negative-one.

3. Observability for agents is fundamentally different.

You can't just look at request/response logs. You need to see the agent's reasoning chain, understand why it chose one tool over another, and track how its behavior drifts over time. We built a trace viewer that shows the full execution tree — every tool call, every LLM interaction, every decision point. It's the feature our users care about most, and it was an afterthought in our original design. Embarrassing.

4. The open-source community taught us more than we expected.

We initially built RapidClaw as a purely internal tool. OpenClaw contributors kept asking us how we were running agents in production, and their questions shaped about 60% of our roadmap. Turns out the problems we were solving weren't unique to us — they were universal. That community feedback loop was the single most valuable thing in our development process.

5. You will underestimate state management.

Agents that run for minutes or hours need persistent state. They need checkpointing. They need the ability to resume after failures. And they need all of that without you having to think about it as an agent developer. Getting this right took us three complete rewrites. Three. We're still not 100% happy with it.

Where We Are Now

RapidClaw is running in production for a handful of teams. It's not perfect — our documentation needs work, our onboarding could be smoother, and there are definitely edge cases we haven't hit yet.

But the core loop works: write your OpenClaw agent, push it to RapidClaw, and it runs reliably in production with monitoring, scaling, and cost management built in. No more 200-line YAML files. No more 3am incidents because an agent went rogue.

If you're running OpenClaw agents (or thinking about it), I'd genuinely love to hear how you're handling the infrastructure side. We're at rapidclaw.dev/try if you want to kick the tires.

What's the gnarliest production issue you've hit with AI agents? I'll bet we've either seen it too or it'll end up on our roadmap. Drop it in the comments — I read every single one.

Signals, Effects, and the Algebra Between Them

Ja — Mon, 13 Apr 2026 02:30:43 +0000

How algebraic data types make reactive state machines explicit, exhaustive, and type-safe

Reactive programming has a dirty secret: state is almost always a finite state machine in disguise, but nobody draws the diagram. You end up with a loading boolean here, a data field that might be null there, an error that coexists awkwardly with both. You write if (loading && !error && data !== null) and pray the compiler doesn't ask questions.

What if the compiler could enforce every possible state, and make the impossible ones unrepresentable?

That's the core idea behind aljabr: a TypeScript library that fuses algebraic data types, exhaustive pattern matching, and reactive signals into a single coherent design. The name is a transliteration of الجبر (algebra), literally "the reunion of broken parts." Which turns out to be a pretty good description of what it does to your application state.

The Problem with Primitive Reactive State

Every signal library gives you something like this:

const count = signal(0);
count.set(42);
count.get(); // 42

Simple enough. But signals have lifecycles: they start uninitialized, become active, and eventually get cleaned up. Flattening that into a single value box forces you to invent your own conventions: is null "not yet set" or "explicitly set to null"? Is reading a disposed signal an error or just zero?

These aren't hypothetical edge cases. They're the things that cause subtle bugs at 2 AM.

aljabr solves this by making the lifecycle an explicit algebraic data type:

type SignalState<T> = Unset | Active<T> | Disposed

Three variants. No overlap. No ambiguity. Every possible state of a reactive value — named, typed, and exhaustive.

Building Blocks: Unions and Pattern Matching

Before diving into signals, let's look at the foundation. aljabr's union function creates tagged variant factories:

import { union, match } from "aljabr";

const Shape = union({
    Circle: (radius: number) => ({ radius }),
    Rect:   (w: number, h: number) => ({ w, h }),
});

type Shape = Union<typeof Shape>; // Circle instance | Rect instance

Each variant carries a hidden [tag] symbol on its prototype, invisible to Object.keys() and JSON.stringify(), but available for dispatch. The match function uses it to route exhaustively:

const area = match(shape, {
    Circle: ({ radius }) => Math.PI * radius ** 2,
    Rect:   ({ w, h })   => w * h,
    // TypeScript error if either arm is missing
});

This is exhaustiveness checking without a third-party library. Miss a variant, get a compile error.

Signal State as an ADT

With that foundation in place, look at how Signal<T> is actually designed:

// From src/prelude/signal.ts

export abstract class SignalLifecycle<T> extends Trait<{ value: unknown }> {
    isActive(): boolean {
        return match(this as unknown as SignalState<T>, {
            Unset:    () => false,
            Active:   () => true,
            Disposed: () => false,
        });
    }

    get(): T | null {
        return match(this as unknown as SignalState<T>, {
            Unset:    () => null,
            Active:   ({ value }) => value,
            Disposed: () => null,
        });
    }
}

export const SignalState = union([SignalLifecycle]).typed({
    Unset:    () => ({ value: null }) as Unset,
    Active:   <T>(value: T) => ({ value }) as Active<T>,
    Disposed: () => ({ value: null }) as Disposed,
});

SignalLifecycle is a Trait, an abstract class that aljabr mixes into every variant at construction time. So Unset, Active, and Disposed all share the same isActive() and get() methods, and those methods are implemented via match internally. The state machine is the type.

Using a signal looks like this:

const count = Signal.create(0);

count.set(42);
count.get();   // 42  (tracked if inside a reactive context)
count.peek();  // 42  (always untracked)

match(count.state, {
    Unset:    () => "waiting for a value",
    Active:   ({ value }) => `current: ${value}`,
    Disposed: () => "signal cleaned up",
});

No booleans. No null guards. The state is an ADT you can match on.

Custom State: Swapping the Lifecycle

Here's where it gets interesting. What if your reactive value isn't just "active or not", what if it carries domain-specific states like Unvalidated, Valid, or Invalid?

aljabr's SignalProtocol<S, T> lets you replace the built-in lifecycle with any union type you want:

import { Signal, Validation } from "aljabr/prelude";

const email = Signal.create(
    Validation.Unvalidated<string, string>(),
    {
        extract: (state) => match(state, {
            Unvalidated: () => null,
            Valid:       ({ value }) => value,
            Invalid:     () => null,
        }),
    }
);

email.set(Validation.Valid("ada@example.com"));
email.get();    // "ada@example.com"
email.read();   // Valid { value: "ada@example.com" }  (tracked, full state)

set() now accepts a full Validation variant. get() extracts T | null via the protocol. read() returns the full state for when you need to match on Invalid errors inside a reactive context. The signal is no longer just a box, it's a typed state machine with domain-specific semantics.

This is the reunion of broken parts the name promises: your validation state and your reactive state, finally speaking the same language.

Effects as a State Machine

Async effects have the same problem as signals, amplified. An async operation can be idle, running, done with a value, done with an error, or stale after a dependency changed. That's five states. Libraries usually pick two or three and leave the rest as conventions.

aljabr models the whole thing:

// From src/prelude/effect.ts

export type Effect<T, E = never> =
    | Idle<T, E>      // thunk registered, not yet run
    | Running<T, E>   // in-flight promise
    | Done<T, E>      // completed: value or error
    | Stale<T, E>     // completed, but a dependency has since changed

Stale is the one most libraries quietly omit. It's the difference between "show a spinner" and "show the old value while the new one loads", the stale-while-revalidate pattern, baked directly into the type.

The Effect union carries a Computable trait that gives every variant chainable map, flatMap, and recover methods, implemented via match internally:

const fetchUser = Effect.Idle(async () => {
    const res = await fetch("/api/user/1");
    return res.json();
});

const fetchName = fetchUser
    .map(user => user.name)
    .recover(err => Effect.Idle(async () => "anonymous"));

const done = await fetchName.run();
// done is Done<string, never>
match(done, {
    Done: ({ signal }) => match(signal, {
        Active:   ({ value }) => console.log("name:", value),
        Disposed: () => console.log("request failed"),
        Unset:    () => {},
    }),
});

Notice that Done carries a SignalState<T> for the result, not a raw value. Success and failure are encoded structurally, not as value | undefined with a separate error field.

Reactive Effects with `watchEffect`

Effect is a value you control manually. For fully automatic dependency tracking, aljabr provides watchEffect:

import { Signal, watchEffect, match } from "aljabr";

const userId = Signal.create(1);

const handle = watchEffect(
    async () => {
        const id = userId.get()!;
        const res = await fetch(`/api/users/${id}`);
        return res.json();
    },
    (result) => {
        match(result, {
            Done:  ({ signal }) => render(signal.get()),
            Stale: (stale) => {
                renderStale(stale.signal.get()); // show old value
                stale.run().then(done => render(done.signal.get()));
            },
        });
    },
);

userId.set(2); // triggers onChange with Stale — caller decides when to re-run
handle.stop(); // unsubscribes all dependencies

Any Signal.get() or Signal.read() call inside the thunk is automatically tracked. When userId changes, the effect transitions to Stale and onChange fires, not with a vague "something changed" signal, but with the full Stale variant carrying the last known value.

Pass { eager: true } and the re-run happens automatically, delivering a fresh Done on every change.

Derived Values: Pull-Based Computation

For synchronous computed values, Derived<T> tracks dependencies lazily — re-evaluating only when read after a dependency has changed:

const firstName = Signal.create("ada");
const lastName  = Signal.create("lovelace");

const fullName = Derived.create(
    () => `${firstName.get()} ${lastName.get()}`
);

fullName.get(); // "ada lovelace" — computed on first read
lastName.set("byron");
fullName.get(); // "ada byron" — re-evaluated lazily

Its internal state is another ADT: Uncomputed | Computed<T> | Stale<T> | Disposed. When a dependency changes, the state transitions from Computed to Stale and dependents are notified, but the value isn't recalculated until someone asks. That's the pull-based part.

For async computation, AsyncDerived<T, E> adds Loading and Reloading to the mix, giving you stale-while-revalidate semantics for data fetching out of the box.

The Pattern That Runs Through Everything

Step back and notice what every primitive in aljabr has in common:

A lifecycle modeled as a tagged union: explicit states, no null, no boolean flags
Trait mixins that attach shared behavior to every variant via match internally
Exhaustive pattern matching at the consumer, so no state goes unhandled

This isn't just aesthetics. It means the TypeScript compiler becomes a collaborator. You can't accidentally read a Disposed signal as if it were Active, the types prevent it. You can't forget to handle the Invalid case in a validation-backed signal, match won't let you compile without it.

The reactive system and the type system are finally speaking the same language, because they're both built from the same algebra.

Get Started

aljabr is available on npm:

npm install aljabr

The core union, match, when, and pred primitives are the main entry point. The reactive layer — Signal, Derived, AsyncDerived, watchEffect, Effect, Result, Validation, Option — lives in the prelude:

import { union, match, when, __ } from "aljabr";
import { Signal, Derived, watchEffect } from "aljabr/prelude";

If you've been reaching for boolean flags to track state, or fighting TypeScript's type narrowing through chains of null checks, aljabr is worth an afternoon. State machines have always been there, it just gives them a name and a type.

Source and docs on GitHub →

All code snippets in this post are drawn directly from the aljabr source. Types like SignalState, Effect, DerivedState, and AsyncDerivedState are real exports, not pseudocode.

How I Secured a Linux Server from Scratch: HNG DevOps Stage 0

Gideon Bature — Mon, 13 Apr 2026 02:24:47 +0000

This is part of my HNG DevOps internship series. Follow along as I document every stage.

Choosing a Cloud Provider

It all started where I had to choose a cloud to use. Ordinarily, the options would have been Google Cloud, AWS or Azure, but somehow I felt there might be more, so I began to search on Reddit and found out that Oracle Cloud has some generous free tier that offers as much as 24GB memory and 200GB storage for free for a lifetime, and it hit me that this is what I had been looking for.

For a lot of other cloud providers, it is either you have limited access for some number of months as a new user, or they give you some cloud credits to spend. The reason Oracle resonated with me is I didn't want something that after the internship I would have to shut down. I needed something I can keep all my work on and reference when necessary.

So I set up Oracle Cloud and subscribed for the free tier instance. At first I set up an instance using Oracle Linux (which is basically a RHEL, RedHat Enterprise Linux), but I quickly realised I was having problems installing ufw, which was one of the required packages for the task. So I completely removed that instance, created another one, this time around using Ubuntu.

The Task

We were given this task:

DEVOPS TRACK, STAGE 0: Linux Server Setup & Nginx Configuration

You will provision a Linux server, install and configure Nginx to serve two different locations, and secure it with a valid SSL certificate. No Docker, no Compose, no automation tools. Just a bare Linux server and your hands.

Here is a summary of what needed to be done:

Server Setup

Create a non-root user called hngdevops with sudo privileges
Configure passwordless sudo for hngdevops for /usr/sbin/sshd and /usr/sbin/ufw
Disable root SSH login
Disable password-based SSH authentication (key-based only)
Configure UFW to allow only ports 22, 80, and 443

Nginx Configuration

GET /: serves a static HTML page containing your HNG username as visible text
GET /api: returns this JSON response exactly:

{
  "message": "HNGI14 Stage 0",
  "track": "DevOps",
  "username": "your-hng-username"
}

SSL

Obtain a valid SSL certificate using Let's Encrypt (Certbot)
HTTP requests must redirect to HTTPS with a 301

But First: Why Stage 0? Why Provision a Linux Server?

To simply put it, everything on the internet runs on a server somewhere. Learning to provision and manage a bare Linux server is the foundation of all DevOps work. Before Docker, containers, Kubernetes, and all the fancy tooling, there is always a Linux machine underneath. So it is best to start from the foundation, so that anything coming after will feel natural, having understood where it all started from.

Step 1: Creating a Non-Root User

First I created a non-root user. Someone might be second-guessing and asking why we had to do this. Ordinarily, when you provision an instance (a Linux server), the user you get is a root account, and a root account has zero restrictions. It can delete every file on the server with a single command, without any confirmation. So running your daily work on a server as root is dangerous and not advisable.

Hence we create a user called hngdevops that can do everything needed via sudo, where mistakes won't have a tremendous effect on the server. Also see it as the principle of least privilege: every user and process should have only the minimum access required to do their job.

To create the user:

sudo adduser hngdevops

Then because I still needed to give this user permission to run some sudo commands, I added them to the sudo group:

sudo usermod -aG sudo hngdevops

Step 2: Copying SSH Keys to the New User

Next I copied my authorized_keys as a root user to the hngdevops user, so they can log in to the server. Here are the commands I used:

# Create the .ssh directory in the hngdevops home folder
sudo mkdir -p /home/hngdevops/.ssh

# Copy authorized_keys so hngdevops can log in
sudo cp ~/.ssh/authorized_keys /home/hngdevops/.ssh/

# Grant hngdevops ownership of the directory
sudo chown -R hngdevops:hngdevops /home/hngdevops/.ssh

# Set correct permissions on the directory
sudo chmod 700 /home/hngdevops/.ssh

# Set correct permissions on the keys file
sudo chmod 600 /home/hngdevops/.ssh/authorized_keys

The permissions matter here. SSH is strict. If the .ssh directory or authorized_keys file has permissions that are too open, SSH will refuse to use them entirely.

Step 3: Passwordless Sudo for Specific Commands

The next step was to grant hngdevops passwordless sudo for sshd and ufw only. This is taking the principle of least privilege even further. With this, even if someone else were to gain access to this user account, there isn't much damage they can do. For everything else requiring sudo, they will be met with a password prompt.

# Open the sudoers file safely
sudo visudo -f /etc/sudoers.d/hngdevops

Note: I used vim as my editor. You can use any editor of your choice: vi, vim, emacs, nano, etc. If you don't have vim installed: sudo apt install vim

Add this exact line and save the file:

hngdevops ALL=(root) NOPASSWD:/usr/sbin/sshd,/usr/sbin/ufw

Always use visudo to edit sudoers files. It validates syntax before saving. A broken sudoers file can lock you out of your own server permanently.

Step 4: Hardening SSH Access

This step is about disabling root login and password-based authentication entirely. Every server on the internet gets thousands of automated login attempts per day from bots scanning for weak credentials. They always try root first because root exists on every Linux machine by default. And passwords can be guessed, brute-forced, or leaked.

By disabling both, the only way into your server is physical possession of your private key file, which is a 256-bit cryptographic secret that is mathematically impossible to brute force.

sudo nano /etc/ssh/sshd_config

Find and update these lines, and if you can't find them, then just add them as they are to the file, with each on it's own line just like this:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Important: Before saving this, open a second terminal window and verify you can SSH in as hngdevops using your key. If you save this and you're locked out, you'll need to use Oracle Cloud's browser console to recover.

Then restart SSH to apply the changes:

sudo systemctl restart sshd

# Verify the config reads correctly
sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"

You should see:

permitrootlogin no
passwordauthentication no

Step 5: Configuring UFW (Firewall)

Your server has 65,535 network ports. By default, any service running on any port is potentially reachable from the entire internet. UFW closes all of them except the three you explicitly need: 22 (SSH), 80 (HTTP), and 443 (HTTPS). This dramatically shrinks your attack surface. A port that is closed cannot be exploited, no matter what software is running behind it.

# Deny all incoming connections by default
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow only the required ports
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Enable the firewall
sudo ufw enable

# Verify it is active
sudo ufw status verbose

Note: Oracle Cloud Ubuntu images don't come with UFW pre-installed. If you get a "command not found" error, install it first with sudo apt install ufw -y

Enable UFW only after confirming port 22 is allowed. Enabling it without allowing SSH will lock you out immediately.

Step 6: Getting a Domain Name

Before installing Nginx or setting up SSL, I needed a domain name. Let's Encrypt won't issue a certificate for a bare IP address. It can only verify ownership of a domain. So SSL is impossible without one.

I didn't want to pay for a domain just yet, so I went looking for a free option. I first tried FreeDNS (afraid.org), signed up, created a subdomain, and filled in my server's IP as the destination. However the DNS ended up not working, I waited for some minutes probably for it to sync and tried, still nothing was resolving hence, I switched to DuckDNS.

DuckDNS is completely free, takes about 5 minutes to set up, and works perfectly with Let's Encrypt. Here's how to set it up:

Go to duckdns.org and log in with Google or GitHub
Choose a subdomain name. Mine became gideonbature.duckdns.org
Enter your server's public IP in the IP field and click Update IP

Then verify it's pointing to your server:

ping <your-subdomain-name>.duckdns.org
# Should show your server's IP in the response

Once the ping resolves to your server's IP, you're ready to proceed.

Step 7: Installing and Configuring Nginx

Nginx is your web server. It listens on ports 80 and 443, receives HTTP requests, and decides what to serve. In real production systems, Nginx sits in front of your actual application and handles routing, SSL termination, rate limiting, caching, and more. Here we use it to serve two routes.

sudo apt update
sudo apt install nginx -y
sudo systemctl enable nginx
sudo systemctl start nginx

Create your HTML page:

sudo nano /var/www/html/index.html

<!DOCTYPE html>
<html>
  <body>
    <h1><your-hng-username></h1>
    <p>HNG DevOps Stage 0</p>
  </body>
</html>

Your username must be visible text on the page. Not in a comment, not hidden with CSS.

Then create your Nginx config:

sudo nano /etc/nginx/sites-available/hng

server {
    listen 80;
    server_name <your-subdomain-name>.duckdns.org;

    # Serve HTML at root
    location / {
        root /var/www/html;
        index index.html;
    }

    # Return JSON at /api
    location = /api {
        add_header Content-Type application/json;
        return 200 '{"message":"HNGI14 Stage 0","track":"DevOps","username":"<your-hng-username>"}';
    }
}

Notice the = sign in location = /api. That is an exact match. Without it, /api/anything would also match, which is sloppy.

Enable the site and reload:

sudo ln -s /etc/nginx/sites-available/hng /etc/nginx/sites-enabled/
sudo rm /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginx

Step 8: The Oracle Cloud Firewall Problem

This is where a lot of people get stuck with Oracle Cloud specifically, and it caught me too. After Nginx was running and confirmed listening on port 80, I still couldn't reach my server from the outside:

curl -I http://<your-subdomain-name>.duckdns.org
# curl: (28) Failed to connect to port 80 after 75326 ms

The issue is that Oracle Cloud has two separate layers of firewall that both need to be opened:

Layer 1: Oracle's Security List (network level)

Go to Oracle Cloud Console → Networking → Virtual Cloud Networks
Click your VCN → Security Lists → default security list
Click Add Ingress Rules and add:

Source CIDR	Protocol	Port
0.0.0.0/0	TCP	80
0.0.0.0/0	TCP	443

Layer 2: iptables on the server itself

Oracle Cloud Ubuntu images ship with extra iptables rules that block ports regardless of UFW. This is the one most people miss:

sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 443 -j ACCEPT

# Make these rules survive a reboot
sudo apt install iptables-persistent -y
sudo netfilter-persistent save

After both layers were open, everything started working:

curl -I http://<your-subdomain-name>.duckdns.org
# HTTP/1.1 200 OK ✅

Step 9: SSL with Let's Encrypt

HTTP sends everything in plain text: passwords, session tokens, personal data. Anyone on the same network can read it. HTTPS encrypts the connection so only the client and server can read the traffic. In 2026 there is no acceptable reason to run a public website without HTTPS.

The 301 redirect specifically matters because it tells browsers and search engines this site is HTTPS only, permanently. Browsers cache 301s, so after the first visit they never even attempt HTTP again.

# Install Certbot
sudo apt install certbot python3-certbot-nginx -y

# Obtain and install the certificate
sudo certbot --nginx -d <your-subdomain-name>.duckdns.org

Certbot will ask for your email address, ask you to agree to terms, and then automatically obtain the certificate, modify your Nginx config to use it, and set up the HTTP → HTTPS 301 redirect. Auto-renewal is also configured automatically via a systemd timer.

Verify both directions work:

# Should show 301 Moved Permanently
curl -I http://<your-subdomain-name>.duckdns.org

# Should show 200 OK
curl -I https://<your-subdomain-name>.duckdns.org

Final Verification

Before submitting, I ran through every check to make sure nothing was missed:

# API response
curl https://<your-subdomain-name>.duckdns.org/api

# HTML page
curl https://<your-subdomain-name>.duckdns.org

# 301 redirect
curl -I http://<your-subdomain-name>.duckdns.org

# HTTPS working
curl -I https://<your-subdomain-name>.duckdns.org

# SSH hardening
sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"

# UFW status
sudo ufw status

Everything came back clean.

The Big Picture

Looking back at everything, Stage 0 is really about building a secure foundation. Every single step answers a specific threat:

What we did	Why it matters
Non-root user	Limits damage from mistakes
Key-based SSH only	Stops password brute force attacks
Root login disabled	Removes the default target for bots
UFW configured	Closes unnecessary attack surface
HTTPS with valid cert	Encrypts data in transit and proves identity

A server without these protections is not a question of if it gets compromised. It is a question of when. With all of these in place, you have something that can sit on the public internet and hold up.

Stage 1 is next. Follow along as I keep documenting the journey.

Find me on Dev.to | GitHub

I built a free salary lookup tool for the Canadian federal government

Statistics of the World — Mon, 13 Apr 2026 02:24:44 +0000

The Canadian federal government employs over 300,000 people across 60+ classification groups. Every salary is public, set by Treasury Board collective agreements. But finding the actual numbers has always been painful: they're buried in dozens of separate PDF documents scattered across government websites.

So I built FedPay.ca to fix that.

What it does

You pick a classification group (like IT for tech, EC for economists, AS for admin) and a level, and it shows you the full pay scale with step by step rates, biweekly pay, and historical salary data going back to previous collective agreements.

It also includes:

A take home pay calculator that shows net pay after federal tax, provincial tax, CPP, EI, and pension deductions
A classification comparison tool for comparing pay across different groups
Job title pages that map real world titles like "software developer" or "policy analyst" to their federal classification codes

Tech stack

Next.js with static export (no server needed)
Deployed on Cloudflare Pages (free tier, auto deploys from GitHub)
All salary data compiled from Treasury Board collective agreements into a single TypeScript data file
SEO optimized with structured data (Occupation schema), dynamic OG images, and 700+ statically generated pages

Why I built it

I work in the Canadian public policy space and got tired of digging through PDFs every time someone asked "what does an IT-03 make?" The official government site lists rates of pay but they are organized by collective agreement rather than by classification, which makes comparison really difficult.

The site now gets about 15,000 to 20,000 monthly pageviews from Google, mostly from people searching things like "EC-05 salary" or "government of canada IT salary."

Some interesting salary facts

The lowest paid permanent federal position is CR-01 at $41,947/year
The highest is MD-MSP (medical specialist) at $266,454
Average across all employees is roughly $85,000
IT developers (IT-02) earn $85,854 to $105,080
Government lawyers have a wild salary band: LP-02 ranges from $130,178 to $206,388

If you have questions about the tech stack, the data pipeline, or how I approached the SEO, happy to answer in the comments.

Check it out: fedpay.ca

Why UI/UX Design is the Backbone of Mobile Development in 2026

fahriel abdul rasyid — Mon, 13 Apr 2026 02:23:30 +0000

Introduction
As we enter mid-2026, competition in the Google Play Store and App Store is no longer just about "who has the most advanced app" but rather "who is the most user-friendly." As developers, we often get caught up in code logic and database structures, but often forget the most crucial element: User Experience.

Paradigm Shift: Mobile-First to Human-First
In 2026, technologies like generative AI will be fully integrated into app UIs. Users no longer want to search for menus behind a stack of hamburger icons. They want intuitive and adaptive interfaces. Understanding UI/UX means understanding user psychology before writing a single line of Kotlin or Java code.
Development Efficiency with Mature Design
Many beginner developers jump straight into Android Studio without going through the wireframing phase in Figma. However, mature design helps us map out:

User Flow: Preventing redundant functions.

Accessibility: Ensuring apps are usable by all groups.

Micro-interactions: Providing satisfying visual feedback to users.

UI/UX and Digital Sustainability One of the biggest trends today is how app design can drive social change. Take the booming e-waste (e-waste) management projects, for example. Without a clean UI, a point system or e-waste drop-off navigation will confuse users, ultimately leading to app abandonment.

Conclusion
UI/UX isn't just the designer's job. It's the responsibility of every developer who wants their app to last on users' devices. Don't just build an app that "works," build an app that "remembers."

Further Information:
I frequently share in-depth thoughts on the connection between IT, application development, and humanity on my personal blog. Please visit Ruang Hening for more related articles.

Upgraded to Tailwind v4 — Config Files Are Gone

LazyDev_OH — Mon, 13 Apr 2026 02:23:23 +0000

Tailwind CSS v4 shipped in January 2025 and tailwind.config.js is gone. Configuration now lives inside the CSS file itself. I migrated a Next.js project — unfamiliar at first, but simpler once you're through it.

The actual transition is faster than expected. The official CLI handles about 80% of it.

What Changes

tailwind.config.js → replaced by a CSS @theme block
Rust-based Oxide compiler — up to 5x faster full builds, up to 100x faster incremental
Automatic content detection — no more manual content array
@tailwind base/components/utilities → single @import "tailwindcss"
Plugins declared in CSS via @plugin "..."

Real-world number from Tailwind's own benchmark: a design system with 15,000 utility classes saw cold builds drop from 840ms to 170ms.

Config Moved into CSS

v3 kept everything in JS. v4 does it all in one CSS file.

/* v4 — configure directly in CSS */
@import "tailwindcss";

@theme {
  --breakpoint-3xl: 1920px;
  --color-brand: oklch(68% 0.19 245);
  --font-display: "Inter Variable", sans-serif;
}

@theme uses CSS variables. Design tokens are visible in DevTools at runtime. One less JS dependency.

@theme Naming Convention

--color-{name}, --font-{name}, --spacing-{name}. Tailwind reads the namespace and generates utility classes automatically. Define --color-brand and text-brand, bg-brand, border-brand light up immediately.

Oxide Compiler

Rust, not Node. Replaces the old PostCSS plugin. Content path detection is automatic — no more content: ['./src/**/*.tsx']. Oxide ships inside the tailwindcss v4 package, no separate install. Integrates with Vite and PostCSS pipelines.

Migration Steps

Option A — one command

npx @tailwindcss/upgrade

Handles config conversion and class renames for projects without custom plugins.

Option B — manual (Next.js / PostCSS)

npm install tailwindcss@latest @tailwindcss/postcss

// postcss.config.js (v4)
module.exports = {
  plugins: {
    "@tailwindcss/postcss": {},
  },
};

/* globals.css (v4) */
@import "tailwindcss";

@theme {
  --color-brand: #6366f1;
}

tailwind.config.js can be deleted or kept — v4 doesn't read it. Deleting it is cleaner for team repos.

Plugins Now Live in CSS

@import "tailwindcss";

@plugin "@tailwindcss/typography";
@plugin "@tailwindcss/forms";
@plugin "./plugins/my-plugin.js";

@theme {
  --color-brand: #6366f1;
}

The plugins array in tailwind.config.js is gone. Pass a package name or a file path to @plugin and it works. Existing addUtilities and addComponents APIs mostly still apply, but parts of the plugin API changed — verify behavior after migrating.

The `outline-none` Gotcha

v3: outline-none rendered as outline: 2px solid transparent — still accessible.
v4: outline-none renders as outline: none — actually removes the outline.

If you used outline-none to hide focus rings on buttons or inputs, swap in outline-hidden. Expect this to surface during accessibility checks.

v3 vs v4 at a Glance

Area	v3	v4
Config	`tailwind.config.js`	CSS `@theme` block
Import	three `@tailwind` lines	`@import "tailwindcss"`
Content detection	manual array	automatic
Compiler	PostCSS (Node)	Oxide (Rust)
Plugins	`plugins: [...]`	`@plugin "..."`
`outline-none`	transparent outline	actual `none` (use `outline-hidden`)

Should You Upgrade Now?

New project → v4. No reason not to.
Existing v3 project → no rush. v3 is still supported.
Heavy custom-plugin stack → stay on v3 until you've tested each plugin against the v4 API.
Build times biting → v4 is worth the migration cost just for the Oxide numbers.

FAQ

Q. Do I need to delete tailwind.config.js?
No — v4 doesn't read it. The upgrade CLI handles conversion. Delete for cleanliness.

Q. Separate Oxide install?
No. Included in the tailwindcss v4 package.

Q. How long does migration take?
Small Next.js projects: 30 minutes including manual review. Larger ones with custom plugins and dynamic class composition (bg-${color}-500 patterns): a couple hours, because those aren't auto-migrated.

Sources

Originally published at GoCodeLab.

Gemma 4 vs Llama 4 vs Mistral Small 4: The 2026 Open-Source LLM Picks

LazyDev_OH — Mon, 13 Apr 2026 02:23:22 +0000

Three heavyweights dropped this year: Gemma 4 (Google), Llama 4 (Meta), Mistral Small 4 (Mistral). All free to run. All structurally different. Here's which one fits which job.

Short answer: long context → Llama 4 Scout. License-clean commercial use → Mistral Small 4. On-device → Gemma 4 E2B / E4B.

Quick Take

	Gemma 4 (31B / 26B MoE)	Llama 4 Scout	Mistral Small 4
Architecture	Dense (31B) · MoE (26B/A4B)	MoE (17B active / 109B)	MoE (~22B active / 119B)
Context	E2B/E4B 128K · 31B/26B 256K	10M	256K
License	Google Gemma ToU	Llama 4 Community	Apache 2.0
Multimodal	text + image + video + OCR (E2B/E4B add audio)	text + image (early fusion)	text + image (first in Small series)
Edge fit	Excellent (E2B/E4B)	Low	Low (multi-GPU even quantized)

MoE vs Dense

MoE is a bank of specialized tellers — only the relevant experts fire per input. Llama 4 Scout: 109B total, 17B active. Mistral Small 4: 119B total across 128 experts, ~22B active. Gemma 4 26B: the "small MoE" path — 26B total, ~3.8B active, targeting 4B-speed with bigger-model intelligence.

Gemma 4 E2B, E4B, and 31B are Dense. Every parameter fires on every token. Higher compute per parameter, but memory requirements scale linearly and planning is easier.

One MoE trap people hit: inference compute drops, but all weights still need to sit in memory. Llama 4 Scout in fp16 = ~218GB VRAM. 4-bit = ~55GB. "Only 17B active so it's lightweight" is wrong.

Context Window — 10M, 256K, 128K

Llama 4 Scout's 10M is the outlier. Meta got there via iRoPE — interleaved RoPE that holds accuracy past the training sequence length. Practical impact: you can drop an entire monorepo into one prompt and skip the RAG pipeline altogether.

Mistral Small 4 sits at 256K. Gemma 4's small variants (E2B/E4B) are 128K; the medium 31B and 26B MoE jump to 256K. For normal-scale work — books, research paper batches, long meeting transcripts — 128K is already more than enough.

Benchmarks

Llama 4 Maverick on SWE-bench: 76.8 to 80.8 depending on the evaluation variant. Open-source top tier — but not "absolute #1." GLM-5 (77.8) shows up right next to it on SWE-bench Verified.
Llama 4 Scout is smaller than Maverick but wins on repo-scale analysis thanks to 10M context.
Gemma 4 31B shines on multimodal tasks relative to its size class.
Mistral Small 4 (per Mistral's evals) matches or surpasses GPT-OSS 120B and Qwen-class models on several key benchmarks — at ~22B active.

Benchmarks and day-to-day use diverge. Run them yourself before committing.

Multimodal — Images, Video, Audio

None of these three is text-only in 2026.

Gemma 4 is natively multimodal across every variant: text, image, video, OCR. E2B and E4B add native audio input — voice assistants and on-device transcription become direct use cases.
Llama 4 Scout/Maverick use early fusion — text and vision tokens unified inside the foundation model.
Mistral Small 4 is the first in the Mistral Small series to support native vision. Images ride in the normal API message array alongside text, inside the same 256K window.

Licenses (Actually Read Before Shipping)

Mistral Small 4 / Apache 2.0 — zero restrictions. Fine-tune, redistribute, embed in SaaS, ship it.
Llama 4 Community — commercial use fine below 700M MAU, but Meta's approval is required above that (sole discretion). Also: mandatory "Built with Llama" badge on a related web or in-app page.
Gemma 4 / Google Gemma ToU — you can't use Gemma outputs to train competing LLMs, and AI-adjacent services need to read the clauses carefully.

Edge Deployment Reality

Model	fp16 VRAM	4-bit VRAM	Realistic hardware
Gemma 4 E4B	~8GB	~3GB	Laptop / phone
Gemma 4 31B	~62GB	~16GB	RTX 4090 / M2 Max
Llama 4 Scout	~218GB	~55GB	Multi-GPU / H100 at Int4
Mistral Small 4	~238GB	~60GB	Multi-GPU / high-end workstation

Gemma 4 E4B at 4-bit = ~3GB. Runs on a laptop. For smartphone deployments E2B is the target. Llama 4 Scout and Mistral Small 4 stay in server territory even quantized — the full MoE weights have to fit in memory regardless of active count.

How to Combine All Three

Routing by request type is more realistic than picking one:

request type                    → model
-------------------------------------------
whole-doc / whole-repo analysis → Llama 4 Scout (10M context)
image + video + audio input     → Gemma 4
commercial API traffic          → Mistral Small 4 (Apache 2.0)

Using hosted APIs (Together AI, Groq, Fireworks) on top of this routing lets you optimize both cost and capability together.

FAQ

Q. How does Scout actually handle 10M tokens?
iRoPE — Meta's interleaved version of RoPE position encoding. Extends accuracy well past training length.

Q. Which is most commercial-friendly?
Mistral Small 4. Apache 2.0. No MAU cap, no branding requirement.

Q. Is MoE always better than Dense?
No. Inference compute drops, but memory scales with total parameters. Edge = Dense small or compact MoE like Gemma 4 26B. MoE only pays off with multi-GPU.

Q. Best at coding?
Llama 4 Maverick (76.8–80.8 on SWE-bench) — top tier, not #1. GLM-5 (77.8) is right there too. Mistral Small 4 is fine for general code review; Scout's 10M wins whole-repo work.

Sources

Originally published at GoCodeLab. Always read each model's official license before commercial deployment — this post is not legal advice.

CameraFool

Zheus Leiandre Codez Cajote — Mon, 13 Apr 2026 02:21:20 +0000

This is a submission for the DEV April Fools Challenge

What I Built

CameraFool is a revolutionary, cutting-edge, AI-powered mirror experience… that literally just opens your device camera.

Yes. That’s it.

In a world where your phone already has a camera app one tap away, CameraFool bravely asks:
“What if… we made it harder?”

Instead of simply opening your camera like a normal person, users must:

Visit a website
Click a dramatic “Open Mirror” button
Select their preferred mirror device (very important)
Then… we open the exact same camera anyway

Innovation.

Demo

zheyuse.github.io

Code

ZheyUse / camerafool

CameraFool

"The Future of Reflection Technology" - a premium-looking prank app that adds dramatic steps before opening a camera flow.

Intro

CameraFool is intentionally overdesigned and funny:

User visits a beautiful landing page.
User clicks Open Mirror.
User sees a fake permission modal (Allow / Definitely Allow).
User gets dramatic startup text and fake calibration.
Then CameraFool launches camera behavior (native-device flow attempt first).

It looks like a $49/month AI product. It mostly opens a camera.

How It Works

Main flow

Open Mirror -> opens fake permission modal.
Allow / Definitely Allow -> runs dramatic loading sequence.
After loading:
- On Windows, it attempts to launch native Camera app via microsoft.windows.camera:.
- On other devices, it triggers native capture intent (input capture) where supported.
If no camera is detected, it shows a No Camera Detected modal.

Demo flow

Try Demo Mode bypasses the fake permission modal…

View on GitHub

How I Built It

TechStack: HTML, JS, CSS

Prize Category

I’m going for Best Google AI Usage because this project uses AI in the most powerful way possible… by making everything feel smart while doing absolutely nothing new 😭

We added “AI-powered reflection enhancement”, smart mirror selection, and dramatic loading like it’s about to scan your soul… but in the end it just opens your camera like usual.

It’s basically a tribute to every product that says “AI-powered” just to sound cool.

So technically, the AI is working… just not in the way you expect 😏

A Pattern Sketch: Server-Sent Events as a Fanout Channel for Edge State

as1as — Mon, 13 Apr 2026 02:19:51 +0000

What this is: a small OSS pattern sketch — not a Redis replacement, not a production auth platform. I built it to play with one specific question: "if you only need to push small mutations from one writer to many readers, do you actually need Redis?" Sharing the design and the trade-offs in case the pattern is useful to anyone.

Repo: github.com/as1as1984/sse-edge-auth

The shape of the problem

The goal here isn't don't use Redis. It's what does this problem look like when you strip it down to the minimum pieces.

A common edge-auth setup has many edge nodes in front of an origin, all needing to agree on things like "is this IP banned?" or "is this JWT revoked?". The default answer is Redis — every edge queries the same shared store.

But notice the asymmetry: mutations are rare, reads are constant. You might revoke a token once a minute; the edge fleet handles thousands of requests per second. Putting a network round trip on every read to keep N nodes in sync feels disproportionate.

One clarification worth making upfront: SSE itself isn't faster than Redis pub/sub — as fanout channels, they're in the same ballpark. The difference shows up on the read path. With Redis, every request pays a network lookup (~0.5–5ms on LAN). With local SQLite, every check is an in-process function call (~0.01–0.1ms). The speed comes from in-process SQLite, not from SSE.

If you frame it as a fanout problem instead of a shared-state problem, two pieces of unexciting tech are a clean fit:

Need	Choice
Push small mutations from one writer to N readers	Server-Sent Events (one-way HTTP stream)
Answer reads locally with no network involved	In-process SQLite — every check is a function call

That's the entire architecture.

Architecture

                  operator
                     |
              POST /ban/ip
                     v
              +---------------+
              | master server |   GET /events  (SSE)
              +-------+-------+ ──────────────────────+
                                                       |
                +-----------+-----------+-----------+
                v           v           v           v
            +-------+   +-------+   +-------+   +-------+
            | edge  |   | edge  |   | edge  |   | edge  |
            |sqlite |   |sqlite |   |sqlite |   |sqlite |
            +---+---+   +---+---+   +---+---+   +---+---+
                |           |           |           |
                +-----------+-> origin <+-----------+

Each edge subscribes to the master's SSE stream on startup. When you POST /ban/ip, the master writes the event to an in-memory ring buffer and broadcasts it. Every connected edge applies it to its own local SQLite. From that moment, requests to that IP are rejected by the local auth gate — no remote call.

SSE + `Last-Event-ID`: the part I find satisfying

The genuinely nice thing about SSE for this pattern is that the resume protocol is already in the spec. Every event has an ID:

id: 42
event: ip_banned
data: {"ip": "1.2.3.4", "reason": "abuse", "timestamp": 1234567890}

The edge sends the last ID it saw on reconnect:

GET /events
Last-Event-ID: 42

The master replays everything since. We didn't have to design a catch-up protocol — we just needed a ring buffer.

The same channel carries cache invalidation:

event: cache_invalidated
data: {"tags": ["products"], "keys": [], "timestamp": 1234567890}

Once you have a reliable fanout channel for one kind of state mutation, adding another kind is a one-line consumer on the edge. Same Last-Event-ID resume, same ordering guarantees.

Why SSE, not WebSocket

	SSE	WebSocket
Direction	server → client	bidirectional
Protocol	plain HTTP	HTTP upgrade + framing
Reconnect / resume	in the spec	DIY
Proxy / LB compatibility	works everywhere HTTP works	sometimes painful

Traffic in this design is strictly master → edge. WebSocket buys bidirectionality we don't use, and costs complexity we don't want.

The bit I'm most curious about: a composable cache TTL pipeline

Since edges already see every request, they double as a response cache. Where it gets interesting is how TTL gets decided — as a pipeline of small pure functions:

function resolveTTL(ip, baseTTL) {
  let ttl = baseTTL;
  ttl = adjustTTLByFrequency(ip, ttl); // trusted IPs → longer TTL
  ttl = adjustTTLByTime(ttl);          // off-peak → longer, peak → shorter
  return Math.max(0, ttl);
}

Each rule lives in its own file:

ttl-by-frequency.js — high-frequency IPs are likely real clients; trust them with a longer TTL. First-seen IPs get a shorter one.
ttl-by-time.js — content changes less off-peak; cache longer overnight, shorter during peak.
failure-pattern.js — N auth failures in a window from the same IP triggers a local auto-ban, written into the same SQLite table the master uses. Edge-local self-healing — no master round trip needed for "I'm being abused right now."
lru-eviction.js — when the cache exceeds CACHE_MAX_ENTRIES, oldest-accessed keys are dropped.

Adding a fifth rule means writing one function and one line in resolveTTL. The composability matters more to me than any specific rule.

Tag-based invalidation

The origin tags responses:

Cache-Control: public, max-age=60
X-Cache-Tags: products, category-3

When products change, one call to the master:

curl -X POST http://master:4000/invalidate \
  -H 'content-type: application/json' \
  -d '{"tags": ["products"]}'

The master broadcasts cache_invalidated, every edge drops matching entries from its local SQLite. Same channel, same resume guarantees as auth state.

Honest limits

I want to be specific about what this pattern does not give you, because the answer to "do I need Redis?" depends entirely on these:

The master is a single point of failure for new mutations. If it's down, edges keep serving with last-known state, but you can't ban anyone new. Master HA is not in v0.1.
An edge offline longer than the ring buffer (10k events by default) can miss intermediate events on reconnect. There's no full-state-pull endpoint yet.
The cache is in-memory only. Restarting an edge clears it.
No cluster, no persistence layer, no replication. Real Redis-shaped systems give you those; this pattern explicitly doesn't.

So this fits a fairly narrow shape: small/medium edge fleets, mostly long-lived edges, one master is acceptable as a coordination point, and "edge keeps working with stale state during master outages" is preferable to "everything halts when the shared store is gone."

If your situation needs more than that, you probably do want Redis — or Kafka, or a real distributed consensus system.

Run it locally

git clone https://github.com/as1as1984/sse-edge-auth
cd sse-edge-auth
(cd master && npm install) && (cd edge && npm install)

# master
(cd master && PORT=4000 npm start)

# three edges
(cd edge && PORT=5001 NODE_ID=edge-a ORIGIN_URL=http://localhost:8080 npm start)
(cd edge && PORT=5002 NODE_ID=edge-b ORIGIN_URL=http://localhost:8080 npm start)
(cd edge && PORT=5003 NODE_ID=edge-c ORIGIN_URL=http://localhost:8080 npm start)

Try a ban:

curl -X POST http://localhost:4000/ban/ip \
  -H 'content-type: application/json' \
  -d '{"ip":"::1","reason":"demo"}'

curl http://localhost:5001/  # 403 ip_banned, same on edges 5002/5003

Current gaps

No full-state-pull endpoint — an edge that exceeds the ring buffer window can't resync cleanly on reconnect. Still undecided between paginated event replay and snapshot dump.
No file-backed SQLite — restarting an edge clears its cache. better-sqlite3 supports this natively; just haven't wired it up yet.
No master HA — a leader/follower setup where followers accept SSE subscriptions and forward writes is needed but not in v0.1.
No real-network benchmark — a docker-compose with tc netem would tell us much more about this pattern's actual behavior than any localhost numbers could.

Repo: github.com/as1as1984/sse-edge-auth
Stack: Node.js 20+, better-sqlite3, jose, Express
License: MIT

We Scored 28 Famous Open Source PRs for Deploy Risk

Andrew — Mon, 13 Apr 2026 02:18:54 +0000

TL;DR
The React Hooks PR that changed every React application on earth? Three words in the commit message. One feature flag removed. It scored 91 out of 100 for deploy risk. The Svelte 5 release scored 99. A 65-line TypeScript change scored 79 and silently broke type inference in codebases worldwide. We ran 28 landmark open source pull requests through Koalr's deploy risk model. Here is what we found — and why it matters for the PRs your team ships every week.

The problem with code review
Modern code review answers one question well: is this code correct?

It answers a different question poorly: how likely is this to cause a production incident?

Those are not the same question. A PR can be clean, well-written, and thoroughly reviewed — and still wreck production because it touches a critical path nobody flagged, because the reviewer had twelve other PRs open, or because it is the fourth consecutive revert of a feature that never landed cleanly.

Most teams have no objective signal for the second question. They have green checkmarks.

What deploy risk scoring is
Koalr scores every pull request from 0 to 100 before it merges. The score is built from 36 signals:

Blast radius signals

How many files changed
What services those files belong to
Whether shared libraries or interfaces were modified
CODEOWNERS compliance — did the right people review the right files

Change quality signals

File churn — how recently and how often these files have been modified
Change entropy — how spread across the codebase the diff is
Lines added vs deleted ratio
Test coverage of changed files

Context signals

Reviewer load — how many open PRs each reviewer currently has
Author's recent incident rate
Time since last deploy to the same service
Revert history on the changed file set

History signals

Consecutive reverts of the same feature
Recent incident correlation with this file set
PR age — how long the branch has been open
A score of 0–39 is Low. 40–69 is Medium. 70–89 is High. 90–100 is Critical.

The score does not replace review. It gives reviewers a number to orient around before they start reading.

The experiment
We pulled 28 of the most consequential pull requests in open source history and ran them through the model. These are PRs the industry knows by name — the ones that shipped features used by millions of developers, or broke them.

Here is what the model said.

The obvious ones scored as expected

Svelte 5 release https://github.com/sveltejs/svelte/pull/13701 — score 99

The full runes rewrite merged to main. Thousands of files changed, the entire reactivity model replaced, years of migration work consolidated into one merge. Of course it scored critical. High blast radius, enormous file count, fundamental architecture change. The model does what you would expect.

TypeScript modules conversion https://github.com/microsoft/TypeScript/pull/51387 — score 98

Microsoft's conversion of the entire TypeScript compiler codebase from namespaces to ES modules. It touched every source file in the compiler, changed the build system, and dropped dependencies. If any PR in history deserved a mandatory all-hands review before merge, it was this one.

The surprising ones — small diffs, enormous blast radius
This is where it gets interesting.

React PR #14679 "Enable hooks!" https://github.com/facebook/react/pull/14679 — score 91

The commit message is three words. The diff is the removal of a single feature flag. You could read the entire change in thirty seconds.

It scored 91.

Why? Because the model does not count lines — it looks at what the changed code controls. A feature flag in a framework used by tens of millions of applications is not a small change. It is a detonation switch. The blast radius is every React application on earth. The model flagged it correctly.

Signals fired:
  blast_radius_score: 0.97
  feature_flag_detected: true
  downstream_consumers: critical
  reviewer_load: 0.2 (core team — low load)

Final score: 91 / Critical

Node.js PR #41749 "lib: add fetch" https://github.com/nodejs/node/pull/41749 — score 82

One file changed: the bootstrap script that runs inside every Node.js process. Adding the global fetch API touched the most critical execution path in the runtime.

Single-file PR. High score. The file changed is what matters, not how many files changed.

TypeScript PR #57465 "Infer type predicates from function bodies" https://github.com/microsoft/TypeScript/pull/57465 — score 79

65 lines of new code. One function modified.

Those 65 lines changed type inference behavior across the entire checker, producing new type errors in codebases that had compiled cleanly for years. A reviewer looks at 65 lines, sees clean code, approves it. The model sees that those 65 lines live inside the type checker core and have cross-cutting effects on every downstream consumer.

This is the failure mode standard review misses every time.

The revert pattern

Next.js PR #45196 https://github.com/vercel/next.js/pull/45196 — score 88

Title: "Revert 'Revert 'Revert 'Revert 'Initial metadata support''"''

PR body: "Hopefully last time."

Four consecutive reverts of the same feature. The model has a specific signal for this: repeated churn on the same file set with revert commits in recent history. It is one of the strongest predictors of another rollback. The PR scored 88 before anyone read a single line of the diff.

The one that surprised us most

The Jest-to-Vitest migration in tRPC — PR #3688 https://github.com/trpc/trpc/pull/3688 — scored 67. Medium risk.

At first glance, that sounds about right for a test runner swap. But look at what actually changed: every single test file in the repository, plus the root configuration, plus the CI pipeline. The surface area was enormous.

The score was “only” 67 because the risk model correctly identified that none of the changed files were production code paths — only test infrastructure. A test runner change cannot break a production deployment directly. What it can do is make future regressions invisible, which is a subtler and harder-to-measure risk.

The model is honest about what it can and cannot see. Broken test infrastructure does not score as a deploy risk — it scores as a coverage risk. Different signal, different response.

The score table
Here are eight of the 28 PRs we scored, with the risk level and the primary reason for the score:

What this means for your PRs
The open source examples are useful because they are public and well-documented. But none of those teams needed a risk model — the React core team was reviewing the hooks PR. It still would have scored 91.

The real value is the ordinary PR your team ships on a Thursday afternoon, reviewed by one person in fifteen minutes, that quietly introduces a breaking change nobody caught. That team does not have the React core team. They have two engineers, a Monday morning deadline, and a PR that looks fine.

That is who Koalr is built for.

Try it
The live risk demo at koalr.com/live-risk-demo scores any public GitHub PR in seconds. No account, no install. Paste a URL, get a score.

If you want to score your own team's PRs — every PR, automatically, as part of your GitHub workflow — there is a free trial at app.koalr.com/signup .

Docker Compose Explained: One File, One Container (2026)

David Tio — Mon, 13 Apr 2026 02:18:49 +0000

🐳 Docker Compose Explained: One File, One Container (2026)

Quick one-liner: Replace docker run commands with a docker-compose.yml file. One command to start or tear down any container, reproducibly, every time.

🤔 Why This Matters

In the last post, you connected containers by building a custom bridge network and running CloudBeaver + PostgreSQL by hand:

$ docker network create dtstack
$ docker run -d --rm --name dtpg \
    --network dtstack \
    -e POSTGRES_PASSWORD=docker \
    -e POSTGRES_DB=testdb \
    -v pgdata:/var/lib/postgresql/data \
    --tmpfs /var/run/postgresql \
    postgres:17
$ docker run -d --rm --name cloudbeaver \
    --network dtstack \
    -p 8978:8978 \
    -v cbdata:/opt/cloudbeaver/workspace \
    dbeaver/cloudbeaver:latest

Three commands. That's not the problem.

The problem is:

The second command is a 150-character wall of flags
One typo in --tmpfs and PostgreSQL silently starts but won't accept connections
Forget --network dtstack and the containers won't find each other
Tear it down and rebuild? Type it all again
What about when you have 5 containers? 10?

There's a better way.

Docker Compose lets you define this entire stack in a single YAML file:

$ docker compose up -d

One command. Same result. Every time.

Here's how it works. Instead of typing flags every time, you write a docker-compose.yml file that captures everything. You list the image, ports, volumes, environment variables, and networks. Then you run docker compose up -d and Docker does the rest. Start it, stop it, tear it down. All with one command.

We'll start by composing each of our containers individually. One compose file for PostgreSQL. One for CloudBeaver. You'll get comfortable with the up/ps/logs/down workflow.

By the end of this post, you'll never have to stare at another never-ending line of docker run flags again.

✅ Prerequisites

Ep 1-6 completed. Docker is installed and running, you know volumes, networking, and port mapping. Rootless mode recommended.
Docker Compose plugin. Already installed as part of Blog-01/02. Just run docker compose version to verify.

Compose v2: The old docker-compose (with hyphen) is deprecated. Modern Docker ships docker compose (space) as a plugin. If docker compose version doesn't work, go back and re-run the installation steps in Blog-01 or Blog-02. The plugin was included there.

📦 Your First docker-compose.yml

Create a directory for your PostgreSQL service:

$ mkdir -p dtstack-pg && cd dtstack-pg

Create docker-compose.yml:

services:
  dtpg:
    container_name: dtpg
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: docker
      POSTGRES_DB: testdb
    volumes:
      - pgdata:/var/lib/postgresql/data
    tmpfs:
      - /var/run/postgresql

volumes:
  pgdata:

Four things to notice:

services: is the top-level key. Each entry under services: is one container. We have one, and it's called dtpg.
container_name gives it a clean name. Instead of Compose's auto-generated dtstack-pg-dtpg-1, we get dtpg. Same as --name in docker run.
No --network flag. The network is implicit. We're not connecting to anything else yet. One container, one service.
Volumes are declared at the bottom. Named volumes are defined in the volumes: block and referenced by the service. Docker creates them on first use.

🚀 Start the Service

$ docker compose up -d

[+] Running 3/3
 ✔ Network dtstack-pg_default  Created
 ✔ Volume dtstack-pg_pgdata    Created
 ✔ Container dtpg              Started

One command creates a container, a network, and a volume. Everything you need.

Verify it's up:

$ docker compose ps
NAME   IMAGE         COMMAND                  SERVICE   CREATED         STATUS         PORTS
dtpg   postgres:17   "docker-entrypoint.s…"   dtpg      54 seconds ago  Up 54 seconds  5432/tcp

🔍 Inspect the Service

View logs:

$ docker compose logs

dtpg | PostgreSQL init process complete; ready for start up.
dtpg | database system is ready to accept connections

Follow logs in real-time (like docker logs -f):

$ docker compose logs -f

Press Ctrl-C to stop following.

Connect and verify:

$ docker compose exec dtpg psql -U postgres -c "SELECT version();"

                                                      version
--------------------------------------------------------------------------------------------------------------------
 PostgreSQL 17.9 (Debian 17.9-1.pgdg13+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
(1 row)

PostgreSQL is running. We used dtpg to target the container, and Compose knows exactly which one to hit.

Let's bring it down before we make changes:

$ docker compose down

[+] Running 2/2
 ✔ Container dtpg              Removed
 ✔ Network dtstack-pg_default  Removed

The volume survives. Your data is safe.

📁 Using Environment Files

Hardcoding passwords in YAML is bad practice. Move secrets to a .env file:

$ cat > .env << EOF
POSTGRES_PASSWORD=docker
POSTGRES_DB=testdb
EOF

Update docker-compose.yml to reference them:

services:
  dtpg:
    container_name: dtpg
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - pgdata:/var/lib/postgresql/data
    tmpfs:
      - /var/run/postgresql

volumes:
  pgdata:

Now docker compose up -d reads the variables automatically. Same command, cleaner file.

🛑 Tear It Down

$ docker compose down

[+] Running 2/2
 ✔ Container dtpg              Removed
 ✔ Network dtstack-pg_default   Removed

The container and network are gone, but the volume survives. Your data is still right where you left it:

$ docker volume ls | grep dtstack

local  dtstack-pg_pgdata

To remove the volume too:

$ docker compose down --volumes

[+] Running 1/1
 ✔ Volume dtstack-pg_pgdata  Removed

Use --volumes when you want a clean slate. Leave it off when you want data to survive across restarts.

📦 Second Compose File: CloudBeaver

Now let's do the same for CloudBeaver. It gets its own directory and its own compose file.

First, go back to your home directory:

$ cd ~

Then create the CloudBeaver directory:

$ mkdir -p dtstack-cb && cd dtstack-cb

services:
  cloudbeaver:
    container_name: cloudbeaver
    image: dbeaver/cloudbeaver:latest
    ports:
      - "8978:8978"
    volumes:
      - cbdata:/opt/cloudbeaver/workspace

volumes:
  cbdata:

Start it:

$ docker compose up -d

[+] Running 3/3
 ✔ Network dtstack-cb_default  Created
 ✔ Volume dtstack-cb_cbdata    Created
 ✔ Container cloudbeaver       Started

Open http://localhost:8978. CloudBeaver loads. ✅

But there's no PostgreSQL on this network. CloudBeaver and PG live in separate compose projects. Different directories, different networks. They can't talk to each other yet.

Déjà vu. We solved this exact problem in the last post with custom bridge networks. Same concept, but this time we're doing it through Compose. We'll get there next post.

For now, let's clean up:

$ docker compose down --volumes

📋 Docker Run vs Docker Compose

Task	`docker run`	`docker compose`
Start	`docker run -d --name x --network n ...`	`docker compose up -d`
List	`docker ps`	`docker compose ps`
Logs	`docker logs x`	`docker compose logs`
Exec	`docker exec -it x sh`	`docker compose exec x sh`
Stop	`docker stop x`	`docker compose down`
Network	`docker network create`	Automatic

The docker compose commands are scoped to your project. docker compose ps only shows your stack's containers. It won't list everything running on your machine.

🧪 Exercise: Build Your Nextcloud Stack with Compose

Nextcloud is a self-hosted productivity platform. It functions just like Google Docs, but it runs on your own server. It needs four services: a database, a cache, a web server, and a PHP backend. You'll create four compose files, one per service, each in its own directory.

First, go back to your home directory:

$ cd ~

Part 1: MariaDB

$ mkdir -p nc-db && cd nc-db

Create .env:

$ cat > .env << EOF
MYSQL_ROOT_PASSWORD=nextcloud
MYSQL_DATABASE=nextcloud
MYSQL_USER=nextcloud
MYSQL_PASSWORD=nextcloud
EOF

Create docker-compose.yml:

services:
  db:
    container_name: nc-db
    image: mariadb:11
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - dbdata:/var/lib/mysql

volumes:
  dbdata:

$ docker compose up -d

Verify:

$ docker compose exec db mariadb -u root -pnextcloud -e "SHOW DATABASES;"

+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| nextcloud          |
| performance_schema |
| sys                |
+--------------------+

$ docker compose down --volumes

Part 2: Redis

$ cd ~
$ mkdir -p nc-redis && cd nc-redis

services:
  redis:
    container_name: nc-redis
    image: redis:8.6
    ports:
      - "6379:6379"
    volumes:
      - redisdata:/data

volumes:
  redisdata:

$ docker compose up -d
$ docker compose exec redis redis-cli PING

You should get PONG.

$ docker compose down --volumes

Part 3: Nextcloud PHP-FPM

$ cd ~
$ mkdir -p nc-php && cd nc-php

services:
  php:
    container_name: nc-php
    image: nextcloud:fpm
    ports:
      - "9000:9000"
    volumes:
      - ./html:/var/www/html

$ docker compose up -d

Nextcloud's PHP-FPM image comes with Nextcloud pre-installed. On first start, it runs its setup scripts and copies the app files into the bind-mounted html/ directory. You can see it populate:

$ ls html/

You'll see Nextcloud's file structure. Things like index.php, core/, apps/, config/. The container put everything there for you.

$ docker compose down

Part 4: Nginx

$ cd ~
$ mkdir -p nc-nginx && cd nc-nginx

services:
  nginx:
    container_name: nc-nginx
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html

$ mkdir -p html
$ cat > html/index.html << 'EOF'
<h2>Nextcloud is coming</h2>
EOF

$ docker compose up -d
$ docker compose exec nginx curl localhost

You should see <h2>Nextcloud is coming</h2>.

$ docker compose down

👉 Coming up: This isn't a full Nextcloud deployment yet, but you now have all the containers you need to get it running. Next post, we'll glue them all up and get it working. See you then.

📚 Want More? This guide covers the basics from Chapter 11: Using Docker Compose in my book, "Levelling Up with Docker". That's 14 chapters of practical, hands-on Docker guides.

> Note: The book has more content than this blog series. Some topics are only available in the book.

📚 Grab the book: "Levelling Up with Docker" on Amazon

Found this helpful? 🙌

LinkedIn: Share with your network
Twitter: Tweet about it
Questions? Drop a comment below or reach out on LinkedIn

How I Cut Our AI Agent Token Costs by 73% Without Sacrificing Quality

Tijo Gaucher — Mon, 13 Apr 2026 02:16:50 +0000

Every month I'd open our cloud billing dashboard and wince. Running AI agents in production at RapidClaw meant our token costs were climbing faster than our revenue. Sound familiar?

After three months of aggressive optimization, we cut our monthly token spend by 73% while actually improving agent response quality. Here's exactly how we did it — no vague advice, just the specific techniques that moved the needle.

The Problem: Death by a Thousand Tokens

When you're running AI agents that handle real workloads — deployment automation, infrastructure monitoring, code review — every unnecessary token adds up. Our agents were processing ~2M tokens per day across various tasks. At GPT-4-class pricing, that's not pocket change.

The root causes were predictable once we actually measured:

Bloated system prompts copied-and-pasted across agents (avg 2,400 tokens each)
No caching layer — identical queries hitting the LLM every time
Redundant context stuffed into every request "just in case"
Wrong model for the job — using frontier models for classification tasks

Strategy 1: Prompt Compression (Saved ~30%)

The biggest win was the simplest. We audited every system prompt and applied aggressive compression.

# BEFORE: 847 tokens
SYSTEM_PROMPT_BEFORE = """
You are a helpful deployment assistant for our cloud infrastructure.
You should help users deploy their applications to our Kubernetes cluster.
You have access to kubectl commands and can help troubleshoot issues.
When a user asks you to deploy something, you should first check if 
the namespace exists, then validate the manifest, then apply it.
You should always be polite and professional in your responses.
You should explain what you're doing at each step.
If something goes wrong, provide clear error messages and suggestions.
Always confirm before making destructive changes.
Remember to check resource limits and quotas before deploying.
"""

# AFTER: 196 tokens
SYSTEM_PROMPT_AFTER = """
Role: K8s deployment agent.
Tools: kubectl
Flow: check namespace → validate manifest → apply
Rules: confirm destructive ops, check resource quotas, explain steps
"""

Same behavior, 77% fewer tokens. The key insight: LLMs don't need the verbose instructions we think they do. They need structured, precise constraints.

We built a simple compression pipeline:

import tiktoken

def audit_prompt(prompt: str, model: str = "gpt-4") -> dict:
    enc = tiktoken.encoding_for_model(model)
    tokens = enc.encode(prompt)

    # Flag prompts over 500 tokens for review
    return {
        "token_count": len(tokens),
        "needs_review": len(tokens) > 500,
        "estimated_daily_cost": len(tokens) * CALLS_PER_DAY * COST_PER_TOKEN
    }

# Run this on every agent prompt quarterly
for agent in get_all_agents():
    report = audit_prompt(agent.system_prompt)
    if report["needs_review"]:
        print(f"⚠️  {agent.name}: {report['token_count']} tokens "
              f"(${report['estimated_daily_cost']:.2f}/day)")

Strategy 2: Semantic Caching (Saved ~25%)

This was the highest-ROI engineering investment. We added a semantic similarity cache in front of our LLM calls.

import hashlib
import numpy as np
from redis import Redis

class SemanticCache:
    def __init__(self, redis_url: str, similarity_threshold: float = 0.95):
        self.redis = Redis.from_url(redis_url)
        self.threshold = similarity_threshold

    def get_embedding(self, text: str) -> np.ndarray:
        """Use a cheap embedding model — not the expensive LLM."""
        # text-embedding-3-small costs ~$0.02/1M tokens
        return embed_model.encode(text)

    def lookup(self, query: str) -> str | None:
        query_emb = self.get_embedding(query)

        # Check against recent cached queries
        for key in self.redis.scan_iter("cache:emb:*"):
            cached_emb = np.frombuffer(self.redis.get(key))
            similarity = np.dot(query_emb, cached_emb) / (
                np.linalg.norm(query_emb) * np.linalg.norm(cached_emb)
            )
            if similarity >= self.threshold:
                response_key = key.decode().replace("emb:", "resp:")
                return self.redis.get(response_key).decode()
        return None

    def store(self, query: str, response: str, ttl: int = 3600):
        key_hash = hashlib.sha256(query.encode()).hexdigest()[:16]
        emb = self.get_embedding(query)
        self.redis.setex(f"cache:emb:{key_hash}", ttl, emb.tobytes())
        self.redis.setex(f"cache:resp:{key_hash}", ttl, response)

The 0.95 similarity threshold was critical. Too low and you get stale/wrong cached responses. Too high and your cache hit rate tanks. We tuned this per agent type — deployment agents got 0.97 (precision matters), monitoring summarizers got 0.92 (more tolerance for variation).

Cache hit rates after one week:

Infrastructure status queries: 67% hit rate
Deployment validation: 41% hit rate
Code review suggestions: 12% hit rate (too unique, as expected)

Strategy 3: Model Routing (Saved ~18%)

Not every task needs a frontier model. We built a lightweight router that directs requests to the cheapest capable model:

MODEL_TIERS = {
    "classification": "gpt-4o-mini",     # $0.15/1M input
    "extraction": "gpt-4o-mini",          # Simple structured output
    "summarization": "gpt-4o",            # Needs nuance
    "reasoning": "gpt-4o",               # Complex decisions
    "code_generation": "claude-sonnet-4-6", # Best for code
}

def route_request(task_type: str, complexity_score: float) -> str:
    """Route to cheapest capable model based on task type and complexity."""
    base_model = MODEL_TIERS.get(task_type, "gpt-4o")

    # Override: bump up if complexity is high
    if complexity_score > 0.8 and base_model.endswith("mini"):
        return base_model.replace("-mini", "")

    return base_model

We score complexity using a fast heuristic — input length, number of distinct entities, presence of code blocks, and whether the request involves multi-step reasoning. The heuristic itself runs on the cheapest model as a pre-filter.

Strategy 4: Context Window Management

This one's underrated. Instead of dumping the entire conversation history into every request, we implemented a sliding window with smart summarization:

def prepare_context(messages: list, max_tokens: int = 2000) -> list:
    """Keep recent messages verbatim, summarize older ones."""
    recent = messages[-4:]  # Last 2 exchanges verbatim
    older = messages[:-4]

    if not older:
        return recent

    # Summarize older context with a cheap model
    summary = summarize(older, model="gpt-4o-mini")

    return [{"role": "system", "content": f"Prior context: {summary}"}] + recent

This alone saved 15-20% on our longer agent conversations without any measurable quality drop.

Measuring What Matters

None of this works without observability. We track three metrics for every agent:

Cost per successful task — not just cost per request
Quality score — automated eval comparing optimized vs. unoptimized outputs
Latency — cache hits are 50-100x faster than LLM calls

We built a simple dashboard that shows these per agent, per day. When cost-per-task creeps up, we investigate. When quality drops below threshold, we roll back.

At RapidClaw, we've baked these patterns into our agent deployment pipeline so every new agent starts with sane defaults — compressed prompts, caching enabled, model routing configured. It's not glamorous work, but it's the difference between an AI agent project that's a cost center and one that actually scales.

The Bottom Line

After implementing all four strategies:

Metric	Before	After	Change
Daily token spend	~2M	~540K	-73%
Monthly cost	$1,840	$497	-73%
Avg response latency	2.3s	0.8s	-65%
Task success rate	91%	94%	+3%

The latency improvement was an unexpected bonus — cache hits are basically free and instant.

If you're deploying AI agents and haven't optimized token costs yet, start with prompt compression. It's the fastest win with zero infrastructure changes. Then add caching. Then model routing. Each layer compounds on the last.

We're building more of these optimization primitives into the RapidClaw platform — if you're running agents in production and want to stop bleeding money on tokens, check it out.

I'm Tijo, founder of RapidClaw. I write about the unglamorous but critical parts of running AI in production. Follow me for more posts on agent ops, infra, and building startups with AI.

DEV Community

Why We Built a Managed Platform for OpenClaw Agents (And What We Learned)

The Problem Nobody Talks About

What Running Agents in Production Actually Looks Like

Why OpenClaw

What RapidClaw Does Differently

What We Learned (The Honest Version)

Where We Are Now

Signals, Effects, and the Algebra Between Them

The Problem with Primitive Reactive State

Building Blocks: Unions and Pattern Matching

Signal State as an ADT

Custom State: Swapping the Lifecycle

Effects as a State Machine

Reactive Effects with watchEffect

Derived Values: Pull-Based Computation

The Pattern That Runs Through Everything

Get Started

How I Secured a Linux Server from Scratch: HNG DevOps Stage 0

Choosing a Cloud Provider

The Task

But First: Why Stage 0? Why Provision a Linux Server?

Step 1: Creating a Non-Root User

Step 2: Copying SSH Keys to the New User

Step 3: Passwordless Sudo for Specific Commands

Step 4: Hardening SSH Access

Step 5: Configuring UFW (Firewall)

Step 6: Getting a Domain Name

Step 7: Installing and Configuring Nginx

Step 8: The Oracle Cloud Firewall Problem

Step 9: SSL with Let's Encrypt

Final Verification

The Big Picture

I built a free salary lookup tool for the Canadian federal government

What it does

Tech stack

Why I built it

Some interesting salary facts

Why UI/UX Design is the Backbone of Mobile Development in 2026

Upgraded to Tailwind v4 — Config Files Are Gone

What Changes

Config Moved into CSS

@theme Naming Convention

Oxide Compiler

Migration Steps

Option A — one command

Option B — manual (Next.js / PostCSS)

Plugins Now Live in CSS

The outline-none Gotcha

v3 vs v4 at a Glance

Should You Upgrade Now?

FAQ

Sources

Gemma 4 vs Llama 4 vs Mistral Small 4: The 2026 Open-Source LLM Picks

Quick Take

MoE vs Dense

Context Window — 10M, 256K, 128K

Benchmarks

Multimodal — Images, Video, Audio

Licenses (Actually Read Before Shipping)

Edge Deployment Reality

How to Combine All Three

FAQ

Sources

CameraFool

What I Built

Demo

Code

ZheyUse / camerafool

CameraFool

Intro

How It Works

Main flow

Demo flow

How I Built It

Prize Category

A Pattern Sketch: Server-Sent Events as a Fanout Channel for Edge State

The shape of the problem

Architecture

SSE + Last-Event-ID: the part I find satisfying

Reactive Effects with `watchEffect`

The `outline-none` Gotcha

SSE + `Last-Event-ID`: the part I find satisfying