feat(docker): add frontend service to docker-compose with env config improvements (#10536)

## 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 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

### 🔧 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

### 🛠️ 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

### 🔗 Files Changed
- `docker-compose.yml` & `docker-compose.platform.yml` - Added frontend
service
- `frontend/Dockerfile` - Added build args for environment variables
- `frontend/src/lib/env-config.ts` - New centralized environment
configuration
- Multiple frontend files - Updated to use env helpers

## 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
-  **Development friendly**: Works in both Docker and local development

## 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

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

---------

Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
Zamil Majdy
2025-08-07 12:26:28 +04:00
committed by GitHub
parent a21711a7ff
commit f172b314a4
18 changed files with 302 additions and 372 deletions

View File

@@ -107,9 +107,9 @@ If you get stuck, follow [this guide](https://docs.github.com/en/repositories/cr
Once that's complete you can continue the setup process.
### Running the backend services
### Running the AutoGPT Platform
To run the backend services, follow these steps:
To run the platform, follow these steps:
* Navigate to the `autogpt_platform` directory inside the AutoGPT folder:
```bash
@@ -120,40 +120,13 @@ To run the backend services, follow these steps:
```
cp .env.example .env
```
This command will copy the `.env.example` file to `.env` in the `supabase` directory. You can modify the `.env` file to add your own environment variables.
This command will copy the `.env.example` file to `.env` in the `autogpt_platform` directory. You can modify the `.env` file to add your own environment variables.
* Run the backend services:
* Run the platform services:
```
docker compose up -d --build
```
This command will start all the necessary backend services defined in the `docker-compose.combined.yml` file in detached mode.
### Running the frontend application
To run the frontend application open a new terminal and follow these steps:
- Navigate to `frontend` folder within the `autogpt_platform` directory:
```
cd frontend
```
- Copy the `.env.example` file available in the `frontend` directory to `.env` in the same directory:
```
cp .env.example .env
```
You can modify the `.env` within this folder to add your own environment variables for the frontend application.
- Run the following command:
```
corepack enable
pnpm install
pnpm dev
```
This command will enable corepack, install the necessary dependencies with pnpm, and start the frontend application in development mode.
This command will start all the necessary backend services defined in the `docker-compose.yml` file in detached mode.
### Checking if the application is running
@@ -185,127 +158,6 @@ poetry run cli gen-encrypt-key
Then, replace the existing key in the `autogpt_platform/backend/.env` file with the new one.
!!! Note
*The steps below are an alternative to [Running the backend services](#running-the-backend-services)*
<details>
<summary><strong>Alternate Steps</strong></summary>
#### AutoGPT Agent Server (OLD)
This is an initial project for creating the next generation of agent execution, which is an AutoGPT agent server.
The agent server will enable the creation of composite multi-agent systems that utilize AutoGPT agents and other non-agent components as its primitives.
##### Docs
You can access the docs for the [AutoGPT Agent Server here](https://docs.agpt.co/#1-autogpt-server).
##### Setup
We use the Poetry to manage the dependencies. To set up the project, follow these steps inside this directory:
0. Install Poetry
```sh
pip install poetry
```
1. Configure Poetry to use .venv in your project directory
```sh
poetry config virtualenvs.in-project true
```
2. Enter the poetry shell
```sh
poetry shell
```
3. Install dependencies
```sh
poetry install
```
4. Copy .env.example to .env
```sh
cp .env.example .env
```
5. Generate the Prisma client
```sh
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:
>
> ```sh
> 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`
6. Migrate the database. Be careful because this deletes current data in the database.
```sh
docker compose up db -d
poetry run prisma migrate deploy
```
</details>
### Starting the AutoGPT server without Docker
To run the server locally, start in the autogpt_platform folder:
```sh
cd ..
```
Run the following command to run database in docker but the application locally:
```sh
docker compose --profile local up deps --build --detach
cd backend
poetry run app
```
### Starting the AutoGPT server with Docker
Run the following command to build the dockerfiles:
```sh
docker compose build
```
Run the following command to run the app:
```sh
docker compose up
```
Run the following to automatically rebuild when code changes, in another terminal:
```sh
docker compose watch
```
Run the following command to shut down:
```sh
docker compose down
```
If you run into issues with dangling orphans, try:
```sh
docker compose down --volumes --remove-orphans && docker-compose up --force-recreate --renew-anon-volumes --remove-orphans
```
### 📌 Windows Installation Note
When installing Docker on Windows, it is **highly recommended** to select **WSL 2** instead of Hyper-V. Using Hyper-V can cause compatibility issues with Supabase, leading to the `supabase-db` container being marked as **unhealthy**.
@@ -332,14 +184,92 @@ For more details, refer to [Docker's official documentation](https://docs.docker
## Development
### Formatting & Linting
Auto formatter and linter are set up in the project. To run them:
### Frontend Development
Install:
#### Running the frontend locally
To run the frontend locally, you need to have Node.js and PNPM installed on your machine.
Install [Node.js](https://nodejs.org/en/download/) to manage dependencies and run the frontend application.
Install [PNPM](https://pnpm.io/installation) to manage the frontend dependencies.
Run the service dependencies (backend, database, message queues, etc.):
```sh
docker compose --profile local up deps_backend --build --detach
```
Go to the `autogpt_platform/frontend` directory:
```sh
cd frontend
```
Install the dependencies:
```sh
pnpm install
```
Generate the API client:
```sh
pnpm generate:api-client
```
Run the frontend application:
```sh
pnpm dev
```
#### Formatting & Linting
Auto formatter and linter are set up in the project. To run them:
Format the code:
```sh
pnpm format
```
Lint the code:
```sh
pnpm lint
```
#### Testing
To run the tests, you can use the following command:
```sh
pnpm test
```
### Backend Development
#### Running the backend locally
To run the backend locally, you need to have Python 3.10 or higher installed on your machine.
Install [Poetry](https://python-poetry.org/docs/#installation) to manage dependencies and virtual environments.
Run the backend dependencies (database, message queues, etc.):
```sh
docker compose --profile local up deps --build --detach
```
Go to the `autogpt_platform/backend` directory:
```sh
cd backend
```
Install the dependencies:
```sh
poetry install --with dev
```
Run the backend server:
```sh
poetry run app
```
#### Formatting & Linting
Auto formatter and linter are set up in the project. To run them:
Format the code:
```sh
poetry run format
@@ -350,71 +280,14 @@ Lint the code:
poetry run lint
```
### Testing
#### Testing
To run the tests:
```sh
poetry run test
poetry run pytest -s
```
To update stored snapshots after intentional API changes:
```sh
pytest --snapshot-update
```
## Project Outline
The current project has the following main modules:
#### **blocks**
This module stores all the Agent Blocks, which are reusable components to build a graph that represents the agent's behavior.
#### **data**
This module stores the logical model that is persisted in the database.
It abstracts the database operations into functions that can be called by the service layer.
Any code that interacts with Prisma objects or the database should reside in this module.
The main models are:
* `block`: anything related to the block used in the graph
* `execution`: anything related to the execution graph execution
* `graph`: anything related to the graph, node, and its relations
#### **execution**
This module stores the business logic of executing the graph.
It currently has the following main modules:
* `manager`: A service that consumes the queue of the graph execution and executes the graph. It contains both pieces of logic.
* `scheduler`: A service that triggers scheduled graph execution based on a cron expression. It pushes an execution request to the manager.
#### **server**
This module stores the logic for the server API.
It contains all the logic used for the API that allows the client to create, execute, and monitor the graph and its execution.
This API service interacts with other services like those defined in `manager` and `scheduler`.
#### **utils**
This module stores utility functions that are used across the project.
Currently, it has two main modules:
* `process`: A module that contains the logic to spawn a new process.
* `service`: A module that serves as a parent class for all the services in the project.
## Service Communication
Currently, there are only 3 active services:
- AgentServer (the API, defined in `server.py`)
- ExecutionManager (the executor, defined in `manager.py`)
- Scheduler (the scheduler, defined in `scheduler.py`)
The services run in independent Python processes and communicate through an IPC.
A communication layer (`service.py`) is created to decouple the communication library from the implementation.
Currently, the IPC is done using Pyro5 and abstracted in a way that allows a function decorated with `@expose` to be called from a different process.
## Adding a New Agent Block
To add a new agent block, you need to create a new class that inherits from `Block` and provides the following information:
@@ -424,4 +297,5 @@ To add a new agent block, you need to create a new class that inherits from `Blo
* `run` method: the main logic of the block.
* `test_input` & `test_output`: the sample input and output data for the block, which will be used to auto-test the block.
* You can mock the functions declared in the block using the `test_mock` field for your unit tests.
* Once you finish creating the block, you can test it by running `poetry run pytest -s test/block/test_block.py`.
* Once you finish creating the block, you can test it by running `poetry run pytest backend/blocks/test/test_block.py -s`.
* Create a Pull Request to the `dev` branch of the repository with your changes so you can share it with the community :)