> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Self-Hosted SCM & Artefakte

> Verbinden Sie Devin mit Ihren self-hosted Source Code Management-Systemen und Artefakt-Repositories

<div id="why-connect-devin-to-self-hosted-systems">
  ## Warum Devin mit self-hosted Systemen verbinden?
</div>

Wenn Ihre Organisation self-hosted Source Code Management-Systeme (wie GitLab) oder Artefakt-Repositories (wie Artifactory) verwendet, können Sie dennoch den vollen Funktionsumfang von Devin nutzen. Indem Sie diese Dienste sicher für die Infrastruktur von Devin zugänglich machen, behält Ihr Team die Kontrolle über Ihre Systeme und ermöglicht Devin gleichzeitig, effektiv in Ihrem Entwicklungs-Workflow mitzuarbeiten.

<div id="overview">
  ## Übersicht
</div>

Ihr Team kann einen Network Load Balancer (NLB) einrichten, Devins statische IPs auf die Allowlist setzen und einen DNS-Eintrag dafür veröffentlichen. Dieser Ansatz:

* **Begrenzt den Zugriff auf eine kleine, kontrollierte Angriffsfläche** – nur Devins bekannte IPs können eine Verbindung herstellen
* **Erfordert weniger als ein paar Stunden** Engineering-Aufwand für die Einrichtung
* **Bewahrt Ihre bestehende Infrastruktur** – keine Migration auf cloud-gehostete Lösungen erforderlich
* **Ermöglicht zentrale Verwaltung** – optional ein einzelner Load Balancer für mehrere Services

<div id="prerequisites">
  ## Voraussetzungen
</div>

Bevor Sie die Integration einrichten, stellen Sie sicher, dass Folgendes vorhanden ist:

* **Self-hosted GitLab** (oder ein anderes SCM-System), das innerhalb Ihres Netzwerks erreichbar ist
* **Self-hosted Artefakt-Repository** (optional), z. B. Artifactory oder Nexus
* **Netzwerkverwaltungszugriff**, um Firewalls, Load Balancer und DNS zu konfigurieren
* **Statische IP-Adressen von Devin** – zu finden [hier](/de/admin/common-issues#ip-whitelisting)

<Note>
  Diese Integration ist für Enterprise-Plan-Kunden verfügbar. Kontaktieren Sie [enterprise@cognition.ai](mailto:enterprise@cognition.ai), wenn Sie Unterstützung benötigen.
</Note>

<div id="setup-options">
  ## Einrichtungsoptionen
</div>

Es gibt zwei Hauptansätze, um Ihre selbstgehosteten Dienste für Devin verfügbar zu machen:

<div id="option-1-direct-ip-whitelisting-recommended">
  ### Option 1: Direktes IP-Allowlisting (empfohlen)
</div>

Behalten Sie Ihre bestehende self-hosted Infrastruktur bei und geben Sie Devins statische IPs einfach auf Firewall-Ebene frei.

**Für das Source Code Management:**

1. Konfigurieren Sie Ihre Firewall so, dass eingehende Verbindungen von Devins IPs (aufgeführt [hier](/de/admin/common-issues#ip-whitelisting)) zugelassen werden
2. Stellen Sie sicher, dass Ihre GitLab- (oder andere SCM-) Instanz über HTTPS erreichbar ist
3. Geben Sie Devin während der Integrationseinrichtung die URL an

**Für Artefakt-Repositories:**

1. Fügen Sie Devins IPs zur Allowlist Ihres Artifactory/Nexus hinzu
2. Stellen Sie sicher, dass das Artefakt-Repository über HTTPS erreichbar ist
3. Konfigurieren Sie geeignete Zugangsdaten, damit Devin auf Artefakte zugreifen kann

<Note>
  Wenn Sie einen Load Balancer mit Ihrem Artefakt-Repository verwenden, lesen Sie den Abschnitt [Überlegungen zum Load Balancer](#load-balancer-considerations) weiter unten für wichtige Details zur IP-Allowlist.
</Note>

<div id="option-2-centralized-load-balancer">
  ### Option 2: Zentraler Load Balancer
</div>

Platzieren Sie mehrere Dienste hinter einem einzigen Application Load Balancer (ALB) oder Network Load Balancer (NLB), um zentrales IP-Filtering zu ermöglichen.

**Vorteile:**

* Zentraler Verwaltungspunkt für alle Netzwerkfilter
* Unterstützung mehrerer interner Dienste mit unterschiedlichen Domains
* Vereinfachte Sicherheitsprüfungen und Compliance

<div id="load-balancer-considerations">
  ## Überlegungen zum Load Balancer
</div>

Bei der Wahl zwischen Application Load Balancer (ALB) und Network Load Balancer (NLB) sollten Sie berücksichtigen, wie jede Option mit IP-Allowlisting umgeht:

**Application Load Balancer (ALB) – für die meisten Anwendungsfälle empfohlen:**

* ALB arbeitet auf Layer 7 (HTTP/HTTPS) und bietet erweiterte Routing-Funktionen
* Der Traffic läuft über NAT, sodass Ihre Backend-Services die internen IP-Adressen des ALB sehen und nicht die Quell-IPs von Devin
* **Für Artefakt-Repositories hinter einem ALB:** Sie müssen IP-Allowlisting direkt auf Artifactory/Nexus konfigurieren, da das Repository die interne IP des Load Balancers sieht
* Verwenden Sie AWS WAF für IP-Filterung auf ALB-Ebene (siehe Beispiel unten)

**Network Load Balancer (NLB) – geeignet für IP-Allowlisting-Szenarien:**

* NLB arbeitet auf Layer 4 (TCP) und bewahrt die ursprünglichen Quell-IP-Adressen
* Ihre Backend-Services sehen die tatsächlichen Quell-IPs von Devin
* **Für Artefakt-Repositories hinter einem NLB:** IP-Allowlisting auf Load-Balancer-Ebene ist ausreichend, da die Quell-IPs beibehalten werden
* Erfordert die manuelle Konfiguration der Security Groups für jede IP-Adresse

<Tip>
  Während ALB im Allgemeinen aufgrund seiner Flexibilität und einfachen Verwaltung bevorzugt wird, eignet sich NLB gut, wenn Sie IP-Allowlisting auf der Load-Balancer-Ebene benötigen, ohne zusätzliche Konfiguration an den Backend-Services.
</Tip>

<div id="aws-implementation-example">
  ## AWS-Implementierungsbeispiel
</div>

Hier sind Beispielkonfigurationen für AWS für beide Load-Balancer-Ansätze:

<div id="application-load-balancer-with-waf-easier">
  ### Application Load Balancer mit WAF (einfachere Variante)
</div>

```bash theme={null}
# Erstellen Sie ein IP-Set mit Devins statischen IPs
aws wafv2 create-ip-set \
  --name devin-allowed-ips \
  --scope REGIONAL \
  --ip-address-version IPV4 \
  --addresses 1.2.3.4/32 5.6.7.8/32 9.10.11.12/32 13.14.15.16/32

# Create a WAF web ACL
aws wafv2 create-web-acl \
  --name devin-access-control \
  --scope REGIONAL \
  --default-action Block={} \
  --rules file://waf-rules.json

# Associate the WAF with your ALB
aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:region:account:regional/webacl/... \
  --resource-arn arn:aws:elasticloadbalancing:region:account:loadbalancer/app/...
```

<Note>
  Ersetzen Sie die IP-Adressen durch die tatsächlichen IP-Adressen aus unserer [Dokumentation zum IP-Whitelisting](/de/admin/common-issues#ip-whitelisting).
</Note>

<div id="network-load-balancer-manual-security-groups">
  ### Network Load Balancer (manuelle Security Groups)
</div>

```bash theme={null}
# Fügen Sie Ingress-Regeln für jede Devin-IP zu Ihrer Sicherheitsgruppe hinzu
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 1.2.3.4/32

# Für jede IP-Adresse wiederholen
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 5.6.7.8/32

# Für alle Devin-IPs fortfahren...
```

<div id="dns-configuration">
  ### DNS-Konfiguration
</div>

Nachdem Sie Ihren Load-Balancer eingerichtet haben, legen Sie einen DNS-Eintrag an, den Devin verwenden kann:

```bash theme={null}
# Beispiel: Richten Sie gitlab.yourcompany.com auf Ihren Load Balancer aus
# Die Domain wird zur Load Balancer-IP aufgelöst, die den Traffic filtert,
# um nur Verbindungen von Devins Whitelist-IPs zuzulassen

# Verwendung von AWS Route 53:
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch file://dns-change.json
```

Beispieldatei `dns-change.json`:

```json theme={null}
{
  "Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "gitlab.yourcompany.com",
      "Type": "A",
      "AliasTarget": {
        "HostedZoneId": "Z215JYRZR1TBD5",
        "DNSName": "your-alb-name-123456.us-west-2.elb.amazonaws.com",
        "EvaluateTargetHealth": false
      }
    }
  }]
}
```

<div id="integration-steps">
  ## Integrationsschritte
</div>

Sobald Ihre Netzwerkinfrastruktur konfiguriert ist:

1. **Konnektivität testen** – Stellen Sie sicher, dass Ihre Dienste von außerhalb Ihres Netzwerks über die konfigurierte Domain erreichbar sind
2. **Devin-Support kontaktieren** – Wenden Sie sich an Cognition mit:
   * Ihrer selbst gehosteten GitLab-URL (z. B. `https://gitlab.yourcompany.com`)
   * Der URL zu Ihrem Artifact-Repository (falls zutreffend)
   * Eventuellen speziellen Authentifizierungsanforderungen
3. **Integrationseinrichtung abschließen** – Arbeiten Sie mit dem Devin-Team zusammen, um die Verbindung endgültig herzustellen
4. **Repositories konfigurieren** – Fügen Sie Ihre Repositories zu [Devin's Machine](https://app.devin.ai/machine) hinzu

<Tip>
  Testen Sie Ihre IP-Filterkonfiguration, bevor Sie Devin Zugriff gewähren, indem Sie versuchen, von einer IP-Adresse aus eine Verbindung herzustellen, die nicht auf der Allowlist steht. Die Verbindung sollte blockiert werden.
</Tip>

<div id="best-practices">
  ## Best Practices
</div>

* **HTTPS verwenden** - Dienste stets über HTTPS mit gültigen SSL-Zertifikaten bereitstellen
* **Eigenes Servicekonto erstellen** - Ein dediziertes Konto für Devin in Ihrem GitLab-/SCM-System einrichten
* **Zugriffsprotokolle überwachen** - Verbindungsprotokolle von den Devin-IP-Adressen regelmäßig prüfen
* **Setup dokumentieren** - Interne Dokumentation zu Ihrer Load-Balancer- und DNS-Konfiguration pflegen
* **Failover testen** - Sicherstellen, dass Ihr Setup Ausfälle von Load Balancer oder Diensten reibungslos verkraftet
* **Regelmäßige Sicherheitsaudits** - Regelmäßig prüfen, welche Dienste erreichbar sind, und IP-Allowlists verifizieren

<div id="troubleshooting">
  ## Fehlerbehebung
</div>

**Devin kann keine Verbindung zu meinem selbst gehosteten System herstellen:**

* Überprüfen Sie, ob alle [Devin IP addresses](/de/admin/common-issues#ip-whitelisting) auf der Allowlist stehen
* Stellen Sie sicher, dass Ihr SSL-Zertifikat gültig und vertrauenswürdig ist
* Stellen Sie sicher, dass DNS-Einträge korrekt konfiguriert und propagiert sind
* Überprüfen Sie, ob Ihre Firewall-Regeln HTTPS-Datenverkehr (Port 443) zulassen

**Authentifizierungsfehler:**

* Stellen Sie sicher, dass die Service-Account-Anmeldedaten korrekt sind
* Überprüfen Sie, ob der Service-Account über die erforderlichen Berechtigungen in Ihrem SCM-/Artefakt-System verfügt
* Prüfen Sie, ob es IP-basierte Authentifizierungsbeschränkungen außerhalb der Allowlist gibt

**Leistungsprobleme:**

* Überwachen Sie die Metriken Ihres Load Balancers auf mögliche Engpässe
* Stellen Sie sicher, dass Ihre selbst gehosteten Dienste über ausreichende Ressourcen verfügen
* Berücksichtigen Sie die geografische Nähe zwischen Ihrer Infrastruktur und den Systemen von Devin

<div id="support">
  ## Support
</div>

Für Unterstützung bei Self-Hosted-Integrationen:

1. Erstellen Sie einen Slack-Connect-Channel mit unserem Team unter [app.devin.ai/settings/support](https://app.devin.ai/settings/support)
2. Senden Sie eine E-Mail an [enterprise@cognition.ai](mailto:enterprise@cognition.ai) mit den Details zu Ihrem spezifischen Setup
3. Teilen Sie relevante Konfigurationsdateien (mit geschwärzten sensiblen Daten), wenn Sie Probleme melden