Documentation

Install the CLI, learn the model and look up every command.

Concepts

How a folder finds its project

.storeenv.json, the resolution order, linked repositories, folders without Git and branch rules.

Concepts 3 min read

A folder belongs to a project through .storeenv.json, a small file that holds the project id and environment rules. It never holds secrets, keys or tokens; the CLI refuses to write anything that looks like a credential. Commit it, and everyone who clones the code finds the same project.

{
"version": 2,
"project": "prj_82844d4b6bd8f18da3d790ba",
"name": "acme/payments",
"files": { ".env": "development", ".env.production": "production" },
"branches": { "main": "production", "release/*": "staging", "*": "development" },
"ignore": ["fixtures/"]
}

Which project a folder uses

The first match wins:

  • --project <namespace/name or prj_ id>.
  • STOREENV_PROJECT.
  • .storeenv.json, the nearest one walking up from the current folder, Git or not.
  • Git remotes (every remote, not only origin) linked to a project you are a member of. Several matches stop with SE_PROJECT_AMBIGUOUS; one match through an unverified link prints a warning.
  • The repository's first commit, only as a suggestion ("your project acme/app has the same first commit").
  • Nothing: an interactive terminal offers create, link or cancel. Without a terminal, push creates a project only with a typed --yes (CI=true alone isn't enough); every other command stops with SE_PROJECT_NOT_LINKED and the command to run.
!A .storeenv.json whose project doesn't exist, was deleted or isn't yours stops with SE_NOT_FOUND. It never falls through to another project. A remote or a first commit is a hint: it proves nothing about ownership, and lookups never show projects you aren't a member of.

Folders without Git

Everything works in a plain folder: init writes .storeenv.json and push, pull and run use it. Without Git there are no remotes, no first commit and no branch rules, so pull and run use the default environment plus the environments of files in the folder. storeenv status says "no Git".

Linked repositories on any host

A project can list Git remotes on any host: GitHub, GitLab, Bitbucket, Gitea or self hosted. They are optional. They let teammates who are already members find the project from a checkout without .storeenv.json. Anyone can link any remote to their own projects, so a link is a hint and never ownership. Verification shows that someone proved they can push to the repository: through the provider when it is connected, or with a tag proof on public repositories; otherwise a link stays unverified. Manage links in the web app (project, Linked repositories) or with storeenv project links.

The first commit suggestion

init also records the repository's first commit. When a folder has no .storeenv.json and no linked remote matches, a project of yours with the same first commit is suggested, never picked silently.

Which environment

push follows files: "files" in .storeenv.json, then the file suffix (.env.production is production, .env is default). pull and run pick one environment in this order:

  • --env.
  • STOREENV_ENV.
  • storeenv env use <name> (this machine and folder only).
  • The "branches" rule for the current branch: an exact name, a prefix/* pattern or *.
  • Otherwise pull takes default plus every environment that has a file here, and run takes default.

A detached HEAD, or a folder without Git, never matches a branch rule. Production is chosen only by an explicit choice, a file named for it, or a rule you wrote.