From install to injected secrets

Six commands on a brand-new account, four on a project someone has already set up. We will not put a stopwatch figure on it, because the honest answer depends entirely on whether the workspace already exists and whether you are the person who has the passphrase. The steps themselves are quick; getting the passphrase from a colleague is the part that takes real time.

Yes, and it is meant to be. It holds slugs only: which workspace, product, project and environments this directory maps to. No secrets, no tokens, no keys. Committing it is what lets a teammate clone the repository and run envless run with no arguments, and it is what makes CI work from a checkout.

No plaintext .env, which is the claim that matters, but not literally nothing. Setting the passphrase has already written the derived key into ~/.envless/config.json at mode 0600, and run reads it from there. The CLI warns you about this at the time. If you want it gone, envless passphrase clear removes it without signing you out.

You will be told immediately rather than later. Before caching anything, the CLI fetches an existing ciphertext from the workspace and tries to decrypt it, so a wrong passphrase is rejected up front. The only case where a passphrase is cached unverified is a workspace with no encrypted variables yet, and that is also the case where the strength floor is enforced.

You can run everything except link. Set ENVLESS_TOKEN to a machine key and supply ENVLESS_KEY or ENVLESS_PASSPHRASE, and reads work headlessly. Link is the exception: it reads your local config and never falls back to a machine key, which is deliberate, because the answer for CI is to commit the .envless file rather than to re-derive the binding on every run.

No. Signup creates a workspace and its three system roles and nothing else, and envless init tries to create all three environments but the Free plan allows one. When that happens init warns you, still writes .envless with the environment it did create, and exits non-zero so a script notices.

Not for reading values, because there is nothing else that can decrypt them. Every read needs a cached workspace key, an ENVLESS_KEY, or an ENVLESS_PASSPHRASE; without one, sync, run and var fail with the workspace reported as locked. On unattended machines prefer the exported raw key, which skips derivation and keeps a human-chosen string out of your environment.

They are separate credentials for separate jobs. Your CLI session authenticates you as a person for interactive work. The @goenvless/env runtime, which loads variables inside a running application, explicitly refuses a CLI session token and requires a machine key. So importing env in your app right after envless login will not work; the runtime path is a machine-key path.