Zum Inhalt springen

Deploy

Der Push ist das Deploy.

Eine animierte Illustration des App Builders: Ein Prompt wird in ein Textfeld getippt, der Button „Bau es“ wird gedrückt, und der Agent listet seinen Plan auf — Seiten, Datenmodell, eine Managed Database, ein Push ins Repository — bevor er anfängt zu arbeiten.

Beschreib eine App, und ein Agent schreibt sie in dein eigenes GitHub-Repository. Oder verbinde ein Repository, das du schon hast. So oder so: Der Push ist das Deploy — ein Build läuft auf deinem gemanagten Deploy-Server, und eine Live-Adresse kommt zurück.

Loslegen und bauen Push-Build ansehen

01 So funktioniert es

Beschreib es. Sieh zu, wie es entsteht.

Ein Workspace bindet ein GitHub-Repository an einen Chat. Du sagst, was du willst; der Agent schreibt den Code und pusht ihn; dein Deploy-Server baut den Push und veröffentlicht das Ergebnis.

Sechs Schritte: beschreiben, planen, bereitstellen, bauen, deployen, live. Eine Fortschrittsschiene zeichnet sich beim Scrollen an den Schritten entlang.

  1. 01 Beschreiben

    Sag, was du willst

    Ganz normale Sprache. Eine Landingpage, eine kleine API, eine WordPress-Site. Der Agent fragt, was er noch wissen muss, und legt dann in deinem Repository los.

  2. 02 Planen

    Der Agent plant es

    Seiten, Datenmodell, der Weg dazwischen. Jeder Schritt steht im Chat — nichts passiert im Verborgenen.

  3. 03 Bereitstellen

    Was sie braucht, fährt hoch

    Eine Managed Database wird mit der App bereitgestellt. Ihre Connection-URL landet als Config-Variable, damit die App sie beim nächsten Start findet.

  4. 04 Bauen

    Ein Push stößt einen Build an

    Der Agent committet in dein GitHub-Repository. Dein Deploy-Server nimmt den Commit auf — klonen, installieren, bauen — ohne dass du eine Pipeline-Datei schreibst.

  5. 05 Deployen

    Ein Release geht raus

    Config-Variablen und die angehängte Datenbank wandern ins neue Release mit. Die URL antwortet über den Wechsel hinweg weiter.

  6. 06 Live

    Eine URL kommt zurück

    Die App antwortet unter ihrer eigenen Adresse. Jeder spätere Push aktualisiert sie genauso, und die Adresse bleibt über alle Releases hinweg gleich.

02 Für Entwickler

Push, und es geht raus.

Verbinde ein Repository, und Interlaken übernimmt ab da — klonen, installieren, bauen, laufen lassen. Private Repositories laufen über deinen eigenen verbundenen GitHub-Account, es wechseln also keine Keys den Besitzer.

  • 01

    Push zum Deployen

    Wähl einen Branch. Jeder Commit darauf wird gebaut und released; es gibt keine Pipeline-Datei zu schreiben und keinen Runner zu pflegen.

  • 02

    Private Repositories, dein Account

    Private Repositories werden über deinen eigenen verbundenen GitHub-Account geklont. Es wechseln keine Deploy-Keys den Besitzer, und nichts wird in die Plattform kopiert.

  • 03

    Draufzeigen, Runtime wählen

    Interlaken klont das Repository, baut es und lässt es laufen. Web-Apps und Services, WordPress-Sites — wenn es baut und auf einem Port lauscht, läuft es.

  • 04

    Logs und Historie in der Console

    Build-Ausgabe, Deployment-Historie und das Aktivitätsprotokoll der App liegen auf derselben Seite wie die App.

Eine animierte Sequenz: Ein Commit ändert die Checkout-Summe, git push läuft, das Deploy-Log zeigt Build- und Release-Schritte, die App kommt unter ihrer Live-URL hoch, und die Deployment-Historie listet die Releases dahinter.

03 Weitermachen

Es wächst mit dir.

Deine App sitzt nicht in einer Black Box. Darunter liegen dieselben Primitive, auf denen alles andere auf Interlaken läuft — und an dem Tag, an dem du eines brauchst, ist es eine Seite entfernt, keine Migration.

01

Wenn sie Zustand braucht

Häng eine Managed-Datenbank an: PostgreSQL, MySQL, MongoDB, Redis oder Elasticsearch. Die Connection-URL landet als Config-Variable in der App; beim nächsten Start findet sie sie.

02

Wenn sie Einstellungen braucht

Bearbeite Umgebungsvariablen in der Console. Sie werden auf die laufende Maschine geschrieben und für den nächsten Start festgeschrieben — nichts driftet auseinander.

03

Wenn ein Release schlecht ist

Jedes Deploy wird mit seinem Build-Log festgehalten. Deploy eine frühere Version neu, und die App rollt darauf zurück — die URL antwortet die ganze Zeit weiter.

04

Wenn sie deinen Namen braucht

Jede App startet auf der App-Domain deines Deploy-Servers. Richte das DNS deiner eigenen Domain auf den Server, füg sie der App hinzu, und sie antwortet auch dort.

Darunter

  • Echte Maschinen

    Apps laufen auf virtuellen Maschinen, Firecracker-MicroVMs und Containern, die du vergrößern, snapshotten, per Konsole öffnen und selbst platzieren kannst.

    Infrastruktur ansehen

  • Echtes Networking

    Private Netzwerke und Subnetze, Load Balancer von TCP bis HTTP/3, öffentliche Adressen und geroutetes Egress — das Fabric, auf dem die Plattform selbst läuft.

    Plattform erkunden

  • Gemanagter Zustand

    PostgreSQL, MySQL, MongoDB, Redis und Elasticsearch als Managed Services, dazu replizierte Block-Volumes und S3-kompatible Buckets.

    Plattform erkunden

04 Fragen

Bevor du loslegst.

Die kurzen Antworten. Die langen sind eine Seite in der Console.

Nein. Im App Builder beschreibst du die App im Chat, und ein Agent schreibt und deployt sie. Der Code liegt die ganze Zeit in deinem eigenen GitHub-Repository — du kannst ihn lesen, ändern oder jederzeit einer Entwicklerin geben.

Nichts zu installieren

Starte mit einem Satz.

Leg einen Account an, beschreib, was laufen soll, und lass den Agenten den ersten Durchgang machen. Du zahlst, was du nutzt.

Loslegen Preise ansehen