Skip to content

GitLab (self-hosted)

Source-control + CI/CD at git.projecteidos.com. GitLab CE on :latest, deployed via Dokploy on E2. Hosts every line of in-house code that lives on our self-hosted GitLab (note: the TnE Connect product source is on Bitbucket — see KI-034).

Field Value
Public URL https://git.projecteidos.com
Admin URL https://git.projecteidos.com/admin
Audience engineers + automated CI
Criticality critical
Edition GitLab CE (Community Edition)
Image tag :latest (not pinned)
Maturity trial — running, integrated, but not yet hardened
Owner [INFO NEEDED] (Vishnu day-to-day)
Last reviewed 2026-05-07

1. At a glance

GitLab CE is the company's GitHub equivalent — every code change to in-house apps passes through it. It also runs the automated test/build/deploy pipelines (CI/CD) for many of our services. If GitLab is down, no one can push code, no automated deploys happen, and the container registry (if used) is unreachable.

2. Business purpose

  • Source-of-truth for in-house source code (Parallax, this engineering repo, custom internal services).
  • Code review (merge requests).
  • CI/CD pipelines via shared runners on E2 + 1 runner deployed in Dokploy.
  • Authentik OIDC integration → SSO-based login.
  • Container registry (usage uncertain — see Section 4).
  • Issue tracking (if used; team primarily uses JIRA).

3. Audience

Engineers, automated CI runners, anyone deploying via Dokploy or other auto-deploy paths.

4. Hosting & cloud infrastructure

  • Server: E2 EIDOSDev1 Dokploy VPS (145.241.230.130) — co-tenanted with 8 other apps on a 3 vCPU / 18 GB Free VPS
  • Deploy method: Dokploy
  • Reverse proxy: Caddy on E1 → Dokploy on E2 → GitLab container

Resource concern: GitLab is normally sized at 8 GB RAM dedicated. On E2 it shares 18 GB with 3 WordPress sites, 3 Twenty CRMs, the Teams Bot, and Dokploy itself. Performance under load and headroom for upgrades is a real question. Re-validate if GitLab usage scales.

Infrastructure map

Item Value Notes
Public hostname git.projecteidos.com DNS via E1 Caddy → E2
Backend host E2 (Dokploy) shared with 8 other apps
Open ports (logical) 443 (HTTPS), 22 (SSH for git push) [CONFIRM] 22 routing — does Caddy/Traefik forward SSH or is it a separate route?
TLS cert Caddy auto-LE
Edition GitLab CE
Image tag :latest (not pinned) no auto-update on E2 (Watchtower not running there) — image stays static; security drift over time
Install method Docker via Dokploy
Database bundled PostgreSQL [CONFIRM] within the GitLab Omnibus container or a sibling Postgres?
Object storage (artifacts/LFS) local disk on E2 not pushed to MinIO; storage growth lands directly on the VPS volume
Container registry usage status unclear ([INFO NEEDED]) if used, all images sit on E2's local disk too
GitLab Runners shared runners on E2 + 1 runner deployed in Dokploy likely both run on the same host as GitLab itself

Credentials in Vault

Secret Vault location
Root admin password kv_pe/git.projecteidos.com/
Runner registration tokens [INFO NEEDED]
Database password [INFO NEEDED]
SMTP credentials shared kv_pe/OCI-SMTP [CONFIRM]
Object-storage (S3/MinIO) credentials n/a — using local disk
OAuth/OIDC client secret (Authentik integration) [INFO NEEDED] (in 448G_KV/auth.448.global per-application config)
Backup encryption keys [INFO NEEDED]
gitlab-secrets.json not captured anywhere off-host (KI-018)

5. Technology behind it

  • Type: off-the-shelf
  • Product: GitLab Community Edition (CE)
  • Stack: Ruby on Rails + PostgreSQL + Redis + Sidekiq + Nginx (Omnibus bundles all)
  • Deployment: containerized via Dokploy (not the traditional Omnibus-on-VM install)

