Files
AutoGPT/docs/content/platform/advanced_setup.md
Zamil Majdy 4bfeddc03d feat(platform/docker): add frontend service to docker-compose with env config improvements (#10615)
## Summary
This PR adds the frontend service to the Docker Compose configuration,
enabling `docker compose up` to run the complete stack, including the
frontend. It also implements comprehensive environment variable
improvements, unified .env file support, and fixes Docker networking
issues.

## Key Changes

### 🐳 Docker Compose Improvements
- **Added frontend service** to `docker-compose.yml` and
`docker-compose.platform.yml`
- **Production build**: Uses `pnpm build + serve` instead of dev server
for better stability and lower memory usage
- **Service dependencies**: Frontend now waits for backend services
(`rest_server`, `websocket_server`) to be ready
- **YAML anchors**: Implemented DRY configuration to avoid duplicating
environment values

### 📁 Unified .env File Support
- **Frontend .env loading**: Automatically loads `.env` file during
Docker build and runtime
- **Backend .env loading**: Optional `.env` file support with fallback
to sensible defaults in `settings.py`
- **Single source of truth**: All `NEXT_PUBLIC_*` and API keys can be
defined in respective `.env` files
- **Docker integration**: Updated `.dockerignore` to include `.env`
files in build context
- **Git tracking**: Frontend and backend `.env` files are now trackable
(removed from gitignore)

### 🔧 Environment Variable Architecture
- **Dual environment strategy**: 
- Server-side code uses Docker service names
(`http://rest_server:8006/api`)
  - Client-side code uses localhost URLs (`http://localhost:8006/api`)
- **Comprehensive config**: Added build args and runtime environment
variables
- **Network compatibility**: Fixes connection issues between frontend
and backend containers
- **Shared backend variables**: Common environment variables (service
hosts, auth settings) centralized using YAML anchors

### 🛠️ Code Improvements
- **Centralized env-config helper** (`/frontend/src/lib/env-config.ts`)
with server-side priority
- **Updated all frontend code** to use shared environment helpers
instead of direct `process.env` access
- **Consistent API**: All environment variable access now goes through
helper functions
- **Settings.py improvements**: Better defaults for CORS origins and
optional .env file loading

### 🔗 Files Changed
- `docker-compose.yml` & `docker-compose.platform.yml` - Added frontend
service and shared backend env vars
- `frontend/Dockerfile` - Simplified build process to use .env files
directly
- `backend/settings.py` - Optional .env loading and better defaults
- `frontend/src/lib/env-config.ts` - New centralized environment
configuration
- `.dockerignore` - Allow .env files in build context
- `.gitignore` - Updated to allow frontend/backend .env files
- Multiple frontend files - Updated to use env helpers
- Updates to both auto installer scripts to work with the latest setup!

## Benefits
-  **Single command deployment**: `docker compose up` now runs
everything
-  **Better reliability**: Production build reduces memory usage and
crashes
-  **Network compatibility**: Proper container-to-container
communication
-  **Maintainable config**: Centralized environment variable management
with .env files
-  **Development friendly**: Works in both Docker and local development
-  **API key management**: Easy configuration through .env files for
all services
-  **No more manual env vars**: Frontend and backend automatically load
their respective .env files

## Testing
-  Verified Docker service communication works correctly
-  Frontend responds and serves content properly  
-  Environment variables are correctly resolved in both server and
client contexts
-  No connection errors after implementing service dependencies
-  .env file loading works correctly in both build and runtime phases
-  Backend services work with and without .env files present

### Checklist 📋

#### For configuration changes:
- [x] `.env.default` is updated or already compatible with my changes
- [x] `docker-compose.yml` is updated or already compatible with my
changes
- [x] I have included a list of my configuration changes in the PR
description (under **Changes**)

🤖 Generated with [Claude Code](https://claude.ai/code)

---------

Co-authored-by: Lluis Agusti <hi@llu.lu>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Nicholas Tindle <nicholas.tindle@agpt.co>
Co-authored-by: Claude <claude@users.noreply.github.com>
Co-authored-by: Bentlybro <Github@bentlybro.com>
2025-08-14 03:28:18 +00:00

3.7 KiB

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.

Introduction

For the advanced setup, first follow the basic setup guide 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.

Configuration

Setting config via environment variables

The server uses environment variables to store configs. You can set these environment variables in a .env file in the root of the project. The .env file should look like this:

# .env
KEY1=value1
KEY2=value2

The server will automatically load the .env file when it starts. 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.

The valid options are listed in .env.default in the root of the builder and server directories. You can copy the .env.default file to .env and modify the values as needed.

# Copy the .env.default file to .env
cp .env.default .env

Secrets directory

The secret directory is located at ./secrets. You can store any secrets you need in this directory. The server will automatically load the secrets when it starts.

An example for a secret called my_secret would look like this:

# ./secrets/my_secret
my_secret_value

This is useful when running on docker so you can copy the secrets into the container without exposing them in the Dockerfile.

Database selection

PostgreSQL

We use a Supabase PostgreSQL as the database. You will swap the commands you use to generate and run prisma to the following

poetry run prisma generate --schema postgres/schema.prisma

This will generate the Prisma client for PostgreSQL. You will also need to run the PostgreSQL database in a separate container. You can use the docker-compose.yml file in the rnd directory to run the PostgreSQL database.

cd autogpt_platform/
docker compose up -d --build

You can then run the migrations from the backend directory.

cd ../backend
prisma migrate dev --schema postgres/schema.prisma

AutoGPT Agent Server Advanced set up

This guide walks you through a dockerized set up, with an external DB (postgres)

Setup

We use the Poetry to manage the dependencies. To set up the project, follow these steps inside this directory:

  1. Install Poetry

    pip install poetry
    
  2. Configure Poetry to use .venv in your project directory

    poetry config virtualenvs.in-project true
    
  3. Enter the poetry shell

    poetry shell
    
  4. Install dependencies

    poetry install
    
  5. Copy .env.default to .env

    cp .env.default .env
    
  6. Generate the Prisma client

    poetry run prisma generate
    

    In case Prisma generates the client for the global Python installation instead of the virtual environment, the current mitigation is to just uninstall the global Prisma package:

    pip uninstall prisma
    

    Then run the generation again. The path should look something like this:
    <some path>/pypoetry/virtualenvs/backend-TQIRSwR6-py3.12/bin/prisma

  7. Run the postgres database from the /rnd folder

    cd autogpt_platform/
    docker compose up -d
    
  8. Run the migrations (from the backend folder)

    cd ../backend
    prisma migrate deploy
    

Running The Server

Starting the server directly

Run the following command:

poetry run app