The College E-Learning Platform uses a fully containerized deployment on AWS EC2. All application services and infrastructure run as Docker containers, with Nginx as the only native service handling SSL termination and reverse proxying.

Automation Scripts

The deploy/ folder in the backend repository contains scripts that automate most of these steps:

                    ┌─────────────────────────────────────────┐
                    │            AWS EC2 Instance              │
                    │                                         │
  Internet ──443──▶ │  Nginx (native, SSL termination)        │
                    │    ├── /                  → /var/www/html│
                    │    ├── /SaltElearning/    → :8081,:8082  │
                    │    └── /SaltELearnAppApi/ → :8091,:8092  │
                    │                                         │
                    │  ┌── Docker (salt-network) ────────────────────────┐ │
                    │  │                                                │ │
                    │  │ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
                    │  │ │backend-1  │ │backend-2  │ │web-admin-1│ │web-admin-2│ │
                    │  │ │  :8091    │ │  :8092    │ │  :8081    │ │  :8082    │ │
                    │  │ │Spring Boot│ │Spring Boot│ │ Next.js   │ │ Next.js   │ │
                    │  │ └─────┬─────┘ └─────┬─────┘ └───────────┘ └───────────┘ │
                    │  │       │             │                                    │
                    │  │ ┌──────▼──────┐ ┌──────┐ ┌──────┐  │ │
                    │  │ │salt-postgres│ │salt- │ │salt- │  │ │
                    │  │ │  :5432      │ │redis │ │minio │  │ │
                    │  │ │PostgreSQL 17│ │:6379 │ │:9000 │  │ │
                    │  │ └─────────────┘ └──────┘ └──────┘  │ │
                    │  └────────────────────────────────────┘ │
                    └─────────────────────────────────────────┘

Docker is used to run all services (backend, web admin, PostgreSQL, Redis, MinIO) as containers on EC2. Nginx is the only native service — it handles SSL termination and reverse proxying to the Docker containers.

How It Works

Verify Docker is Ready

# Check Docker is installed and running
docker --version
systemctl status docker

# Ensure the ubuntu user can run Docker without sudo
docker ps

# If "permission denied", add ubuntu to the docker group:
sudo usermod -aG docker ubuntu
# Then log out and log back in for the change to take effect

Docker User Permissions (Required for CI/CD)

# Verify ubuntu is in the docker group
groups ubuntu
# Should show: ubuntu : ubuntu docker

# If not, add it:
sudo usermod -aG docker ubuntu

# Log out and back in, then verify
docker ps   # Should work without sudo

Docker Disk Space

Docker images accumulate over time with each deployment. Monitor disk space:

# Check Docker disk usage
docker system df

# Clean up unused images and containers
docker image prune -f        # Remove dangling images
docker system prune -f       # Remove all unused objects

Backend Docker Build Process

The backend Dockerfile uses a multi-stage build (no pre-installed Maven or JDK required on EC2):

1. Stage 1 (Builder): Uses eclipse-temurin:21-jdk-alpine to compile the Spring Boot source code with Maven inside the container → produces a JAR file
2. Stage 2 (Runner): Uses eclipse-temurin:21-jre-alpine (smaller image) to run the compiled JAR

Maven, JDK, and all build tools are inside the Docker image — nothing needs to be installed on the EC2 host beyond Docker itself.

Web Admin Docker Build Process

The web admin Dockerfile also uses a multi-stage build:

1. Stage 1 (Builder): Uses node:20-alpine to install npm dependencies and build Next.js (standalone output)
2. Stage 2 (Runner): Uses node:20-alpine to run the standalone Next.js server on port 8081

Node.js and npm are inside the Docker image — no Node.js installation needed on EC2.

Create the directories where the application code and files will live:

sudo mkdir -p /opt/salvation/backend
sudo mkdir -p /opt/salvation/frontend
sudo mkdir -p /opt/salt_files
sudo mkdir -p /opt/backups
sudo chown -R ubuntu:ubuntu /opt/salvation /opt/salt_files /opt/backups

GitHub Repositories

The College E-Learning platform is split across 3 independent repositories under the SGL2024 GitHub organization:

Option A: Clone via HTTPS with Personal Access Token (Recommended)

If the repositories are private, you need a GitHub Personal Access Token (PAT):

1. Go to GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic)
2. Click Generate new token (classic)
3. Select scopes: repo (full control of private repositories)
4. Copy the generated token (you won’t see it again)

