## 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>
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:
-
Install Poetry
pip install poetry -
Configure Poetry to use .venv in your project directory
poetry config virtualenvs.in-project true -
Enter the poetry shell
poetry shell -
Install dependencies
poetry install -
Copy .env.default to .env
cp .env.default .env -
Generate the Prisma client
poetry run prisma generateIn 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 prismaThen run the generation again. The path should look something like this:
<some path>/pypoetry/virtualenvs/backend-TQIRSwR6-py3.12/bin/prisma -
Run the postgres database from the /rnd folder
cd autogpt_platform/ docker compose up -d -
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