Forem: Daniel Gustafsson

One Redis Instance, Three Jobs: DevOps for AI Agents Without the Overkill

Daniel Gustafsson — Sat, 14 Mar 2026 17:51:47 +0000

I've built my share of microservices over the years. It usually ends with an architecture where every service has its own database, its own cache, its own queue, and a 200 line YAML file just to hold everything together in Docker Compose.

When I started experimenting with AI agents, I expected the same story. A vector database here, a message queue there, a cache service, a state store. But it turned out that Redis Stack handles all of it. And it simplifies operations more than I expected.

The entire infrastructure: one docker compose yaml

services:
  redis:
    image: redis/redis-stack:latest
    ports:
      - "6379:6379"
      - "8001:8001"  # RedisInsight
    volumes:
      - redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 5

  ollama:
    image: ollama/ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama_models:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:11434/api/tags || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 3

volumes:
  redis_data:
  ollama_models:

That is it. Two containers. No Postgres, no Pinecone, no RabbitMQ, no separate Memcached. Redis handles all three jobs and Ollama runs models locally.

What Redis actually does (and why it is elegant)

1. Conversation memory (checkpointer)

LangGraph needs somewhere to persist conversation state, such as which messages were sent, which tools were called, and what the results were. RedisSaver handles that:

with RedisSaver.from_conn_string("redis://localhost:6379") as checkpointer:
    checkpointer.setup()
    agent = create_react_agent(..., checkpointer=checkpointer)

Each thread (thread_id) gets its own history. Restart the agent and reconnect to the same thread? It picks up right where it left off. No manual serialization, no migrations.

From an ops perspective: these are just regular Redis keys. You can inspect them in RedisInsight, set TTL to automatically clean up old conversations, and monitor memory usage with INFO memory.

2. Long term memory (vector index)

RedisStore with a vector index gives you semantic search. Data is stored with embeddings and can be queried based on meaning, not exact string matching.

with RedisStore.from_conn_string(
    "redis://localhost:6379",
    index={
        "embed": embeddings,
        "dims": 768,
        "distance_type": "cosine",
        "fields": ["text"],
    },
) as store:
    store.setup()

The point from a DevOps perspective: you do not need to run a separate vector database. No Milvus, no Qdrant, no Weaviate. Redis Stack includes RediSearch out of the box, and it is more than sufficient for this kind of workload.

3. Semantic cache

The same question phrased slightly differently, like "what is WCAG?" versus "explain WCAG to me", produces the same answer. Instead of sending both through the LLM, we cache responses based on vector proximity:

from redisvl.extensions.llmcache import SemanticCache

cache = SemanticCache(
    name="llm_cache",
    redis_url="redis://localhost:6379",
    distance_threshold=0.1,
    ttl=3600,
)

A distance_threshold of 0.1 means queries with cosine distance ≤0.1 get cached responses. In practice, this means very similar questions. Where exactly to set this threshold depends on your embedding model (different models spread their vectors differently), so experiment. TTL of 3600 seconds automatically cleans up stale data.

Three completely different use cases. Same redis://localhost:6379.

No state in the application

This is the biggest win for operations. The agent itself is stateless. All state lives in Redis:

Conversation history: Redis (checkpointer)
Saved memories: Redis (vector index)
Cached responses: Redis (semantic cache)
Scan history: Redis (vector index)

This means you can:

Restart the agent without losing anything
Run multiple instances behind a load balancer
Scale horizontally without shared state in memory
Deploy new versions with zero downtime (rolling update)

In practice: docker compose restart agent and the user notices nothing.

Ollama as a local inference server

Ollama abstracts away model management. You pull a model once, then it is exposed as an HTTP API:

ollama pull qwen3.5:4b      # 2.5 GB, requires ~4 GB VRAM
ollama pull nomic-embed-text  # 274 MB, for embeddings

From the agent, it looks like any other API call:

model = ChatOllama(
    model="qwen3.5:4b",
    base_url="http://ollama:11434",  # Docker service name
)

No API key management. No rate limiting. No cost per token. Models run locally on your GPU.

Want to swap models? Change an environment variable:

CHAT_MODEL=qwen3.5:4b
EMBEDDING_MODEL=nomic-embed-text

No code changes. Ollama handles the rest.

Monitoring without extra tooling

Redis has built in monitoring that goes a long way:

# Memory usage
redis-cli INFO memory | grep used_memory_human

# Key count
redis-cli DBSIZE

# Live command stream
redis-cli MONITOR

# Slow queries
redis-cli SLOWLOG GET 10

