# Site für Laravel, WordPress, Next.js und mehr anlegen

> Lege auf deinem Server eine Site aus einer Vorlage wie Laravel, WordPress oder Next.js an, mit Repository, Datenbank, Domain und kostenloser Testadresse.

Eine **Site** in Vimonto Deploy ist eine Website oder App auf einem deiner Server: mit eigener Domain, Nginx-Konfiguration, eigenem Code, eigener `.env` und eigenen Deploys. Du legst sie aus einer Framework-Vorlage an (Laravel, WordPress, Next.js und andere). Die Vorlage wählt die Runtime, das Web-Verzeichnis, den Build-Befehl und ein passendes Deploy-Skript.

Wenn du eine Site anlegst, richtet Vimonto Deploy sie auf dem Server ein, verknüpft ihr Repository und deployt sie sofort. Wenige Minuten später ist die Site unter einer generierten `on-deploy.link`-Adresse live, noch bevor du DNS angefasst hast.

![Das Formular für eine neue Site mit Server, Repository, Datenbank und generierter Adresse](https://ops.vimonto.com/docs-media/de/create-site.webp?v=161e760d "Eine Laravel-Site anlegen")

![Das Formular für eine neue Site ausfüllen und die Site anlegen](https://ops.vimonto.com/docs-media/de/create-site.mp4?v=161e760d)

## Alle deine Sites finden

Der Tab **Sites** in der oberen Leiste listet alle Sites der Organisation auf, über alle ihre Server hinweg. Jede Zeile zeigt die Domain mit dem Symbol des Frameworks und darunter den Server, das Framework, die PHP-Version und den Branch. **Deployt** sagt, wie lange der letzte Deploy der Site her ist (oder **noch nicht deployt**), und **Status** zeigt, ob sie bereit oder noch beschäftigt ist. Suche nach Domain, sortiere nach einer Spalte und klicke auf eine Zeile, um die Site zu öffnen.

Nutzt deine Organisation [Teams](https://ops.vimonto.com/docs/de/organization/teams), siehst du nur die Sites auf den Servern, auf die du Zugriff hast. Die eigene Seite **Sites** eines Servers listet nur die Sites auf diesem Server.

![Die Sites-Liste der Organisation mit Server, Framework, letztem Deploy und Status jeder Site](https://ops.vimonto.com/docs-media/de/sites-list.webp?v=161e760d "Die Sites der Organisation")

## Eine neue Site starten

1. Öffne einen Server und gehe zu seiner Seite **Sites**.
2. Klicke auf **Neue Site** und wähle, womit die Site gebaut ist, zum Beispiel **Laravel** oder **WordPress**.
3. Fülle das Formular aus (jedes Feld wird unten beschrieben) und klicke auf **Site anlegen**.

**Neue Site** in der Liste **Sites** der Organisation hat dasselbe Menü mit Frameworks. Im Formular wählst du dann den Server, und sein Link **← Sites** führt zurück zur Liste der Organisation statt zu der des Servers.

Sites laufen auf Servern, die Websites ausliefern: einem App-Server oder einem Webserver. Ein Load Balancer nimmt nur lastverteilte Sites auf (siehe [Lastverteilung](https://ops.vimonto.com/docs/de/sites/load-balancing)). Gibt es noch keinen passenden Server, zeigt das Formular **Noch kein Server für Sites** und bietet **Neuer Server** an. Unter [Servertypen](https://ops.vimonto.com/docs/de/servers/server-types) siehst du, was jeder Typ installiert.

Du brauchst in der Organisation die Berechtigung, Sites zu verwalten; siehe [Mitglieder und Rollen](https://ops.vimonto.com/docs/de/organization/members-and-roles). Der kostenlose Tarif umfasst 3 Sites über alle Server der Organisation zusammen; sind sie belegt, zeigt das Formular **Dein Tarif ist voll** mit **Tarife ansehen**. Siehe [Abrechnung](https://ops.vimonto.com/docs/de/organization/billing).

## Welche Frameworks kannst du wählen?

Das Menü **Neue Site** gruppiert die Vorlagen nach Sprache. Jede Vorlage legt die Runtime fest (wie Nginx die Site ausliefert) und sinnvolle Standardwerte, die du unter **Erweiterte Einstellungen** ändern kannst.

| Vorlage | Runtime | Web-Verzeichnis | Composer | Standard-Build-Befehl | Repository |
|---|---|---|---|---|---|
| Laravel | Laravel (PHP) | `/public` | Ja | `npm run build` | Ja |
| Symfony | PHP | `/public` | Ja | keiner | Ja |
| Statamic | Laravel (PHP) | `/public` | Ja | `npm run build` | Ja |
| WordPress | PHP | `/` | Nein | keiner | Nein, wird für dich installiert |
| phpMyAdmin | PHP | `/` | Nein | keiner | Nein, wird für dich installiert |
| PHP | PHP | `/public` | Ja | keiner | Ja |
| Next.js | Node.js | nicht verwendet | Nein | `npm run build` | Ja |
| Nuxt | Node.js | nicht verwendet | Nein | `npm run build` | Ja |
| HTML | Statisch | `/` | Nein | keiner | Ja |
| Sonstiges | PHP | `/` | Nein | keiner | Ja |
| Load Balancer | Proxy zu deinen App-Servern | nicht verwendet | Nein | keiner | Nein |

Was die Runtimes bedeuten:

- **Laravel**: PHP-FPM hinter Nginx, mit Laravels `storage/`, das zwischen Releases geteilt wird, Queue-Workern und dem Scheduler.
- **PHP**: jede PHP-App mit einer `index.php`, etwa Symfony oder WordPress.
- **Statisch**: HTML oder ein Frontend, das zu Dateien gebaut wird (Vite, Astro, ein statischer Next.js-Export).
- **Node.js**: eine App, die auf einem Port lauscht; Nginx leitet Anfragen an sie weiter.

Die Vorlage **Load Balancer** unter **Lastverteilung** im Menü ist nur für Load-Balancer-Server gedacht und die einzige Art von Site, die diese aufnehmen. Sie hat keinen Code und keine Deploys: Sie leitet Anfragen an deine App-Server weiter. Ihr Formular hat kein Repository, keine Datenbank und keinen Bereich **Erweiterte Einstellungen**, weil es nichts zu bauen oder zu isolieren gibt. Siehe [Lastverteilung](https://ops.vimonto.com/docs/de/sites/load-balancing).

### WordPress und phpMyAdmin

WordPress und phpMyAdmin brauchen kein Repository. Vimonto Deploy lädt das neueste Release auf den Server herunter und schreibt die Konfiguration:

- **WordPress** bekommt eine `wp-config.php` mit Datenbankname, Benutzer und Passwort sowie neuen Sicherheitsschlüsseln und Salts. WordPress braucht immer eine Datenbank, deshalb lässt sich **Datenbank verbinden** nicht ausschalten.
- **phpMyAdmin** bekommt eine `config.inc.php`, die sich per Cookie-Authentifizierung beim Datenbankserver auf derselben Maschine anmeldet.

Öffne die Site danach, um die WordPress-Installation im Browser abzuschließen.

## Das Formular ausfüllen

### Server

Wähle den Server, auf dem die Site laufen soll. Aufgeführt sind nur aktive Server, die diese Art von Site hosten können, jeweils mit ihrer IP-Adresse: App- und Webserver für jede Vorlage, Load Balancer nur für die Vorlage **Load Balancer**.

### Quellcode, Repository und Branch

Wähle unter **Quellcode** eine deiner [Git-Verbindungen](https://ops.vimonto.com/docs/de/connections/source-control) (GitHub, GitLab oder Bitbucket) oder **Eigene Git-URL**.

- Mit einer Verbindung wählst du das **Repository** (optional gefiltert nach **Organisation**) und den **Branch**.
- Mit **Eigene Git-URL** gibst du die **Git-URL** ein, etwa `git@github.com:you/project.git` oder `https://github.com/you/project.git`, und den **Branch**.

Das Repository ist optional. Ohne Repository wird die Site mit einer Platzhalterseite eingerichtet, und du kannst später auf der Seite [Deployments](https://ops.vimonto.com/docs/de/sites/deployments) ein Repository verbinden.

### Datenbank verbinden

Auf einem Server mit Datenbank ist **Datenbank verbinden** standardmäßig aktiv, mit einer neuen Datenbank, die nach der Site benannt ist (zum Beispiel `shop_example_com`). Du kannst:

- auf **Ändern** oder **Datenbank anlegen** klicken, um den Namen, einen eigenen **Benutzer** und ein **Passwort** zu wählen. Lässt du den Benutzer leer, wird der eigene Datenbankbenutzer des Servers verwendet. Lässt du das Passwort leer, wird eines generiert.
- eine vorhandene Datenbank aus der Liste wählen. Die Site bekommt dann einen eigenen Datenbankbenutzer dafür, sodass sie nie ein Passwort mit einer anderen Site teilt.

Bei Laravel- und Statamic-Sites werden Datenbankname, Benutzer und Passwort in die `.env` der Site geschrieben. Wie du sie später verwaltest, steht unter [Datenbanken](https://ops.vimonto.com/docs/de/servers/databases).

### Domain oder generierte Adresse

Jede Site kann eine kostenlose Adresse auf `on-deploy.link` bekommen, etwa `kalme-rivier-4821.on-deploy.link`. Den ersten Teil des Namens kannst du im Feld **on-deploy.link-Adresse** ändern. Die Adresse funktioniert sofort, ganz ohne eigenes DNS. Das ist praktisch zum Testen und Teilen. Eine Site, die unter dieser Adresse läuft, bekommt außerdem von selbst HTTPS (siehe unten).

Für eine eigene Domain klickst du auf **Eigene Domain verwenden** und gibst sie ein, zum Beispiel `shop.example.com`. Lass **Auch …on-deploy.link** angehakt, wenn die Site auch unter der generierten Adresse erreichbar sein soll.

Dann braucht die Domain DNS-Einträge, die auf den Server zeigen. Mit DNS-Integrationen steht unter der Domain der Hinweis „Wir suchen die Domain bei deinen DNS-Anbietern und setzen ihre Einträge automatisch.“ Während du tippst, zeigt ein Feld **DNS**, ob eine deiner [Integrationen](https://ops.vimonto.com/docs/de/connections/integrations) (Hetzner Cloud, DigitalOcean, Vultr, Akamai, AWS, Google Cloud oder Cloudflare) sie verwaltet; deren Domain-Listen werden live geholt:

- Wenn ja, ist **Automatisch mit … einrichten** gewählt. Das Feld listet die Einträge (einen A-Record für die Domain und einen CNAME für `www.`) als **Neu**, **Bereits richtig** oder **Änderungen** auf, mit einer Warnung für alles, was sich ändert oder entfernt wird. Ändern sich bestehende Einträge, hake **Diese Einträge ändern** an. Nach der Einrichtung aktualisiert Vimonto Deploy die Einträge, wartet, bis die Domain auflöst, und fordert HTTPS von selbst an. Wähle **Ich verwalte das DNS selbst**, um das DNS unverändert zu lassen.
- Wenn nein, du aber DNS-Integrationen hast, schalte **Domain zu einem DNS-Anbieter hinzufügen** ein und wähle **Provider** und **Zone** (vorgegeben ist die Domain ohne ihre Subdomain, etwa `example.com`). Vimonto Deploy legt die Zone dort an, setzt die Einträge und listet in der Ausgabe des Tasks die Nameserver auf, die du bei deinem Registrar einträgst; HTTPS folgt, sobald das DNS auflöst.
- Sonst richte bei deinem DNS-Anbieter selbst einen A-Record ein, der auf die IP-Adresse des Servers zeigt.

> [!TIP]
> Das DNS deiner Domain kann für dich eingerichtet werden. Verbinde Cloudflare, Hetzner Cloud, DigitalOcean, Vultr, Akamai, AWS oder Google Cloud unter [Integrationen](https://ops.vimonto.com/docs/de/connections/integrations), dann findet Vimonto Deploy die Domain dort, legt ihre Einträge an und beantragt HTTPS selbst. Ohne Verbindung zeigt das Domain-Formular **Tipp: Lass uns die DNS-Einträge setzen** mit einem Link, um eine zu verbinden.

Was jede Warnung bedeutet, steht unter [Domains und SSL](https://ops.vimonto.com/docs/de/sites/domains-and-ssl#domain-automatisch-per-dns-integration-einrichten).

Weitere Domains hinzufügen, die generierte Adresse abschalten und HTTPS aktivieren kannst du später; siehe [Domains und SSL](https://ops.vimonto.com/docs/de/sites/domains-and-ssl).

### Composer-Pakete installieren

Bei Laravel-, Symfony-, Statamic- und PHP-Sites mit Repository fügt **Composer-Pakete installieren** dem Deploy-Skript `composer install` hinzu. Schalte es aus, wenn dein Projekt keine `composer.json` hat oder seine Pakete anders installiert.

### Eigener Deploy Key

Ist **Eigener Deploy Key für GitHub** (oder GitLab, Bitbucket; bei einer eigenen Git-URL **Eigener Deploy Key für deinen Git-Host**) aktiv, wie standardmäßig, bekommt die Site einen eigenen SSH-Schlüssel für ihr Repository. Bei einem verbundenen Git-Host registriert Vimonto Deploy ihn als schreibgeschützten Deploy Key im Repository. Bei einer eigenen Git-URL kopierst du den Schlüssel von der Seite Deployments und fügst ihn selbst bei deinem Git-Host hinzu.

Bei einem Repository von einem verbundenen Git-Host wird außerdem **Bei jedem Push deployen** eingeschaltet: Vimonto Deploy fügt einen Webhook hinzu, und jeder Push auf den Branch löst einen Deploy aus. Du kannst das auf der Seite [Deployments](https://ops.vimonto.com/docs/de/sites/deployments#push-to-deploy) ausschalten.

## Erweiterte Einstellungen

Klicke auf **Erweiterte Einstellungen**, um die Standardwerte der Vorlage zu ändern. Mit **Einstellungen speichern** behältst du sie.

| Einstellung | Was sie bewirkt |
|---|---|
| **Stammverzeichnis** | Wo die App im Repository liegt. `/` ist das ganze Repository; für ein Monorepo nimmst du `/backend` oder Ähnliches. |
| **Web-Verzeichnis** | Was Nginx ausliefert, innerhalb des Stammverzeichnisses, etwa `/public` oder `/dist`. Bei Node.js-Sites nicht sichtbar. |
| **PHP-Version** | Eine der auf dem Server installierten PHP-Versionen. Siehe [PHP](https://ops.vimonto.com/docs/de/servers/php). |
| **Frontend-Paketmanager** | npm (Standard), yarn, pnpm oder bun. Yarn und pnpm laufen über Corepack. |
| **Build-Befehl** | Läuft nach der Installation der Pakete, etwa `npm run build`. Leer: Es wird nichts gebaut. |
| **Website-Isolation** | Gibt der Site einen eigenen Linux-Benutzer mit einem **Benutzernamen**, den du wählst. |
| **Zero-Downtime-Deploys** | Baut jeden Deploy in einem neuen Release und schaltet erst um, wenn er erfolgreich war. Standardmäßig aktiv. |
| **Composer-Authentifizierung** | Host, Benutzername und Passwort oder Token für private Composer-Pakete, etwa `repo.packagist.com`. |
| **npm-Authentifizierung** | Registry und Token für eine private npm-Registry, etwa `https://npm.pkg.github.com`. |

### Ein Monorepo deployen

Setze das **Stammverzeichnis** auf den Ordner der App, zum Beispiel `/backend`. Das ganze Repository wird geklont, aber das Deploy-Skript läuft in diesem Ordner, die `.env` wird dort verlinkt, und das Web-Verzeichnis wird darin gesucht. Liegt der Ordner nicht im Repository, schlägt der Deploy mit einer klaren Meldung fehl.

### Website-Isolation

Eine isolierte Site läuft unter einem eigenen Linux-Benutzer, mit einem Home-Verzeichnis, das andere Sites nicht lesen können. Eine PHP-Site bekommt außerdem einen eigenen PHP-FPM-Pool, der unter diesem Benutzer läuft. Nginx kann die Dateien trotzdem ausliefern, weil der Systembenutzer des Servers der Gruppe der Site beitritt. Nutze das, wenn sich mehrere Kunden oder Projekte einen Server teilen.

Der Benutzer wird beim Anlegen der Site gewählt. Der Name darf nur Kleinbuchstaben, Ziffern, `_` und `-` enthalten, muss mit einem Buchstaben beginnen und darf kein Systemname wie `root` oder `www-data` sein.

### Zero-Downtime-Deploys

Mit Zero-Downtime-Deploys wird jeder Deploy in einem neuen Release-Verzeichnis gebaut und mit einem einzigen atomaren Wechsel live geschaltet. Besucher sehen so nie eine halb gebaute Site, und du kannst zurücksetzen. Ist die Option aus, wird ein Release direkt aktualisiert: schneller, aber Besucher sehen den Build eventuell mit, und es gibt kein Rollback. Du kannst das später in den [Site-Einstellungen](https://ops.vimonto.com/docs/de/sites/site-settings) ändern. Details findest du unter [Deployments](https://ops.vimonto.com/docs/de/sites/deployments).

### Private Composer- und npm-Pakete

Die Zugangsdaten unter **Composer-Authentifizierung** und **npm-Authentifizierung** werden verschlüsselt gespeichert und nur während des Builds verwendet: Composer liest sie aus `COMPOSER_AUTH`, npm aus einer temporären Konfigurationsdatei, die danach gelöscht wird. Später kannst du sie in den **Einstellungen** der Site in den Tabs **Composer** und **npm** hinzufügen, ändern oder entfernen: siehe [Zugangsdaten für Composer und npm](https://ops.vimonto.com/docs/de/sites/site-settings#zugangsdaten-für-composer-und-npm).

## Was passiert, nachdem du auf Site anlegen geklickt hast?

Du landest auf der Seite der Site, die bis zum Livegang nur die Einrichtung zeigt: die Phasen, den laufenden Schritt und das Log jeder Aufgabe. Du kannst die Seite jederzeit verlassen; die Arbeit läuft im Hintergrund weiter.

1. **Einrichten**: Vimonto Deploy legt den DNS-Eintrag für die generierte Adresse an, erstellt die Datenbank und ihren Benutzer, legt die Verzeichnisse der Site an und schreibt die `.env`, den PHP-FPM-Pool (bei Isolation) und die Nginx-Konfiguration. Bis zum ersten Deploy zeigt die Site eine Seite, die meldet, dass sie bereit ist. WordPress und phpMyAdmin werden in dieser Phase installiert.
2. **Verknüpfen**: Bei einem Repository wird der Deploy Key auf dem Server abgelegt und, bei einem verbundenen Git-Host, zusammen mit dem Push-Webhook im Repository registriert.
3. **Abrufen, Build, Live**: Der erste Deploy klont den Branch, führt das Deploy-Skript aus und schaltet das Release live.
4. **HTTPS**: für eine Site, deren Adresse die generierte `on-deploy.link`-Adresse ist, und für eine Site mit eigener Domain, die eine DNS-Integration verweist. Bei einer eigenen Domain aktualisiert Vimonto Deploy zuerst die DNS-Einträge, wie der Plan es gezeigt hat. Dann wartet es, bis der Name auf den Server zeigt (höchstens 10 Minuten), fordert ein kostenloses Let's-Encrypt-Zertifikat an und stellt die Site auf HTTPS um. Diese Phase läuft parallel zum ersten Deploy und wird als letzte angezeigt. Schlägt sie fehl, funktioniert die Site weiter über HTTP; fordere später unter [Domains und SSL](https://ops.vimonto.com/docs/de/sites/domains-and-ssl) ein Zertifikat an.

Eine Site, die mit einer eigenen Domain angelegt wurde, deren DNS du selbst verwaltest, überspringt die HTTPS-Phase, weil ihr DNS vielleicht noch nicht auf den Server zeigt. Fordere ihr Zertifikat an, sobald das der Fall ist.

Solange die Einrichtung läuft (Einrichten, Verbinden des Repositorys, der erste Deploy und das erste HTTPS-Zertifikat), ist diese Übersicht mit den Schritten die einzige Seite der Site, zusammen mit dem Log des ersten Deploys: Es gibt keine Seitenleiste, und die anderen Seiten der Site führen zu ihr zurück.

Sobald alles erledigt ist, wird die Seite zur normalen Übersicht der Site mit ihrer Seitenleiste. Wenn du (oder jemand anderes in der Organisation) sie danach zum ersten Mal öffnest, beginnt sie mit **Deine Site ist live**, wie lange die Einrichtung gedauert hat, und einem Button **Öffnen**; **Schließen** blendet das aus, und bei späteren Besuchen siehst du nur die Übersicht.

Auf der Festplatte liegt jede Site in `/home/{user}/{domain}`, mit `releases/`, `shared/` und einem Symlink `current`. Das Verzeichnis behält seinen Namen, wenn du die Domain der Site später änderst.

Schlägt eine Phase fehl, zeigt die Seite **Einrichtung fehlgeschlagen**, **Verbinden des Repositorys fehlgeschlagen** oder **Erster Deploy fehlgeschlagen**, mit dem Fehler und dem Log des fehlgeschlagenen Schritts (unter **Details und Log**). Behebe die Ursache (einen Branch-Namen, einen fehlenden Deploy Key) und nutze den Button auf der Seite: **Erneut versuchen**, **Erneut verbinden** oder **Erneut deployen**. Ist eine Phase fehlgeschlagen, sind die Seitenleiste und alle Seiten der Site wieder da, damit du die Ursache auf den Seiten **Deployments** und **Umgebung** beheben kannst.

### Wie es weitergeht

- Aktiviere für eine Site mit eigener Domain, deren DNS du selbst verwaltest, HTTPS mit einem kostenlosen Let's-Encrypt-Zertifikat unter [Domains und SSL](https://ops.vimonto.com/docs/de/sites/domains-and-ssl).
- Prüfe die `.env` unter [Umgebung](https://ops.vimonto.com/docs/de/sites/environment).
- Füge bei Laravel Queue-Worker und den Scheduler unter [Queues und Scheduler](https://ops.vimonto.com/docs/de/sites/queues-and-scheduler) hinzu oder schalte Horizon im Menü der [Site-Features](https://ops.vimonto.com/docs/de/sites/site-features) ein.
- Rufe bei einer eigenen Git-URL die [Deploy-URL](https://ops.vimonto.com/docs/de/sites/deployments#aus-der-ci-mit-der-deploy-url-deployen) von deinem Git-Host oder deiner CI aus auf, um bei einem Push zu deployen.

![Die Sites eines Servers mit ihren Domains und letzten Deploys](https://ops.vimonto.com/docs-media/de/server-sites.webp?v=161e760d "Die Sites eines Servers")

## Häufig gestellte Fragen

### Brauche ich eine Domain, um eine Site anzulegen?

Nein. Jede Site kann eine generierte `on-deploy.link`-Adresse bekommen, die sofort funktioniert. Füge deine eigene Domain hinzu, sobald du so weit bist.

### Kann ich mehrere Sites auf einem Server hosten?

Ja. Ein Server kann so viele Sites aufnehmen, wie er Platz hat. Jede Site hat ihre eigene Nginx-Konfiguration und ihr eigenes Verzeichnis; mit Website-Isolation bekommt jede zusätzlich einen eigenen Linux-Benutzer.

### Welches Repository nutzt WordPress?

Keines. WordPress und phpMyAdmin werden beim Anlegen der Site heruntergeladen und auf dem Server installiert. Wenn du ein WordPress-Projekt in Git verwaltest, wähle stattdessen die Vorlage **PHP** und verbinde dein Repository.

### Wie deploye ich eine Next.js- oder Nuxt-App?

Wähle **Next.js** oder **Nuxt**. Die Site bekommt einen freien lokalen Port (ab 3000 aufwärts), an den Nginx weiterleitet, und das Deploy-Skript installiert die Pakete und führt `npm run build` aus. Vimonto Deploy fügt außerdem den Prozess hinzu, der deine App auf diesem Port betreibt, und das erste Deployment startet ihn. Du findest ihn unter [Prozesse](https://ops.vimonto.com/docs/de/sites/queues-and-scheduler#eine-nodejs-app-betreiben).

### Kann ich eine Site auf mehrere Server verteilen?

Ja, mit einem Load-Balancer-Server vor zwei oder mehr App-Servern, auf denen jeweils dieselbe Site läuft. Siehe [Lastverteilung](https://ops.vimonto.com/docs/de/sites/load-balancing).

### Kann ich das Framework später ändern?

Nein, die Vorlage wird beim Anlegen der Site gewählt. PHP-Version, Web-Verzeichnis, Node.js-Port und Zero-Downtime-Deploys kannst du in den [Site-Einstellungen](https://ops.vimonto.com/docs/de/sites/site-settings) ändern, das Deploy-Skript auf der Seite [Deployments](https://ops.vimonto.com/docs/de/sites/deployments).

### Kann ich eine bestehende Site kopieren?

Ja. Klicke in den **Einstellungen** der Site auf **Site klonen**, um eine neue Site mit demselben Repository, denselben Build-Einstellungen, demselben Deploy-Skript und denselben Regeln anzulegen, auf demselben oder einem anderen Server. Siehe [eine Site klonen](https://ops.vimonto.com/docs/de/sites/site-settings#eine-site-klonen).