# Configure Git to cache credentials (so you don't re-enter the token every time)
git config --global credential.helper store

# Clone backend repository
cd /opt/salvation/backend
git clone https://github.com/SGL2024/Salvation-Army-Backend-main.git .
# When prompted: Username = your-github-username, Password = your-PAT-token

# Clone web admin repository
cd /opt/salvation/frontend
git clone https://github.com/SGL2024/SaltElearning.git .

# Clone mobile repository (optional — only needed for Flutter web builds)
mkdir -p /opt/salvation/mobile
cd /opt/salvation/mobile
git clone https://github.com/SGL2024/mobile.git .

Option B: Clone via SSH Key

If you prefer SSH authentication:

# 1. Generate an SSH key on the EC2 server (if not already done)
ssh-keygen -t ed25519 -C "ec2-salt-deploy"
# Press Enter to accept default path (~/.ssh/id_ed25519)

# 2. Display the public key
cat ~/.ssh/id_ed25519.pub

# 3. Add the public key to GitHub:
#    Go to GitHub → Settings → SSH and GPG keys → New SSH key
#    Paste the public key and save

# 4. Test the SSH connection
ssh -T git@github.com
# Should show: "Hi SGL2024! You've successfully authenticated..."

# 5. Clone using SSH URLs
cd /opt/salvation/backend
git clone git@github.com:SGL2024/Salvation-Army-Backend-main.git .

cd /opt/salvation/frontend
git clone git@github.com:SGL2024/SaltElearning.git .

mkdir -p /opt/salvation/mobile
cd /opt/salvation/mobile
git clone git@github.com:SGL2024/mobile.git .

Verify Clones

# Check that each directory has the code
ls /opt/salvation/backend/pom.xml       # Should exist (Spring Boot)
ls /opt/salvation/frontend/package.json  # Should exist (Next.js)
ls /opt/salvation/mobile/pubspec.yaml    # Should exist (Flutter)

# Verify Git remotes
cd /opt/salvation/backend && git remote -v
cd /opt/salvation/frontend && git remote -v

Create the .env file for the backend container:

nano /opt/salvation/backend/.env

Add the following contents:

SPRING_DATASOURCE_URL=jdbc:postgresql://salt-postgres:5432/salvation
SPRING_DATASOURCE_USERNAME=postgres
SPRING_DATASOURCE_PASSWORD=your_database_password
SPRING_REDIS_HOST=salt-redis
SPRING_REDIS_PORT=6379

PostgreSQL, Redis, and MinIO all run as Docker containers defined in docker-compose.infra.yml (located in the backend repository). This file creates the containers, volumes, and the shared salt-network.

Copy the Production Database

Place the salvation.sql file in the backend directory so PostgreSQL can initialize from it on first startup:

# Copy salvation.sql to the backend directory
cp /path/to/salvation.sql /opt/salvation/backend/salvation.sql

Start Infrastructure

cd /opt/salvation/backend

# Start PostgreSQL, Redis, and MinIO containers
docker compose -f docker-compose.infra.yml up -d

# Verify all three are running
docker compose -f docker-compose.infra.yml ps

Verify Infrastructure

# Check PostgreSQL is ready
docker exec salt-postgres pg_isready -U postgres -d salvation

# Check Redis is ready
docker exec salt-redis redis-cli ping
# Should return: PONG

# Check MinIO is ready
curl -s -o /dev/null -w "%{http_code}" http://localhost:9000/minio/health/live
# Should return: 200

What This Creates

Flyway migrations will run automatically when the backend container starts (Step 5), applying any pending schema changes.

The platform uses Hibernate (JPA) as the ORM and Flyway for database migrations. Together they ensure that JPA entity definitions stay synchronized with the PostgreSQL database schema across all environments.

How It Works in Docker

Database Initialization Flow

1. PostgreSQL container starts — loads salvation.sql into an empty database on first run (35 legacy tables). Subsequent restarts skip this step because postgres_data volume already has data.
2. Backend container starts — Flyway runs automatically and applies any pending migrations (V1–V13+). These add new tables, columns, indexes, and seed data.
3. Hibernate validates — compares all JPA @Entity classes against the database schema. In production (ddl-auto=validate), startup fails if any entity field is missing from the DB.

DDL-Auto Settings by Environment

Developer Workflow: Adding New Tables or Columns