RedisInsight (port 8001 in the docker compose) gives you a web UI to inspect keys, run queries, and view memory graphs. It is included in the redis-stack image.

For Ollama:

# Which models are loaded?
curl http://localhost:11434/api/tags

# How much VRAM is being used?
nvidia-smi

Need more? A Prometheus exporter exists for Redis (redis_exporter) and is straightforward to set up. But for most use cases, the built in tools are enough.

The cost model is different

With cloud AI (OpenAI, Claude, etc) you pay per token. That makes costs unpredictable, as an agent that makes many tool calls can get expensive.

With Ollama locally, the cost is fixed to your hardware. A machine with an RTX 4070 (12 GB VRAM) costs around $1,500 and runs qwen3.5:4b fast enough for production.

Rough math:

Cloud (e.g. Qwen 3 72b via OpenRouter): ~$0.005 per scan. 200 scans per day = $30 per month
Local (Qwen 3.5 4b): ~$0 per scan. Unlimited.

The difference becomes dramatic at volume. And the local model works well enough for tasks with clear context.

You can also mix them. Run locally for 90% of traffic and fall back to a cloud model for complex queries.

Backup and persistence

Redis Stack with appendonly yes (default in redis stack) gives you AOF persistence. Every write is logged to disk. On restart, everything is restored.

Backup:

# Snapshot
redis-cli BGSAVE
cp /data/dump.rdb /backup/redis.rdb

# Or copy AOF
cp /data/appendonly.aof /backup/

Ollama models are cached in /root/.ollama. Mount it as a Docker volume and models survive container restarts without needing to be downloaded again.

What I would do differently in production

Set maxmemory and eviction policy: Redis without a memory limit on a shared machine is a ticking time bomb. maxmemory-policy allkeys-lru automatically evicts the oldest entries.
TTL on everything that does not need to live forever: Cached LLM responses: 1 hour. Conversation history: 7 days. Scan history: keep.
Separate Redis instances per environment: Dev, staging, prod should not share data. Use key prefixes (dev:, staging:, prod:) or ideally separate Redis instances entirely. Avoid logical databases (/0, /1, /2). RediSearch and other modules only work on database 0, and clustering does not support them either.
Health checks in docker compose: Already included in the example above. If you add an agent service, use depends_on with condition: service_healthy so it does not start before Redis and Ollama are ready.
Log token usage: Even with local models, you want to know how much inference you are running. It helps with capacity planning.

Conclusion

What makes this stack attractive for DevOps is its simplicity. Two containers. No external state. Standard monitoring tools. Predictable cost.

Redis is no longer just a cache. With the Stack distribution, it replaces three or four services that would otherwise require separate operations. LangGraph abstracts away agent orchestration. Ollama turns LLM inference into a local service.

Bottom line: less to operate, less that can break, easier to debug.

Stack: Redis Stack, LangGraph, Ollama. Everything runs in Docker. You need a GPU with ≥8 GB VRAM for local models, or point Ollama at a cloud endpoint.

Published: March 2026 | Daniel Gustafsson

The Human Side of Web Accessibility, Beyond Compliance Checklists

Daniel Gustafsson — Tue, 13 Jan 2026 12:58:56 +0000

The Human Side of Web Accessibility: Beyond Compliance Checklists

1.3 billion people live with some form of disability worldwide. That's not a statistic - that's your users, your customers, your colleagues, and eventually, all of us.

When we talk about accessibility in tech, we often jump straight to WCAG criteria, automated scanners, and compliance audits. But before we dive into the code, let's talk about why this matters so deeply.

The Temporary Nature of Ability

Here's something that changed how I think about accessibility:

"Disability is a mismatch between a person and their environment."

You don't need a permanent condition to experience this mismatch:

Holding a baby with one arm - temporarily one-handed
Bright sunlight on your screen - temporarily low vision
Loud environment - temporarily deaf
Broken arm - temporarily motor impaired
Aging - gradually everything

When you build for accessibility, you're building for everyone - including your future self.

Real Stories, Real Impact

The Blind Developer Who Tested My Code

I once shipped a "beautiful" dashboard with drag-and-drop widgets. A blind developer on our team tried to use it. His screen reader announced:

"Button. Button. Button. Clickable. Image. Button."

40 minutes of his day - wasted. Not because he couldn't do his job, but because I hadn't done mine.

The CEO With RSI

A company executive developed repetitive strain injury. Suddenly, using a mouse was painful. She needed to navigate everything with a keyboard. Our application - which we thought was modern and polished - became unusable for her.

The Parent in a Meeting

A developer told me: "I need captions on your tutorial videos. Not because I'm deaf - because my toddler is sleeping in the next room."

