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:**
```dockerfile
# Copy everything to /app inside image
COPY . /app/

# No need for volume mount - image contains all code
```

**Change docker-compose.yml:**
```yaml
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**
```dockerfile
# Instead of: COPY . .
# Change docker-compose volume mount pattern
```

### 2. **Update docker-compose.yml**
```yaml
volumes:
  # Remove: ./data:/app
  # Keep only:
  - ./data/instance:/app/instance
  - ./data/uploads:/app/app/static/uploads
```

### 3. **Update deploy.sh**
```bash
# Remove: bash init-data.sh
# Just build and run:
docker-compose build
docker-compose up -d
```

### 4. **Add Migration Path**
```bash
# 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?