Come creare e ospitare piccole app interne con Custom App di osFoundry

È giovedì, mancano due ore a un rilascio e Dari è l'unica persona che sa quali passaggi del cutover sono già stati fatti. La checklist sta in una scheda di un foglio di calcolo, il runbook in un drive condiviso e la discussione in un thread di chat che nessuno riesce a trovare. Quello che serve davvero al team è una piccola app con quattro caselle di spunta e due responsabili, proprio accanto ai file. Scriverla è facile. Ospitarla, darle un database, tenere al sicuro le sue chiavi e procurarle un URL è la parte dove di solito ci si blocca.

Cos'è la categoria Custom App

osFoundry raccoglie tutto ciò che serve per creare e far girare le tue piccole app in un'unica categoria nella barra laterale dell'app desktop, chiamata CUSTOM APP. Ha cinque schermate. Room è lo spazio condiviso in cui le app vivono come schede. App Code è il repository dietro un'app. Deployed Apps è l'elenco, a livello di tutto il workspace, di ciò che è online. Snippets raccoglie le mini-app che non hanno mai avuto bisogno di un repository. Domains gestisce gli indirizzi web da cui vengono servite queste app. Se conosci Notion, immagina una pagina le cui schede sono app funzionanti invece di documenti, con sotto un piccolo livello di hosting in stile Vercel: ogni app ha il suo database, i suoi secret, i suoi job pianificati e un sottodominio, come descritto nella pagina della funzionalità app interne.

Uno sguardo alla schermata di build

Il modo più rapido per vedere come nasce un'app è la vista di build dell'app desktop. Questa schermata viene dal builder di Websites (progetto di esempio "Hearth Bakery"), che usa lo stesso ciclo descrivi-e-costruisci offerto da una Room con il suo riquadro "Describe the app you want".

• Pages, a sinistra: le parti dell'app che esistono già, con Add page in fondo.
• L'anteprima, al centro: quello che stai costruendo, con le dimensioni desktop, tablet e telefono sopra. L'etichetta "On this computer" indica che non è stato ancora pubblicato nulla.
• Il riquadro di descrizione: scrivi cosa fa l'app, per chi è e che impressione deve dare, poi premi Build my site. Maestro, l'assistente IA dell'app, scrive i file.
• Il pannello di Maestro, a destra: la conversazione che costruisce e modifica l'app. Use a folder gli fa usare il tuo materiale invece di lasciarlo tirare a indovinare.
• Publish needs credits, in alto: build e anteprima avvengono sul tuo computer; l'hosting è il passaggio che consuma crediti del workspace.

Dentro una Room l'idea è la stessa, con una disposizione diversa: una barra di schede con le app in alto, l'app selezionata al centro e un pannello a destra con due schede, Maestro e Details.

Caso d'uso 1: un team di rilascio tiene la checklist dove si lavora

Chi: una release manager e tre colleghi che preparano un lancio.

La situazione: i passaggi del cutover, il runbook e il tracker del rilascio sono sparsi su tre strumenti, e il giorno del rilascio nessuno si fida del foglio di calcolo.

Cosa fanno in osFoundry:

1. Creano una room chiamata "Launch Ops" con New Room e aggiungono il tracker del rilascio e i file del lancio come schede.
2. Premono il pulsante + sulla barra delle schede. Il selettore New Tab elenca le app installate e un catalogo (Incident log, Retro board, On-call rota, Changelog builder), filtrabile per All, Forked o Snippets.
3. In "Describe the app you want" cliccano invece su Build a snippet e chiedono una checklist del cutover con un responsabile per ogni voce. Uno snippet è una mini-app eseguibile fatta di pochi file. Non ha repository, né versione, né deploy, e gira direttamente nella scheda.
4. Continuano a parlare con Maestro nel pannello di destra mentre la checklist è aperta, e usano la scheda Details per vedere cos'è la room e cosa vi è successo.

Cosa ottengono: un'unica room in cui la checklist (nella demo: Freeze the 2.4 branch, Run the order-index migration, Smoke-test the order desk, Post the release note) sta accanto al runbook e al tracker. In seguito, la schermata Snippets elenca tutti gli snippet di tutte le room. Da lì si può esportarne uno in JSON con Export per un altro workspace, oppure trasformarlo in un vero repository con Promote quando la scheda gli va stretta.

Caso d'uso 2: uno sviluppatore dà un vero backend a uno strumento interno

Chi: uno sviluppatore che lavora da solo e costruisce uno strumento di iscrizioni e ordini per il team di supporto.

La situazione: la prima versione girava su un portatile con un file SQLite. Ora servono a tre team, deve chiamare un'API di pagamento e una pulizia notturna deve partire senza che nessuno debba ricordarsi di premere un pulsante.

Cosa fa in osFoundry:

