# Fenaura

> Fenaura is a backend platform: edge functions that run in V8 isolates,
> a Postgres database per project, end-user authentication with twelve OAuth
> providers, and file storage. Edge routes are private by default, so every
> request is checked for a signed-in end user before application code runs.

Every page below is available as HTML at the URL given, and the complete
text of all pages is in https://docs.fenaura.dev/llms-full.txt.

## Getting started

- [Introduction](https://docs.fenaura.dev/): Fenaura is a backend you talk to. Edge functions, a Postgres database, end-user authentication and file storage, all wired together in one project.
- [Quickstart](https://docs.fenaura.dev/quickstart): Create a Fenaura project, install the SDK, and run your first authenticated database query in about ten minutes.
- [How Fenaura works](https://docs.fenaura.dev/how-it-works): The four pieces of a Fenaura project — edge functions, database, auth and storage — and how a request travels through them.
- [Coming from Supabase](https://docs.fenaura.dev/coming-from-supabase): A mapping table from Supabase concepts and calls to their Fenaura equivalents, and the three things that behave differently.

## Veilo

- [Veilo](https://docs.fenaura.dev/veilo): Veilo is Fenaura's built-in AI engineer. It reads your project, writes and deploys edge functions, edits the schema, runs the API tester, and verifies its own work.
- [Using Veilo](https://docs.fenaura.dev/veilo/using): How to ask Veilo for work so it gets done in one pass — clear outcomes, real constraints, and what to do when it gets something wrong.
- [Approvals](https://docs.fenaura.dev/veilo/approvals): Which Veilo actions stop for approval, why the line is drawn there, and what an approval card means.
- [The API tester](https://docs.fenaura.dev/kora): Kora is the built-in HTTP client — collections, folders, environments, request editing with section diffs, and a workspace Veilo can drive for you.
- [The Edge IDE](https://docs.fenaura.dev/ide): A file tree, editor, terminal, source control, problems panel and version timeline for your edge function — in the browser, with no local setup.

## Fleets

- [Fleets](https://docs.fenaura.dev/fleets): Fleets are Fenaura's edge functions — the server code for your project. One URL runs everything, and the development and production environments share that code with different data.
- [Routing](https://docs.fenaura.dev/fleets/routing): Route however you like — plain if statements, controllers in folders, or Hono. If you have written Express, a Fleet will feel familiar.
- [The context object](https://docs.fenaura.dev/fleets/context): Everything a Fleet handler receives — the project, the signed-in user, environment variables, Drizzle, raw SQL and Redis — plus the full request and response syntax.
- [Environments](https://docs.fenaura.dev/fleets/environments): Development and production run the same code against different data. Default URLs, the private dev key, and what happens to a development URL after you deploy.
- [The database](https://docs.fenaura.dev/fleets/database): Every Fleet gets a Postgres database, a Drizzle client and a raw SQL escape hatch, isolated per environment and available with no connection string.
- [The IDE](https://docs.fenaura.dev/fleets/ide): The editor around a Fleet — files and folders, a command terminal, compile checks, source control, versions and trash — all in the browser.
- [Testing](https://docs.fenaura.dev/fleets/testing): Call your Fleet while building — the private dev key, curl and fetch, and how Kora and Veilo remove the need for a separate testing tool.

## Authentication

- [Authentication overview](https://docs.fenaura.dev/auth): End users belong to your project. The SDK signs them in, a proxy keeps credentials off the client, and every edge request is checked before your code runs.
- [Methods](https://docs.fenaura.dev/auth/methods): Every authentication call in @fenaura/sdk — password, OAuth, verification codes, magic links, resets and state changes — with options and return shapes.
- [OAuth providers](https://docs.fenaura.dev/auth/oauth): The twelve OAuth providers Fenaura supports, how the callback exchange works, and the setup each provider needs.
- [Sessions and cookies](https://docs.fenaura.dev/auth/sessions): How Fenaura stores a session, the three ways a request can carry it, and why conflicting cookies fail closed.
- [End-user management](https://docs.fenaura.dev/auth/end-users): List, inspect, revoke, block, restore and delete the end users of a project from the dashboard.
- [Troubleshooting authentication](https://docs.fenaura.dev/auth/troubleshooting): What each authentication error means and the fix for it — session conflicts, unverified users, OAuth callbacks and proxy mistakes.

## Database

- [Database overview](https://docs.fenaura.dev/database): Every Fenaura project gets its own whole Postgres database, not a schema in a shared one. Reach it from the browser with the SDK, or from a Fleet with ctx.db and ctx.sql.
- [Querying](https://docs.fenaura.dev/database/querying): The Fenaura query builder — select, insert, update, delete, upsert, counting and pagination — and when a chain runs.
- [Filtering](https://docs.fenaura.dev/database/filtering): Every filter operator in the Fenaura query builder, with a runnable example each, plus combining, negating and searching text.
- [Drizzle in the edge](https://docs.fenaura.dev/database/drizzle): Inside an edge function the database is available as ctx.db (Drizzle) and ctx.sql (raw), already connected and already scoped to the project.
- [Migrations](https://docs.fenaura.dev/database/migrations): How schema changes reach a Fenaura project without losing data, and the order to apply them in.
- [Security and RLS](https://docs.fenaura.dev/database/security): Row-level security, sensitive columns, and the rule that a client-side filter is a convenience, never a defence.

## Edge functions

- [Edge functions](https://docs.fenaura.dev/edge): JavaScript that runs in a V8 isolate, private by default. Every route checks for a signed-in end user before your code runs.
- [Your first function](https://docs.fenaura.dev/edge/first-function): Write, deploy and call an edge function that reads from the database as the signed-in user.
- [The context object](https://docs.fenaura.dev/edge/context): Every field on FenauraContext — the project, the signed-in user, environment variables, the database, raw SQL and Redis.
- [Routing](https://docs.fenaura.dev/edge/routing): How paths reach a handler, how method matching works, and how to split a growing function across files.
- [Environments](https://docs.fenaura.dev/edge/environments): Development and production are separate deployments with separate data, keys and URLs. How to promote code without mixing data.
- [Public routes](https://docs.fenaura.dev/edge/public-routes): How to serve unauthenticated traffic deliberately, and the three consequences of doing it.
- [Rate limits](https://docs.fenaura.dev/edge/rate-limits): The exact request limits applied to edge functions, per project, per end user and per environment, with the error you get when you cross them.
- [Errors](https://docs.fenaura.dev/edge/errors): Every error code the edge runtime returns, what causes it, and the fix — throttling, session conflicts, missing functions and isolate failures.

## Storage

- [Storage](https://docs.fenaura.dev/storage): Buckets, chunked uploads with progress and retry, compression on the way in, and three ways to read a file back.
- [Uploading](https://docs.fenaura.dev/storage/uploading): How chunked uploads, per-chunk retry, progress events and compression work, and how to handle a failure without losing the file.
- [Access control](https://docs.fenaura.dev/storage/access): Session-gated, public and signed URLs — what each one actually proves, and how to pick the right one.
- [Managing files](https://docs.fenaura.dev/storage/managing): Listing with prefixes, paginating a large bucket, downloading and deleting files, and keeping paths organised.

## Email

- [Email](https://docs.fenaura.dev/email): Transactional and broadcast email from a Fenaura project — templates, sending, and the deliverability setup that makes messages arrive.
- [Templates](https://docs.fenaura.dev/email/templates): The email templates a project ships with, the variables each one can use, and how to edit one without breaking the flow it belongs to.
- [Deliverability](https://docs.fenaura.dev/email/deliverability): SPF, DKIM and DMARC explained as what they actually do, plus the sending habits that decide whether your mail reaches an inbox.

## SDK reference

- [Installation](https://docs.fenaura.dev/sdk): Install @fenaura/sdk, create a client with your publishable key, and understand what the key does and does not grant.
- [createClient](https://docs.fenaura.dev/sdk/create-client): Every option createClient accepts — apiUrl, apiKey, auth overrides and headers — with the defaults.

## Platform

- [Projects and organisations](https://docs.fenaura.dev/platform/projects): How tenants, projects and environments are arranged, and which one you create when.
- [API keys](https://docs.fenaura.dev/platform/keys): The publishable key, the secret key, the edge token and the dev key — what each one grants, where each may live, and how to rotate one.
- [Quotas](https://docs.fenaura.dev/platform/quotas): What is measured, what happens when a limit is reached, and why resetting a counter does not give you more of anything.

## Guides

- [Build a waitlist](https://docs.fenaura.dev/guides/waitlist): A waitlist with duplicate protection, a position number and an authenticated admin view — built with a public route, one table and the SDK.
- [Build an auth-gated API](https://docs.fenaura.dev/guides/auth-gated-api): An API where every endpoint requires a session and every query is scoped to the caller, using RLS plus the default private routing.
- [Build a file uploader](https://docs.fenaura.dev/guides/file-uploader): An avatar uploader with progress, compression, ownership rules and a signed URL for sharing — end to end.
- [Ship a paid API](https://docs.fenaura.dev/guides/paid-api): An API where customers authenticate with their own keys, usage is metered, and billing follows — built with one public route and Redis counters.