> For the complete documentation index, see [llms.txt](https://agpt.co/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://agpt.co/docs/platform/self-hosting/advanced_setup.md). # Advanced Setup The advanced steps below are intended for people with sysadmin experience. If you are not comfortable with these steps, please refer to the [basic setup guide](/docs/platform/self-hosting/getting-started.md). ## Introduction For the advanced setup, first follow the [manual setup](/docs/platform/self-hosting/getting-started.md#manual-setup) to get the server up and running. Once you have the server running, you can follow the steps below to configure the server for your specific needs. These steps apply to the Docker Compose setup; the [single-container image](/docs/platform/self-hosting/single-container.md) is configured with the environment variables you pass to `docker run`. ## Configuration ### Setting config via environment variables The server uses environment variables to store configs. Each part of the platform reads its own `.env` file inside `autogpt_platform/`: * `backend/.env` for the backend services * `frontend/.env` for the frontend * `.env` for Docker Compose itself The valid options are listed, with a comment for each, in the `.env.default` file next to each `.env`. `make init-env` creates any missing `.env` from its `.env.default` and generates the secrets that `.env.default` leaves blank: ```bash cd autogpt_platform make init-env ``` Then edit the `.env` files to change what you need. Do not copy `.env.default` over an existing `.env`: that erases your generated `ENCRYPTION_KEY`, and the integration credentials stored under it can no longer be read. With Docker Compose, the `environment:` entries in `docker-compose.platform.yml` take precedence over the `.env` files. They connect the services to each other by their Compose names and set the database URLs, so change those settings in `docker-compose.platform.yml`. When you run the backend outside Docker, you can also set the environment variables directly in your shell. Refer to your operating system's documentation on how to set environment variables in the current session. ## Database selection ### PostgreSQL We use PostgreSQL 15 with the pgvector extension as the database. Docker Compose runs it as the `db` service, keeps its data in `autogpt_platform/data/db/data`, and applies the Prisma migrations through the `migrate` service every time you run `docker compose up`. To use your own PostgreSQL server instead: 1. Make sure the `vector` and `pg_trgm` extensions are available on it; the migrations create them. 2. Run `autogpt_platform/db/init/00-init.sql` against the database once. It creates the `platform` schema and an empty `auth.users` table that older migrations reference. 3. Point `DATABASE_URL` and `DIRECT_URL` at it, keeping `schema=platform` (in `docker-compose.platform.yml` under Docker, or in `backend/.env` when you run the backend directly), and point the frontend's `DATABASE_URL` at the same database. The `migrate` service, or `make migrate` outside Docker, then applies the migrations. ## Redis The platform uses Redis for caching, distributed locks, rate limits, and the streams that carry agent output to the browser. The Docker Compose stack runs its own Redis Cluster: three `redis:7` shards on ports `17000` to `17002` of `127.0.0.1`, joined by a one-shot `redis-init` service. They require the `REDIS_PASSWORD` that `make init-env` generates in `backend/.env`. `make start-core` starts it along with the other dependencies. ### Using an external Redis cluster The backend connects with a cluster client only, so the deployment must have cluster mode enabled. A standalone server, with cluster mode disabled, does not work. The cluster also needs: * **Redis 7.0 or later, or a compatible engine such as Valkey.** The backend uses sharded pub/sub (`SPUBLISH`, `SSUBSCRIBE`), which Redis 7.0 introduced, along with Streams and Lua scripts. It uses no Redis modules. * **Shard addresses the backend can reach.** With `REDIS_USE_ANNOUNCED_ADDRESS=true`, the backend connects to each shard at the address the cluster announces, so those addresses must resolve from where the backend runs. Without it, the backend connects to every shard at `REDIS_HOST` and keeps only the announced port, which works only when every shard is reachable on that one host. * **A private network between the backend and every shard.** The backend connects without TLS and does not send a username. It sends `REDIS_PASSWORD` when one is set, and a cluster without a password works too. Nothing on the connection is encrypted, so don't route it over a network you don't trust. Point `REDIS_HOST` and `REDIS_PORT` at any node of the cluster, and set `REDIS_PASSWORD` if the cluster has one. In the Compose stack, `REDIS_HOST`, `REDIS_PORT` and `REDIS_USE_ANNOUNCED_ADDRESS` are set in the `x-backend-env` block of `autogpt_platform/docker-compose.platform.yml`, which takes precedence over `backend/.env`, so change them there. `REDIS_PASSWORD` is read from `backend/.env`. Point `backend/.env` at the cluster too, with `REDIS_HOST` or with `REDIS_CLUSTER_HOST`, which the backend reads first: while the one it reads names the bundled cluster (`localhost`, as `.env.default` has it), `make init-env` gives a blank `REDIS_PASSWORD` a generated value, which a cluster without a password refuses. The bundled shards still start, because the backend services wait for `redis-0` to be healthy. ## AutoGPT Agent Server Advanced set up To run the backend server outside Docker with Poetry, follow [Backend Development](/docs/platform/self-hosting/getting-started.md#backend-development). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://agpt.co/docs/platform/self-hosting/advanced_setup.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.