I built an open-source ops automation platform — here's what I learned

Mohammed — Tue, 14 Apr 2026 19:43:20 +0000

For the past few months I've been building Infralane, an open-source platform for DevOps and IT operations teams. Think of it as a service desk that actually understands infrastructure workflows — not just a form that creates a ticket and throws it into a queue.

## Why I built it

Every DevOps team I've worked on has the same problem: access requests come through Slack, deployments are tracked in spreadsheets, and incident response is a mix of PagerDuty alerts and "who's online?" messages. There are
enterprise tools for this but they're expensive and take forever to set up.

I wanted something where:

Requests come in with the right fields already defined (not "describe your issue")
Automation rules handle the boring parts (assign, tag, notify, escalate)
Sensitive actions need approval before executing
Everything is auditable

## What it looks like

## How the automation engine works

You create rules with a trigger, conditions, and an action.

Trigger → when something happens

Conditions → match against ticket fields

Action → do something

Some real examples:

Trigger: Ticket created
Conditions: type = incident AND priority = urgent

Action: Assign to on-call operator

Trigger: SLA breached

Conditions: type = incident AND priority = high
Action: Escalate priority to urgent

Trigger: Ticket created

Conditions: type = deployment AND environment = production
Action: Require approval before proceeding

There are 8 action types: assign, change status, change priority, add tag, notify, Slack message, webhook, and escalation chains.

### Under the hood

The worker is a separate Node.js process that polls for queued jobs every 5 seconds. It uses SELECT FOR UPDATE SKIP LOCKED in PostgreSQL for atomic job claiming — no Redis needed.

Jobs get exponential backoff on failure and move to a dead-letter queue after 3 attempts. Every state transition is logged so you can trace exactly what happened and why.

## Approval workflows

This is the feature I think makes it more than just another ticketing tool.

When a rule has "requires approval" enabled, the automation job pauses in a PENDING_APPROVAL state. The ticket gets locked — operators can't resolve or close it until someone approves or rejects.

This means you can enforce rules like "any production deployment needs approval" at the system level. No one can skip the approval by just resolving the ticket directly.

## Three-tier role system

Not every user should see everything:

| Role | What they can do |

|------|-----------------|
| Requester | Submit tickets, view their own, comment, rate resolved tickets |

| Operator | Work all tickets, assign, change status, approve/reject, view reports |

| Admin | Everything above + manage settings, automation rules, team, integrations |

## What I learned building it

### Dedup is harder than it looks

My first approach used a unique constraint on (ruleId, ticketId, trigger). That's too coarse — the same rule should fire multiple times on the same ticket for repeated status changes.

I ended up using SHA-256 hash keys derived from rule + ticket + trigger + context. The unique constraint on the hash handles race conditions — if two concurrent emissions both pass the check, the database rejects the duplicate.

### Automation needs cascade prevention

If an automation rule changes a ticket's status, and there's another rule that triggers on status changes... you get infinite loops.

The fix: executors write directly to Prisma, not through the service functions that emit triggers. Automation actions never re-trigger other automation rules.

### Gates must block all paths

I built approval workflows that block automation execution. Then someone pointed out: what's stopping an operator from just resolving the ticket manually while the approval is pending?

Nothing was. So I added ticket locking — while an approval is pending, the ticket's status can't be changed through any path. The API returns 409 PENDING_APPROVAL. The UI shows a warning instead of the status dropdown.

### Dev fallbacks are production footguns

I had a dev fallback for the session signing secret — if the env var was missing, it used a hardcoded default. One bad deployment config and every session is forgeable.

Now it throws a fatal error in production if the secret is missing. Fail fast, not fail silently.

## Stack

| Layer | Technology |

|-------|-----------|
| Frontend | Next.js 15, React, TypeScript, Tailwind CSS |

| Backend | Next.js API Routes, Prisma ORM |

| Database | PostgreSQL 16 |
| Auth | HMAC-SHA256 session cookies + Slack OAuth |

| Worker | Standalone Node.js process |

| Real-time | Server-Sent Events (SSE) |

## Self-host it


bash                                                   
  git clone https://github.com/infralaneapp/infralane.git
  cd infralane
  docker compose up -d

  App runs at http://localhost:3000. First user to register becomes admin.                                                                                                                                                            

  What's next                                                                                                                                                                                                                         

  The core is stable but there's plenty to improve. Some open issues:                                                                                                                                                                 

  - Test Slack integration against a real workspace                                                                                                                                                                                   
  - Implement actual SMTP email sending (currently a stub)  
  - Password reset flow                                                                                                                                                                                                               
  - Rate limiting on more endpoints                         

  MIT licensed. If you're running ops workflows and have opinions about what's missing, I'd genuinely like to hear them.                                                                                                              

  GitHub: github.com/infralaneapp/infralane

DEV Community: Mohammed

I built an open-source ops automation platform — here's what I learned