DevLoop — Boring parts of shipping software, done right.

// for software teams · v0.4 · feature/oauth

devloop@prod ~ /workspace/orders-svc · branch: main · v2.4.1

whoami

devloop · repos, releases, deploys, all in one place.

describe

Built for software teams that prefer fewer dashboards

and more shipping.

try-it

Try DevLoop → Watch the deploy log →

+──────────────────────────────────────────────────+ │ built for terminals · runs in the browser · ok │ +──────────────────────────────────────────────────+

deploy.log · main · live

streaming · events: 0 · uptime: 99.98% · region: eu-central-1

// $ ls ./features

What it does (no fluff)

Six modules. Each one is something a dev team actually needs daily. No "AI co-pilots for synergy". Just tools that work.

~/repos

All your repositories — one view. Branches, tags, releases.

● 24 repos indexed · last sync 12s ago

~/branches

Compare, merge, delete. With a kanban view if you want it.

⚠ 3 stale branches (>30d) — prune?

~/commits

Search, blame, revert. Author avatars and timestamps.

i 12,847 commits indexed · search < 80ms

~/pull-requests

Diff viewer with inline comments. Approvals. Merges.

● 8 open · 14 awaiting review · 2 conflicting

~/ci-cd

Triggers on commit. Status across all repos. Pipeline history.

● last 50 builds: 48 pass / 2 flake

~/tasks

Kanban that syncs with git activity. Tasks linked to commits.

i auto-linked: 94% · stale tickets: 7

// how it sees a deploy

From commit to verified in 5 steps

Every step is observable. Every failure is recoverable. You don't need to ssh into a box at 2am to figure out what happened.

””€”€”€”€” │ ¥ │ │git │ └────┘

[1/5]

commit

webhook fires
devloop ingests

””€”€”€”€” │ ™ │ │ CI │ └────┘

[2/5]

CI runs

lint · test · build
parallel where it can

””€”€”€”€” │ │ │ PR │ └────┘

[3/5]

review

diff · comments
approvals · merge

””€”€”€”€” │ ▶ │ │ DEP│ └────┘

[4/5]

deploy

staging → prod
blue/green if set

””€”€”€”€” │ “ │ │ OK │ └────┘

[5/5]

verify

smoke tests
health probes

Every step is observable. · Every failure is recoverable.

// $ tail -f /var/log/devloop

Live deploy log & commit graph

This isn't a screenshot. The log on the left streams. The graph on the right is rendered from a real repo shape. Nothing is fake about the activity feel.

tail -f deploy.log · orders-svc · main

git log --graph --oneline --all · last 14 commits

● CI: passing · 124 builds this week · 96% pass rate · last deploy: 14m ago · mean build: 4m 32s · p95 deploy: 2m 18s · flaky test rate: 0.8%

// $ man devloop

Things DevLoop actually does

Three of the screens you'll be staring at the most. Nothing here is a marketing rendering — these are the real UIs.

Diff viewer that doesn't suck

go · pkg/orders/handler.go · +14 / -8

pkg/orders/handler.go PR #284 · + approved by ari

4242func (h *Handler) CreateOrder(w http.ResponseWriter, r *http.Request) {
  ctx := r.Context()
    body, err := io.ReadAll(r.Body)
    if err != nil {
        http.Error(w, "bad body", 400)
        return
    }
  var req CreateOrderReq
  if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
      h.logger.Warn(ctx, "invalid request", "err", err)
      respondErr(w, http.StatusBadRequest, ErrBadRequest)
      return
  }
  // trace boundary for distributed retries
  ctx = trace.WithSpan(ctx, "orders.create")
  order, err := h.svc.Create(ctx, req)
  if err != nil { respondErr(w, 500, err); return }
  respondJSON(w, http.StatusCreated, order)
5255}

@ari2h ago · on line 46

Nice — finally killed that io.ReadAll footgun. Can you also add a max-body limit middleware? saw a 14MB payload last week.

@noa1h ago · on line 50

Trace span name — should match the naming convention (service.operation). I'd rename to "orders.handler.create".

@tom23m ago · on line 50

Will rename in a follow-up. Filed #291. Not blocking this PR.

Conflict resolution UI

3 conflicts in 1 file · pkg/auth/middleware.go

their origin/main @b8e4d72

func AuthMiddleware(h http.Handler) http.Handler { return http.HandlerFunc(func(w, r) { token := r.Header.Get("X-Token") if token == "" { http.Error(w, "unauth", 401) return } h.ServeHTTP(w, r) }) }

yours feature/oauth @c1a7e83

