grove dev --seed --persist: fixtures beat a local database

grove dev starts the whole backend on your machine — API, dashboard, functions — in memory, on port 8099. Stop it and everything is gone. That sounds like a limitation until you’ve spent a month mutating a local database nobody else can reproduce.

The pair you almost always want

grove dev --seed --persist

The two flags are one unit:

• --persist — on exit, writes your work back as files: the shape (collections, policies, functions, roles) into groveback/, the documents into seeds/.
• --seed — on start, loads seeds/ back in.

Alone, each is a trap: --persist saves work you’ll never load again, and --seed loads fixtures you’ll lose on exit. Together, your local backend survives restarts and the rest of the team gets it from git pull.

Shape and data travel differently

grove pull and grove push move shape between your repo and a deployed project. They never move documents. There’s no path that pulls production data onto a laptop or pushes local test data into production — local data comes from committed fixtures, full stop.

Tips from real sessions

• Point your app with an env var, not a regenerate. The typed client from grove gen reads GROVE_URL, so switching between http://localhost:8099 and the real project doesn’t need a new client.
• Run grove status before grove push. It shows what would change without changing anything. push plans and asks anyway, and a non-interactive shell answers “no”.
• If push refuses, someone else moved the project. pull records a hash per file; push stops rather than clobbering a teammate’s change. Pull, look at the diff, then push.
• The dashboard link has the key in it. Open it once; after that http://localhost:8099/dashboard#/ is enough — the key is stored and stripped from the URL.

Full picture in the local loop guide.