Wie ich einen Podcast gestartet habe, ohne ein einziges Mal das Mikrofon einzuschalten

Ein wöchentliches KI-Update auf Spotify – Recherche, Skript, Stimme, Veröffentlichung: alles automatisch. Was funktioniert, was sich zwischendurch geweigert hat zu funktionieren, und warum genau das der spannende Teil ist.

Niemand am Mikrofon

Mein Podcast heißt KI.update. Er erscheint wöchentlich. Er ist auf Spotify zu hören. Er klingt nach einem Menschen, der über die wichtigsten KI-News der Woche spricht.

Nur: Da ist kein Mensch. Ich habe nichts aufgenommen. Ich habe keine Folge geschnitten. Ich habe nicht einmal ein Skript geschrieben.

Was ich getan habe: Ich habe eine Pipeline gebaut, die jede Woche automatisch recherchiert, einen Sprechtext erzeugt, ihn in natürlicher Stimme vorliest, hochlädt und in einen RSS-Feed schreibt, den Spotify dann von alleine zieht. Mein Job ist es, das Setup zu warten und einmal die Woche kurz zu kontrollieren, dass die Maschine nicht halluziniert hat.

Das ist nicht „Podcast mit KI-Hilfe". Das ist „Podcast ohne mich". Der einzige menschliche Beitrag ist redaktionelle Verantwortung – und genau das steht inzwischen auch im Impressum.

Der Stack in fünf Bausteinen

Die ganze Maschine besteht aus fünf Komponenten, die miteinander reden:

• Hermes – ein eigener Recherche-Agent, der Tech- und KI-News der Woche sammelt und in strukturiertem Klartext liefert.

• Mistral Large – das Sprachmodell, das aus der Recherche zwei Dinge generiert: ein sprechfertiges Skript (~5 Minuten, 700–800 Wörter) und einen Episodentitel mit Beschreibung.

• Voxtral – Mistrals Text-to-Speech, das den Sprechtext in eine naturally klingende MP3 verwandelt. Ich habe eine Voice-ID festgelegt, damit jede Folge nach derselben „Stimme" klingt.

• n8n – der Klebstoff. Hier läuft die ganze Pipeline als Workflow: Webhook rein, Skript erzeugen, in Häppchen schneiden, vertonen, zusammenfügen, hochladen, RSS bauen.

• Hetzner Object Storage – S3-kompatibler Bucket auf einem deutschen Server. Hier liegen die MP3s und die ki-update.xml, die Spotify alle paar Stunden abruft.

Spotify selbst betreibt mein Podcast-Hosting nicht. Spotify zieht nur den RSS-Feed. Das macht das Ganze portabel: morgen funktioniert es genauso bei Apple Podcasts, Pocket Casts oder Overcast.

Wie eine Folge entsteht

Jeden Donnerstag triggert Hermes einen Webhook auf meinem n8n. Was dann passiert, läuft in 18 Schritten ab – hier die Kurzfassung:

Plaintext

Hermes
  → Research-Text
  → ┬─ Mistral schreibt Skript (700-800 Wörter)
    └─ Mistral schreibt Titel + Beschreibung (JSON)
  → Skript in Chunks zu je ~1500 Zeichen schneiden
  → Pro Chunk: Voxtral generiert MP3-Schnipsel
  → MP3-Schnipsel konkatenieren, Dauer messen
  → MP3 in den S3-Bucket hochladen (public-read)
  → Bestehendes RSS-XML laden
  → Neues <item> generieren, mit Titel, Audio-URL, Größe, Dauer, GUID
  → Beide zusammenmergen, neuen <channel> bauen
  → Komplette RSS-Datei mit Content-Type application/rss+xml hochladen

Das Skript wird in Stücke geschnitten, weil Voxtral pro Request nur eine begrenzte Textmenge frisst. Die Chunks werden einzeln vertont und am Ende zur fertigen MP3 zusammengeklebt. Die Dauer der Episode messe ich direkt aus den MP3-Frame-Headern – kein ffprobe nötig, sondern ein paar Zeilen JavaScript, die die MPEG-Audio-Header lesen und Bitrate gegen Bytes rechnen.

Das Cover-Bild liegt einmal statisch im Bucket. Der Rest entsteht jede Woche neu.

Warum das alles in n8n läuft

Ich hätte das auch in Python schreiben können. Ein Cron-Job, ein Skript, fertig. Aber n8n hat zwei Eigenschaften, die ich für genau diese Sorte Pipeline mag:

Sichtbarkeit. Jeder Schritt ist eine Node, die ich einzeln öffnen, debuggen und wieder anstoßen kann. Wenn Voxtral mal zickt, sehe ich das sofort an der roten Node, nicht erst durch Log-Wühlen.

Wiederverwendbarkeit von Credentials. Mistral-API-Key, Hetzner-S3-Zugang – einmal hinterlegt, in zehn Nodes verwendbar. Kein Secrets-Management-Theater.

Trade-off: n8n-Workflows sind in JSON modelliert. Versionskontrolle und Code-Reviews sind dadurch hakelig. Bei dieser einen Pipeline akzeptiere ich das.

Die Geschichte, wie Spotify den Feed eine Woche lang ignoriert hat

Hier wird's interessant.

Ich hatte die Pipeline gebaut, zwei Folgen produziert, das XML lag im Bucket, alles sah gut aus. Ich reichte den Feed bei Spotify for Creators ein. Spotify zuckte mit den Schultern: Feed ungültig.

Ich habe drei Stunden lang nach Fehlern im RSS-Schema gesucht. Falsche Tag-Reihenfolge? Fehlende Felder? Apple-Podcasts-Validator sagte „okay". Spotify sagte „nope".

Der Fehler war nicht im XML. Der Fehler war im HTTP-Header.

