> ## Documentation Index > Fetch the complete documentation index at: https://docs.px0.ai/llms.txt > Use this file to discover all available pages before exploring further. # The store > What lives in ~/.px0, what is versioned, how to move it, and how px0 keeps history without git. Everything px0 knows lives in one directory. By default that is `~/.px0`; set `PX0_HOME` to put it anywhere else. ```bash theme={null} export PX0_HOME=~/Documents/px0 px0 init ``` The store is designed to be a *bare directory*. It works with nothing else installed alongside it - no git repository, no database server, no daemon required. Copy it to another machine and it keeps working, history included. ## Layout ``` ~/.px0/ ├── workflows/ the jobs px0 can run ├── guidelines/ how you work ├── brain/ what you have read and kept │ ├── blogs/ │ ├── docs/ │ ├── papers/ │ └── work/ never retrieved, by design ├── output/ what runs produced ├── tools/ tools you declared yourself, one TOML file each ├── config.toml every setting └── .state/ internal: not meant for hand-editing ``` | Path | Versioned | Rebuildable | | :------------ | :-------- | :----------------------------- | | `workflows/` | Yes | No - these are yours | | `guidelines/` | Yes | No - these are yours | | `config.toml` | Yes | Defaults only | | `brain/` | No | Yes, from source URLs | | `output/` | No | Yes, by rerunning | | `tools/` | No | No - these are yours too | | `.state/` | n/a | Mostly, but history lives here | The first three are the ones that would hurt to lose. They are also the smallest - plain Markdown and TOML, easy to back up anywhere. ## Inside `.state/` You do not need to touch any of this, but knowing what it holds makes `px0 doctor` output legible. | Path | What it holds | Rebuildable | | :----------------------- | :----------------------------------------------------------------------------------------------- | :------------------------ | | `versions/` | The version manifest (SQLite) and content-addressed blobs - this is the history | No | | `index/index.sqlite` | The retrieval index over `brain/` | Yes - `px0 brain reindex` | | `ingest/` | Queued playlist ingest jobs, drained by the daemon, with `failed/` for retired ones | Yes | | `credentials.toml` | Connector authorizations, kept at mode `0600` | No | | `schema` | The store's on-disk schema version | No | | `schedule.json` | The daemon's persisted scheduling state | Yes | | `update-history.json` | What was installed when, and which migrations ran | No | | `update-check.json` | When px0 last checked for an update | Yes | | `retrieval-consent.json` | Whether the `qmd` backend's local models were consented to | Yes | | `running/` | One file per run in flight, holding its pid so `px0 runs cancel` can signal it | Yes | | `catalogue.json` | Composio tool definitions discovered by `px0 workflows new`, so a workflow keeps working offline | Yes - `px0 tools refresh` | | `lock` | Process lock, so two px0 runs cannot write at once | Yes | The retrieval index is derived data and is dropped and rebuilt whenever its schema changes - for instance when the tokenizer or a column changes between releases. `px0 doctor` reports an empty index and names `px0 brain reindex`. ## How versioning works px0 keeps its own history rather than relying on git, because a store should not require you to adopt a version-control workflow to keep your notes safe. Every write to a versioned file records a **change**: an actor (you, or the builder), a timestamp, and the new content of each file involved. A change can span several files - a workflow build that also wrote a guideline is one change, and reverts as one: ```bash theme={null} px0 changes list --since 7d px0 changes show px0 changes revert ``` Two things follow from that design and are worth knowing: **Your hand edits are captured, not overwritten.** A run checkpoints the workflow it is about to execute, and the daemon's nightly pass checkpoints everything else. Your editor session shows up in the same history as px0's own changes, under the `user:manual` actor. **Guideline history is addressable per section.** A guideline heading becomes a claim id (`#`), so `px0 guidelines log #` walks one convention's history without disturbing the rest of the file. See [History](/guidelines/history). ## Move a store to another machine ```bash theme={null} px0 store export ~/px0-backup ``` That copies content and version history - workflows, guidelines, brain, output, tools, `config.toml`, plus the parts of `.state/` that matter for continuity: version history, the schema marker, and the schedule. **Secrets are stripped, in both places they live.** `.state/credentials.toml` is excluded, `config.toml` is exported with `connectors.composio_api_key` blanked, and `config.toml`'s version history is dropped from the exported manifest - otherwise the raw key would still sit in the history blobs, one command away. Blobs are content-addressed and shared, so only those nothing else references are removed. That is what makes the export safe to move over a network or drop into a backup. The retrieval index is not exported; run `px0 brain reindex` after importing. Load one back on the new machine: ```bash theme={null} px0 store import ~/px0-backup px0 store import ~/px0-backup --merge # add what is missing, keep what is already here px0 store import ~/px0-backup --force # let the import win on a collision ``` Without `--merge` or `--force`, importing into an existing store stops rather than silently overwriting workflows you are running. An export contains no credentials, so importing never blanks the API key on the machine you are importing into - a `config.toml` already present is kept, and the Composio key is set separately: ```bash theme={null} px0 config composio px0 store verify px0 doctor ``` `px0 store verify` checks that what arrived hangs together - workflows parse, guideline references resolve, version blobs exist, and any user-declared tool is well-formed - separate from `px0 doctor`, which asks whether the *install* is wired up rather than the store's contents. One consequence worth knowing: because config history is dropped on export, an imported store has no history for `config.toml` before the import. Everything else keeps its full history. To move the store rather than copy it, move the directory and point `PX0_HOME` at the new location. Nothing inside the store depends on its absolute path. ## Run history is per store Run records and logs live under `logs.path`, which sits *outside* the store and defaults to one directory shared by every store on the machine. Each record is stamped with the store that produced it, and `px0 runs` only lists the current store's runs - so `PX0_HOME` isolates history rather than showing you another store's runs and offering to rerun workflows this store does not have. Point `logs.path` somewhere per-store if you would rather they not share a directory at all. ## Sharing and syncing Because it is a plain directory, syncing a store through Dropbox, iCloud, Syncthing, or a private git repository all work. Two cautions worth taking seriously: `.state/credentials.toml` holds your connector secrets. Exclude it from anything you sync or commit, or make sure the destination is encrypted and private. See [What leaves your machine](/reference/privacy). Also avoid running the daemon on two machines against the same synced store. Both would evaluate the same schedules and fire the same workflows, and a synced `schedule.json` is not a coordination mechanism. ## Backing up The high-value, low-cost backup is the versioned paths plus history: ```bash theme={null} px0 store export ~/backups/px0-$(date +%F) ``` `brain/` is rebuildable from source URLs and `output/` from reruns, so if you want a small backup, those are the two you can drop. ## Deleting a store Uninstalling px0 via the installer script (`sh install.sh --uninstall`) never deletes your store for you. It leaves the store as-is so you can keep your data. When you want it gone manually: ```bash theme={null} rm -rf ~/.px0 ``` Alternatively, you can remove px0 and purge your store in one command: ```bash theme={null} px0 uninstall ```