Team development secrets

Service Federation Cloud can fill the manual credentials declared by a project during fed start. One teammate sets a value in the dashboard. Other authorized teammates fetch it without passing around an env file.

Use this for development credentials only. The service can decrypt values in order to deliver them to authorized clients. It is not an end-to-end encrypted vault, a production secrets manager, or a compliance product.

What the open-source CLI needs

Local stacks, worktree isolation, generated secrets, and scripts do not require a Service Federation Cloud account. Cloud is an optional source for type: secret, source: manual parameters.

Set up a team

Sign in at app.service-federation.com with GitHub.
Create an organization and a project. A Cloud project normally maps to one repository.
Add teammates by email. New users receive an invite link.
Add the development credentials the project needs.

Link a repository

fed login
fed link acme/web
git add .fed/cloud.yaml
git commit -m "Link fed development secrets"

For a new link, fed link writes .fed/cloud.yaml with secret_cache: file, the default cache policy. Re-linking preserves the project's configured policy. Commit the file so every checkout points at the same Cloud project and uses the same policy. If .gitignore ignores the whole .fed/ directory, add an exception for .fed/cloud.yaml.

Sign-in works over SSH: open the printed URL on any machine, approve, and the terminal finishes on its own. --no-browser skips the browser attempt and just prints the URL. CI can supply FED_TOKEN instead of storing credentials on disk.

Declare a manual secret

parameters:
  STRIPE_SECRET_KEY:
    type: secret
    source: manual
    description: "Development key from the Stripe dashboard"

Add STRIPE_SECRET_KEY in the Cloud dashboard. A linked and signed-in teammate can then run fed start without creating a local env file first.

Resolution and caching

A value from a declared env_file always wins. For each required manual secret still missing locally, fed applies the linked project's cache policy:

file (default). A complete cache newer than FED_VAULT_TTL can satisfy the run without a vault request. The default TTL is five minutes. Otherwise fed requests the missing values from the vault and refreshes the owner-only .fed/secrets.cache.env file. With --offline, or when the vault is unavailable, fed can use the last cached values regardless of age.
memory. fed removes any existing file cache, requests the values from the vault on every online start, and keeps them only for the current process and its child services. --offline and unavailable-vault starts fail when a required manual secret is not available from an env_file.

If a required value is still missing after applying the selected policy, startup stops and lists it.

The secret_cache setting controls fed's local handling of plaintext values; it does not change how Service Federation Cloud stores them. The vault returns requested plaintext values to an authorized CLI with Cache-Control: no-store and keeps no in-process plaintext cache.

In file mode, fed writes the cache atomically with mode 0600 and manages .fed/.gitignore. If the cache path becomes eligible for Git, fed disables caching and removes an existing commit-eligible cache.

To select memory mode for every checkout, set the linked project's shared policy in .fed/cloud.yaml:

org: acme
project: web
secret_cache: memory

The --secret-cache file|memory flag overrides the committed policy for one invocation. The policy applies only to values fetched from the team vault. It does not change locally generated secrets in .fed/secrets.generated.env or values supplied through an explicit env_file.

Removing access does not erase a laptop

Removing an organization member blocks their next server fetch immediately. It cannot delete values already fetched to that person's machine. Those values can still support offline startup.

Rotate every credential the person could read. This is the only way to revoke a value that may already exist outside the service.

Security model

Values are encrypted with AES-256-GCM before database storage. Each value uses a random nonce and row-bound authenticated data.
Production deploys provision the encryption key from Scaleway Secret Manager into the application environment. It is absent from the database, repository, container image, and infrastructure state.
The plaintext endpoint sends Cache-Control: no-store. The application keeps no in-process plaintext cache.
Secret reads are audited with the actor, names, and time. List responses and audit entries do not contain values.
CLI bearer tokens can read the development secrets their owner can access and revoke themselves. They cannot create, change, or delete secrets, manage members, or change billing.
Secret changes happen through a browser session in the dashboard, not through the CLI.

Accepted limits

The service can decrypt values. This is not end-to-end encryption.
A CLI token is user-wide. If stolen, it can read every development secret its owner can reach across their organizations and projects.
Cached values survive removal. Member removal stops new fetches but does not revoke copies already stored on a device.
Processes receive plaintext. Memory-only cache mode avoids an intentional disk cache, but a child process can still log, swap, dump, or otherwise persist a value it receives.
No production or compliance claim. There are no per-secret ACLs, scoped CI tokens, secret-version history, SOC 2 claim, or ISO claim.

Pricing and failure behavior

The first three people in an organization are free. Each additional seat costs €8 per month. Billing only gates adding members. Billing state does not disable existing memberships or secret reads, so it does not by itself block fed start.

A machine with a valid local cache can keep using those cached values while Cloud is unavailable. It cannot fetch rotations, new values, or membership changes until the service returns.

Compare with local generated secrets →