Vexly puts at most two files in your project directory, and they have opposite rules: commit .vexly, never commit .env. Everything else the CLI needs is kept outside your project, so there’s nothing else to manage.

The two project files

.vexly holds only the (non-secret) project id and a pointer to the cloud, so committing it is safe — and it’s what lets a teammate clone the repo and start working immediately: their CLI already knows which project this is. The secrets themselves never touch the repo; they live in the cloud, and in your local, gitignored .env only if you’ve chosen to keep one.

vexly init does not modify .gitignore. If you keep a .env, add it to your .gitignore yourself, and make sure .vexly is not ignored.

Per-machine state lives outside your project

The CLI keeps a little per-machine bookkeeping — your stored credentials and the baseline it uses to detect changes before a push. This is not kept in your project directory; it lives in the CLI’s per-user directory, ~/.vexly/, keyed by project id. So your repo stays clean and there’s nothing extra to gitignore. If that state is ever lost, the CLI rebuilds it on the next pull.

Commands

There are no dedicated file commands — .vexly is written by vexly init and .env is written by vexly pull.

Next

• Projects & access — what the project id grants.
• Managing secrets — the cloud-to-.env bridge.