digiserver-v2/old_code_documentation/DEPLOYMENT_ARCHITECTURE_ANALYSIS.md

Dockerfile vs init-data.sh Analysis

Date: January 17, 2026

Current Architecture

Current Workflow

1. Run init-data.sh (on host)
   ↓
2. Copies app code → data/app/
3. Docker build creates image
4. Docker run mounts ./data:/app
5. Container runs with host's data/ folder

Current Docker Setup

• Dockerfile: Copies code from build context to /app inside image
• docker-compose: Mounts ./data:/app OVERRIDING the Dockerfile copy
• Result: Code in image is replaced by volume mount to host's ./data folder

---

Problem with Current Approach

1. Code Duplication

   • Code exists in: Host ./app/ folder
   • Code copied to: Host ./data/app/ folder
   • Code in Docker image: Ignored/overridden

2. Extra Deployment Step

   • Must run init-data.sh before deployment
   • Manual file copying required
   • Room for sync errors

3. No Dockerfile Optimization

   • Dockerfile copies code but it's never used
   • Volume mount replaces everything
   • Wastes build time and image space

---

Proposed Solution: Two Options

Option 1: Use Dockerfile Copy (Recommended) ✅

Change Dockerfile:

# Copy everything to /app inside image
COPY . /app/

# No need for volume mount - image contains all code

Change docker-compose.yml:

volumes:
  # REMOVE the ./data:/app volume mount
  # Keep only data-specific mounts:
  - ./data/instance:/app/instance      # Database
  - ./data/uploads:/app/app/static/uploads  # User uploads

Benefits:

• ✅ Single source of truth (Dockerfile)
• ✅ Code is immutable in image
• ✅ No init-data.sh needed
• ✅ Faster deployment (no file copying)
• ✅ Cleaner architecture
• ✅ Can upgrade code by rebuilding image

Drawbacks:

• Code changes require docker-compose rebuild
• Can't edit code in container (which is good for production)

---

Option 2: Keep Current (With Improvements)

Keep:

• init-data.sh for copying code to data/
• Volume mount at ./data:/app

Improve:

• Add validation that init-data.sh ran successfully
• Check file sync status before starting app
• Add automated sync on container restart

Benefits:

• ✅ Dev-friendly (can edit code, restart container)
• ✅ Faster iteration during development

Drawbacks:

• ❌ Production anti-pattern (code changes without rebuild)
• ❌ Extra deployment complexity
• ❌ Manual init-data.sh step required

---

Current Production Setup Evaluation

Current System: Option 2 (with volume mount override)

Why This Setup Exists

The current architecture with ./data:/app volume mount suggests:

1. Development-focused - Allows code editing and hot-reload
2. Host-based persistence - All data on host machine
3. Easy backup - Just backup the ./data/ folder

Is This Actually Used?

• ✅ Code updates via git pull in /app/ folder
• ✅ Then cp -r app/* data/app/ copies to running container
• ✅ Allows live code updates without container rebuild

---

Recommendation

For Production

Use Option 1 (Dockerfile-based):

• Build immutable images
• No init-data.sh needed
• Cleaner deployment pipeline
• Better for CI/CD

For Development

Keep Option 2 (current approach):

• Code editing and hot-reload
• Faster iteration

---

Implementation Steps for Option 1

1. Update Dockerfile

# Instead of: COPY . .
# Change docker-compose volume mount pattern

2. Update docker-compose.yml

volumes:
  # Remove: ./data:/app
  # Keep only:
  - ./data/instance:/app/instance
  - ./data/uploads:/app/app/static/uploads

3. Update deploy.sh

# Remove: bash init-data.sh
# Just build and run:
docker-compose build
docker-compose up -d

4. Add Migration Path

# For existing deployments:
# Copy any instance/database data from data/instance to new location

---

Data Persistence Strategy (Post-Migration)

Current:                          After Option 1:
./data/app/          (code)  →   /app/ (in image)
./data/instance/     (db)    →   ./data/instance/ (volume mount)
./data/uploads/      (files) →   ./data/uploads/ (volume mount)

---

Risk Assessment

Option 1 (Dockerfile-only)

• Risk Level: LOW ✅
• Data Loss Risk: NONE (instance & uploads still mounted)
• Rollback: Can use old image tag

Option 2 (Current)

• Risk Level: MEDIUM
• Data Loss Risk: Manual copying errors
• Rollback: Manual file restore

---

Conclusion

Recommendation: Option 1 (Dockerfile-based) for production deployment

• Simpler architecture
• Better practices
• Faster deployment
• Cleaner code management

Would you like to implement this change?