fedService Federation
fed · the runtime contract for your repository

Give every coding agent its own working stack.

fed gives developers and coding agents one executable contract for starting, testing, and isolating the whole development stack. Docker containers, native processes, Compose services, ports, secrets, and healthchecks — declared once in service-federation.yaml, then run the same way in every checkout.

Read the docs

Open source · Rust · macOS & Linux

SYSTEM MAP · fed start
database postgres:15 ✓ :54832 cache redis:7 ✓ :54833 backend npm start ✓ :61044 gateway caddy ✓ :61080 ENTRYPOINT localhost: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
The executable development contract

Your repository should know how to run itself.

A README can describe the right start order, environment, and test setup. fed makes them executable. A teammate or coding agent checks out the repository, runs the named command, and gets the same working stack you do.

before

Setup lives in prose

The README says “start Postgres, then the API…” until one missing step turns onboarding into Slack archaeology.

before

Commands lack context

A test, migration, or seed command needs the right database URL, ports, and dependencies. Bare commands quietly hit the wrong stack.

before

Agents improvise

A worktree isolates source code, not port 3000, Postgres, or Redis. Parallel agents collide in the running system.

One contract for start, test, seed, and debug.

Containers, native processes, and existing Compose services become one dependency graph. Repository scripts join that graph with the environment and services they need. fed starts in order, waits for health, and gives every caller the same named interface.

git clone → fed start — whether the caller is a new hire or a coding agent.

# service-federation.yaml — the entire runbook
parameters:
  API_PORT: { type: port }
services:
  database:
    image: postgres:15
    healthcheck: { command: pg_isready -U postgres }
  backend:
    process: npm start
    depends_on: [database]
    environment: { PORT: '{{API_PORT}}' }
    healthcheck: { httpGet: 'http://localhost:{{API_PORT}}/health' }
entrypoint: backend
Parallel work without collisions

A working stack for every worktree.

A worktree already separates the files. fed separates the running state too: ports, containers, volumes, generated secrets, and service state. Enable isolation once in a checkout and developers or agents can run the whole application in parallel without touching the main stack.

$ 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

Test against real dependencies, not your dev state.

Mark a script isolated: true and it receives a throwaway copy of the services it depends on — fresh ports, scoped volumes, separate containers — torn down on exit. Your development stack never becomes test setup.

fed test:integration — repeatable for a person, an agent, or CI.

Development inputs, resolved

The keys your dev stack needs, without the Slack archaeology.

Declare development secrets as inputs to the same repository contract. fed can generate local values such as database passwords and JWT keys, or resolve manually supplied API keys from a local file or the optional team vault. Values stay out of git and are cached in a mode-0600 file for offline use.

Inputs belong to the contract, not the onboarding guide.

Ports and secrets are declared, not hardcoded, so isolation can scope them per checkout and templates such as {{DB_PORT}} resolve everywhere they are used. A new teammate learns what is required from the config itself.

Team secrets are optional · free for orgs up to 10 people · development use only.

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}}'
Hosted execution

The same contract, on remote compute.early access

Local isolation gives every checkout a working stack. Service Federation Cloud is being built to execute that same repository contract in an isolated remote environment: submit a git ref, wait for the declared healthchecks, and get a URL for every branch, PR, or agent task.

1

From branch to running URL

fed share will submit the current branch and print a URL. “Here’s the change, running” replaces “pull it and reproduce my setup”.

2

Agent work that can prove itself

Give each coding task its own remote stack, then let the agent run integration tests and return a reviewable application — not only a diff and a claim that tests passed.

3

Pay for active work, not idle stacks

Every environment carries a TTL. When the work is done, its containers, volumes, secrets, and compute allocation are removed with it.

Hosted execution is in development — fed itself and team development secrets are available today. Early-access invites go out as runner capacity comes 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`