A website backend on your own Supabase, wired in for you
What Laarpi sets up in your own Supabase project, how connecting works step by step, the access rules that protect each table, and what to do before real visitors sign in.
A site that looks extraordinary but cannot sign anyone in, or quietly loses every form submission, is a mood board. Laarpi builds the site and wires the backend it needs into your own Supabase project: sign-in, tables, forms and the security rules that protect them.
You do not write SQL or configure auth by hand. You connect your account, choose a project, and Laarpi does the rest.
What gets wired
The plan for every site lists what its backend needs. When you connect Supabase, Laarpi creates exactly that.
| The site needs | What Laarpi sets up in your Supabase |
|---|---|
| Visitors who can sign in | Magic-link and email-and-password sign-in, with your published address and preview allowed as redirect targets |
| A contact, booking or waitlist form | A table for the submissions that anyone may add to and only you may read |
| Members-only content | Sections shown to signed-in visitors, with anything truly private loaded from a protected table after sign-in |
| Things people save for themselves | Tables where each row belongs to the person who created it |
| Content you publish | Tables everyone may read and only you may change |
| Orders and subscriptions | Tables filled by a webhook from Polar when someone pays |
How connecting works
- Connect your account. Sign in to Supabase through OAuth, or paste a personal access token. Laarpi checks the token with a live call before it saves it.
- Choose a project. Pick an existing project, or create a new one in the organisation and region you choose.
- Laarpi waits until it is ready, then creates the tables the site needs, each with its row-level security policies.
- It configures sign-in: your published address and the preview become the allowed redirect targets, so magic links land in the right place.
- It deploys the functions the site needs, such as the payment webhook, and sets their secrets.
- The site gets its public keys, the project URL and the public key, which are safe to ship to the browser by design.
When the plan changes what the site needs, press sync in the Backend panel and Laarpi applies the difference.
Who can see what: access rules in plain words
Every table Laarpi creates has row-level security switched on and one of four access rules:
| Access rule | Who can read | Who can write | Typical use |
|---|---|---|---|
| Public read | Everyone | Only you | A programme, a catalogue, opening times |
| Owner | The signed-in owner of each row | The signed-in owner of each row | Saved items, profiles, preferences |
| Public insert | Only you | Anyone, add-only | Contact forms, waitlists, bookings |
| Admin | Only you | Only you | Internal notes, moderation |
Row-level security is a Postgres feature Supabase builds on. Even with the public key in the browser, the database refuses any read or write the rule does not allow.
Security, specifically
- Your tokens never reach the browser. Access tokens are encrypted at rest and used only on the server.
- The site ships only public values: the project URL and the public key, which Supabase designs for exactly this use.
- Policies exist before data does. Tables are created with their security rules in the same step.
- Forms are hardened. Submissions use native validation and a hidden honeypot field to keep simple bots out.
- You can revoke access at any time from your Supabase account. Your site keeps working with the keys it has.
Before real visitors sign in
Supabase sends the magic-link and confirmation emails. Its built-in email service is meant for testing and has low sending limits, so before launch, connect your own email provider in the Supabase dashboard under authentication settings. Your visitors then get sign-in emails from your own address, without delays.
It is also worth customising the email templates in Supabase so the sign-in message sounds like your site, not like a default.
Why it is your account, not ours
Your users, submissions and orders live in your Supabase project. You can open them in the Supabase dashboard, export them, write your own queries, and take them anywhere. If you stop using Laarpi, the backend stays exactly where it is. Supabase's own plans and limits apply to your project.
A studio site like the one above is a good example of what a backend adds: commission requests that land in a table you can read, a waitlist for the next firing, and orders that arrive from the checkout through a webhook. Pair it with website payments for the checkout itself.
Building now, connecting later
You do not have to decide on day one. Until Supabase is connected:
- forms render and work, and tell visitors politely that submissions are not connected yet;
- the preview shows a quiet note where data would go;
- sign-in shows the same quiet note in the preview instead of failing silently.
Connect when you are ready to publish, and the same site starts storing data.
What Laarpi does not do
- It does not host your database. Supabase does, in your account.
- It is a website agent, not an app platform. It builds sites with sign-in, data and payments. For a complex web application with heavy business logic, a general-purpose app builder or a developer is the better fit.
How to ask for it
Say what visitors should be able to do, and the agent works out the tables:
- "Visitors can join a waitlist with their email and city."
- "Members sign in to see the full archive." (Good for music artists with a fan club.)
- "A booking request form for Saturday studio visits." (The same pattern runs RSVPs for an event website.)
Then publish to a custom domain, take payments with Polar, and see the whole flow on how it works.