func AuthMiddleware(h http.Handler) http.Handler { return http.HandlerFunc(func(w, r) { token := r.Header.Get("X-Token") token := extractBearer(r) if token == "" { respondErr(w, 401, ErrUnauth) return } h.ServeHTTP(w, r) }) }

merged resolved by devloop

func AuthMiddleware(h http.Handler) http.Handler { return http.HandlerFunc(func(w, r) { token := extractBearer(r) if token == "" { respondErr(w, 401, ErrUnauth) return } h.ServeHTTP(w, r) }) }

↑ ↓ nav conflict · T take theirs · Y take yours · B take both · ˜ E open in editor · accept merge

CI/CD pipeline view

build #1284 · 7e8a912 · failed at smoke

build

go 1.22 · linux/amd64

passed · 1m 04s

test

428 specs · 2 skipped

passed · 2m 41s

deploy-staging

eu-central-1 · v2.4.2-rc.1

deployed · 48s

smoke

12 checks · 1 failed

failed · 19s

deploy-prod

blocked by smoke

waiting

FAIL smoke/orders_create_test.go:118 · POST /v1/orders returns 201

expected status: 201

actual status: 500 Internal Server Error

body: {"error":"db: connection refused","trace":"a3f9c12-orders-create"}

→ likely cause: staging-db rolled back during canary. autopaused deploy.

→ suggested action: re-run smoke after staging-db green for 60s.

// who runs this

Built for the kind of team that ships

If you're running 4+ repos and you've ever needed to open 6 browser tabs to figure out what broke prod — yeah, this is for you.

~/small-eng-teams

2-30 engineers. Multiple repos. One dashboard.

Skip the 3 standups about who deployed what. DevLoop shows the whole team's git activity, CI runs, and open PRs on one page.

avg setup time: 12 min · breakeven vs. current stack: week 2

~/technical-founders

Build, deploy, monitor. Stop juggling 8 tools to ship.

You don't need GitHub + Linear + Vercel + CircleCI + Sentry + a Notion roadmap to ship a SaaS. Cut the surface area. Keep your context.

replaces: ~4 tools · keeps: one mental model

~/contractor-teams

Multiple clients, multiple codebases, one workspace per client.

Each client gets their own DevLoop workspace. Permissions are scoped per-workspace. No more sharing GitHub orgs.

workspaces: unlimited · client-facing read-only: yes

// $ cat integrations.toml

Connects to what you already run

DevLoop doesn't want to replace your git host. It wants to be the dashboard on top of it.

integrations.toml · readonly

[git-hosts]

connects = [ "GitHub"·"GitLab"·"Bitbucket" ]

[deploy-targets]

connects = [ "Vercel"·"Netlify"·"Fly.io"·"AWS"·"Render" ]

[ci-providers]

connects = [ "CircleCI"·"GitHub Actions"·"GitLab CI" ]

[notifications]

connects = [ "Slack"·"Discord"·"Email" ]

[planned]

connects = [ "Linear"·"Sentry"·"PagerDuty"·"Datadog" ]

--webhook-signing = "hmac-sha256" · --rate-limit = "1k/min" · --retry-policy = "exponential, max=5"

// $ devloop --help | grep faq

Things you'll probably ask

If your question isn't here, the docs cover it. If the docs don't, open an issue. We'll write you back, not a bot.

A:Yes. We ship a docker-compose for single-node and a Helm chart for k8s. Postgres + Redis + an object store (S3-compatible) and you're up. Self-host runs the same binary as the cloud — no feature gating, no separate "community edition".

A:Yes. You can define paths (e.g. apps/web, packages/api) as logical sub-projects with their own pipelines, owners, and changelogs. Conditional CI on path changes is built-in. Turborepo and Nx are detected automatically.

Tested up to ~40 sub-projects in a single tree. Beyond that you'll want to talk to us about index sharding.

A:Secrets are encrypted at rest with AES-256-GCM, keys per-workspace, optional BYOK via AWS KMS or HashiCorp Vault. Secrets are scoped per environment (dev/staging/prod) and per repo. CI gets them via short-lived signed tokens — they never sit in env files on disk.

You can also opt out entirely and just point us at your existing Vault. We won't touch the secret values — only check they exist.

A:It doesn't replace them. DevLoop reads from your existing GitHub/GitLab/Bitbucket repos. The difference is the surface:

GitHub is excellent at hosting code and running Actions, but its dashboard was built for individuals scrolling notifications. DevLoop is built for a team looking at one screen together — your repos, your builds, your deploys, your tasks, in one terminal-shaped UI.

You keep GitHub. You add DevLoop on top.

DevLoop — repos, builds, deploys, all in one place.