6. Data it handles

Data class Present? Notes
Source code (intellectual property) yes Parallax, this engineering repo, custom internal services
CI/CD secrets / variables yes per-project stored encrypted; require gitlab-secrets.json to decrypt on restore
Container images (registry) [INFO NEEDED] unclear if used; affects backup planning
User accounts (PII) yes engineers; federated via Authentik
Issue / project content [INFO NEEDED] low if team primarily uses JIRA

7. External dependencies

  • Authentik for SSO login — confirmed working
  • SMTP — shared kv_pe/OCI-SMTP Oracle Email Delivery ([CONFIRM])
  • E2 host availability (single SPOF for the entire GitLab service)
  • Object storage — local disk on E2 today

8. Authentication & access

  • End-user login: Authentik OIDC (confirmed working) — federation chain is M365 → Authentik → GitLab
  • Admin login: GitLab root account; password in kv_pe/git.projecteidos.com/
  • MFA: inherited from M365 via the SSO chain. Direct root login bypasses Authentik — [INFO NEEDED] whether MFA on root is enforced (it should be).
  • 2FA on git push? [INFO NEEDED] — SSH key-based push is the typical path; key + signed commits are good practice.
  • Personal Access Tokens — every PAT is a long-lived credential; periodic audit + rotation needed.

9. Maturity assessment

Dimension Status Evidence
Backups Hobby No scheduled gitlab-backup; gitlab-secrets.json not captured off-host. Tracked as KI-018 / RM-015.
Restore tested Hobby Not possible without backup.
Monitoring Hobby No Beszel coverage; no alert rules.
Alerting Hobby None.
Redundancy Hobby Single GitLab on a single host (E2).
Patching cadence At risk On :latest; Watchtower not on E2 so image stays static (no surprise breakage but no security patches either — KI-004).
Compose in Git Hobby Same gap as the rest of E2 — config is in Dokploy/Portainer state, not source-controlled.
Object storage Trial Works today on local disk; will need MinIO offload as artefacts/registry grow.
OIDC federation Trial Authentik integration confirmed working.

10. Known risks & vulnerabilities

  • No scheduled backup; gitlab-secrets.json not captured (KI-018) — without it, encrypted CI variables on a restored instance cannot be decrypted. Most common GitLab-restore failure mode.
  • Single host SPOF — E2 hosts 9 apps including GitLab. E2 dies = source control + CI/CD + 8 other apps go with it.
  • :latest tag (KI-004) — no Watchtower on E2 means the image is stuck wherever it landed. No security patches over time.
  • Local-disk storage for artifacts / LFS / registry — disk growth on E2 will eventually become a capacity concern. Move to MinIO well before that.
  • Container registry usage status unknown — could already be heavy disk; worth checking.
  • CI runner trust boundary — runners execute arbitrary code; a compromised runner reads all secrets exposed to its jobs. With shared runners on the same host as GitLab itself, the trust boundary is thin.
  • Personal Access Tokens — long-lived credentials, easy to leak in code; need an audit + rotation policy.
  • Public attack surface — GitLab login + SSH on the public internet; rate-limiting + Authentik-only sign-in (disabling local password sign-in) reduces brute-force risk.

11. Impact if it goes down

  • No code pushes / merges.
  • CI pipelines halt → no deploys, no Dokploy auto-deploys triggered by pushes.
  • Container image pulls (if registry is used) may fail at deploy time.
  • Engineers fall back to local-only work for the duration.

12. Owner & on-call

  • Primary owner: Vishnu Kant (day-to-day) [CONFIRM]
  • Backup owner: [INFO NEEDED]

13. References & links

  • Public URL: https://git.projecteidos.com
  • Vendor docs: https://docs.gitlab.com/
  • Root credentials: kv_pe/git.projecteidos.com/
  • Authentik OIDC client: managed in Authentik admin UI under the "GitLab" provider
  • Critical runbook needs: backup + restore + secrets-file recovery (RM-015)
  • Domain: see domains.md