1. Modify the @Entity class — add new fields, relationships, or create new entity classes.
2. Run locally with localhost profile — Hibernate auto-creates the new columns/tables in your local DB.
3. Generate a schema diff — run the built-in schema export tool to compare entities against the database:

   mvn spring-boot:run -Dspring-boot.run.profiles=localhost,schema-export

   This produces schema-diff.sql with the exact ALTER/CREATE statements needed.
4. Create a Flyway migration — copy the relevant SQL to a new migration file:

   cp schema-diff.sql src/main/resources/db/migration/V14__your_description.sql

5. Deploy — Flyway applies the migration on startup, then Hibernate validates the schema matches.

Docker Commands for Database Operations

# Check which Flyway migrations have been applied
docker exec salt-postgres psql -U postgres -d salvation \
  -c "SELECT version, description, installed_on FROM flyway_schema_history ORDER BY installed_rank;"

# Connect to database shell
docker exec -it salt-postgres psql -U postgres -d salvation

# View a table's structure
docker exec salt-postgres psql -U postgres -d salvation -c "\d tbl_student"

# List all tables
docker exec salt-postgres psql -U postgres -d salvation -c "\dt"

# Check Hibernate validation in backend logs
docker logs salt-backend-1 2>&1 | grep -i "schema"

# Repair Flyway (if a migration file was modified after being applied)
docker exec salt-backend-1 java -jar app.jar --spring.flyway.repair=true

Flyway Migration Conventions

Troubleshooting

The Dockerfile uses a multi-stage build:

• Stage 1 (Builder): Eclipse Temurin JDK 21 Alpine — compiles the Spring Boot source code with Maven into a JAR file
• Stage 2 (Runner): Eclipse Temurin JRE 21 Alpine — runs the compiled JAR (smaller image)

# Navigate to the backend directory
cd /opt/salvation/backend

# Build the Docker image (this compiles Spring Boot inside Docker)
docker build -t salt-backend:latest .

# Create logs directory on host
mkdir -p /opt/salvation/backend/logs

# Start the container
docker run -d \
  --name salt-backend \
  --restart unless-stopped \
  --network salt-network \
  --env-file .env \
  -e TZ=Africa/Nairobi \
  -p 8091:8091 \
  -v /opt/salt_files:/opt/salt_files \
  -v /opt/salvation/backend/logs:/app/logs \
  salt-backend:latest

Volume Summary

Wait about 15–20 seconds for Spring Boot to start, then verify:

# Check container is running
docker ps --filter "name=salt-backend"

# Check application logs
docker logs --tail 50 salt-backend

The web admin runs as 2 replicas on distinct ports, using Docker Compose:

The Dockerfile uses a multi-stage build:

• Stage 1 (Builder): Node 20 Alpine — installs dependencies and builds Next.js (standalone output)
• Stage 2 (Runner): Node 20 Alpine — runs the standalone server on the port specified by PORT env var

# Navigate to the web admin directory
cd /opt/salvation/frontend

# Build and start both replicas
docker compose up -d --build

# This builds the image once and starts two containers:
#   salt-web-admin-1 on port 8081
#   salt-web-admin-2 on port 8082

Each container runs the same Next.js image but listens on a different port via the PORT environment variable. Nginx load-balances traffic across both.

Verify:

docker ps --filter "name=salt-web-admin"
docker logs --tail 20 salt-web-admin-1
docker logs --tail 20 salt-web-admin-2

The documentation HTML files are served directly by Nginx from /var/www/html/:

