The backend for apps your agent builds
Postgres, team sign-in, API keys for agents, scheduled jobs, file storage, and hosting, declared in one config file your agent writes. Sign-in runs at floo's gateway, so there are no row-level security policies for your agent to get wrong.
What you get
- Postgres
Managed Postgres per environment. floo injects DATABASE_URL into your service, and the migrate_command you set runs on every deploy before traffic moves.
- Sign-in for your team
access_mode = "accounts" puts hosted, invite-only sign-in in front of the app. Your code reads the signed-in person from request headers.
- API keys for agents
Declare which routes take machine access, then give each agent its own scoped key. Revoking one key touches nothing else.
- Scheduled jobs
A [cron.<name>] block runs a command on a schedule inside your app's image, with the same database and environment variables.
- File storage and Redis
Declare S3-compatible storage or Redis next to Postgres. Credentials arrive as environment variables; nothing to provision by hand.
- Hosting and environments
Any app with a Dockerfile. Every push deploys to dev, a GitHub release deploys to prod, and you can roll back a deploy.
No row-level security to get wrong
Backends that let the browser query the database directly depend on a correct row-level security policy on every table. When an agent adds a table with RLS switched off, or writes a policy that lets everyone through, the data is open to anyone with the public key.
On floo the browser never talks to the database. Every request passes floo's gateway, which signs people in and tells your code who they are. Your server code queries Postgres with credentials only it holds, so permissions live in ordinary code your agent can read, test and review.
One file in the repo
Your agent writes floo.app.toml next to the code. This one gives the app sign-in, Postgres, file storage and a nightly job.
[app] name = "orders" access_mode = "accounts" [services.web] type = "web" path = "." port = 3000 migrate_command = "npm run migrate" [managed.default] type = "postgres" [managed.files] type = "storage" [cron.nightly-report] schedule = "0 6 * * *" command = "node scripts/report.js" service = "web"
Start from a working app
- Approval queue
Team members submit requests; admins approve or reject them with a comment.
- Team CRM
Companies, contacts, a deal pipeline, and an activity log your agents can write to.
- Inventory tracker
Items, stock movements, low-stock highlighting, and a daily low-stock check.
- KPI dashboard
Metric cards with targets and trends, fed by the numbers your agents push.
- Feedback board
Customer feedback and feature requests, ranked by team votes, with duplicate merging.
Questions
- What backend should I use for an app my AI agent built?
- One that gives the app a database, sign-in, scheduled jobs and storage without your agent writing auth code or database security policies. floo provides Postgres, team sign-in, cron jobs, storage, agent API keys and hosting from one config file in the repo.
- Do I need row-level security on floo?
- No. Backends that let the browser query the database rely on row-level security policies on every table. On floo the browser never reaches the database: requests pass floo's gateway, which signs people in, and your server code queries Postgres with credentials only it holds.
- Is floo a backend-as-a-service?
- It is the backend and the host together. floo runs your app's own server code, so the backend is code your agent writes in your repository, with Postgres, sign-in, cron and storage supplied by floo.
- Which stacks and agents work?
- Any app with a Dockerfile, with guides for Next.js, Rails, Django, FastAPI and Express. Claude Code, Codex, Cursor and any agent that can run a CLI or make HTTP requests can set it up.
- What does it cost?
- Pay as you go has no monthly commitment: you buy credits and usage draws them down. Sign-in for people and agents is included. Plan details are on the pricing page.