1. Finché l'app gira ancora in locale, apre il progetto nell'IDE e clicca sulla scheda Database. Trova i file .db e .sqlite dell'app e apre una tabella in sola lettura, 200 righe per pagina (dati di esempio qui sopra), così vedi cosa ha davvero salvato l'app prima di spostare qualsiasi cosa.
2. Sposta l'app in una room condivisa. La finestra Move to cloud copia l'app in una Cloud room perché tutti i membri possano usarla, e indica quali tabelle sono state copiate e quali sono rimaste sul dispositivo. L'app e i suoi dati restano anche su questo dispositivo.
3. Apre le impostazioni della scheda dell'app. In Secrets, App Runtime Secrets elenca le chiavi dichiarate dall'app; Add a custom secret ne salva una nuova e Rotate sostituisce un valore. L'app mostra poi "Secrets updated. Redeploy to apply changes."
4. Dichiara la pulizia in container.cron nel manifest dell'app, poi apre Scheduled jobs e clicca su Sync from manifest. Ogni job si può mettere in pausa, riprendere o avviare una volta con Run now.

Cosa ottiene: un'app con il suo database Postgres. Su osFoundry ogni Room App ne ha uno, con pgvector e TimescaleDB installati, e la stringa di connessione arriva come secret a runtime (Postgres per app). Il browser del database ha un editor di righe con filtri e una vista SQL solo SELECT, e Database snapshots offre New snapshot, Restore e un link per il download. Le modifiche al codice si fanno in App Code, dove lo sviluppatore può lavorare su una versione come version/2.4 senza toccare main, controllare il Manifest (entry point, visibilità, connettori richiesti) e seguire l'albero Versions prima del rilascio.

Caso d'uso 3: la titolare di un negozio pubblica una pagina e la tiene d'occhio

Chi: una persona che gestisce un piccolo panificio e non scrive codice.

La situazione: vuole un sito semplice con il menu e gli orari, sul proprio indirizzo, e vuole sapere quanto costa tenerlo online.

Cosa fa in osFoundry:

1. Apre Websites, preme New Website, descrive il panificio e preme Build my site. La prima versione (qui sopra, di esempio) usa testi segnaposto, e Maestro lo dice chiaramente.
2. Preme Use a folder, sceglie la cartella con il menu vero e le foto, poi chiede modifiche a parole semplici, come "Make the headline bigger."
3. Quando va bene, pubblica. L'hosting usa crediti del workspace. Who can open it offre Workspace members only, Anyone with the link oppure il login proprio dell'app; un sito pubblico di panificio usa Anyone with the link.
4. In Domains registra un dominio o ne aggiunge uno che possiede già, poi ne modifica i record DNS. Events mostra chi ha cambiato quale record, e Settings contiene rinnovo, privacy e codice di trasferimento.

Cosa ottiene: un sito con i suoi testi e le sue foto, servito sul suo dominio. Deployed Apps risponde poi alle domande che una titolare si fa davvero. Apps mostra ogni app e dove è servita, Activity mostra cosa è cambiato, Usage mostra il costo di build e storage per app, e Previews elenca le versioni di anteprima ancora attive.

Come si collega al resto di osFoundry

Custom App raramente lavora da sola. Maestro è l'assistente nel pannello di destra di ogni Room e nelle viste di build; scrive e modifica il codice insieme a te. L'IDE ti dà la scheda Database, il controllo di versione e l'editor per le app che nascono come cartella sul tuo computer. Websites è una strada più rapida quando l'"app" è in realtà un sito pubblico. Gli Snippets si collegano ad App Code solo tramite Promote, quindi uno strumento usa e getta può diventare un repository mantenuto senza essere riscritto. Il lavoro pianificato dentro un'app è coperto dai cron job delle app, descritti nella pagina della piattaforma su app cron.

Domande di chi inizia

Una Room è una chat room?
No. Il cuore di una Room sono le sue schede di app. La chat di Maestro sta nel pannello di supporto a destra, accanto ai Details della room.

Quando conviene creare uno snippet invece di un'app?
Quando lo strumento è fatto di pochi file e deve girare solo dentro una room, come un formattatore di date o un controllo di webhook. Salvare uno snippet non installa nulla e non fa nessun deploy. Se più avanti gli servono versioni, secret o un database, trasformalo in repository con Promote.

Due app possono condividere un database?
Ogni app ha il suo Postgres. La condivisione passa da autorizzazioni esplicite: la scheda Database della room mostra Incoming Requests, Active Grants e Outgoing Access, e ogni richiesta può essere approvata o rifiutata.

Provarlo costa qualcosa?
Build e anteprima sul tuo computer non richiedono crediti. Pubblicare, fare deploy e registrare domini usa crediti del workspace. Puoi scaricare l'app desktop su osfoundry.io/it/download.