Wie man mit osFoundry Custom App kleine interne Apps baut und hostet

Es ist Donnerstag, zwei Stunden vor einem Release, und Dari ist die einzige Person, die weiß, welche Schritte des Cutovers schon erledigt sind. Die Checkliste liegt in einem Tabellenblatt, das Runbook auf einem geteilten Laufwerk und die Diskussion in einem Chat-Thread, den niemand mehr findet. Was das Team eigentlich braucht, ist eine winzige App mit vier Checkboxen und zwei Verantwortlichen, direkt neben den Dateien. Die zu schreiben ist einfach. Sie zu hosten, ihr eine Datenbank zu geben, ihre Schlüssel sicher aufzubewahren und ihr eine URL zu verschaffen, daran hakt es meistens.

Was die Kategorie Custom App ist

osFoundry bündelt alles, was man zum Bauen und Betreiben eigener kleiner Apps braucht, in einer einzigen Kategorie in der Seitenleiste der Desktop-App: CUSTOM APP. Sie hat fünf Ansichten. Room ist der gemeinsame Raum, in dem Apps als Tabs leben. App Code ist das Repository hinter einer App. Deployed Apps ist die Workspace-weite Liste dessen, was live ist. Snippets sammelt die winzigen Apps, die nie ein Repository gebraucht haben. Domains verwaltet die Webadressen, unter denen diese Apps ausgeliefert werden. Wer Notion kennt, stellt sich eine Seite vor, deren Tabs funktionierende Apps statt Dokumente sind, mit einer kleinen Hosting-Schicht im Stil von Vercel darunter: Jede App bekommt ihre eigene Datenbank, Secrets, geplante Jobs und eine Subdomain, wie auf der Feature-Seite zu internen Apps beschrieben.

Ein Blick auf die Build-Ansicht

Am schnellsten sieht man, wie eine App entsteht, in der Build-Ansicht der Desktop-App. Dieser Screenshot stammt aus dem Websites-Builder (Beispielprojekt "Hearth Bakery"), der denselben Ablauf aus Beschreiben und Bauen nutzt, den eine Room mit ihrem Feld "Describe the app you want" anbietet.

• Pages, links: die Teile der App, die schon existieren, unten mit Add page.
• Die Vorschau, in der Mitte: das, was du gerade baust, darüber die Größen Desktop, Tablet und Smartphone. Das Label "On this computer" zeigt, dass noch nichts veröffentlicht wurde.
• Das Beschreibungsfeld: Du schreibst, was die App tut, für wen sie ist und wie sie wirken soll, und klickst dann auf Build my site. Maestro, der KI-Assistent der App, schreibt die Dateien.
• Das Maestro-Panel, rechts: die Unterhaltung, in der die App gebaut und geändert wird. Mit Use a folder gibst du ihm dein eigenes Material, statt es raten zu lassen.
• Publish needs credits, oben: Bauen und Vorschau laufen auf deinem Rechner; erst das Hosting verbraucht Workspace-Credits.

In einer Room ist es dieselbe Idee in anderer Anordnung: oben eine Tableiste mit Apps, in der Mitte die ausgewählte App und rechts ein Panel mit zwei Tabs, Maestro und Details.

Anwendungsfall 1: Ein Release-Team hat seine Checkliste dort, wo die Arbeit ist

Wer: eine Release-Managerin und drei Teammitglieder, die einen Launch vorbereiten.

Die Lage: Cutover-Schritte, Runbook und Release-Tracker sind auf drei Tools verteilt, und am Release-Tag traut niemand der Tabelle.

Was sie in osFoundry tun:

1. Mit New Room eine Room namens "Launch Ops" anlegen und den Release-Tracker und die Launch-Dateien als Tabs hinzufügen.
2. Auf den +-Button in der Tableiste klicken. Die Auswahl New Tab listet installierte Apps und einen Katalog (Incident log, Retro board, On-call rota, Changelog builder), filterbar nach All, Forked oder Snippets.
3. In "Describe the app you want" stattdessen auf Build a snippet klicken und eine Cutover-Checkliste mit einer verantwortlichen Person pro Punkt anfordern. Ein Snippet ist eine lauffähige Mini-App aus ein paar Dateien. Es hat kein Repository, keine Version und kein Deploy und läuft direkt im Tab.
4. Weiter mit Maestro im rechten Panel sprechen, während die Checkliste offen ist, und im Tab Details nachsehen, was die Room ist und was darin passiert ist.

Ergebnis: eine Room, in der die Checkliste (in der Demo: Freeze the 2.4 branch, Run the order-index migration, Smoke-test the order desk, Post the release note) neben dem Runbook und dem Tracker liegt. Später listet die Ansicht Snippets alle Snippets aus allen Rooms. Von dort kann man eines mit Export als JSON in einen anderen Workspace mitnehmen oder es mit Promote in ein echtes Repository überführen, wenn es dem Tab entwachsen ist.

Anwendungsfall 2: Ein Entwickler gibt einem internen Tool ein echtes Backend

Wer: ein Solo-Entwickler, der ein Tool für Anmeldungen und Bestellungen für das Support-Team baut.

Die Lage: Die erste Version lief auf einem Laptop mit einer SQLite-Datei. Jetzt brauchen sie drei Teams, sie muss eine Payment-API aufrufen, und ein nächtlicher Clean-up soll laufen, ohne dass jemand daran denken muss, einen Knopf zu drücken.

Was er in osFoundry tut:

