Quick start

Run npx @floomhq/cli@latest setup once per machine. It opens a browser page to link your Floom account. The token is saved to ~/.floom/config.json.

In CI, set the FLOOM_API_KEY env var instead; no setup command needed.

floom init generates three files in the current directory:

• floom.yaml: the app manifest
• app.py: a minimal Python app
• requirements.txt: empty, ready to fill

floom deploy bundles the current directory into a .tar.gz, uploads it, and registers the app under your account. The slug from floom.yaml becomes the app ID.

After deploy, the app is live at https://floom.dev/p/your-slug with a browser UI, REST endpoint, and MCP tool. No extra config.

Use the CLI or the browser UI. The CLI returns JSON:

# 1. Authenticate (once per machine)
npx @floomhq/cli@latest setup

# 2. Scaffold a new app
mkdir my-floom-app && cd my-floom-app
npx @floomhq/cli@latest init --name "My App" --slug my-app --type custom

# 3. Deploy
npx @floomhq/cli@latest deploy

# 4. Run it
npx @floomhq/cli@latest run my-app '{"text":"hello"}' --json

A Floom app is a directory with a floom.yaml at the root. The manifest declares the slug, the run command, optional input/output schemas, and any secret names the app needs.

When you deploy, Floom bundles the directory, stores it, and registers the metadata. When someone runs the app, Floom spins up a stock E2B sandbox, extracts the bundle, installs declared dependencies, and executes the command.

• Each run is isolated: a fresh sandbox, no state from previous runs.
• Inputs arrive via stdin and the FLOOM_INPUTS env var as JSON.
• Output is whatever the command prints to stdout, optionally validated against a schema.
• Python and Node.js both work. Python is the primary target.

Floom is a thin wrapper. It does not rewrite your code or proxy HTTP traffic. The E2B sandbox is the execution environment; see e2b.dev/docs for available system packages and preinstalled tools.