DEV Community: Francesco Meli

crew: run just the services you're working on - wired to the rest

Francesco Meli — Sun, 09 Aug 2026 09:42:43 +0000

You have fifteen services. Today you're touching two.

If your stack is more than a couple of services, you know this moment. You want to run web and api locally to work on a feature - but api talks to auth, billing, a queue, a search cluster, and three other internal services. So what are your options?

Run the whole thing in Docker Compose. Now you're maintaining a docker-compose.yml that mirrors production (and drifts from it), booting thirteen containers you don't care about, feeding a daemon and disk, and waiting on rebuilds - all to change two services.
Point your two local services at staging by hand. Edit env files, swap URLs to localhost for the one peer you're running, remember to change them back. Every time.

Both are chores. I wanted a third option, so I built crew.

Every service is a switch

The whole idea fits in one line: on = local, off = remote.

Flip a service on → crew runs it natively and rewrites every peer that talks to it to point at your localhost.
Leave it off → it stays on its real deployed environment (qa / staging / prod), and its callers keep hitting the real host.

The "slice" you run locally is just which switches are on - one service, or the whole stack, or anything in between. And flipping a switch flips the wiring for you, read straight from the .env files you already ship.

crew start env=staging     web   [x] on  → http://localhost:3000
                           api   [x] on  → http://localhost:4000   (web now calls this)
                           auth  [ ] off → https://auth.staging.acme.dev
                           …     [ ] off → deployed staging

Here's crew start in practice - pick a connected slice from the dependency graph, run it, watch the labelled logs:

How the wiring works

crew doesn't ask you to declare a topology. It derives the dependency graph from your env files: each project gets a match (the host(s) it's deployed under, per env) and a local (its localhost URL). When a URL in one project's env matches another project's match host, that's an edge.

At crew start, for each service you switched on, crew reads its env file, rewrites the URLs of any other on-services to their local value, writes the result to a throwaway file, and hands that path to your start command via {envfile}. Services you left off keep their real URLs. Nothing in your repo is touched - the wired copy lives in ~/.config/crew/tmp/ and is deleted on teardown.

Because the env each service resolves to is derived from the graph (not a static setting), the same shared config serves multiple teams correctly - the frontend team and the SDK team each get the right remote env for the services they didn't run.

You don't hand-write the config

crew config is a visual editor: pick a project's folder and crew auto-fills the mechanical parts it can read from your package.json, lockfiles and .envs - type, runner, start command, env-file path. You fill in the URLs (local port + deployed host per env). Out comes one readable, committable config.json with no secrets in it.

{
  "projects": {
    "web": {
      "path": "web",
      "type": "frontend",
      "tasks": { "start": "dotenv -e {envfile} -- npm run dev" },
      "env": ".envs/{env}.env",
      "match": { "staging": "web.staging.acme.dev", "prod": "web.acme.dev" },
      "local": "http://localhost:3000"
    },
    "api": {
      "path": "api",
      "tasks": { "start": "uvicorn app:main --reload --env-file {envfile}" },
      "env": ".envs/{env}.env",
      "match": { "staging": "api.staging.acme.dev", "prod": "api.acme.dev" },
      "local": "http://localhost:4000"
    }
  }
}

The same slice, three ways

The picked set is remembered, so the other two commands open exactly what you started:

Command	What it opens
`crew start env=staging`	the dev servers (streamed, per-project-colored logs; Ctrl-C tears the whole group down)
`crew workspace`	one multi-root VS Code window with every picked repo side by side
`crew claude`	one Claude Code session over the set, history kept per group of repos

Why not just Docker Compose?

crew runs your slice natively and borrows the rest from their deployed envs - a different category from the usual tools:

	crew	Compose	Tilt	mirrord	overmind
Runs your slice natively	✅	❌	❌	✅	✅
Rest of stack = real remote	✅	❌	❌	✅	❌
Wiring from	`.env` files	compose file	k8s manifests	cluster intercept	-
Infra required	none	daemon	k8s	k8s	none

crew sits between plain process-runners (overmind, foreman, mprocs) and remote-wiring tools (mirrord, Telepresence): the native-slice-plus-real-remote of the latter, without the cluster, daemon, or containers - just URL swaps in the env files you already have.

When Docker is the right call: you need full-stack isolation, byte-for-byte prod/CI parity, or your services can't run natively. crew doesn't replace that. It replaces the daily loop of flipping a couple of services on and letting everything else stay remote.

The honest caveats

