Database

When your app needs user accounts, private data per user or files uploaded by its users, it needs a backend. Highwind creates it for you in one click: no account to open elsewhere, nothing to configure. The agent then creates the tables, sign-up and sign-in.

What the backend includes

A database

Tables for your app’s data (tasks, bookings, catalog…), protected by access rules.

User accounts

Sign-up and sign-in with email and password, ready to use.

File storage

Profile pictures, documents, attachments: each user has their own folder.

Each app gets its own Supabase project, created in Highwind’s organization and hosted in Europe (Paris). Your database isn’t shared with any other app, and you don’t need a Supabase account.

Enabling the backend

The backend is never enabled without you. There are two ways to enable it:

1. From the choice card. When your request involves accounts or shared data, the agent shows you a Your call card. Click Database: the database is created (“Creating the database… (under a minute)”), then the agent carries on with what was planned by itself. See Where data goes.

2. From the project settings. Open Project settings → Backend and click Enable backend. The database is ready in under a minute; you can leave the page while it’s being created. Then ask the agent for what you want to build.

The Backend section then shows the Status, the API URL and the Region.

During the beta

The number of backends per account is limited. The Backend section shows how many you use; if you’ve reached the limit, delete another project’s backend to enable one here.

Add sign-up and sign-in: each user finds their own recipes, and can add, edit
and delete them.

The database

The agent first reads your database’s structure, then changes it through migrations: small SQL scripts applied one by one (the “Database: create recipes” step in the thread). Each migration is also saved in your project, in supabase/migrations/, and is part of the downloaded code.

• Small, additive migrations: the agent adds tables and columns. Destructive operations (dropping or renaming a table or a column, erasing data) are refused, to protect your data.
• Careful states: every screen that reads the database shows a loading state, an empty state and an error message.
• No key in the code: the app connects with the client prepared by Highwind (src/lib/supabase.ts) and its public key. The agent never uses the database’s admin key.

Access rules are mandatory

Your database’s public key is visible in the app’s code: what protects the data is the access rules (row level security, or RLS). The agent enables them on every table, in the same migration that creates it:

• a row that belongs to a user carries their identifier, filled in automatically, and only that user can read, create, edit or delete it;
• data is only visible to signed-out visitors if it’s meant to be public, and read-only.

Check before publishing

Before each publish, Highwind scans your database’s security. A critical issue (a table anyone can read or change) blocks publishing; a less serious point is flagged without blocking. The Publish menu lists the issues, with a Fix with the agent button. See Publishing your app.

User accounts

The agent builds sign-up, sign-in and sign-out with email and password, shared across the whole app, with protected pages reserved for signed-in users.

• Passwords of at least 8 characters: the form checks it, and, where possible, passwords known to have leaked are refused.
• Signed in right after sign-up: users don’t have to wait for a confirmation email.
• No emails sent: no confirmation, no magic sign-in link, no password reset for now. Signing in with Google or other accounts isn’t available either.

Tip

Since there’s no forgotten-password flow yet, let your users know, or provide a way to reach you (a contact form, for example) in the meantime.

File storage

For files uploaded by users, the agent creates a storage space (a “bucket”) in a migration, with rules that keep each user in their own folder: nobody can read or replace someone else’s files.

Let each user add a photo to their recipes, visible only to them.

Good to know

• The preview and the published app use the same database. Accounts and data created while you test in the preview show up in the live app, and a new table created by the agent exists right away for both. See Updating a published app.
• Restoring a version doesn’t touch the database: the code goes back, the tables and data stay as they are.
• An unpublished app loses its database after a period without activity (24 h by default, shown in Project settings → Backend), with a message in the chat. If you enable the backend again, the tables are recreated, but not the data. A published app keeps its database.
• Deleting the backend: Project settings → Danger zone → Delete backend. Tables, the app’s user accounts and its files are permanently deleted; the app’s code doesn’t change. Deleting the project also deletes its backend.

Danger

Deleting the backend, or its automatic deletion on an unpublished app, erases all your users’ data. Publish your app if it has real users.

Not available yet

Coming soon

These features aren’t available yet:

• emails for apps with accounts: sign-up confirmation and forgotten password;
• magic sign-in links and signing in with Google or other accounts;
• a panel to browse the app’s tables and users from the editor;
• approving a destructive migration yourself (today it’s simply refused);
• scheduled tasks and export to your own Supabase account.

See also

Where data goesWhen a database is needed, and when it isn't.

Publishing your appThe security check before going live.

Project settingsEnable, monitor and delete the backend.

SecurityHow Highwind protects your apps and their data.