fedService Federation
fed · dev-stack orchestrator

The whole stack, running, in one command.

fed starts your Docker containers, native processes, and Compose servicesin dependency order, waits for every healthcheck, and gets out of your way. One service-federation.yaml — the file that runs your stack on a laptop is the file that will run it on a URL.

Read the docs

Open source · Rust · macOS & Linux

SYSTEM MAP · fed startidle
databasepostgres:15✓ :54832cacheredis:7✓ :54833backendnpm start✓ :61044gatewaycaddy✓ :61080ENTRYPOINTlocalhost:61080
$ fed start
resolving order: database, cache → backend → gateway
database healthy :54832 1.9s
cache healthy :54833 0.4s
backend healthy :61044 3.1s
gateway healthy :61080 0.7s
http://localhost:61080
Why fed exists

Setup instructions rot. Running code doesn’t.

Every project has a README that says “start Postgres, then the API, then…” — and every new laptop, teammate, and returning-after-three-months you pays for it again. fed replaces the instructions with one file that runs them.

before

“Works on my machine”

Ports, env vars, and start order live in someone’s head. Onboarding is an afternoon of Slack archaeology.

before

Compose-file sprawl

docker-compose.yml, three override files, a Makefile, and a .env you must never commit — per project.

before

Half the stack isn’t Docker

Your API runs with npm, your worker with Gradle, your DB in a container. Compose only sees a third of it.

Declare it once.
git clone → fed start → running.

Containers, host processes, Compose services, and Gradle tasks are all justservices in one YAML. fed computes the dependency order, starts everything, waits for the healthchecks you declared, and backgrounds. Your teammate’s first command on day one is the same as yours: fed start.

fed status · fed logs api · fed stop — the whole surface fits in your head.

# service-federation.yaml — the entire runbook
services:
  database:
    image: postgres:15
    healthcheck: { command: pg_isready -U postgres }
  backend:
    process: npm start
    depends_on: [database]
    healthcheck: { httpGet: 'http://localhost:{{API_PORT}}/health' }
entrypoint: backend
Directory-scoped isolation

Every worktree gets its own city.

All state — ports, containers, volumes — is scoped to the directory. Two checkouts are two independent stacks that can’t collide. If you run coding agents in parallel worktrees, each one gets a full running stack with zero coordination.

$ git worktree add ../app-agent-1 feature/pricing
$ cd ../app-agent-1 && fed start --isolate
 database  healthy  :55210   ← fresh ports,
 backend   healthy  :61301     fresh volumes,
→ http://localhost:61301            fresh containers

# meanwhile, your main checkout is untouched:
$ cd ~/app && fed status
 backend   healthy  :61044

Integration tests that never touch your dev stack.

Mark a script isolated: true and it runs against a throwaway copy of the stack — fresh ports, scoped volumes, separate containers — torn down when it exits. Your dev services keep running through the whole test run.

fed test:integration — the dev stack never flinches.

Development secrets

Secrets that generate themselves and never hit git.

Declare a parameter as type: secret and fed generates it — passwords, keys, ports — writes it to a mode-0600 file outside version control, and injects it where services need it. No .env in the repo, no “ask Sarah for the key”, no secret in your shell history.

The parameter system is the point.

Ports and secrets are declared, not hardcoded — so isolation can re-generate them per directory, templates like{{DB_PORT}} resolve everywhere they’re used, and the same file works on every machine without edits.

fed ports list · generated once, scoped per stack.

parameters:
  DB_PORT:    { type: port }             # allocated free port
  JWT_SECRET: { type: secret }           # generated, 0600, gitignored
services:
  backend:
    environment:
      DATABASE_URL: 'postgres://localhost:{{DB_PORT}}/db'
      JWT_SECRET:   '{{JWT_SECRET}}'
Service Federation Cloud

Push a branch. Get a URL.early access

The YAML that runs your stack locally is already a portable environment definition. Cloud takes a git ref, runs the same fed on a host, waits for your healthchecks, and hands back a link — an ephemeral, isolated environment for every branch, PR, and agent task. When you’re done, it’s gone: containers, volumes, secrets, all of it.

1

Share work that’s running, not described

fed share pushes your current branch and prints a URL. “Here’s my branch, running” replaces “pull it and follow the README”.

2

A stack per agent, beyond your laptop

Parallel agents already get isolated stacks in worktrees. Cloud gives every PR and agent task the same thing on a host — reviewable at a link.

3

Environments that clean up after themselves

Every environment carries a TTL. When it expires, teardown is total —nothing left to pay for, nothing left to leak.

Cloud is in development — fed itself is shipped and open source today. Early-access invites go out as hosts come online. No spam; one email when it’s your turn.

$ fed share
pushing feature/pricing → envs.service-federation.com
cloning… installing… starting…
✓ database  healthy
✓ backend   healthy
✓ gateway   healthyhttps://pricing-8f2c.envs.service-federation.com
   expires in 4h · refresh with `fed share --keep`