Warum wir Setup bauen

Du findest ein Projekt, das genau das kann, was du brauchst. Dann öffnest du das README. Du sollst Docker einrichten, eine Datenbank anlegen und Einstellungen ausfüllen, die dir nichts sagen. Eigentlich wolltest du nur einen Kalender fürs Team.

Daran arbeiten wir mit Setup. Du fügst ein Repository, einen Space auf Hugging Face oder eine Anleitung ein. Oder du beschreibst, welche App du brauchst. Setup schreibt ein Rezept, zeigt es dir und startet die App nach deiner Bestätigung abgeschottet.

Heute laufen Apps auf deinem eigenen Rechner oder Server zu Hause oder im Büro. Jemand muss ihn zuerst anschließen. Für alle, die ihre Apps bei uns betreiben möchten, kommt später Setup Cloud. Es ist noch nicht geöffnet.

Vor dem Start nachlesen

Während der Analyse liest Setup Projektdateien als Daten. Es installiert keine Abhängigkeiten und führt keinen Projektcode aus. Ein vorhandenes Rezept aus dem Katalog hat Vorrang. Sonst sucht die Analyse nach Anleitungen, etwa einer Datei für Compose. Ein eingerichtetes Modell kann fehlende Teile ergänzen.

Das Ergebnis heißt setup.json. Hier ist das Rezept für Uptime Kuma aus dem Katalog. Die App prüft, ob Webseiten erreichbar sind.

{
  "version": 1,
  "slug": "uptime-kuma",
  "name": "Uptime Kuma",
  "source": {
    "kind": "github",
    "url": "https://github.com/louislam/uptime-kuma"
  },
  "services": {
    "app": {
      "image": "louislam/uptime-kuma:2.5.6-slim",
      "env": { "UPTIME_KUMA_DB_TYPE": "sqlite" },
      "ports": [{ "container": 3001 }],
      "volumes": [{ "name": "data", "path": "/app/data" }],
      "egress": "public",
      "resources": { "memoryMb": 512 }
    }
  },
  "expose": { "service": "app", "port": 3001 },
  "checks": { "http": { "path": "/" } }
}

Du siehst das verwendete Image, den Speicherort der Daten und die Prüfung nach dem Start. Der Internetzugang steht ausdrücklich im Rezept, weil die App andere Webseiten erreichen muss. Privilegierten Modus oder direkten Zugriff auf Docker kann das Rezept nicht anfordern.

Ein Rezept ist trotzdem erst ein Plan. Manche Projekte brauchen Änderungen, bevor sie laufen. Setup zeigt seine Erkenntnisse, damit du die Einstellungen prüfen kannst.

Ein Kalender für Kollegen, ein Rezept für Entwickler

In der einfachen Ansicht fragst du nach einem Kalender oder einem Ort für Familienfotos. Der Assistent schlägt eine App vor und fragt vor Änderungen nach. Probier etwa Immich für Fotos oder einen Passwortmanager fürs Büro.

In der Detailansicht stehen dir Rezepte und Protokolle zur Verfügung. Entwickler können ein Rezept ändern, erneut ausführen und lokal mit der CLI prüfen.

Teams teilen Arbeitsbereiche mit Rollen. Team und Business ergänzen Richtlinien, Freigaben und ein Änderungsprotokoll. In einem privaten Katalog finden Kollegen die internen Apps, die ihr ausgewählt habt. Diese Funktionen sind gebaut und lassen sich auf Anfrage freischalten. Bezahltarife sind noch nicht buchbar.

Wenn die App läuft

Ein Test endet nach einer Stunde und entfernt seine Daten. Behalte die App vorher, wenn du sie brauchst. Setup schaltet tägliche Sicherungen ein und prüft, ob sie antwortet. Änderungen am Rezept kannst du vor dem Anwenden ansehen.

Sicherungen liegen auf demselben Server wie die App. Sie sind keine zusätzliche Kopie an einem anderen Ort. Wenn der Server selbst ausfällt, macht das einen Unterschied.

Du kannst eine eigene Domain mit HTTPS nutzen oder mehrere zusammengehörige Apps als Stack starten. Laufen auf deinem Server schon Apps, listet Setup sie auf und zieht die ausgewählten mit ihren Daten um. Alte Kopien bleiben gestoppt liegen, bis du sie entfernst. Ordner, die an ihrem bisherigen Ort bleiben, werden noch nicht gesichert. Umgezogene Apps bekommen eine neue Adresse.

Deine Konten bleiben bei dir

Setup betreibt keine Sprachmodelle. Apps mit KI nutzen deinen Zugang zu einem Modellanbieter. Bei OpenRouter bekommt jede App einen eigenen Schlüssel mit Monatslimit. Für eine andere mit OpenAI kompatible API hinterlegst du einen Schlüssel nur für diese App.

Genauso trennt Setup verbundene Dienste für Mailversand oder Speicher. Es erfasst, was es für eine App anlegt, und entfernt es beim Löschen der App. Fehlgeschlagene Löschungen werden wiederholt. Was übrig bleibt, erscheint mit einer Anleitung. Die meisten Anbindungen müssen noch mit echten Konten getestet werden.

Was die Abschottung abdeckt und was offen bleibt

Apps haben Ressourcengrenzen und getrennte Netze. Standardmäßig erreichen sie dein lokales Netz nicht. Erlaubter Internetzugang führt über einen Proxy, der private Adressen ablehnt.

Bauschritte können das Netz des Servers trotzdem erreichen. Container teilen sich außerdem dessen Kernel, sofern der Runner nicht gVisor oder Kata nutzt. Das Sicherheitsmodell erklärt diese Grenzen und die nötigen Einstellungen am Server.

Ein grünes Badge braucht einen erfolgreichen Lauf auf Setups eigenen Runnern. Blau bedeutet eine Erfolgsmeldung aus der CI des Projekts mit einem Token des Projektbetreuers. Ein Lauf auf deinem eigenen Runner ändert das Badge nie.

Was noch kommt

Die Begleitapp fürs Handy ist gebaut, aber weder im App Store noch bei Google Play. Setup Cloud ist noch nicht geöffnet. Für beides nennen wir hier keinen Starttermin.

Rezeptformat, Analyse, Katalog und Runner sollen als Open Source erscheinen. Veröffentlicht ist noch nichts, ein öffentliches Repository gibt es nicht. Die Webanwendung und Setup Cloud bleiben geschlossen. Auch Downloads des Runners und die GitHub Action sind noch nicht veröffentlicht. Die Beispiele auf dieser Seite beschreiben die Umsetzung, keinen verfügbaren Download.

Du hast einen Server und eine App, die du ausprobieren möchtest? Schreib uns, was du brauchst.