Final Design Approach:

Proposal: Replace Forgejo with Embedded HTTP-Only Git Service (Sztabina)

Summary

This proposal replaces Forgejo with a lightweight, embedded Git service (Sztabina) that is internal-only, HTTP-based, and fully controlled by Sztab. Git is treated as an internal subsystem, not as a separate product with users, authentication, or UI.

The goal is to align the implementation with the repeatedly stated requirement:

Git must not introduce a separate user base, authentication model, or operational burden.

Core Principles

1. Git is an Internal Subsystem

• Git is not exposed as a product or platform.
• Git has no users, no authentication, no UI.
• Git is accessible only inside the Docker Compose / internal network.
• Sztab owns the entire repository lifecycle.

2. HTTP-Only Git (No SSH)

• Only Git Smart HTTP is supported (clone, push, pull).
• No SSH server, no keys, no system users, no home directories.
• Security boundary is the internal Docker network.
• Eliminates identity, key management, and SSH-related complexity.

This is intentional and directly aligned with the “no Git users” requirement.

---

Architecture Overview

Components

Sztabina (Git Service)

• Lightweight Go service (Alpine-based)
• Exposes:
  • Git Smart HTTP protocol
  • Minimal REST API for repository creation/deletion
• Does NOT include:
  • Web UI
  • User management
  • Authentication / authorization
• Uses system git binaries and filesystem-backed repositories

Sztab (Main Application)

• Automatically creates repositories when projects are created
• Uses JGit for:
  • Repository browsing
  • File inspection
  • Metadata access
• Treats Git as infrastructure, not as a user-facing system

---

Filesystem Model

• A shared Docker volume (git-repos) is mounted into both containers.
• Repositories exist as standard Git directories on disk.
• Benefits:
  • No syncing or duplication
  • Direct JGit access from Sztab
  • Simple backup and inspection
  • Git remains “just Git” on disk

---

Docker Compose Sketch

services: sztabina: image: sztab/sztabina:latest volumes: - git-repos:/repos networks: - sztab-internal # No external exposure

sztab: image: sztab:latest volumes: - git-repos:/repos environment: GIT_SERVICE_URL: http://sztabina:8080 depends_on: - sztabina

volumes: git-repos:

networks: sztab-internal:

---

Repository Lifecycle

• Repository is created automatically when a Sztab project is created.
• Repository deletion follows project deletion policy.
• No manual initialization steps.
• No separate Git administration required.

---

External Git Repositories

This proposal does NOT eliminate support for external Git systems.

Clear separation:

• Internal projects: use embedded Git automatically.
• External projects (GitHub, OneDev, etc.):
  • Treated as integrations
  • Explicitly configured
  • Credentialed via tokens
  • Typically read-only or limited-scope

Sztab remains capable of observing and integrating with external repositories.

---

Benefits (Aligned with Requirements)

1. Zero external dependencies; Sztab is self-contained
2. Single user base; only Sztab users exist
3. Automatic repository creation on project creation
4. Zero initialization; docker-compose up works
5. Direct repository browsing via JGit
6. Reduced operational and cognitive load
7. Clear product positioning: “Sztab includes built-in Git hosting”

---

Implementation Notes

• Prefer Git Smart HTTP via system git http-backend wrapped by Go HTTP handlers.
• Avoid scope creep (no hooks UI, no permissions model, no users).
• Document explicitly that this is not a general-purpose Git hosting platform.

---

Estimated Effort

• Git Smart HTTP wiring: ~2 days
• Repository lifecycle REST API: ~1 day
• Container hardening and packaging: ~1 day
• Sztab integration (project → repo): ~1–2 days
• Testing and cleanup: ~1 day

Total estimate: ~6–7 working days

---

Key Constraint

This design only works if Git remains:

• Internal
• Userless
• Auth-less
• Infrastructure-level

Any deviation from this reintroduces the complexity this proposal intentionally removes.

---

Conclusion

This approach directly satisfies the stated requirements:

• No Git users
• No Git authentication
• No separate Git UI
• Internal-only Git service
• Automatic repository management

It simplifies the system, reduces long-term maintenance cost, and keeps Sztab focused on project management rather than Git hosting.