Data and storage

This page covers where Rewind stores its data, how the storage location is chosen, what the various pieces on disk are, and how to tune the storage limits.

Where your data lives

The local API uses the platform's standard application-data directory for its data. The exact path depends on your OS:

OS	Path
Linux	$XDG_DATA_HOME/rewind (default ~/.local/share/rewind)
macOS	~/Library/Application Support/Rewind
Windows	%LOCALAPPDATA%\Rewind

You can override the directory with the REWIND_DATA_DIR environment variable. Set it to an absolute path; relative values resolve from the process working directory. This is the right knob to use when you want a per-project workspace (e.g. one workspace per repo, both checked into source control).

You can also override only the database file with SQLITE_PATH. This is the legacy override and is still supported; absolute values are used directly and relative values resolve from the process working directory. Everything else (attachments, response bodies, logs, backups) stays in REWIND_DATA_DIR or its default.

The default database file is rewind.sqlite inside the data directory. Older versions of Rewind created apps/api/data/rewind-api-studio.sqlite; the launcher detects this and migrates the contents on first run.

What's in the data directory

<data-dir>/
  rewind.sqlite              # the database
  rewind.sqlite-shm          # SQLite shared-memory file (transient)
  rewind.sqlite-wal          # SQLite write-ahead log (transient)
  attachments/               # uploaded files (multipart, binary, network TLS)
    <id>-<safe-name>         # one file per attachment
  response-bodies/           # stored response bodies for history entries
    <history-id>.bin         # one file per stored body
  logs/                      # rotating text logs
    rewind.log               # current log
    rewind.log.1 .. rewind.log.4   # older rotations
  backups/                   # automatic pre-restore backups
    rewind-<timestamp>.rewind
    legacy-<timestamp>/      # one-time legacy migration

The .sqlite-shm and .sqlite-wal files are SQLite's normal transactional companions. They are not user data and can be ignored.

What the database stores

• collections, folders, requests
• environments, environment_variables
• history, response_bodies (the row, not the file)
• settings (the network and storage configurations)
• attachments (the row; the file is on disk)
• cookies

The schema is the source of truth for the application. It is in apps/api/src/db/schema.ts and the generated SQL migrations are in apps/api/drizzle/. To change the schema, edit the TS file and run bun run db:generate.

Storage knobs

Four values control how much disk the workspace uses. They live under the Settings → Storage key in the database, and the bundled apps/api/dist/rewind launcher exposes them through the API at /api/v1/settings/storage. The web app does not yet render a settings page for them; the values below are the defaults.

Setting	Default	Effect
previewBytes	1 MB	The maximum response body that the API includes inline in the SendResponseV2 body. Larger bodies are still stored on disk if maxStoredResponseBytes allows.
maxStoredResponseBytes	50 MB	The maximum size of a single response body kept on disk. Larger responses are recorded in history with storageState: "omitted_limit".
maxHistoryBytes	1 GB	Total size of all stored response bodies. When exceeded, the oldest entries are removed first.
maxHistoryEntries	1 000	Maximum number of history entries. Same eviction policy.

The retention pass runs on every successful send and removes entries past the byte and entry limits. It removes both the database row and the corresponding response-bodies/<id>.bin file.

Logs

The API writes a rolling text log to <data-dir>/logs/rewind.log. The current log is renamed rewind.log.1, rewind.log.2, etc. when it exceeds 5 MB, with up to 4 rotations kept. The log entries look like:

2024-09-12T08:30:00.000Z INFO Application started {"platform":"darwin","arch":"arm64","version":"2.0.0"}
2024-09-12T08:30:01.000Z INFO GET /api/v1/collections 200
2024-09-12T08:30:02.000Z ERROR Failed to send request { "category": "connection" }

The logger redacts values for keys matching authorization, proxy-authorization, cookie, set-cookie, client[_-]?secret, password, and token, and replaces any path-like strings with [path]. If you need to share a log, run a quick grep first to make sure nothing sensitive slipped through.

Backups

There are two sources of backups:

• Manual: created through the Export button in the top bar. Lands as rewind-workspace-YYYY-MM-DD.rewind in your downloads.
• Automatic: created by the restore endpoint before it replaces your workspace. Lands in <data-dir>/backups/rewind-<timestamp>.rewind. The file is a normal .rewind archive; you can restore from it the same way you'd restore any other.

The legacy migration backup, created when an older workspace is detected on first run, is in <data-dir>/backups/legacy-<timestamp>/. It is a one-time copy; once the new database is in use, you can delete the directory.

Diagnostic archive

If you need to file a bug, the diagnostic endpoint downloads a .tar.gz containing:

• A diagnostic.json with the application version, the host OS and architecture, Bun version, database size, and counts of every table
• All current log files

It does not include collections, environments, history, or attachments. Run curl http://127.0.0.1:8000/api/v1/diagnostics/archive > rewind-diagnostics.tar.gz and attach the file to the issue.

Disk space

SQLite is single-file, so the only practical limit is how much disk you have. A 1 000-request workspace with 1 000 small responses is well under 100 MB. Attachments and response bodies are the only things that grow without bound; tune the storage knobs if you need to.

What's next?

• Architecture — the higher-level view of the data flow
• Exporting and backups — the manual backup path
• Troubleshooting — what to do when something goes wrong on disk