Building and hosting small internal apps with osFoundry Custom App

It is Thursday, two hours before a release, and Dari is the only person who knows which steps of the cutover are done. The checklist lives in a spreadsheet tab, the runbook in a shared drive, and the discussion in a chat thread nobody can find. What the team actually needs is a tiny app with four checkboxes and two owners, sitting right next to the files. Writing one is easy. Hosting it, giving it a database, keeping its keys safe and getting it a URL is the part that usually stalls.

What the Custom App category is

osFoundry groups everything for building and running your own small apps under one category in the desktop app's sidebar, called CUSTOM APP. It has five screens. Room is the shared space where apps live as tabs. App Code is the repository behind an app. Deployed Apps is a workspace-wide list of what is live. Snippets collects the tiny apps that never needed a repository. Domains manages the web addresses those apps are served from. If you know Notion, picture a page whose tabs are working apps instead of documents, with a small Vercel-style hosting layer underneath: each app gets its own database, secrets, scheduled jobs and a subdomain, as described on the internal apps feature page.

A look at the build screen

The fastest way to see how an app starts is the build view in the desktop app. This capture is from the Websites builder (example project "Hearth Bakery"), which uses the same describe-then-build loop that a Room offers with its "Describe the app you want" box.

• Pages, on the left: the parts of the app that already exist, with Add page at the bottom.
• The preview, in the middle: what you are building, with desktop, tablet and phone sizes above it. The label "On this computer" tells you nothing has been published yet.
• The describe box: you write what the app does, who it is for and how it should feel, then press Build my site. Maestro, the app's AI assistant, writes the files.
• The Maestro panel, on the right: the conversation that builds and changes the app. Use a folder points it at your own material instead of letting it guess.
• Publish needs credits, at the top: building and previewing happen on your computer; hosting is the step that uses workspace credits.

Inside a Room the layout is the same idea in a different arrangement: a tab strip of apps across the top, the selected app in the middle, and a right panel with two tabs, Maestro and Details.

Use case 1: a release team keeps its checklist where the work is

Who: a release manager and three teammates preparing a launch.

The situation: the cutover steps, the runbook and the release tracker are spread over three tools, and nobody trusts the spreadsheet on release day.

What they do in osFoundry:

1. Create a room called "Launch Ops" with New Room, and add the release tracker and the launch files as tabs.
2. Press the + button on the tab strip. The New Tab picker lists installed apps and a catalogue (Incident log, Retro board, On-call rota, Changelog builder), filtered by All, Forked or Snippets.
3. In "Describe the app you want", click Build a snippet instead and ask for a cutover checklist with an owner per item. A snippet is a runnable mini-app made of a few files. It has no repository, no version and no deploy, and it runs right there in the tab.
4. Keep talking to Maestro in the right panel while the checklist is open, and use the Details tab to see what the room is and what has happened in it.

What they end up with: one room where the checklist (in the demo: Freeze the 2.4 branch, Run the order-index migration, Smoke-test the order desk, Post the release note) sits next to the runbook and the tracker. Later, the Snippets screen lists every snippet across rooms. From there someone can Export one as JSON for another workspace, or Promote it into a real repository when it outgrows the tab.

Use case 2: a developer gives an internal tool a real backend

Who: a solo developer building a sign-up and orders tool for the support team.

The situation: the first version ran on a laptop with a SQLite file. Now three teams need it, it has to call a payment API, and a nightly clean-up must run without anyone remembering to press a button.

What they do in osFoundry:

1. While the app still runs locally, open the project in the IDE and click the Database tab. It finds the app's .db and .sqlite files and opens a table read-only, 200 rows a page (example data above), so you can see what the app really saved before anything moves.
2. Move the app into a shared room. The Move to cloud dialog copies the app into a Cloud room so everyone in it can use it, and reports which tables were copied and which stayed on the device. The app and its data stay on this device too.
3. Open the app's tab settings. Under Secrets, App Runtime Secrets lists the keys the app declares; Add a custom secret stores a new one, and Rotate replaces a value. The app then shows "Secrets updated. Redeploy to apply changes."
4. Declare the clean-up under container.cron in the app manifest, then open Scheduled jobs and click Sync from manifest. Each job can be paused, resumed or started once with Run now.

What they end up with: an app with its own Postgres database. On osFoundry every Room App gets one, with pgvector and TimescaleDB installed, and the connection string arrives as a secret at runtime (per-app Postgres). The database browser has a row editor with filters and a SELECT-only SQL view, and Database snapshots offers New snapshot, Restore and a download link. Code changes happen in App Code, where the developer can work on a version such as version/2.4 without touching main, check the Manifest (entry point, visibility, required connectors) and follow the Versions tree before releasing.

Use case 3: a shop owner publishes a page and keeps an eye on it

Who: someone who runs a small bakery and does not write code.

The situation: they want a simple site with a menu and opening hours, on their own address, and they want to know what it costs to keep online.

What they do in osFoundry:

1. Open Websites, press New Website, describe the bakery and press Build my site. The first version (above, example) uses placeholder words, and Maestro says so plainly.
2. Press Use a folder and pick the folder with the real menu and photos, then ask for changes in plain words, such as "Make the headline bigger."
3. When it looks right, publish. Hosting uses workspace credits. Who can open it offers Workspace members only, Anyone with the link, or the app's own sign-in; a public bakery site uses Anyone with the link.
4. In Domains, register a domain or add one they already own, then edit its DNS records. Events shows who changed which record, and Settings holds renewal, privacy and the transfer code.

What they end up with: a site that uses their words and photos, served on their own domain. Deployed Apps then answers the questions an owner actually asks. Apps shows every app and where it is served, Activity shows what changed, Usage shows build and storage cost per app, and Previews lists any preview versions still running.

Where it hands off in the rest of osFoundry

Custom App rarely works alone. Maestro is the assistant in every Room's right panel and in the build views; it writes and edits the code with you. The IDE gives you the Database tab, source control and the editor for apps that start as a folder on your computer. Websites is a quicker path when the "app" is really a public site. Snippets connect to App Code only through Promote, so a throwaway tool can become a maintained repository without being rewritten. Scheduled work inside an app is covered by app cron jobs, described on the app cron platform page.

Questions newcomers ask

Is a Room a chat room?
No. A Room's core is its app tabs. Maestro chat sits in the companion panel on the right, next to the room's Details.

When should I build a snippet instead of an app?
When the tool is a few files and only needs to run inside one room, such as a date formatter or a webhook check. Saving a snippet installs nothing and deploys nothing. If it later needs versions, secrets or a database, Promote it to a repository.

Can two apps share one database?
Each app has its own Postgres. Sharing goes through explicit grants: the room's Database tab shows Incoming Requests, Active Grants and Outgoing Access, and each request can be approved or denied.

Does it cost anything to try?
Building and previewing on your computer does not need credits. Publishing, deploying and registering domains use workspace credits. You can download the desktop app at osfoundry.io/download.