# Veröffentlichen und teilen

Das Veröffentlichen ist die Übergabe von Ihrem Harness an die betriebene Plattform: Das Dashboard hört auf, die Ausgabe eines Agenten zu sein, und wird zu etwas, auf das sich Ihr Team verlassen kann — eine stabile URL, geregelt durch Ihre Zugriffsrechte, die auch nach Ende der Sitzung weiter antwortet.

## Entwurf und Hauptzweig sind echte Git-Branches[​](#entwurf-und-hauptzweig-sind-echte-git-branches "Direkter Link zur Entwurf und Hauptzweig sind echte Git-Branches")

Das ist keine Metapher. Jedes Dashboard ist ein **Git-Repository**, gehalten als Bare-Repo im Objektspeicher. Ihre Änderungen — von Ihrem Agenten, vom In-App-Assistenten, vom Code-Editor — sind Commits auf einem **draft**-Branch. Das Veröffentlichen mergt diesen Entwurf in **main**.

Drei Konsequenzen, mit denen Sie planen sollten:

* **Sie können nicht direkt in `main` schreiben.** Schreibvorgänge dorthin werden verweigert; der einzige Weg, wie Inhalt die Live-Version erreicht, ist eine Veröffentlichung.
* **Jede Veröffentlichung erstellt ein Versions-Tag.** Das Tag hält den Zustand fest, in dem sich `main` *vor* dem Merge befand — also ist `v1` das, was Ihre erste Veröffentlichung ersetzt hat, `v2` das, was Ihre zweite Veröffentlichung ersetzt hat, und die aktuell live geschaltete Version ist `main`, ungetaggt bis zur nächsten Veröffentlichung.
* **Gleichzeitige Veröffentlichungen mergen, statt zu überschreiben.** Wenn sich `main` bewegt hat, während Ihr Entwurf offen war, und beide unterschiedliche Dateien betroffen haben, landen beide Änderungssätze. Wenn sie *dieselbe* Datei inkompatibel betroffen haben, schlägt die Veröffentlichung mit `409 PUBLISH_MERGE_CONFLICT` fehl und nennt die widersprüchlichen Pfade. Es wird nicht stillschweigend ein Gewinner ausgewählt.

Sie können diese Historie lesen:

```
print(client.viz.list_tags(viz_id))

print(client.viz.get_commit_log(viz_id, "main", max_count=20))

print(client.viz.preview_publish(viz_id))   # diff between draft and main
```

```
console.log(await client.viz.listTags(vizId));

console.log(await client.viz.getCommitLog(vizId, 'main', { maxCount: 20 }));

console.log(await client.viz.previewPublish(vizId));
```

## Ein Dashboard veröffentlichen[​](#ein-dashboard-veröffentlichen "Direkter Link zur Ein Dashboard veröffentlichen")

Ihr Agent kann das direkt über [MCP](/de/guides/build-with-your-agent.md) tun; in der App ist es der Knopf **Veröffentlichen**; im Code ist es ein Aufruf:

```
client.viz.publish(viz_id)
```

```
await client.viz.publish(vizId);
```

Das Veröffentlichen führt zunächst eine Gesundheitsprüfung des letzten Builds des Dashboards durch. Ist das Bundle `FAILED` oder veraltet, wird die Veröffentlichung mit einem `409` verweigert, statt etwas zu befördern, das nicht dargestellt wird — übergeben Sie `force=true`, um das bewusst zu übergehen.

Die Veröffentlichung mergt dann, taggt und startet einen Build. **Der Status wird erst dann `PUBLISHED`, wenn dieser Build erfolgreich ist**; schlägt er fehl, landet das Dashboard in `ERROR`, und `main` wird zurückgesetzt. Also ist die Rückkehr von `publish()` nicht dasselbe wie die Tatsache „das Dashboard ist live" — lesen Sie `publishStatus` zurück, bevor Sie jemandem sagen, der Link funktioniere. (Dieselbe Regel wie bei [einer Aktualisierung, die `202` liefert](/de/guides/keep-your-data-fresh.md#refresh-a-dataset-now): Der Abschluss des Aufrufs und der Abschluss der Arbeit sind zwei verschiedene Dinge.)

## Wer es öffnen kann — drei Modi, nicht zwei[​](#wer-es-öffnen-kann--drei-modi-nicht-zwei "Direkter Link zur Wer es öffnen kann — drei Modi, nicht zwei")

Das Veröffentlichen entscheidet, *dass* das Dashboard live ist. Ein separates Feld, `viewMode`, entscheidet, *wer* es öffnen kann. Diese beiden zu verwechseln ist der häufigste Fehler hier.

| `viewMode`  | Wer es öffnen kann                                                                                                                                                              |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `public`    | Jeder mit dem Link. Kein Konto erforderlich.                                                                                                                                    |
| `protected` | Nur ein Betrachter, für den Ihr Backend ein Embed-Token ausgestellt hat — mit Filtern pro Betrachter auf Zeilenebene. Siehe [Einbetten](/de/api/embedding-the-share-iframe.md). |
| `private`   | Niemand außerhalb Ihres Kontos. Veröffentlicht, aber von der öffentlichen Oberfläche aus nicht erreichbar.                                                                      |

