🚀 Join the waitlist now! waitlist.floot.dev
LogoFlootdocs

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

--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.

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, so without it those flows fail silently.

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: your hosted Supabase URL and publishable key, your live OAuth client ids, and your production redirect URL.

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 holds production credentials and is git-ignored for that reason. Keep it out of version control and supply it from your CI secret store instead.

What's next?

On this page