1. Solange die App noch lokal läuft, das Projekt in der IDE öffnen und auf den Tab Database klicken. Er findet die .db- und .sqlite-Dateien der App und öffnet eine Tabelle schreibgeschützt, 200 Zeilen pro Seite (Beispieldaten oben). So sieht man, was die App wirklich gespeichert hat, bevor irgendetwas umzieht.
2. Die App in eine geteilte Room verschieben. Der Dialog Move to cloud kopiert die App in eine Cloud-Room, damit alle darin sie nutzen können, und meldet, welche Tabellen kopiert wurden und welche auf dem Gerät geblieben sind. App und Daten bleiben auch auf diesem Gerät erhalten.
3. Die Tab-Einstellungen der App öffnen. Unter Secrets listet App Runtime Secrets die Schlüssel, die die App deklariert; Add a custom secret speichert einen neuen, Rotate ersetzt einen Wert. Die App zeigt danach "Secrets updated. Redeploy to apply changes."
4. Den Clean-up unter container.cron im App-Manifest deklarieren, dann Scheduled jobs öffnen und auf Sync from manifest klicken. Jeder Job lässt sich pausieren, fortsetzen oder mit Run now einmalig starten.

Ergebnis: eine App mit eigener Postgres-Datenbank. In osFoundry bekommt jede Room App eine, mit installiertem pgvector und TimescaleDB, und der Connection-String kommt zur Laufzeit als Secret an (Postgres pro App). Der Datenbank-Browser hat einen Zeileneditor mit Filtern und eine SQL-Ansicht nur für SELECT, und Database snapshots bietet New snapshot, Restore und einen Download-Link. Codeänderungen passieren in App Code. Dort kann der Entwickler an einer Version wie version/2.4 arbeiten, ohne main anzufassen, das Manifest prüfen (Entry Point, Sichtbarkeit, benötigte Connectors) und vor dem Release den Versions-Baum verfolgen.

Anwendungsfall 3: Eine Ladenbesitzerin veröffentlicht eine Seite und behält sie im Blick

Wer: jemand, der eine kleine Bäckerei führt und nicht programmiert.

Die Lage: Sie möchte eine einfache Website mit Angebot und Öffnungszeiten unter ihrer eigenen Adresse und wissen, was es kostet, sie online zu halten.

Was sie in osFoundry tut:

1. Websites öffnen, auf New Website klicken, die Bäckerei beschreiben und Build my site drücken. Die erste Version (oben, Beispiel) verwendet Platzhaltertexte, und Maestro sagt das auch klar.
2. Auf Use a folder klicken, den Ordner mit dem echten Angebot und den Fotos auswählen und Änderungen in normalen Worten anfordern, etwa "Make the headline bigger."
3. Wenn alles passt, veröffentlichen. Das Hosting verbraucht Workspace-Credits. Who can open it bietet Workspace members only, Anyone with the link oder den eigenen Login der App; eine öffentliche Bäckerei-Website nutzt Anyone with the link.
4. In Domains eine Domain registrieren oder eine vorhandene hinzufügen und dann ihre DNS-Einträge bearbeiten. Events zeigt, wer welchen Eintrag geändert hat, und unter Settings finden sich Verlängerung, Privatsphäre und der Transfer-Code.

Ergebnis: eine Website mit ihren eigenen Texten und Fotos, ausgeliefert unter ihrer eigenen Domain. Deployed Apps beantwortet danach die Fragen, die sich eine Inhaberin tatsächlich stellt. Apps zeigt jede App und wo sie ausgeliefert wird, Activity zeigt, was sich geändert hat, Usage zeigt die Build- und Speicherkosten pro App, und Previews listet alle Vorschauversionen, die noch laufen.

Wo es an den Rest von osFoundry übergibt

Custom App arbeitet selten allein. Maestro ist der Assistent im rechten Panel jeder Room und in den Build-Ansichten; er schreibt und bearbeitet den Code mit dir. Die IDE liefert den Database-Tab, die Versionskontrolle und den Editor für Apps, die als Ordner auf deinem Rechner beginnen. Websites ist der schnellere Weg, wenn die "App" eigentlich eine öffentliche Website ist. Snippets sind nur über Promote mit App Code verbunden, sodass aus einem Wegwerf-Tool ein gepflegtes Repository werden kann, ohne es neu zu schreiben. Geplante Aufgaben innerhalb einer App übernehmen App-Cron-Jobs, beschrieben auf der Plattformseite zu App Cron.

Fragen, die Neue stellen

Ist eine Room ein Chatraum?
Nein. Der Kern einer Room sind ihre App-Tabs. Der Maestro-Chat sitzt im Begleitpanel rechts, neben den Details der Room.

Wann baue ich ein Snippet statt einer App?
Wenn das Tool aus ein paar Dateien besteht und nur in einer Room laufen muss, etwa ein Datumsformatierer oder ein Webhook-Check. Ein Snippet zu speichern installiert nichts und deployt nichts. Braucht es später Versionen, Secrets oder eine Datenbank, mach es mit Promote zu einem Repository.

Können sich zwei Apps eine Datenbank teilen?
Jede App hat ihr eigenes Postgres. Geteilt wird über explizite Freigaben: Der Database-Tab der Room zeigt Incoming Requests, Active Grants und Outgoing Access, und jede Anfrage kann genehmigt oder abgelehnt werden.

Kostet das Ausprobieren etwas?
Bauen und Vorschau auf deinem Rechner brauchen keine Credits. Veröffentlichen, Deployen und Domains registrieren verbrauchen Workspace-Credits. Die Desktop-App gibt es unter osfoundry.io/de/download.