Files
letta-server/fern/pages/selfhosting/overview.mdx
Cameron Pfiffer fc531ca6de docs: center documentation around current Letta architecture (#5634)
* docs: restructure architecture documentation to sideline legacy agent types

This commit reorganizes the agent architecture documentation to address
confusion around legacy agent types (memgpt_agent, memgpt_v2_agent) and
clarify that users should not specify agent_type for new projects.

The documentation was causing confusion for both users and LLMs:
- References to memgpt_agent, memgpt_v2_agent, and letta_v1_agent were scattered
  throughout main docs
- The naming progression (memgpt → memgpt_v2 → letta_v1) is non-standard
- LLMs trained on these docs were recommending deprecated architectures
- Discord users were confused about which agent type to use
- send_message tool and heartbeat references were in mainline docs

- architectures_overview.mdx - Landing page explaining legacy types exist
- migration_guide.mdx - Step-by-step migration with code snippets
- naming_history.mdx - Hidden page explaining progression for LLMs
- memgpt_agents_legacy.mdx - Moved from main docs with deprecation warnings
- heartbeats_legacy.mdx - Moved from main docs with deprecation warnings

- Removed "Agent Architectures" subsection from main nav
- Moved "MemGPT Agents" to top-level (renamed "Agent Memory & Architecture")
- Removed "Heartbeats" page from main nav
- Added "Legacy & Migration" section with 5 sub-pages
- Added redirects for old URLs

- pages/agents/memgpt_agents.mdx - Completely rewritten to focus on current
  architecture without mentioning legacy agent types
- pages/agents/sleep_time_agents.mdx - Changed from agent_type to enableSleeptime
- pages/agents/base_tools.mdx - Added stronger deprecation warning for send_message
- pages/agents/overview.mdx - Updated assistant_message description
- pages/agents/tool_rules.mdx - Removed send_message default rule examples
- pages/agents/message_types.mdx - Removed heartbeat message type section
- pages/agents/json_mode.mdx - Removed send_message requirements
- pages/agents/archival_best_practices.mdx - Removed send_message tool rule example
- pages/agents/react_agents.mdx - Removed heartbeat mechanism reference
- pages/getting-started/prompts.mdx - Removed send_message note
- pages/ade-guide/simulator.mdx - Removed tip about removing send_message
- pages/advanced/custom_memory.mdx - Changed send_message to "respond to user"
- pages/deployment/railway.mdx - Removed legacy tools array from example
- pages/selfhosting/overview.mdx - Changed send_message example to memory_insert

- pages/agents/heartbeats.mdx - Moved to legacy section

Added to memory: aggressively remove send_message and heartbeat references
from main docs. Keep legacy content only in /guides/legacy/ section. Don't
add notes about legacy in main docs - just remove the references entirely.

* docs: remove evals tab from navigation

The evals content is not ready for public documentation yet.

* docs: move send_message to deprecated tools table with legacy link

- Removed Legacy Tools section
- Added send_message to Deprecated Tools table with link to legacy guide
- Removed undefined warning text

* docs: move ReAct agents to legacy section

- Moved pages/agents/react_agents.mdx to pages/legacy/react_agents_legacy.mdx
- Added deprecation warning at top
- Updated slug to guides/legacy/react_agents_legacy
- Added to Legacy & Migration navigation section
- Added redirect from old URL to new legacy location

ReAct agents are a legacy architecture that lacks long-term memory
capabilities compared to the current Letta architecture.

* docs: move workflow and low-latency architectures to legacy

- Moved pages/agents/workflows.mdx to pages/legacy/workflows_legacy.mdx
- Moved pages/agents/low_latency_agents.mdx to pages/legacy/low_latency_agents_legacy.mdx
- Deleted pages/agents/architectures.mdx (overview page no longer needed)
- Removed 'Agent Memory & Architecture' from main Agents section
- Added workflows and low-latency to Legacy & Migration section
- Added redirects for old URLs

These agent architectures (workflow_agent, voice_convo_agent) are legacy.
For new projects, users should use the current Letta architecture with
tool rules or voice-optimized configurations instead.

* docs: remove orphaned stateful workflows page

- Deleted pages/agents/stateful_workflows.mdx
- Page was not linked in navigation or from other docs
- Feature (message_buffer_autoclear flag) is already documented in API reference
- Avoids confusion with legacy workflow architectures
2025-10-24 15:13:45 -07:00

156 lines
6.0 KiB
Plaintext

---
title: Self-hosting Letta
subtitle: Learn how to run your own Letta server
slug: guides/selfhosting
---
<Note>
The recommended way to use Letta locally is with Docker.
To install Docker, see [Docker's installation guide](https://docs.docker.com/get-docker/).
For issues with installing Docker, see [Docker's troubleshooting guide](https://docs.docker.com/desktop/troubleshoot-and-support/troubleshoot/).
You can also install Letta using `pip`.
</Note>
## Running the Letta Server
You can run a Letta server with Docker (recommended) or pip.
<AccordionGroup>
<Accordion icon="docker" title="Running with Docker (recommended)" defaultOpen="true">
To run the server with Docker, run the command:
```sh
# replace `~/.letta/.persist/pgdata` with wherever you want to store your agent data
docker run \
-v ~/.letta/.persist/pgdata:/var/lib/postgresql/data \
-p 8283:8283 \
-e OPENAI_API_KEY="your_openai_api_key" \
letta/letta:latest
```
This will run the Letta server with the OpenAI provider enabled, and store all data in the folder `~/.letta/.persist/pgdata`.
If you have many different LLM API keys, you can also set up a `.env` file instead and pass that to `docker run`:
```sh
# using a .env file instead of passing environment variables
docker run \
-v ~/.letta/.persist/pgdata:/var/lib/postgresql/data \
-p 8283:8283 \
--env-file .env \
letta/letta:latest
```
</Accordion>
<Accordion icon="file-code" title="Running with pip">
You can install the Letta server via `pip` under the `letta` package:
```sh
pip install -U letta
```
To run the server once installed, simply run the `letta server` command:
To add LLM API providers, make sure that the environment variables are present in your environment.
```sh
export OPENAI_API_KEY=...
letta server
```
Note that the `letta` package only installs the server - if you would like to use the Python SDK (to create and interact with agents on the server in your Python code), then you will also need to install `letta-client` package (see the [quickstart](/quickstart) for an example).
</Accordion>
</AccordionGroup>
Once the Letta server is running, you can access it via port `8283` (e.g. sending REST API requests to `http://localhost:8283/v1`). You can also connect your server to the [Letta ADE](/guides/ade) to access and manage your agents in a web interface.
## Enabling model providers
The Letta server can be connected to various LLM API backends ([OpenAI](https://docs.letta.com/models/openai), [Anthropic](https://docs.letta.com/models/anthropic), [vLLM](https://docs.letta.com/models/vllm), [Ollama](https://docs.letta.com/models/ollama), etc.). To enable access to these LLM API providers, set the appropriate environment variables when you use `docker run`:
```sh
# replace `~/.letta/.persist/pgdata` with wherever you want to store your agent data
docker run \
-v ~/.letta/.persist/pgdata:/var/lib/postgresql/data \
-p 8283:8283 \
-e OPENAI_API_KEY="your_openai_api_key" \
-e ANTHROPIC_API_KEY="your_anthropic_api_key" \
-e OLLAMA_BASE_URL="http://host.docker.internal:11434" \
letta/letta:latest
```
<Note>
**Linux users:** Use `--network host` and `localhost` instead of `host.docker.internal`:
```sh
docker run \
-v ~/.letta/.persist/pgdata:/var/lib/postgresql/data \
--network host \
-e OPENAI_API_KEY="your_openai_api_key" \
-e ANTHROPIC_API_KEY="your_anthropic_api_key" \
-e OLLAMA_BASE_URL="http://localhost:11434" \
letta/letta:latest
```
</Note>
The example above will make all compatible models running on OpenAI, Anthropic, and Ollama available to your Letta server.
## Optional: Telemetry with ClickHouse
Letta supports optional telemetry using ClickHouse. Telemetry provides observability features like traces, LLM request logging, and performance metrics. See the [telemetry guide](/guides/server/otel) for setup instructions.
## Password protection
<Warning>
When running a self-hosted Letta server in a production environment (i.e. with untrusted users), make sure to enable both password protection (to prevent unauthorized access to your server over the network) and tool sandboxing (to prevent malicious tools from executing in a privledged environment).
</Warning>
To password protect your server, include `SECURE=true` and `LETTA_SERVER_PASSWORD=yourpassword` in your `docker run` command:
```sh
# If LETTA_SERVER_PASSWORD isn't set, the server will autogenerate a password
docker run \
-v ~/.letta/.persist/pgdata:/var/lib/postgresql/data \
-p 8283:8283 \
--env-file .env \
-e SECURE=true \
-e LETTA_SERVER_PASSWORD=yourpassword \
letta/letta:latest
```
With password protection enabled, you will have to provide your password in the bearer token header in your API requests:
<CodeGroup>
```typescript TypeScript maxLines=50
// install letta-client with `npm install @letta-ai/letta-client`
import { LettaClient } from '@letta-ai/letta-client'
// create the client with the token set to your password
const client = new LettaClient({
baseUrl: "http://localhost:8283",
token: "yourpassword"
});
```
```python title="python" maxLines=50
# install letta_client with `pip install letta-client`
from letta_client import Letta
# create the client with the token set to your password
client = Letta(
base_url="http://localhost:8283",
token="yourpassword"
)
```
```curl curl
curl --request POST \
--url http://localhost:8283/v1/agents/$AGENT_ID/messages \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer yourpassword' \
--data '{
"messages": [
{
"role": "user",
"text": "hows it going????"
}
]
}'
```
</CodeGroup>
## Tool sandboxing
To enable tool sandboxing, set the `E2B_API_KEY` and `E2B_SANDBOX_TEMPLATE_ID` environment variables (via [E2B](https://e2b.dev/)) when you use `docker run`.
When sandboxing is enabled, all custom tools (created by users from source code) will be executed in a sandboxed environment.
This does not include MCP tools, which are executed outside of the Letta server (on the MCP server itself), or built-in tools (like `memory_insert`), whose code cannot be modified after server startup.