The Business Case (Because Sometimes You Need It)

Let's be honest: sometimes empathy alone doesn't get budget approval. Here's what does:

Impact	Numbers
Global disabled population	1.3 billion
Spending power in the US alone	$490 billion
Target.com accessibility lawsuit	$6 million settlement
Domino's Supreme Court case	Company lost, forced to remediate

Accessibility isn't charity. It's market access.

From Empathy to Action: The Technical Implementation

Now that we understand why, let's talk how.

At Holm Digital, we built an open-source ecosystem that bridges the gap between technical WCAG validation and legal compliance.

1. Automated Scanning That Speaks Human

Most scanners tell you:

X WCAG 1.4.3 violation: contrast ratio 3.2:1 < 4.5:1

Our scanner tells you:

X Low contrast makes this text hard to read

Legal: EN 301 549 Clause 9.1.4.3 | Swedish DOS-lagen 12 P
Risk: HIGH - This affects users with low vision
Fix: Darken the text color from #767676 to #595959

Impact: ~8% of your users may struggle to read this

The difference? Context. Risk. Human impact.

2. Components That Don't Let You Fail

Instead of teaching every developer ARIA patterns, we built React components that are accessible by default:

import { Button, FormField, Dialog } from '@holmdigital/components';

// This automatically handles:
// - Correct ARIA attributes
// - Focus management  
// - Keyboard navigation
// - 44px touch targets (not 32px!)
// - Color contrast

<FormField 
  label="Email Address"
  type="email"
  required
  helpText="We'll never share your email."
/>

No special knowledge required. Just use the component.

3. Regulatory Mapping for Non-Technical Stakeholders

Legal teams don't care about aria-labelledby. They care about:

Are we compliant with the European Accessibility Act?
What's our exposure under Section 508?
Can we prove due diligence?

Our standards database maps every technical rule to:

WCAG 2.1 criteria (A, AA, AAA)
EN 301 549 clauses (EU standard)
National laws (DOS-lagen, Section 508, AODA, BITV, RGAA)
Risk levels (critical, high, medium, low)

Now your compliance report speaks their language.

The Practical Workflow

1. Start With Automated Checks

# Add to your CI pipeline
npx hd-a11y-scan https://your-staging-url.com --ci --lang en

This catches ~30% of issues automatically. Not everything, but a solid baseline.

2. Use Accessible Components

Don't build buttons, forms, and dialogs from scratch. Use libraries that handle accessibility for you.

3. Test With Real Assistive Technology

Once a month, try this:

Navigate your app with only a keyboard
Turn on VoiceOver (Mac) or NVDA (Windows) and close your eyes
Zoom to 400% and try to complete a task

4. Include Disabled Users in Testing

Invite people who use assistive technology daily to test your product. Pay them - their expertise is valuable.

Common Objections (And Counter-Arguments)

"We don't have disabled users"

You don't know you have disabled users. If your analytics show none, it's likely they left because they couldn't use your product.

"We'll add accessibility later"

Retrofitting accessibility is 10x more expensive than building it in.

"Automated tools say we're fine"

Automated tools catch 30% of issues. The other 70% require human judgment.

Resources

Accessibility Wiki - Deep dives on regulations and compliance
@holmdigital/engine - Regulatory scanning
@holmdigital/components - Accessible React components
WebAIM - Excellent tutorials

The Ask

Next time you're building a feature, take 5 extra minutes to:

Add proper labels to your form fields
Test keyboard navigation
Check color contrast
Add alt text to images

Accessibility is not about perfect compliance. It's about gradually making things better, one commit at a time.

Connect:

HolmDigital - Accessibility consulting
Accessibility Wiki - Free documentation
GitHub - Open source tools

Have you encountered accessibility challenges in your projects? I'd love to hear your stories in the comments.

Building a Regulatory-Compliant Accessibility Scanner: From WCAG to Legal Compliance

Daniel Gustafsson — Sun, 11 Jan 2026 20:45:57 +0000

Building a Regulatory-Compliant Accessibility Scanner: From WCAG to Legal Compliance

Most accessibility tools tell you what's wrong. But when regulators come knocking, they don't ask "Did you fix the color contrast?" — they ask "Are you compliant with EN 301 549 clause 9.1.4.3?"

This guide walks you through three open-source packages I built to bridge that gap: from technical WCAG validation to legal compliance reporting, with ready-to-use React components that are accessible by default.

The Problem We're Solving

Here's a typical accessibility tool output:

❌ color-contrast: Elements must have sufficient color contrast ratio
   Expected: 4.5:1, Actual: 3.2:1

But here's what a compliance auditor needs:

