Concepts

Projects, services and environments

How your code maps to StoreEnv.

Concepts 1 min read

If you know Git, you know StoreEnv. A project has its own id, kept in a .storeenv.json committed with your code; remotes are optional hints.

Git and StoreEnv

`Repository`	Project (namespace/name, its own id in a committed .storeenv.json)
`Remote`	Optional link: GitHub, GitLab, Gitea or any host, or none
`Folder`	Service (frontend/, backend/, root)
`Branch`	Environment, picked by an optional branch rule
`Commit`	Signed version (author, message, changed keys)
`Submodule / dependency`	Import from a library or another project
`push / pull / clone`	storeenv push / pull / init

`Folder with an env file`	Service. backend/.env belongs to backend. The folder root is called root. Nested folders keep their path, such as apps/web.
`.env`	The default environment.
`.env.<suffix>`	An environment named after the suffix. prod becomes production, dev becomes development.
`.env.example, .env.sample, .env.template`	Not pushed. They are compared against the generated template.

node_modules, .git, dist, build, .next, coverage, vendor and .venv are skipped. Add more under "ignore" in .storeenv.json.