Deploying a Letta server remotely

The Letta server can be deployed remotely, for example on cloud services like Railway, or also on your own self-hosted infrastructure. For an example guide on how to remotely deploy the Letta server, see our Railway deployment guide.

Connecting the cloud/web ADE to your remote server

Danger

The cloud/web ADE can only connect to remote servers running on https.

The cloud (web) ADE is only able to connect to remote servers running on https

• the only exception is localhost, for which http is allowed (except for Safari, where it is also blocked).

Most cloud services have ingress tools that will handle certificate management for you and you will automatically be provisioned an https address (for example Railway will automatically generate a static https address for your deployment).

Using a reverse proxy to generate an https address

If you are running your Letta server on self-hosted infrastructure, you may need to manually create an https address for your server. This can be done in numerous ways using reverse proxies:

1. Use a service like ngrok to get an https address (on ngrok) for your server
2. Use Caddy or Traefik as a reverse proxy (which will manage the certificates for you)
3. Use nginx with Let’s Encrypt as a reverse proxy (manage the certificates yourself)

Port forwarding to localhost

Alternatively, you can also forward your server’s http address to localhost, since the https restriction does not apply to localhost (on browsers other than Safari):

ssh -L 8283:localhost:8283 your_server_username@your_server_ip

If you use the port forwarding approach, then you will not need to “Add remote server” in the ADE, instead the server will be accessible under “Local server”.

Securing your Letta server

Danger

Do not expose your Letta server to the public internet unless it is password protected (either via the SECURE environment variable, or your own protection mechanism).

If you are running your Letta server on a cloud service (like Railway) that exposes your server via a static IP address, you will likely want to secure your Letta server with a password by using the SECURE environment variable. For more information, see our password guide.

Note that the SECURE variable does not have anything to do with https, it simply turns on basic password protection to the API requests going to your Letta server. Make sure to also enable tool sandboxing if you are allowing untrusted users to create tools on your Letta server.

Connecting to a persistent database volume

Danger

If you do not mount a persistent database volume, your agent data will be lost when your Docker container restarts.

The Postgres database inside the Letta Docker image will look attempt to store data at /var/lib/postgresql/data, so to make sure your state persists across container restarts, you need to mount a volume (with a persistent data store) to that directory.

For example, the recommend docker run command includes -v ~/.letta/.persist/pgdata:/var/lib/postgresql/data as a flag, which mounts your local directory ~/.letta/.persist/pgdata to the container’s /var/lib/postgresql/data directory (so all your agent data is stored at ~/.letta/.persist/pgdata).

Different cloud infrastructure platforms will handle mounting differently. You can view our Railway deployment guide for an example of how to do this.

Connecting to an external Postgres database

Tip

Unless you have a specific reason to use an external database, we recommend using the internal database provided by the Letta Docker image, and simply mounting a volume to make sure your database is persistent across restarts.

You can connect Letta to an external Postgres database by setting the LETTA_PG_URI environment variable to the connection string of your Postgres database. To have the server connect to the external Postgres properly, you will need to use alembic or manually create the database and tables.