Ship your App

Create and test an App locally, build its Release, and install it on an Oyster you own. Find the separate hosted Team publishing path.

Start with a small App that people can open and agents can call. This guide takes you from the published starter to a built Release and an existing Oyster.

Create and try it

In a directory where you want the project to live, run:

npm create fungi-app@latest my-app
cd my-app
npm run dev

Open the printed local URL and click Say hello. The page calls the App’s typed greet backend method. Edit the files in src/, save, and check the reloaded page. Stop the development command with Ctrl-C when you are done.

The starter runs its own local Oyster. It has no Computer attached and does not emulate Team sign-in, grants or funded model services. Its local requests run as the owner. Prove access to files, models and other resources on the host where you intend to use those capabilities.

See the starter quickstart for its files and development commands, or Make your own App to begin with the Hello App from the Oyster trial instead.

Build a Release

From my-app, run:

npm run build

The output is dist/release.json and dist/artifacts/. Keep them together. The build captures your saved files, including uncommitted edits, in an isolated Git snapshot. It does not create a commit in your working repository. The Release records that snapshot so you can identify what was built.

A successful build creates the files locally. Installation is the next step.

Install on your Oyster

Use the URL and owner key of an Oyster that is already running. Set OYSTER_URL and OYSTER_OWNER_KEY in your shell, then run from my-app:

npx @fungi.computer/oyster \
  install ./dist --installation-id my-app

The command uploads the artifacts and asks that Oyster to install the Release. It exits with an error if uploading or installation fails. It does not create or deploy a host; follow Oyster’s setup guide first if you need one.

Open the installed App on that Oyster and check the same greeting there. Review the access it requests before approving it. If you add a Computer or model capability, test both approval and refusal on the target host.

For the next version, edit, test, build and install again using the same installation ID. Keep the previous Release files if you need to reinstall a known version. Restoring an App version does not undo changes to its stored data.

Publish for a hosted Team

The hosted workflow has its own owner controls. Build an App and Publish an App walk through a Team’s source fork, build, candidate preview and explicit acceptance. They require an existing Team and a funded build Computer.

For repository-driven updates, the starter also supports Bonsai’s Make this an App flow. Registration reads the committed App metadata; it does not build or install immediately. Later accepted pushes to main can build on an attached hosted backend. New permissions require consent before replacing the previous Release. See the starter documentation for that path and its local-backend limit.

Installing an App for yourself or your Team does not list it for sale in Bazaar. Share the source repository when you want another builder to run their own copy.