❌ WCAG 2.1 Success Criterion 1.4.3 (Level AA)
   EN 301 549 Reference: 9.1.4.3
   Swedish DOS-lagen: 12 § Lag (2018:1937)
   Risk Level: HIGH
   Remediation: Increase foreground/background contrast to minimum 4.5:1

Let's build this.

The Three Packages

Package	Purpose	npm
`@holmdigital/engine`	Accessibility scanner + CLI
`@holmdigital/standards`	Regulatory mapping database
`@holmdigital/components`	Accessible React components

Part 1: The Quick Win — CLI Scanning

Install and scan any website in seconds:

npx hd-a11y-scan https://your-website.com --lang en --ci

Output:

🔍 Scanning https://your-website.com...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  HolmDigital Regulatory Accessibility Report
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  Score: 72/100
  Violations: 4 critical, 8 serious, 12 moderate

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  CRITICAL: Missing form labels
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  📋 WCAG 2.1: 1.3.1 (Level A)
  📋 EN 301 549: 9.1.3.1
  📋 Section 508: 1194.22(n)

  ⚠️  Risk: CRITICAL

  💡 Fix: Associate each input with a <label> element using 
     the 'for' attribute matching the input's 'id'.

  📍 Elements affected:
     - <input type="email" class="newsletter-input">
     - <input type="text" class="search-box">

CLI Options

# Generate PDF report
npx hd-a11y-scan https://example.com --pdf report.pdf

# Mobile viewport
npx hd-a11y-scan https://example.com --viewport mobile

# Swedish language output
npx hd-a11y-scan https://example.com --lang sv

# JSON for CI/CD pipelines
npx hd-a11y-scan https://example.com --json > results.json

Part 2: Programmatic Integration

For deeper integration, use the scanner programmatically:

import { RegulatoryScanner, setLanguage } from '@holmdigital/engine';

// Set language context (affects rule descriptions)
setLanguage('en');

async function auditWebsite(url: string) {
  const scanner = new RegulatoryScanner({
    url,
    failOnCritical: true,  // Throws if critical issues found
    viewport: { width: 1920, height: 1080 }
  });

  try {
    const result = await scanner.scan();

    console.log(`
      ✅ Accessibility Score: ${result.score}/100
      📊 Total Issues: ${result.violations.length}
      ⚠️  Critical: ${result.violations.filter(v => v.risk === 'critical').length}
    `);

    // Group by WCAG criterion
    const byWcag = result.violations.reduce((acc, v) => {
      const key = v.wcagCriterion;
      acc[key] = (acc[key] || []).concat(v);
      return acc;
    }, {});

    return { score: result.score, byWcag };
  } catch (error) {
    console.error('Critical accessibility violations found!');
    process.exit(1);
  }
}

// Usage
auditWebsite('https://your-site.com');

Real-World Example: GitHub Actions Integration

name: Accessibility Audit

on:
  pull_request:
    branches: [main]

jobs:
  a11y-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install & Build
        run: |
          npm ci
          npm run build
          npm run start &
          sleep 5

      - name: Run Accessibility Scan
        run: npx hd-a11y-scan http://localhost:3000 --ci --lang en

This fails the PR if any critical accessibility violations are found.

Part 3: The Standards Database

The real magic is in the regulatory mapping. Here's how it works under the hood:

import { 
  getEN301549Mapping, 
  getRulesByLanguage 
} from '@holmdigital/standards';

// Get the EN 301 549 mapping for a WCAG criterion
const mapping = getEN301549Mapping('1.4.3');

console.log(mapping);
// {
//   wcagCriterion: '1.4.3',
//   wcagLevel: 'AA',
//   en301549Clause: '9.1.4.3',
//   description: 'Contrast (Minimum)',
//   risk: 'high',
//   remediation: {
//     description: 'Ensure text has a contrast ratio of at least 4.5:1',
//     technicalGuidance: 'Use CSS to adjust foreground or background colors...'
//   }
// }

// Get all rules for a specific language/region
const swedenRules = getRulesByLanguage('sv');
const usRules = getRulesByLanguage('en-us');

// Each rule includes national law references
console.log(swedenRules[0].nationalLaw);
// {
//   name: 'DOS-lagen',
//   reference: 'Lag (2018:1937) 12 §',
//   description: 'Lagen om tillgänglighet till digital offentlig service'
// }

Supported Regulations

Language	Regulation	Coverage
`en`	EN 301 549, WCAG 2.1	EU Generic
`en-us`	Section 508, ADA	United States
`en-ca`	AODA	Canada
`en-gb`	PSBAR	United Kingdom
`sv`	DOS-lagen	Sweden
`de`	BITV 2.0	Germany
`fr`	RGAA	France
`nl`	Digitoegankelijk	Netherlands
`es`	UNE 139803	Spain

