🏗️ Architecture: Should platform generation continue using GitLab as primary ...

Date: 2026-03-20
Time: 18:21:55 UTC
Session: gspace1-246.4
Agent: angular
Confidence: 90%
Status: ✅ Documented

📋 Decision Context

Question:

Should platform generation continue using GitLab as primary code storage, or move to local git repos on the Hetzner server?

Task: Not specified

🎯 Decision Made

Chosen:

Replace GitLab as primary storage with local git repos on the Hetzner server. GitLab becomes an optional async export for customers who want CI/CD. Implement LocalGitProviderService using the existing GitProviderService interface abstraction.

Options Considered:

1. Keep GitLab as primary (status quo)
2. Local git repos as primary + GitLab as optional export (chosen)
3. MongoDB document storage for code (rejected — wrong data model)
4. S3/R2 object storage for files

💭 Reasoning

GitLab adds 3-4 min of pure overhead per generation: template fork (15-30s), file commits via HTTP API (2-5 min for 847 files), VFS reads (1-3s per refresh). A GitProviderService abstraction already exists in backend-api/src/app/git-provider/ — only GitLabProviderService implements it today. Creating LocalGitProviderService (local filesystem + simple-git) makes template init <1s (cp -r), commits <1s (disk writes + git commit), reads instant (fs). The generation pipeline, preview system, VFS, and draft/branch system are all decoupled from GitLab — they work through abstractions. Preview system has zero GitLab dependency (already in-memory VFS → rspack WASM → Service Worker). Total generation time drops from 25-40 min to ~20-35 min.

📁 Files Involved

• APIs/backend-api/src/app/git-provider/
• APIs/backend-vitto-api/src/app/studio/universe-git.service.ts
• libs/libs-structural/vitto-studio/src/lib/services/vfs-sync.service.ts
• libs/libs-structural/vitto-studio/src/lib/services/preview.service.ts

🔗 Related

• Decision ID: dev_1774030915530_adpeihd
• Session: 246
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation