Agent Memory in Docker: Persist Data Across Restarts

Agent memory in Docker persists only when the agent writes to a mounted volume rather than to the container's own filesystem. A container's writable layer is deleted when the container is removed, so any file the agent creates there disappears.

Getting persistence right in Docker is a configuration decision, not a code decision. The application code writes to a path; whether that path is ephemeral or durable depends on how the container is launched. Tools like fenbs give agents a shared project record that lives outside any container, so the context survives even if the container is rebuilt from scratch.

Why container filesystems erase agent memory

When Docker creates a container from an image, it adds a thin writable layer on top of the image layers. Writes go into this layer. When you run docker rm, that writable layer is deleted. Even docker stop followed by docker start (without docker rm) keeps the writable layer, so data written in a previous run survives a stop-start cycle, but not a remove-and-recreate cycle.

Most CI/CD pipelines and deployment tools recreate containers on deploy. If your agent writes memory only to the container filesystem, every deployment is a memory wipe. Write to a mounted volume from day one, before the first real data lands in the container.

Named volumes versus bind mounts

A named volume is managed by Docker and stored in Docker's storage directory on the host. It persists until you explicitly run docker volume rm. A bind mount maps a specific directory on the host into the container. Both survive container removal, but they suit different situations.

• Named volumes are portable across hosts when you use a volume driver. Use them when the agent is the only consumer of the data.
• Bind mounts expose a known host path inside the container. Use them when you also need to read or write the memory files from outside Docker, for example from a script that backs up or inspects the data.
• Do not mix both for the same memory directory. Pick one and document the choice so the next person running the container knows where to find the data.

Choosing a storage format for agent memory

SQLite is a practical default for agent memory inside a container. It is a single file, so you can mount a volume at the file's directory and move or back up the database by copying that file. The agent opens the file at startup and writes to it through normal SQL queries.

JSON files work for simpler use cases where the total memory is small and you do not need to query by attribute. A newline-delimited JSON file (one JSON object per line) is easy to append to and easy to parse. The downside is that searching for a specific fact requires reading the entire file. For anything larger than a few thousand entries, SQLite is faster. See what is agent memory and agent memory vs RAG for a comparison of storage approaches.

Testing persistence after a container restart

Run this test after setting up your volume mount.

1. Start the container and let the agent write at least one memory item.
2. Stop and remove the container: docker stop <name> && docker rm <name>.
3. Start a new container from the same image, with the same volume mount.
4. Confirm the agent loads the previously written memory item before doing any new work.

If step four returns nothing, the volume is not mounted at the path the agent is writing to. Check the --mount or -v flag in your docker run command and compare the mount target path with the path your agent uses to open its database or file. For broader guidance on agent memory persistence patterns, see how to build agent memory.

Access boundaries for a containerized memory service

A named volume is accessible to any container that mounts it. If you run multiple agent containers that should not share memory, use separate volumes with distinct names. If two agents must share a memory store, mount the same volume into both containers and make sure your write logic handles concurrent access correctly: SQLite has WAL mode for concurrent readers and a single writer, which is usually sufficient.

When the memory service runs in its own container (for example, a Redis or PostgreSQL container that the agent connects to over a Docker network), isolate it on a private network that only the agent containers can reach. Do not expose the memory service port to the host unless you need to inspect it directly. See agent memory security for a fuller treatment of memory isolation.

How to do this with fenbs

Use Docker volumes for the agent's operational memory. Use fenbs for the project context the agent needs at the start of each container run.

1. Create a free account and add your project to fenbs. Write the standing rules as Decisions and rules.
2. Connect your assistant from /integrations. Ask it to call fenbs at container startup to read Rules and Where we left off.
3. Add a named volume to your docker run command, for example -v agent-memory:/app/data.
4. Configure the agent to write its SQLite database or JSON files to /app/data.
5. Run the stop-remove-recreate test to confirm persistence before running the agent on real work.