FastAPI Project - Development

Docker Compose

Start the local stack with Docker Compose:

docker compose watch

Now you can open your browser and interact with these URLs:

Frontend, built with Docker, with routes handled based on the path: http://localhost:5173

Backend, JSON based web API based on OpenAPI: http://localhost:8000

Automatic interactive documentation with Swagger UI (from the OpenAPI backend): http://localhost:8000/docs

Adminer, database web administration: http://localhost:8080

Traefik UI, to see how the routes are being handled by the proxy: http://localhost:8090

Note: The first time you start your stack, it might take a minute for it to be ready. While the backend waits for the database to be ready and configures everything. You can check the logs to monitor it.

To check the logs, run (in another terminal):

docker compose logs

To check the logs of a specific service, add the name of the service, e.g.:

docker compose logs backend

Mailcatcher

Mailcatcher is a simple SMTP server that catches all emails sent by the backend during local development. Instead of sending real emails, they are captured and displayed in a web interface.

This is useful for:

Testing email functionality during development
Verifying email content and formatting
Debugging email-related functionality without sending real emails

The backend is automatically configured to use Mailcatcher when running with Docker Compose locally (SMTP on port 1025). All captured emails can be viewed at http://localhost:1080.

Local Development

You can run the entire environment in a hybrid fashion (database/redis in Docker, backend/frontend code on the host). This is the recommended option for developers looking for a fast, light, and low-storage workflow.

1. Hybrid Development (Docker Services + Local Apps)

To avoid running heavy Python and Node Docker images, run the core services (Postgres & Redis) in Docker, and run your code natively on the host:

Create a .env.local file at the root of the project to target your host's ports (this file is gitignored):
```
POSTGRES_SERVER=localhost
REDIS_URL=redis://localhost:6379/0
```
Start the databases and both development servers simultaneously with:
```
bun run dev:local
```
This command starts Postgres and Redis in Docker background mode, triggers fastapi dev for the backend on your host, and starts Vite for the frontend.

To stop the databases, run:

bun run services:down

2. Manual Host Running (Separated)

If you prefer to start and control services individually:

Start DB & Redis in Docker:
```
docker compose up -d db redis
```

Run Backend (Host):

cd backend
uv sync
uv run fastapi dev app/main.py

Run Frontend (Host):
```
cd frontend
bun install
bun run dev
```

Docker Compose in `localhost.tiangolo.com`

When you start the Docker Compose stack, it uses localhost by default, with different ports for each service (backend, frontend, adminer, etc).

When you deploy it to production (or staging), it will deploy each service in a different subdomain, like api.example.com for the backend and dashboard.example.com for the frontend.

In the guide about deployment you can read about Traefik, the configured proxy. That's the component in charge of transmitting traffic to each service based on the subdomain.

If you want to test that it's all working locally, you can edit the local .env file, and change:

DOMAIN=localhost.tiangolo.com

That will be used by the Docker Compose files to configure the base domain for the services.

Traefik will use this to transmit traffic at api.localhost.tiangolo.com to the backend, and traffic at dashboard.localhost.tiangolo.com to the frontend.

The domain localhost.tiangolo.com is a special domain that is configured (with all its subdomains) to point to 127.0.0.1. This way you can use that for your local development.

After you update it, run again:

docker compose watch

When deploying, for example in production, the main Traefik is configured outside of the Docker Compose files. For local development, there's an included Traefik in compose.override.yml, just to let you test that the domains work as expected, for example with api.localhost.tiangolo.com and dashboard.localhost.tiangolo.com.

Docker Compose files and env vars

There is a main compose.yml file with all the configurations that apply to the whole stack, it is used automatically by docker compose.

And there's also a compose.override.yml with overrides for development, for example to mount the source code as a volume. It is used automatically by docker compose to apply overrides on top of compose.yml.

These Docker Compose files use the .env file containing configurations to be injected as environment variables in the containers.

They also use some additional configurations taken from environment variables set in the scripts before calling the docker compose command.

After changing variables, make sure you restart the stack:

docker compose watch

The .env file

The .env file is the one that contains all your configurations, generated keys and passwords, etc.

Depending on your workflow, you could want to exclude it from Git, for example if your project is public. In that case, you would have to make sure to set up a way for your CI tools to obtain it while building or deploying your project.

One way to do it could be to add each environment variable to your CI/CD system, and updating the compose.yml file to read that specific env var instead of reading the .env file.

Pre-commits and code linting

we are using a tool called prek (modern alternative to Pre-commit) for code linting and formatting.

When you install it, it runs right before making a commit in git. This way it ensures that the code is consistent and formatted even before it is committed.

You can find a file .pre-commit-config.yaml with configurations at the root of the project.

Install prek to run automatically

prek is already part of the dependencies of the project.

After having the prek tool installed and available, you need to "install" it in the local repository, so that it runs automatically before each commit.

Using uv, you could do it with (make sure you are inside backend folder):

❯ uv run prek install -f
prek installed at `../.git/hooks/pre-commit`

The -f flag forces the installation, in case there was already a pre-commit hook previously installed.

Now whenever you try to commit, e.g. with:

git commit

...prek will run and check and format the code you are about to commit, and will ask you to add that code (stage it) with git again before committing.

Then you can git add the modified/fixed files again and now you can commit.

Running prek hooks manually

you can also run prek manually on all the files, you can do it using uv with:

❯ uv run prek run --all-files
check for added large files..............................................Passed
check toml...............................................................Passed
check yaml...............................................................Passed
fix end of files.........................................................Passed
trim trailing whitespace.................................................Passed
ruff.....................................................................Passed
ruff-format..............................................................Passed
biome check..............................................................Passed

Some changes (for example under backend/ or scripts/generate-client.sh) may also trigger the local generate-frontend-sdk hook, which regenerates the typed frontend SDK by running bash ./scripts/generate-client.sh. That hook requires the Docker backend service to be up and healthy.

In addition, the hook executes bun run commands in the frontend/ workspace, so you must have bun installed on the host.

Combined Validation & Testing Commands

To make code verification simpler and faster, several combined workspace-level commands are configured in the root package.json:

Static Code Checks:
```
bun run check
```
This runs static analysis across both frontend and backend without running test suites or touching databases. It checks formatting and lint rules (using Biome and Ruff) and performs full TypeScript typechecking (tsc --noEmit) and Python typechecking (mypy).
Run All Tests:
```
bun run test
```
Runs the backend pytest suite first, then runs the frontend playwright end-to-end test suite. (Note: Backend DB/Redis services must be running for this command).
Full verification (CI simulation):
```
bun run verify
```
Runs bun run check and bun run test consecutively. Use this to fully verify your changes before proposing commits or creating pull requests.