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.
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, 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.
Eine neue Site starten
- Öffne einen Server und gehe zu seiner Seite Sites.
- Klicke auf Neue Site und wähle, womit die Site gebaut ist, zum Beispiel Laravel oder WordPress.
- 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). Gibt es noch keinen passenden Server, zeigt das Formular Noch kein Server für Sites und bietet Neuer Server an. Unter Servertypen siehst du, was jeder Typ installiert.
Du brauchst in der Organisation die Berechtigung, Sites zu verwalten; siehe Mitglieder und Rollen. 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.
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.
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.phpmit 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 (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.gitoderhttps://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 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.
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 (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.
Was jede Warnung bedeutet, steht unter Domains und SSL.
Weitere Domains hinzufügen, die generierte Adresse abschalten und HTTPS aktivieren kannst du später; siehe Domains und 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 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. |
| 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 ändern. Details findest du unter 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.
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.
- 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. - 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.
- Abrufen, Build, Live: Der erste Deploy klont den Branch, führt das Deploy-Skript aus und schaltet das Release live.
- 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 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.
- Prüfe die
.envunter Umgebung. - Füge bei Laravel Queue-Worker und den Scheduler unter Queues und Scheduler hinzu oder schalte Horizon im Menü der Site-Features ein.
- Rufe bei einer eigenen Git-URL die Deploy-URL von deinem Git-Host oder deiner CI aus auf, um bei einem Push zu deployen.
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.
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.
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 ändern, das Deploy-Skript auf der Seite 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.