sudo cp -r /opt/salvation/frontend/docs/* /var/www/html/
sudo chown -R www-data:www-data /var/www/html/

This copies all user guides, technical documentation, and the documentation hub index page to the Nginx web root.

Nginx is the only native service on EC2. It handles SSL termination and routes traffic to the correct Docker container based on the URL path. The configuration file should be at:

/etc/nginx/sites-available/stagging.saltcollegeandresourcecentre.com.conf

Key routing rules (Nginx load-balances across replicas using upstream blocks):

Example Nginx upstream configuration:

upstream backend {
    server localhost:8091;
    server localhost:8092;
}

upstream frontend_backend {
    server localhost:8081;
    server localhost:8082;
}

After any Nginx config change:

# Test the configuration
sudo nginx -t

# Reload Nginx
sudo systemctl reload nginx

In both GitHub repositories (Salvation-Army-Backend-main and SaltElearning), go to Settings → Secrets and variables → Actions and add these secrets:

Run these commands on the EC2 server to verify everything is working:

# 1. Check all containers are running
docker ps

# 2. Test infrastructure containers
docker exec salt-postgres pg_isready -U postgres -d salvation
docker exec salt-redis redis-cli ping

# 3. Test backend replicas
curl http://localhost:8091/SaltELearnAppApi/common/is_online
curl http://localhost:8092/SaltELearnAppApi/common/is_online

# 4. Test web admin replicas
curl -s -o /dev/null -w "%{http_code}" http://localhost:8081
curl -s -o /dev/null -w "%{http_code}" http://localhost:8082

# 5. Test through Nginx (public)
curl -s -o /dev/null -w "%{http_code}" https://stagging.saltcollegeandresourcecentre.com/
curl -s -o /dev/null -w "%{http_code}" https://stagging.saltcollegeandresourcecentre.com/SaltELearnAppApi/common/is_online

# 6. Check Nginx (the only native service)
systemctl status nginx

Both repositories have GitHub Actions workflows (.github/workflows/deploy.yml) that automate testing and deployment. Deployment only proceeds if all tests pass.

Pipeline Flow

What Triggers What?

Backend Pipeline — Spring Boot (Salvation-Army-Backend-main)

Workflow file: .github/workflows/deploy.yml

Automated Testing (runs on GitHub Actions runner):

• JDK 21 (Temurin) with Maven dependency caching
• Unit tests: ./mvnw test -B
• Integration tests: ./mvnw verify -B -Dskip.unit.tests=true (uses Testcontainers with PostgreSQL 17 + Redis 7)
• Test reports uploaded as artifacts (7-day retention)

Automated Deployment (after all tests pass):

1. SSH into EC2 using EC2_SSH_PRIVATE_KEY secret
2. cd /opt/salvation/backend
3. git pull origin main (or production)
4. docker build -t salt-backend:latest . — Maven compiles Spring Boot inside Docker (JDK 21 Alpine)
5. Stop & remove old container: docker stop salt-backend && docker rm salt-backend
6. Ensure Docker network: docker network create salt-network 2>/dev/null || true
7. Start new container:

docker run -d \
  --name salt-backend \
  --restart unless-stopped \
  --network salt-network \
  --env-file .env \
  -e TZ=Africa/Nairobi \
  -p 8091:8091 \
  -v /opt/salt_files:/opt/salt_files \
  -v /opt/salvation/backend/logs:/app/logs \
  salt-backend:latest

7. Health check: wait 15 seconds, verify container is running
8. Clean up: docker image prune -f

Web Admin Pipeline — Next.js (SaltElearning)

Workflow file: .github/workflows/deploy.yml

Automated Testing (runs on GitHub Actions runner):

• Node.js 20 with npm dependency caching
• Install: npm ci
• Lint: npm run lint
• Build: npm run build (Next.js standalone output)

Automated Deployment (after all tests pass):

1. SSH into EC2 using EC2_SSH_PRIVATE_KEY secret
2. cd /opt/salvation/frontend
3. git pull origin main (or production)
4. Ensure Docker network: docker network create salt-network 2>/dev/null || true
5. Build and start both replicas:

docker compose up -d --build
# Builds the image once and starts:
#   salt-web-admin-1 on port 8081
#   salt-web-admin-2 on port 8082

6. Copy docs to Nginx (NOT Docker — served as static files):

sudo cp -r docs/* /var/www/html/
sudo chown -R www-data:www-data /var/www/html/

7. Health check: wait 10 seconds, verify both containers are running
8. Clean up: docker image prune -f

Failure Logging

If a deployment fails, the pipeline automatically captures:

• Last 200 lines of container logs
• Container status and error messages
• Docker image information
• Disk space usage

These logs are visible in the GitHub Actions run output.

View Container Status

docker ps                                    # Running containers
docker ps -a                                 # All containers (including stopped)

View Logs

docker logs --tail 100 salt-backend-1       # Backend replica 1
docker logs --tail 100 salt-backend-2       # Backend replica 2
docker logs --tail 100 salt-web-admin-1     # Web admin replica 1
docker logs --tail 100 salt-web-admin-2     # Web admin replica 2
docker logs --tail 100 salt-postgres        # PostgreSQL
docker logs -f salt-backend-1               # Follow logs in real-time

Restart a Container

docker restart salt-backend-1 salt-backend-2
docker restart salt-web-admin-1 salt-web-admin-2
docker restart salt-postgres

Manual Redeploy

# Backend (both replicas)
cd /opt/salvation/backend
git pull origin main
docker compose up -d --build
# Rebuilds and restarts backend-1 (:8091) and backend-2 (:8092)

# Web Admin (both replicas)
cd /opt/salvation/frontend
git pull origin main
docker compose up -d --build
# Rebuilds and restarts web-admin-1 (:8081) and web-admin-2 (:8082)

# Copy docs
sudo cp -r docs/* /var/www/html/

Rollback to Previous Version

# The deploy scripts tag the current image as :previous before each deployment
# To roll back:
docker stop salt-backend && docker rm salt-backend
docker run -d --name salt-backend --restart unless-stopped \
  --network salt-network --env-file .env \
  -e TZ=Africa/Nairobi \
  -p 8091:8091 -v /opt/salt_files:/opt/salt_files \
  -v /opt/salvation/backend/logs:/app/logs salt-backend:previous

Clean Up Disk Space

docker image prune -f                        # Remove unused images
docker system prune -f                       # Remove all unused Docker objects

Data Persistence & Volumes

All persistent data is stored in Docker named volumes or host bind mounts. Data survives container restarts, redeployments, and image rebuilds.

Database Backup

# Create a backup (from the PostgreSQL container)
docker exec salt-postgres pg_dump -U postgres -d salvation -F p \
  > /opt/backups/salvation_$(date +%Y%m%d).sql

# Restore from backup
cat /opt/backups/salvation_20260220.sql | \
  docker exec -i salt-postgres psql -U postgres -d salvation

# Automated backup (add to crontab)
# Run daily at 2 AM:
# 0 2 * * * docker exec salt-postgres pg_dump -U postgres -d salvation -F p > /opt/backups/salvation_$(date +\%Y\%m\%d).sql

The platform uses 3 separate Docker Compose files, each managing its own service independently:

All three share a Docker network called salt-network so containers can communicate by name (e.g., the backend connects to salt-postgres:5432).

Docker Compose Volumes

Docker Compose does NOT auto-load salvation.sql via docker-entrypoint-initdb.d. Instead, the database is initialized once using the setup script:

# First-time database setup (run once after starting the PostgreSQL container)
bash deploy/setup-db.sh --staging

Place salvation.sql in the backend directory (/opt/salvation/backend/) before running the setup script. The script creates the salvation database and loads the SQL dump. Subsequent container restarts skip this step because the postgres_data volume already has data.

Startup Order

# 1. Start infrastructure first (PostgreSQL, Redis, MinIO)
cd /opt/salvation/backend
docker compose -f docker-compose.infra.yml up -d

# 2. Start backend (connects to infrastructure via salt-network)
docker compose up -d

# 3. Start frontend
cd /opt/salvation/frontend
docker compose up -d

# Check all containers
docker ps

Rebuild a Single Service

# Rebuild and restart only the backend
cd /opt/salvation/backend
docker compose up -d --build

# Rebuild and restart only the frontend
cd /opt/salvation/frontend
docker compose up -d --build

All containers must be on the same Docker network (salt-network) so they can communicate with each other by container name. This applies whether containers are started via docker compose or individual docker run commands.

Create the Network

The network is created automatically by docker-compose.infra.yml when you start infrastructure. You can also create it manually (safe to run multiple times):

# Create the shared bridge network (idempotent)
docker network create salt-network 2>/dev/null || true

Why All Containers Must Share a Network

Since all services (PostgreSQL, Redis, MinIO, Backend, Frontend) run as Docker containers, they must share a network to communicate. Docker DNS resolves container names automatically within the same network.

Container Names on the Network

Verify Network Connectivity

# List all containers on salt-network
docker network inspect salt-network --format '{{range .Containers}}{{.Name}} {{end}}'

# Test connectivity between containers
docker exec salt-backend ping -c 2 salt-postgres
docker exec salt-backend ping -c 2 salt-redis
docker exec salt-web-admin ping -c 2 salt-backend

# Check which networks a container is connected to
docker inspect salt-backend --format '{{range $k,$v := .NetworkSettings.Networks}}{{$k}} {{end}}'

Docker Swarm enables scaling, load balancing, and high availability for the platform services. It is built into Docker — no additional software needed.

Initialize Docker Swarm

# On the EC2 server (manager node)
docker swarm init

# Note the join token for adding worker nodes later:
docker swarm join-token worker

Prepare Docker Compose for Swarm

The backend docker-compose.yml defines 2 named replicas with distinct ports:

Each replica runs the same Spring Boot image but listens on a different port via the SERVER_PORT environment variable. Nginx load-balances traffic across both.

Before deploying with Docker Swarm, remove the container_name directives (Swarm manages naming dynamically):

# Step 1: Remove fixed container_name lines from docker-compose.yml
# Swarm does not support container_name with service replicas
sed -i '/container_name: salt-backend/d' docker-compose.yml

# Step 2: Build images and start both backend services
# --build forces a fresh image build from the Dockerfile before starting
docker compose up -d --build

Create the Shared Network

# Create an overlay network for Swarm services
docker network create --driver overlay --attachable salt-network

Deploy Infrastructure Stack

# From backend directory
cd /opt/salvation/backend
docker stack deploy -c docker-compose.infra.yml salt-infra

# Check services
docker stack services salt-infra

Deploy Backend Stack

cd /opt/salvation/backend
docker stack deploy -c docker-compose.yml salt-backend

# 2 services: backend-1 (:8091) and backend-2 (:8092)
docker stack services salt-backend

Deploy Frontend Stack

cd /opt/salvation/frontend
docker stack deploy -c docker-compose.yml salt-frontend

# 2 services: web-admin-1 (:8081) and web-admin-2 (:8082)
docker stack services salt-frontend

Scaling Reference

Useful Swarm Commands

# View all stacks
docker stack ls

# View services in a stack
docker stack services salt-backend

# View tasks (containers) for a service
docker service ps salt-backend_backend

# View logs for a service
docker service logs salt-backend_backend --tail 50

# Update a service (rolling update)
docker service update --image salt-backend:latest salt-backend_backend

# Remove a stack
docker stack rm salt-backend

Rolling Updates

Docker Swarm performs rolling updates by default. When you rebuild an image and update the service, it replaces containers one at a time with zero downtime:

# Rebuild the image
cd /opt/salvation/backend
docker build -t salt-backend:latest .

# Update the running service with the new image
docker service update --image salt-backend:latest salt-backend_backend

Container won’t start

# Check the logs for errors
docker logs --tail 200 salt-backend

# Common issues:
# - "Connection refused" to PostgreSQL → check salt-postgres container is running
# - "Unable to connect to Redis" → check salt-redis container is running
# - Port already in use → check if another process is using the port:
ss -tlnp | grep 8091

Backend can’t connect to PostgreSQL

# 1. Verify salt-postgres container is running
docker ps --filter "name=salt-postgres"

# 2. Verify both containers are on the same network
docker network inspect salt-network --format '{{range .Containers}}{{.Name}} {{end}}'

# 3. Test connectivity from backend to PostgreSQL
docker exec salt-backend ping -c 2 salt-postgres

# 4. Verify .env has the correct container name
# Should be: SPRING_DATASOURCE_URL=jdbc:postgresql://salt-postgres:5432/salvation
# NOT: localhost or host.docker.internal

# 5. Check PostgreSQL logs
docker logs --tail 50 salt-postgres

Docker build fails

# Check disk space
df -h /

# Free up space
docker system prune -f

# Check Docker daemon
systemctl status docker

Nginx returns 502 Bad Gateway

# The upstream service (Docker container) is not running
docker ps  # Check if the container is running
docker logs salt-backend  # Check for startup errors

# Check Nginx error log
sudo tail -50 /var/log/nginx/error.log

GitHub Actions deployment fails

Check the GitHub Actions run output for detailed logs. The pipeline captures failure logs automatically, including container status, application logs, and disk space.

# Manually check on EC2 after a failed deploy
docker ps -a
docker logs --tail 200 salt-backend
df -h /

Infrastructure containers not starting

# Check infrastructure container status
docker compose -f /opt/salvation/backend/docker-compose.infra.yml ps

# Restart infrastructure
docker compose -f /opt/salvation/backend/docker-compose.infra.yml down
docker compose -f /opt/salvation/backend/docker-compose.infra.yml up -d

# Check individual container logs
docker logs salt-postgres
docker logs salt-redis
docker logs salt-minio