You need shared remote environments to borrow from. If you don't have a staging/qa the "off" services can run on, a full-stack tool fits better.
crew doesn't proxy. If staging is down, your off-services are unreachable - same as calling staging directly. Turn them on to run locally.
POSIX only (macOS + Linux) - teardown relies on process groups so reparented dev-server children actually die.
No task graph, no ordering, no caching. crew fans out one task at a time; that's make/turbo/nx territory, on purpose.

Zero dependencies, by design

crew is one file of Node built-ins - no runtime dependencies, no build step, no bundler. The source is what runs, and its own parallel process runner handles the fan-out and teardown. So it installs instantly:

npx @pinkynrg/crew          # or: npm i -g @pinkynrg/crew

Try it

The site has a live version of that on/off switchboard: flip services on and off and watch the URLs and wiring rewire as you go. Source, docs, and the full config reference are on GitHub.

I built crew for my own stack. If you've solved the run-a-slice-locally problem a different way, I'm curious which trade-offs you landed on.

PR Reviews: The Silent Team Killer? Let's Talk About It 🔍

Francesco Meli — Fri, 08 Aug 2025 21:00:12 +0000

Hey dev community! 👋

I've been thinking about something that's been bugging me (and probably you, too): PR reviews. Not the technical part, I'm referring to the human aspect.

The Daily Drama We All Know

You know the drill:

PRs sitting for days while everyone assumes "someone else will review it"
@channel's messages flooding Slack: "Can someone please review my urgent PR?"
That one teammate who cranks out massive 500 line PRs that nobody wants to touch
The guilt when you realize you've been the bottleneck on three different PRs

Sound familiar? 😅

My Experiment: A Different Approach

Instead of more pings and notifications, I built a simple bot that sends one daily summary to our team's Slack channel every morning. We split our week into:

Monday, Wednesday, Friday: Async PR reviews - everyone finds time to review on their own schedule
Tuesday, Thursday: Sync PR reviews - we have a 1-hour meeting before lunch where PR owners demo their changes live, then a randomly assigned presenter shares their screen to walk through the code

The daily message looks like this:

PR Updates for our team
[repo-name] Feature: User authentication
Reviewable | Async | Author: @john | Presenter: @paul | Updated: 2025-08-05 | Files: 12

[repo-name] Fix: Critical bug in payment flow  
Ready to merge | Sync | Author: @sarah | Presenter: @mike | Files: 3

Here's what each part means:

Async vs Sync: The PR owner decides whether to demo changes to everyone (sync) or let people review individually (async)
Random Presenter: For sync reviews, someone is randomly assigned to actively examine the code and ask questions - this ensures at least one person is deeply engaged with each PR
PR States:
- Reviewable = No conflicts, ready for team feedback
- Ready to merge = Has enough approvals, feedback for the owner
- Conflicting = Needs attention before review can happen
- Mergeable with conflicts = Approved but conflicts appeared after approval (someone else merged something)

File Counts: Shows total files changed, but separates out "noise" like tests and snapshots (configurable) so teams get a real sense of the change scope

What Happened Surprised Me

Instead of faster reviews, something more interesting happened: we developed a ritual.

The team started naturally checking this message every morning with coffee. People began budgeting time for reviews instead of treating them as interruptions. Large PRs became less common because the daily visibility made everyone conscious of their PR sizes.

It wasn't about speed; it was about sustainable habits.

The Questions I'm Wrestling With

This got me thinking about PR reviews differently:

Is the real problem coordination, or something deeper?

Are we treating symptoms (slow reviews) instead of causes (unclear priorities, poor slicing)?
Do teams need better tools, or better practices?
Is "faster" actually better, or do we need "more sustainable"?

What makes teams want to do reviews?

Is it social accountability? Clear expectations? Reducing cognitive load?
How do you balance thoroughness with timeliness?
Does team culture matter more than tooling?

Help Me Understand Your World

I'm curious about your team's experience:

🤔 Questions for you:

What's your biggest PR review frustration? (Too slow? Too shallow? Wrong people reviewing?)
How does your team currently coordinate reviews? (GitHub assignments? Slack chaos? Formal rotation?)
What would make you excited to review code daily? (Better tooling? Different process? Team structure?)
Have you found any approaches that work? (Tools, practices, cultural changes?)

The Bigger Picture

I'm wondering if there's space for tools that focus on team habits rather than individual productivity. Something that helps teams develop sustainable review practices instead of just automating the mechanics.

What do you think?

Is this a real problem worth solving?
Are there existing solutions that work well for your team?
Would you pay for something that helped build better review habits vs. just faster reviews?

Drop your thoughts below! Curious to hear how other teams handle this challenge.

PS: If you've built or used tools that address PR review coordination, I'd love to hear about them. Always looking to learn from what's working (or not working) out there.