Part 4: Accessible React Components

Stop reinventing the wheel. These components handle ARIA, focus management, and keyboard navigation for you:

import { 
  Button, 
  FormField, 
  Dialog, 
  Heading,
  SkipLink 
} from '@holmdigital/components';

function ContactForm() {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <>
      {/* Skip link for keyboard users */}
      <SkipLink href="#main-content">
        Skip to main content
      </SkipLink>

      <main id="main-content">
        {/* Semantic headings with enforced hierarchy */}
        <Heading level={1}>Contact Us</Heading>

        <form>
          {/* Auto-generated labels, error states, ARIA */}
          <FormField
            label="Email Address"
            type="email"
            required
            autoComplete="email"
            helpText="We'll never share your email."
            error={emailError}
          />

          <FormField
            label="Message"
            type="textarea"
            required
            minLength={10}
          />

          {/* Accessible button with loading state */}
          <Button 
            variant="primary" 
            type="submit"
            loading={isSubmitting}
          >
            Send Message
          </Button>
        </form>

        {/* Focus-trapped modal dialog */}
        <Dialog
          open={isOpen}
          onClose={() => setIsOpen(false)}
          title="Message Sent"
        >
          <p>Thank you! We'll respond within 24 hours.</p>
          <Button onClick={() => setIsOpen(false)}>
            Close
          </Button>
        </Dialog>
      </main>
    </>
  );
}

What's Handled Automatically

Feature	Component	WCAG Criterion
Focus trapping	`Dialog`, `Modal`	2.4.3
Escape to close	`Dialog`, `Modal`	2.1.2
Label association	`FormField`	1.3.1
Error announcement	`FormField`	3.3.1
Heading hierarchy	`Heading`	1.3.1
Skip navigation	`SkipLink`	2.4.1
Visible focus	All components	2.4.7
Color contrast	All components	1.4.3

The Development Story

Why I Built This

I was working with a Swedish agency that needed to prove compliance with DOS-lagen (Sweden's digital accessibility law). Standard tools gave them WCAG violations, but auditors wanted EN 301 549 clause references with Swedish legal context.

Existing solutions were either:

Too technical (WCAG-only, no legal mapping)
Too expensive (enterprise SaaS pricing)
Too manual (consultants doing spreadsheet mappings)

Architecture Decisions

1. Monorepo Structure

packages/
├── engine/      # Scanner + CLI (depends on standards)
├── standards/   # Regulatory database (no deps)
└── components/  # React UI library (no deps)

Each package is independently publishable but designed to work together.

2. Build Tooling

We use tsup for building because:

Single config for CJS, ESM, and DTS
Fast builds (Rollup under the hood)
Tree-shakeable output

// tsup.config.ts
export default {
  entry: ['src/index.ts'],
  format: ['cjs', 'esm'],
  dts: true,
  clean: true
}

3. Exports Configuration

A lesson learned the hard way — always put types first:

{
  "exports": {
    ".": {
      "types": "./dist/index.d.ts",
      "import": "./dist/index.mjs",
      "require": "./dist/index.js"
    }
  }
}

If types comes after import, some bundlers won't find your TypeScript definitions.

4. i18n Architecture

All user-facing strings are externalized:

// src/i18n/index.ts
import en from '../locales/en.json';
import sv from '../locales/sv.json';
// ... other locales

let currentLang = 'en';

export function setLanguage(lang: string) {
  if (locales[lang]) {
    currentLang = lang;
  }
}

export function t(key: string): string {
  return locales[currentLang][key] ?? key;
}

Getting Started

Install

# CLI scanning (no install needed)
npx hd-a11y-scan https://your-site.com

# For programmatic use
npm install @holmdigital/engine

# For React components
npm install @holmdigital/components

# For regulatory database only
npm install @holmdigital/standards

Quick Integration Checklist

Add CI scanning to catch regressions
Replace form components with accessible versions
Add skip links for keyboard navigation
Generate PDF reports for compliance documentation

What's Next

[ ] Browser extension for on-page scanning
[ ] VS Code extension for inline warnings
[ ] More national regulations (Australia, India, Japan)
[ ] Automated fix suggestions with code generation

Resources

GitHub: github.com/holmdigital/a11y-hd
NPM:

Built with ❤️ by Holm Digital — Making accessibility compliance actually achievable.

Did you find this useful? Drop a comment below or connect with me on LinkedIn. I'd love to hear about your accessibility challenges!