Private Composer-Auslieferung composer install. Aber nur, wer bezahlt hat.

Wir bauen private Composer-Auslieferung mit Zugriff pro Kunde und Lizenz. Für Entwickler ändert sich nichts: Repository eintragen, Token hinterlegen, installieren. Unsere eigenen Magento-Module liefern wir genau so aus.

Delivery-Setup prüfen lassen
So sieht es für Entwickler aus
$ composer config repositories.acme composer https://repo.example.com
$ composer require acme/b2b-pricing
✓ Token aktiv · Lizenz gültig · Archiv ausgeliefert

$ composer update acme/b2b-pricing
✕ Lizenz abgelaufen · Zugriff verweigert

Wo es hakt

Ein Repository ist schnell aufgesetzt. Der Ärger kommt mit dem ersten Kunden.

  • Geteilte Tokens

    Ein Token wandert zwischen Agentur, Entwicklern und Build-Server. Rotieren kann ihn danach niemand mehr, ohne dass irgendwo etwas bricht.

  • Lizenz und Zugriff laufen auseinander

    Der Vertrag ist gekündigt, aber das Repository liefert weiter Updates. Oder umgekehrt.

  • Builds hängen am Download

    Fehlende Archive, veraltete Metadaten oder ein manueller Release-Schritt machen aus einem normalen Deployment einen Supportfall.

  • Jeder Fehler sieht gleich aus

    Token abgelaufen, Paket fehlt, Lizenz deckt es nicht ab: Composer meldet in allen drei Fällen dasselbe.

Der Ablauf

Vier Momente, eine Zugriffsentscheidung.

  1. Release

    Die Pipeline baut aus einer geprüften Version ein unveränderliches Archiv und veröffentlicht es einmal.

  2. Installation

    Composer fragt an, die Plattform prüft Token und Lizenz und liefert dann Metadaten und Archiv aus.

  3. Sperren

    Token oder Lizenz entziehen, ohne Pakete umzubenennen oder neu zu bauen. Die nächste Anfrage wird abgelehnt.

  4. Support

    Das Protokoll zeigt, welche Prüfung fehlgeschlagen ist, ohne dass jemand den Token sehen muss.

Freitags deployen. Und trotzdem ins Wochenende.

Release bauen, prüfen, veröffentlichen, ausliefern: einmal sauber automatisiert, statt jedes Mal von Hand.

Delivery-Setup prüfen lassen
Unbenutzter Feuerlöscher

Was Sie brauchen

Nicht jedes private Paket braucht eine eigene Plattform.

SatisGehostete RegistryAuslieferung nach Lizenz
Aufgabe Composer-Metadaten erzeugen und hosten Private Pakete für Teams bereitstellen Pakete an zahlende Kunden ausliefern
Kundenzugriff Selbst bauen Konten und Rechte Aus Kunden- und Lizenzdaten
Tokens sperren Selbst bauen Im Anbieter-Backend Automatisch mit der Lizenz
Betrieb Ihr Team Anbieter Ihr Team oder mit uns
Passt für Wenige interne Pakete Entwicklung über mehrere Teams Kommerzielle Module mit Lizenzen

Wenn Ihr bestehender Aufbau reicht, sagen wir das auch so. Eine neue Plattform ist nicht automatisch die richtige Antwort.

Technische Fragen

Was Teams am Anfang klären sollten.

Nutzen Kunden weiter die normalen Composer-Befehle?
Ja. Sie tragen das private Repository ein und melden sich mit ihrem eigenen Token an. Alles andere bleibt Composer 2 wie gewohnt.
Kann derselbe Token lokal und in CI laufen?
Technisch ja. Getrennte Tokens lassen sich aber leichter rotieren, zuordnen und sperren. Deshalb trennen wir Personen, Projekte und Pipelines.
Was passiert, wenn Lizenz oder Supportzeitraum enden?
Das legen Sie fest: Zugriff sofort beenden, auf bereits veröffentlichte Versionen begrenzen oder eine andere vertragliche Regel. Die Plattform setzt sie durchgängig um.
Müssen bestehende Magento-Module neu gebaut werden?
In der Regel nicht. Die Pakete brauchen gültige Composer-Metadaten und versionierte Archive. Zugriff und Auslieferung liegen um das Paket herum, nicht in dessen Code.
Kann die Plattform bei uns laufen?
Ja. Ganz bei Ihnen, bei uns oder aufgeteilt. Hosting, Überwachung und Zuständigkeit bei Störungen klären wir vorher.

Finden Sie die Lücke vor Ihrem nächsten Kunden.

Delivery-Setup prüfen lassen