Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/joaomonteir0/printheritage/llms.txt

Use this file to discover all available pages before exploring further.

PrintHeritage bundles every component it needs into a Docker Compose file at the repository root. A single docker compose up command provisions a PostgreSQL 15 database, the FastAPI auth service, and the React front-end, wiring them together through a shared virtual network. This page explains each service, the environment variables that control runtime behaviour, and how to keep your deployment secure and maintainable.
The SECRET_KEY used to sign JWT tokens is currently set to a hardcoded placeholder value (CHAVE_MUITO_SECRETA_PARA_PRODUCAO) in docker-compose.yml. You must replace it with a cryptographically random secret before running PrintHeritage in any environment reachable over a network. Tokens signed with a known key can be forged.

​
Services

The docker-compose.yml file defines three services. They start in dependency order: db-auth first, then auth-service, then front-end.

​
db-auth — PostgreSQL database

Runs the official postgres:15-alpine image. It stores all user accounts, project records, permissions, and audit logs in a named volume so data survives container restarts. 
db-auth:
  image: postgres:15-alpine
  container_name: auth-db-postgres
  restart: always
  environment:
    POSTGRES_USER: auth_user
    POSTGRES_PASSWORD: auth_password
    POSTGRES_DB: auth_db
  ports:
    - "5432:5432"
  volumes:
    - auth_db_data:/var/lib/postgresql/data

​
auth-service — FastAPI API

Built from ./auth-service using the local Dockerfile. It connects to db-auth, creates the schema on startup via SQLAlchemy, and seeds the default super-admin account if it does not already exist. 
auth-service:
  build: ./auth-service
  container_name: auth-service-api
  restart: always
  environment:
    - DATABASE_URL=postgresql://auth_user:auth_password@db-auth:5432/auth_db
    - SECRET_KEY=CHAVE_MUITO_SECRETA_PARA_PRODUCAO
  ports:
    - "8001:8000"
  depends_on:
    - db-auth
  volumes:
    - ./auth-service:/app
The ./auth-service:/app bind mount means code changes on the host are immediately reflected inside the container — useful during development without needing to rebuild.

​
front-end — React application

Built from ./front-end. The REACT_APP_API_URL environment variable is injected at build time and tells the Axios client where to find the auth service. 
front-end:
  build: ./front-end
  container_name: front-end-react
  restart: always
  ports:
    - "3000:3000"
  volumes:
    - ./front-end/src:/app/src
  depends_on:
    - auth-service
  environment:
    - REACT_APP_API_URL=http://localhost:8001

​
Exposed ports

ServiceHost portContainer portPurpose
db-auth54325432PostgreSQL (direct access)
auth-service80018000FastAPI REST API
front-end30003000React development server
In a production deployment behind a reverse proxy (e.g. Nginx or Caddy), you should remove the host-side port binding for db-auth (5432:5432) so the database is not reachable from outside the Docker network.

​
Environment variables

​
auth-service

VariableDefault valueDescription
DATABASE_URLpostgresql://auth_user:auth_password@db-auth:5432/auth_dbFull SQLAlchemy connection string for the PostgreSQL instance.
SECRET_KEYCHAVE_MUITO_SECRETA_PARA_PRODUCAOSecret used to sign and verify HS256 JWT tokens. Must be changed.
Generate a strong SECRET_KEY with: 
python3 -c "import secrets; print(secrets.token_hex(32))"

​
front-end

VariableDefault valueDescription
REACT_APP_API_URLhttp://localhost:8001Base URL the React app uses for all API requests. Update this to your public API hostname in production.

​
db-auth

VariableDefault valueDescription
POSTGRES_USERauth_userPostgreSQL superuser name for the auth_db database.
POSTGRES_PASSWORDauth_passwordPassword for auth_user. Change before production use.
POSTGRES_DBauth_dbName of the database created on first start.

​
Volume

A single named volume handles database persistence: 
volumes:
  auth_db_data:
auth_db_data is mounted at /var/lib/postgresql/data inside the db-auth container. All tables, rows, and indexes survive docker compose down and are reused when the stack is started again. To wipe all data and start fresh, run: 
docker compose down -v

​
Startup sequence

The depends_on directives enforce the following startup order: 
db-auth  →  auth-service  →  front-end
  1. db-auth starts first and initialises the auth_db database.
  2. auth-service waits for db-auth, then calls Base.metadata.create_all() to create tables and seeds the super@print.com super-admin account if it does not exist.
  3. front-end waits for auth-service before starting the React development server.
Docker Compose’s depends_on only waits for the container to start, not for the service inside it to become ready. If auth-service crashes because PostgreSQL hasn’t finished initialising yet, Docker’s restart: always policy will restart it automatically until the database accepts connections.

​
Rebuilding after code changes

The ./auth-service and ./front-end/src directories are bind-mounted into their containers, so Python and React source file edits are picked up at runtime without a rebuild. However, changes to requirements.txt, package.json, or either Dockerfile require a full rebuild: 
docker compose up --build
To rebuild a single service without restarting the others: 
docker compose up --build auth-service

​
Stopping and removing the stack

Stop all containers while keeping volumes intact: 
docker compose down
Stop all containers and delete all volumes (this destroys the database): 
docker compose down -v

Build docs developers (and LLMs) love

Get started for freeTalk to us