Der Link eines veröffentlichten Dashboards sieht so aus:

```
https://cloud.vibedasher.com/v/<slug>
```

Diese URL liefert nur dann Inhalt, wenn das Dashboard **sowohl** veröffentlicht **als auch** `public` ist. Ein `protected`-Dashboard unter derselben URL braucht ein angehängtes Token.

### Öffentlich zu werden wird separat freigeschaltet, und ein Agent kann es nicht allein tun[​](#going-public-is-gated-separately-and-an-agent-cannot-do-it-alone "Direkter Link zur Öffentlich zu werden wird separat freigeschaltet, und ein Agent kann es nicht allein tun")

Firmendaten weltweit lesbar zu machen ist das einzige unumkehrbare Ding in diesem ganzen Ablauf, deshalb hat es eine eigene Schranke, statt einfach bei `publish` mitzulaufen. Zwei Schalter, beide auf Kontoebene, beide serverseitig auf jeder Route geprüft, die `viewMode` schreiben kann:

* **`allowForPublicViz`** — ein kontoweiter Notschalter. Schalten Sie ihn aus, kann nichts im Konto von irgendjemandem über irgendeine Route öffentlich gemacht werden.
* **`apiKeysMayPublish`** — **standardmäßig `false`.** Selbst wenn öffentliches Teilen erlaubt ist, darf ein Aufrufer, der sich mit einem **API-Schlüssel** authentifiziert, nicht derjenige sein, der ein Dashboard auf öffentlich umschaltet. Ein Admin muss dies aktivieren und kann das nur aus einer Browser-Sitzung heraus tun — `PUT /v1/account` weigert sich, dies von einem API-Schlüssel aus zu setzen, sodass der Schalter sich nicht selbst aktivieren kann.

Der zweite Punkt ist der entscheidende. An anderer Stelle auf dieser Plattform handelt ein API-Schlüssel als der Benutzer, der ihn erstellt hat, mit dessen voller Rolle (siehe [Wer sieht was](/de/guides/who-can-see-what.md)). Die Veröffentlichung ins offene Internet ist die bewusste Ausnahme: Ihr Agent kann das Dashboard bauen, veröffentlichen und innerhalb Ihres Kontos teilen, aber standardmäßig kann er nicht dasjenige sein, das es öffentlich macht. Ein Mensch in einem Browser muss einmal Ja gesagt haben, auf Kontoebene.

## Der Code ist eingefroren; die Daten sind es nicht[​](#der-code-ist-eingefroren-die-daten-sind-es-nicht "Direkter Link zur Der Code ist eingefroren; die Daten sind es nicht")

Das ist die Eigenschaft, die ein veröffentlichtes Dashboard eher hostenswert als exportierenswert macht.

**Der Dashboard-Code wird bei der Veröffentlichung als Momentaufnahme festgehalten.** Das Bundle wird einmal gebaut und aus dem Speicher ausgeliefert. Ihr Entwurf entwickelt sich unabhängig weiter und sickert nicht in die Live-Version, bis Sie erneut veröffentlichen.

**Die Daten werden zur Ansichtszeit live gelesen.** Jedes Diagramm auf einem veröffentlichten Dashboard fragt beim Öffnen den aktuellen Inhalt seiner Datensätze ab. Eine Aktualisierung, die um 3 Uhr morgens eintrifft, erscheint um 9 Uhr auf dem veröffentlichten Dashboard, ohne dass irgendetwas neu gebaut wird und ohne dass jemand beteiligt ist. Das ist der ganze Grund, warum die Datenhälfte in der Plattform lebt — siehe [Ihre Daten aktuell halten](/de/guides/keep-your-data-fresh.md).

## Veröffentlichung aufheben und erneut veröffentlichen[​](#veröffentlichung-aufheben-und-erneut-veröffentlichen "Direkter Link zur Veröffentlichung aufheben und erneut veröffentlichen")

`DELETE /v1/viz/{id}/publish` nimmt das Dashboard vom Netz: Der Status kehrt zu `NOT_PUBLISHED` zurück, und das Live-Bundle wird entfernt. Ihr Entwurf bleibt unangetastet.

* **Der Slug wird behalten und bleibt reserviert**, sodass eine erneute Veröffentlichung dieselbe URL wiederverwendet.
* **Alte Links scheitern uneinheitlich.** Die Betrachterseite antwortet mit `404`, die öffentliche API mit `403`, und die zwischengespeicherten Datenendpunkte mit `404`. Wenn Sie das programmatisch behandeln, verzweigen Sie nicht allein nach dem Statuscode.
* **Das Umbenennen des Slugs bricht jeden bestehenden Link dauerhaft.** Es gibt keine Weiterleitung von einem alten Slug zu einem neuen. Wählen Sie den Slug, bevor Sie die URL verteilen.

## Einbetten[​](#einbetten "Direkter Link zur Einbetten")

Veröffentlichte Dashboards werden über ein einbettbares Iframe dargestellt, das Sie in jede App, Dokumentationsseite oder Website einfügen können — öffentlich oder pro Betrachter mit zeilenbasierten Filtern gesichert. Siehe **[Ein Dashboard einbetten](/de/api/embedding-the-share-iframe.md)**.