Flootdocs

Get Started

A comprehensive guide to installing and configuring your Floot application.

Prerequisites

In order to start using Floot starter kit, here are the required tools to have installed on your machine. Once the Floot CLI is installed you can run floot requirements check to verify all of them at once, and floot requirements install to install whatever is missing.

  • Git
  • Flutter (3.47.2)
    • The tested version, pinned in .fvmrc.

    fvm

    is the only way to install exactly this version.

  • Docker
    • The daemon must be running. OrbStack, Colima, Podman and Rancher also work.
  • Supabase CLI (2.116.0 or higher)
    • Earlier versions fail the initial migration by design.
  • Deno (2.0.0 or higher)
    • Type-checks and tests the Edge Functions.
  • jq
    • Required by the coding-agent hooks shipped with your project.
  • Stripe CLI
    • Required only if you plan to use Stripe for payments and need to test payments locally.

Install the Floot CLI

Floot CLI is the command-line tool that creates and manages Floot projects. Install it from the CLI tab, then verify it with floot --help.

Create your project

Terminal
floot create my_app --org com.acme --web-domain app.myapp.com

--org is worth setting: it becomes the Android package name, the iOS bundle identifier prefix and the deep-link scheme, and changing it afterwards means editing several platform files by hand. Left out, it defaults to com.example.

--web-domain is the bare host your web app will be served from: no scheme, path or port. Stripe's returns and invitations are links on it, and the installed app opens them (see Verified links). Left out, it defaults to the placeholder app.example.com, so you can create the project before you own a domain: links then open the web app until you set yours.

What it asks you

floot create composes your project from layers, and asks three questions to decide which ones to include:

Enable multi-tenancy (organizations & member roles)?

Adds organizations, invitations, member roles and ownership transfer. Answer no and your app is single-user: accounts own their own subscriptions.

Enable seat-based billing (per-member paid seats)?

Bills a subscription per organization member instead of per account. Only asked if you enabled multi-tenancy, because it builds on it.

Which coding-agent harnesses should be included?

A multi-select over Claude Code, Codex, Copilot and a generic harness, with Claude Code preselected. Each adds the configuration, agents and hooks its tool reads, on top of the shared instruction files the harnesses have in common. Space toggles, Enter confirms.

Every question has a flag, so the whole thing can be answered up front, which is also how you script it in CI, where there is no terminal to prompt on. See the full flag reference for the complete list and how they combine.

Every feature flag starts off

Layers decide what code exists; ENABLE_* environment variables decide what runs. A new project ships every one of them false, so it boots with email/password auth and nothing else no matter which layers you picked. Each feature page tells you which flag to flip, and in which file: .env.local for the app, supabase/.env.local for the Edge Functions, and for four of them, both.

These choices are made once, at creation. There is no supported way to add a layer to an existing project afterwards, so if you are unsure, generate a throwaway project with the layer enabled and look at what it adds.

Run it

Navigate to the project directory.

Terminal
cd my_app

Open a new terminal window and start the Supabase local instance.

Before you proceed

Ensure Docker is running in the background before starting Supabase. Note: initial startup may take several minutes while it pulls images.

New Terminal
cd supabase
supabase start

Once it finishes it prints your local URLs and keys. The API is on 54321, Postgres on 54322, Studio on 54323, and the Mailpit inbox that catches every email your project sends on 54324.

Serve the Edge Functions, still from supabase/.

New Terminal
supabase functions serve --env-file .env.local --import-map ./functions/deno.json --no-verify-jwt

Leave this running: sign-up confirmation, password reset and every other transactional email is sent by an Edge Function. Without it, Auth answers Unexpected status code returned from hook: 500 and the login page shows a generic "Please try again" error; see Every auth email fails to send.

In your original terminal window, run the Flutter app.

Terminal
flutter run

Building for release

Debug and profile builds read .env.local, which floot create writes for you. Release builds read .env, which it does not: every .env* file is git-ignored, and shipping a prefilled one would mean baking local development secrets into a store binary.

So the first time you build for release, do this once:

Copy .env.local to .env and replace the local values with your production ones:

  • SUPABASE_URL and SUPABASE_PUBLISHABLE_KEY: on Supabase Cloud, https://<ref>.supabase.co and the project's sb_publishable_… key; self-hosted, your API host, such as https://api.myapp.com, and SUPABASE_PUBLISHABLE_KEY from the stack's .env.
  • WEB_APP_URL: your web app's origin.
  • The production values of every other key the features you ship read, such as your OAuth client ids.

Keep OAUTH_REDIRECT_URL as it is. The release .env lists every key.

Add .env to the bundled assets. An asset that is not listed here is not included in the build, and the app will throw on startup.

pubspec.yaml
flutter:
  assets:
    - .env
    - .env.local
    - assets/app/
    - assets/icons/
    - assets/legal/

.env is git-ignored, so a pipeline writes it from its secret store. It is still public: every build bundles it, and a web build serves it at /assets/.env, with .env.local beside it. Put in either only values you would publish, never the secret key, a webhook secret or SMTP credentials; see The app's .env is public.

What's next?

On this page