Hetzner Object Storage liefert hochgeladene Dateien standardmäßig mit Content-Type: text/html aus. Es sei denn, man sagt explizit etwas anderes. Spotify-Parser bekamen also XML-Inhalt mit der falschen Verpackung – „hier ist HTML, viel Spaß" – und gaben sofort auf, ohne den Inhalt überhaupt anzuschauen.

Lösung: Im n8n-Workflow lade ich die RSS-Datei nicht mehr als Text-Body hoch, sondern als Binary mit explizitem MIME-Typ application/rss+xml. Eine einzige Zeile JavaScript-Logik:

JavaScript

const binary = await this.helpers.prepareBinaryData(
  buf, 'ki-update.xml', 'application/rss+xml'
);

Plus dazu zwei weitere Fehler, die im Lauf des Debugs sichtbar wurden:

• Sprach-Tag war de-de (lowercase) statt de-DE. Spotify is da strenger als der RSS-Standard verlangt.

• Geist-Items im Feed. Wenn ein Pipeline-Lauf in der Mitte schiefging, blieb ein <item> mit leerem Titel, GUID ki-update-undefined und einer Enclosure-URL ohne URL übrig. Spotify zählte das als „Feed enthält null gültige Episoden" und lehnte die Submission ab. Ich habe einen Guard eingebaut: Wenn die kritischen Felder fehlen, wird kein Item geschrieben, kein zerstörter Feed nach oben gereicht.

Drei kleine Dinge. Eine Woche unsichtbarer Bug.

Was diese Erfahrung wert war

Wenn ich diese drei Probleme isoliert auf Stack Overflow gefunden hätte, wäre das nutzlos gewesen. In ihrer Kombination – Content-Type, Sprach-Code, defensive Item-Generierung – sind sie das, was zwischen „mein RSS funktioniert auf meinem Rechner" und „mein Podcast existiert in der Welt" steht.

Übersetzt: Die Spezifikation eines Standards verrät dir nicht, was die Konsumenten dieses Standards in der Realität an Strenge erwarten. Apple ist gnädig. Spotify ist es nicht. Du erfährst das erst, wenn du beide gleichzeitig zufriedenstellen willst.

Was die Pipeline (noch) nicht kann

Ehrlichkeit ist Pflicht, wenn man sich technisch produziert: Die Pipeline hat Grenzen.

• Halluzinationen. Wenn die Recherche ungenau ist, plappert das Skript sie nach. Mistral fact-checked nichts.

• Stimmlich monoton. Voxtral klingt natürlich, aber die emotionale Bandbreite ist begrenzt. Eine Pointe klingt wie ein Wetterbericht.

• Keine Cuts, keine Musik, kein Intro. Bewusst minimal gehalten – das wäre der nächste Schritt.

• Niemand prüft das Endprodukt vor Veröffentlichung. Theoretisch könnte eine völlig kaputte Folge live gehen. Praktisch habe ich genau dieses Problem bei einer Folge gehabt: Voxtral hat irgendetwas Unverständliches gebrabbelt. Ich habe die Folge nachträglich aus dem Feed entfernt – einen kleinen Cleanup-Workflow gebaut, ausgeführt, wieder gelöscht.

Das ist der Trade-off, den ich bewusst eingehe: Geschwindigkeit und Konsistenz gegen perfekte Qualität. Wenn ich jede Folge persönlich abnehmen würde, gäbe es den Podcast nicht.

Wenn du sowas selbst bauen willst

Ein paar Sachen, die ich rückblickend anders machen würde:

1. Content-Type beim Upload von Anfang an explizit setzen. Nicht erst, wenn Spotify dich auflaufen lässt.

2. Defensive Item-Generierung. Jeder Schritt in der Pipeline sollte die Frage beantworten: „Was passiert, wenn ich kaputte Eingangsdaten bekomme?" Im Zweifel: nichts veröffentlichen.

3. GUIDs deterministisch erzeugen. Ich nutze ki-update-YYYY-MM-DD. Damit kann ich denselben Workflow zweimal triggern, ohne dass Spotify eine doppelte Folge sieht.

4. RSS-Feed als binary uploaden. Mit explizitem MIME-Typ. Punkt.

5. Impressum direkt in die Channel-Description. Spotify und Apple verlinken im Player auf die Show-Beschreibung. Wer in Deutschland einen Podcast macht, hat Impressumspflicht – und die Description ist der einzige Ort, an dem der Hörer das findet.

6. Einen Validator nutzen. podba.se/validate oder castfeedvalidator.com sagen dir innerhalb von Sekunden, was schief ist. Bevor Spotify dir das sagt.

Kosten

Eine Folge kostet mich:

• Mistral Large (Skript + Titel): ein paar Cent

• Voxtral TTS (~5 Minuten Audio): unter einem Euro

• Hetzner S3 (Storage + Traffic): vernachlässigbar

• n8n: läuft selbst gehostet auf einem kleinen Server, ~10 €/Monat

Macht überschlagen einen Euro pro Folge. Ein Podcast für den Preis eines Kaffees pro Woche.

Hör rein

KI.update läuft auf Spotify und überall, wo es RSS-Feeds gibt. Die Feed-URL ist:

Plaintext

https://kipunktupdate.fsn1.your-objectstorage.com/ki-update.xml

Eine Folge pro Woche, ca. 5–10 Minuten, kompakt auf die wichtigsten Entwicklungen der Woche.

Und falls du gerade selbst überlegst, ob sich so etwas lohnt: Der spannendste Teil dieses Projekts war nicht die fertige Pipeline. Es waren die drei Tage dazwischen, in denen Spotify den Feed nicht mochte und ich nicht wusste, warum.

Da lernt man Dinge, die in keinem Tutorial stehen.