---
title: "Overview"
description: "Why and how to use a shared remote D1 backend."
---

> Documentation Index
> Fetch the complete documentation index at: https://machine-memory.jfa.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

The remote backend stores memories in a shared database behind an authenticated Worker. It is the best choice when memory should follow the project instead of a particular checkout or computer.

## Why use a remote database?

- **Share context across agents and machines.** Multiple working copies and agent sessions can read and write the same project memory.
- **Keep memory available across branches.** Memories are not trapped in a local SQLite file that can be lost, overwritten, or become difficult to merge.
- **Preserve project boundaries.** The remote database is shared, but records are filtered by the current Git repository, so different projects remain isolated.
- **Enable semantic search.** The remote stack includes Vectorize and Workers AI, allowing [`query`](/machine/query) to search by meaning as well as exact text.
- **Centralize infrastructure.** D1, the Worker API, Vectorize, and their credentials are managed as one deployable stack.

## Get started

Choose one path:

| Guide                                         | Use it when                                             |
| --------------------------------------------- | ------------------------------------------------------- |
| [`remote setup`](/human/remote/setup)         | A Worker already exists and you have its URL and token. |
| [`remote provision`](/human/remote/provision) | You want to deploy a new Cloudflare-backed stack.       |

## MCP

The same Worker can serve agents over the Model Context Protocol. Deploy via [Infrastructure](/infrastructure/overview), then see [MCP](/docs/mcp/overview) for OAuth enablement, the public init script, and tools.

Source: https://machine-memory.jfa.dev/human/remote/overview/index.mdx