Team secrets

Share development secrets across your team through Service Federation Cloud. One person sets a secret once; everyone else's fed start just works.

Scope, stated plainly: this is for development secrets — the API keys and OAuth credentials your dev stack needs. It is a dev tool, not a production vault. Values are encrypted at rest and never logged, listings return names only, and removing an org member blocks their next fetch — values already cached on their disk stay readable (see resolution). Don't put production credentials here.

Setup (once per team)

Sign in at app.service-federation.com with GitHub.
Create an org and a project (a project maps to a repo).
Add your teammates by email — existing users are added directly; others get an invite link to share.

Setup (once per repo)

fed link acme/web        # writes .fed/cloud.yaml
git add .fed/cloud.yaml && git commit -m "link to acme/web"

.fed/cloud.yaml is meant to be committed — it's how teammates inherit the link. If your .gitignore covers .fed/, add !.fed/cloud.yaml.

Setup (once per machine)

fed login                # browser sign-in; token stored in ~/.fed/credentials (0600)

On a box with no browser: fed login --no-browser. In CI: set FED_TOKEN in the environment instead.

Daily use

There isn't any. Declare the secret in service-federation.yaml, and set generated_secrets_file so fetched values are cached locally (that's also what makes fed --offline start work):

generated_secrets_file: .env.secrets   # must be gitignored

parameters:
  STRIPE_SECRET_KEY:
    type: secret
    source: manual
    description: "From https://dashboard.stripe.com/apikeys"

Put the value in the vault (either the dashboard, or):

fed secrets set STRIPE_SECRET_KEY    # value read from stdin, never argv

Every linked, logged-in teammate's fed start now resolves it automatically.

How resolution works

source: manual secrets resolve in this order:

Local values first — generated_secrets_file and any env_file entries. A value already on disk wins and is not re-fetched on later runs.
Team vault — names still missing are fetched over HTTPS and written to generated_secrets_file (mode 0600), so later runs — including fed --offline start — don't need the network.
Error — anything still missing stops startup with a list of exactly what's needed.

Consequences of cache-first, stated honestly:

A rotated vault value doesn't reach machines that already hold the old one — delete the line from your generated_secrets_file to re-fetch.
A revoked member can still read values already on their disk — revocation stops new fetches. That's the honest semantics of any local cache.

fed secrets ls shows names and who last updated them, never values. Vault records are scoped per environment (development by default): the subcommand-local flag selects one for CLI operations — fed secrets ls --env staging — while fed -e staging start selects one for fetching.

The local generated_secrets_file is not namespaced by environment. Because local values win, a cached development value also wins during a later staging run. Delete that line before switching environments, or use a separate cache file or checkout for each environment.

Pricing

The first 10 people in an org are free, forever. Seats beyond that cost €5/month each and fund fed's development. Billing only ever gates adding members — reads, existing teammates, and fed start keep working whatever your billing state, and vault values are cached in a plain env file on your machine, so losing the service would lose you sync, not secrets.

Next: Isolation →