Projekt-Vorlagen landen im eigenen Repo

Der größte sichtbare Unterschied in diesem Update betrifft neue Projekte: Erstellst du sie aus einer Vorlage, entsteht das Repository jetzt in deiner eigenen GitHub- oder GitLab-Organisation – inklusive vollständiger Historie. Dazu zwei Änderungen rund ums Abonnement, die du kennen solltest.

Projekt aus Vorlage: das Repo entsteht in deiner Organisation

Beim Anlegen eines Projekts kannst du dir das Code-Repository von Spedy erzeugen lassen – Neues Projekt → GitHub-Repository → Aus Template generieren. Bisher lief das über die „Generate from template"-Funktion von GitHub, was das neue Repo an ein einziges Konto band. Das ist ersetzt.

Was jetzt passiert: Spedy legt über deine aktive Git-Integration ein frisches, privates Repository in deiner eigenen Organisation an, klont die Vorlage und pusht sie dort hinein.

Konkret bedeutet das:

• Das Repo gehört dir. Es entsteht unter deinem GitHub- bzw. GitLab-Namespace, nicht bei einem fremden Konto.
• GitHub oder GitLab. Das Ziel richtet sich nach der aktiven Integration deiner Organisation: Ist GitHub verbunden, wird GitHub verwendet; ist nur GitLab verbunden, entsteht das Projekt in GitLab.
• Vorlage und Ziel sind entkoppelt. Eine Vorlage, die auf GitHub liegt, kann in einem GitLab-Projekt landen – und umgekehrt.
• Die komplette Historie kommt mit. Übernommen werden alle Branches und Tags der Vorlage, nicht nur ein Startzustand – inklusive des vorbereiteten Docker-Stacks für Preview-Umgebungen.
• Für die eingebauten Spedy-Vorlagen (Shopware, Magento, Next.js) ist kein Token nötig. Sie werden ohne Zugangsdaten gelesen.

So gehst du vor

1. Klicke in der Seitenleiste auf Neues Projekt
2. Vergib Name und Kürzel
3. Wähle unter GitHub-Repository die Option Aus Template generieren
4. Wähle die gewünschte Vorlage aus der Liste

Der Repository-Name wird aus dem Projektnamen abgeleitet (kleingeschrieben, mit Bindestrichen). Das erzeugte Repo wird direkt mit dem Projekt verknüpft und als Preview-Repository gesetzt.

Eigene Vorlagen registrierst du weiterhin unter Einstellungen → Projekt-Templates; sie werden mit dem Token deiner eigenen Integration gelesen.

Wenn etwas schiefgeht: Das leere Ziel-Repository wird angelegt, bevor der Inhalt hineingepusht wird. Scheitert der Push, bleibt ein leeres Repo zurück – die Fehlermeldung nennt seinen Namen. Lösche es oder wähle beim nächsten Versuch einen anderen Projektnamen, sonst kollidiert der Name. Das Projekt selbst bleibt bestehen: Du kannst das Repository später aus den Projekt-Einstellungen verbinden.

Self-hosted GitLab: Die Instanz muss unter einer öffentlich erreichbaren Adresse liegen. Interne Adressen werden beim Anlegen und Pushen abgelehnt.

Nach dem Abo-Ende: Lesezugriff statt Sperre

Läuft ein gekündigtes Abonnement aus oder endet die Testphase ohne Buchung, wird der Workspace jetzt schreibgeschützt – statt dich auf die Abrechnungsseite umzuleiten:

• Ansehen und Exportieren funktioniert weiter.
• Änderungen (Tickets anlegen, kommentieren, verschieben) sind nicht mehr möglich.
• Ein Banner oben in der App weist darauf hin und verlinkt auf Abonnement reaktivieren.

Passend dazu beschreibt die Kündigungs-E-Mail jetzt, was wirklich passiert: Bis zum Ende des bezahlten Zeitraums bleibt der volle Zugriff bestehen, danach besteht das Konto mit Lesezugriff weiter. Eine automatische Umstellung auf einen kostenlosen Plan gibt es nicht, und der bereits bezahlte Zeitraum wird nicht anteilig erstattet.

Ebenfalls neu sichtbar: Bei einer fehlgeschlagenen Zahlung siehst du während der 14-tägigen Kulanzfrist einen Banner mit der Aufforderung, die Zahlungsmethode zu aktualisieren. Vorher blieb dieser Zeitraum unkommentiert.

Testphase: Klartext beim Start und vor der ersten Abbuchung

Im Onboarding stand beim Pro-Trial bisher „Keine Kreditkarte nötig" – das stimmte nicht, denn der Start hinterlegt eine Zahlungsmethode. Der Schritt sagt jetzt, was passiert: Zahlungsmethode hinterlegen, 0,01 € Verifizierung (sofort erstattet), und nach 30 Tagen läuft der Plan kostenpflichtig weiter, sofern du nicht vorher kündigst.

Auch die Erinnerungs-E-Mail vor Ablauf der Testphase ist eindeutiger. Wenn danach abgerechnet wird, nennt sie:

• den Betrag,
• das Datum der Abbuchung,
• die Anzahl der Nutzerplätze,
• und den Hinweis, dass bis zu diesem Datum jederzeit gekündigt werden kann.

Kurz zusammengefasst

• Projekt aus Vorlage: Das neue, private Repository entsteht in deiner eigenen GitHub- oder GitLab-Organisation, mit allen Branches und Tags der Vorlage. Vorlage und Ziel dürfen bei unterschiedlichen Anbietern liegen; für die eingebauten Vorlagen brauchst du kein Token.
• Nach dem Abo-Ende: Lesezugriff mit Export statt Sperre, mit Banner und Reaktivieren-Link – plus ein sichtbarer Hinweis während der 14-tägigen Kulanzfrist nach einer fehlgeschlagenen Zahlung.
• Testphase: Onboarding und Erinnerungsmail nennen Zahlungsmethode, Betrag, Datum und Plätze.