DEV Community: Skapi

Database built for AI agents

Skapi — Mon, 26 Oct 2026 07:53:27 +0000

No schema, no setup, no scans: how the Skapi database works, and why it is built for AI agents

The question we get more than any other is some version of "how do I set up my database?" Where is the schema designer. Where do I define the tables. What about indexes, migrations, the query planner. The answer is that you do not. There is nothing to set up. You write a record, and the table exists. You delete the last record, and the table is gone. If that sounds like something that cannot possibly hold up under real load, this article is for you. It explains the model behind the Skapi database, schema-free and index-on-write: why it does the work you reach for a relational database to do, why it never falls into the full-table scan that quietly drains production budgets, why the same mechanism is what keeps your data secure, and why it is the right shape for a world where AI agents write most of the code.

The question, answered once

A Skapi project has no database to set up, because there is no moment at which structure is decided ahead of data.

Tables are not created. A table appears when the first record is written into it and disappears when the last one leaves. Indexes are not defined. An index is an argument you pass when you write a record. Access rules are not configured. They are an argument too. There are no migrations, because there is nothing to migrate: a record written today with a new field does not care what the record next to it looks like, and the database does not care either.

So when you ask "how should I design my schema", the honest answer is this. Write the records your product needs, and say, on each one, how you want to find it again. That is the whole discipline. Everything below is about why that is enough.

Where the confusion comes from

If you come from traditional backend engineering, you have been trained on two ways a database decides what data looks like.

The first is schema-on-write. You design the structure before any data exists: tables, columns, types, constraints, indexes. The database refuses anything that does not fit. This is the relational model, and it is very good at protecting the integrity of data. What it does not protect is the cost of reading it. Every query is handed to a planner at runtime, and the planner decides how to find the rows. If your condition happens to be covered by an index, it seeks. If it is not, it scans the whole table. Both are legal. Nothing warns you. The scan is the silent default for any question nobody anticipated when the schema was drawn.

The second is schema-on-read. You store whatever arrives and decide what it means when you query it. This is the data lake, and it is also what a document store becomes when its indexes are an afterthought. There is no structure to maintain, which is pleasant, and every read is a scan by definition, which is not.

Both models share one trait. The cost of a read is decided at read time, by machinery you do not see, over data you wrote earlier without saying how you would read it. The expensive decision is made at the moment you have the least information and the least control.

Index-on-write

Skapi moves that decision to the one moment you know the most about a record: when you write it.

When you post a record, you say a few things alongside the data. Which table it belongs to. Which access group may read it. Optionally, one index name and value to find it by. Optionally, tags. Optionally, the record it references. The database stores the record under keys built from those declarations, in sorted order, typed so that numbers sort as numbers and strings as strings.

await skapi.postRecord(
    { title: 'Dukkha', artist: 'Asian Spice House', tracks: 7 },
    {
        table: { name: 'Albums', access_group: 'public' },
        index: { name: 'year', value: 2023 },
        tags: ['Indie', 'Experimental']
    }
);

That is the schema. It is local to this record, it was decided by the code that had the record in hand, and it is already applied by the time the write returns.

A query is the mirror image: a table, an access group, and at most one index condition or range.

await skapi.getRecords({
    table: { name: 'Albums', access_group: 'public' },
    index: { name: 'year', value: 2010, condition: '>=' }
});

Every such query maps to one contiguous range of sorted keys. The read is a seek to the start of the range and a walk to the end of it, a page at a time. Nothing outside the range is touched. There is no planner, because there is nothing to plan.

One record, written once. The table, access group and index you pass become a sorted key, and a query reads one range of those keys. Rows outside the range are never touched.

	Structure is decided	Access path is decided	What a read costs
Schema-on-write (relational)	Before any data, for the whole table	At query time, by the planner	A seek if an index happens to cover it, a scan if not
Schema-on-read (lakes, loose document stores)	At query time	At query time	A scan
Index-on-write (Skapi)	Per record, when it is written	When it is written	One key range, proportional to the result

The expensive query cannot be written

Here is the theory in one line. A scan costs in proportion to the size of the table. A seek costs in proportion to the size of the result. Everything that goes wrong with database bills lives in the gap between those two.

A scan reads every row, so its cost grows with the table. A seek reads the matching range, so its cost grows with the result. On Skapi, only the seek exists.

Every experienced engineer has seen the pattern. A query runs fine in development against ten thousand rows. It ships. The table grows to fifty million rows, and the same query is now five thousand times more expensive, because it was always a scan and nobody noticed while the table was small. On a database billed per read, that is not a slow page. That is an invoice. The fix is an index that someone had to think of in advance, which is exactly the thinking the schema was supposed to force, and did not.

On Skapi the scan is not slow. It does not exist. There is no way to ask the database for "every record whose data contains some value", because the data is not what the database reads. The keys are. If you want to find records by a value, you index on that value when you write. If you did not, the query is not expensive, it is not a query.

The consequence is that the cost of any read is proportional to what it returns, not to how much you have stored. A table of ten records and a table of ten million answer the same query at the same cost per record returned. There is no slow-query log to read, no planner to second-guess, and no index advisor telling you what you should have done last month. A junior developer and a senior one write the same query, because there is only one kind of query to write.

Everything you build a relational database for

The objection at this point is that a single index per record cannot possibly cover what a relational database does. It covers what you actually build. Every item below is a key read, and each one is a few lines of skapi-js.

Find by id. Every record has an id, and you can give it your own: an order number, a slug, a SKU. Both are direct lookups.

await skapi.postRecord(order, {
    table: { name: 'Orders', access_group: 'authorized' },
    unique_id: 'order-1042'
});

await skapi.getRecords({ unique_id: 'order-1042' });
await skapi.getRecords({ record_id: order.record_id });

Newest first, oldest first. Every record is ordered by when it was uploaded and when it was last updated. Both are reserved index names, so "everything from the last seven days, newest first" is a range read.

const since = Date.now() - 7 * 24 * 60 * 60 * 1000;

await skapi.getRecords(
    {
        table: { name: 'Orders', access_group: 'authorized' },
        index: { name: '$uploaded', value: since, condition: '>=' }
    },
    { ascending: false, limit: 50 }
);

Conditions and ranges. Equal, greater, greater or equal, less, less or equal, and a range between two values. On a string, the same operators give you "starts with" and "ends with".

// albums released from 1960 to 1970
await skapi.getRecords({
    table: { name: 'Albums', access_group: 'public' },
    index: { name: 'year', value: 1960, range: 1970 }
});

// titles that end with "Gilberto" ('>=' on a string is "starts with")
await skapi.getRecords({
    table: { name: 'Albums', access_group: 'public' },
    index: { name: 'title', value: 'Gilberto', condition: '<=' }
});

Relations. A record can reference another record. Comments reference a post, order items reference an order, a like references what was liked. Fetch everything that references a record, and the relationship is already there. A join is the engine discovering a relationship at query time. A reference is the relationship recorded at write time, which is the only moment anyone actually knew it.

const post = await skapi.postRecord({ text: 'What do you think?' }, {
    table: { name: 'Posts', access_group: 'public' }
});

await skapi.postRecord({ text: 'I like it!' }, {
    table: { name: 'Comments', access_group: 'public' },
    reference: post.record_id
});

// every comment on that post
await skapi.getRecords({
    table: { name: 'Comments', access_group: 'public' },
    reference: post.record_id
});

A post is written once. Each comment and like points at it, and the post carries a count of how many records point at it. Fetching by reference reads those records and nothing else.

Counting relations. How many records reference a record is itself an index. "The most commented posts" is a range read, not a GROUP BY over a comments table.

// posts with more than ten comments, most commented first
await skapi.getRecords(
    {
        table: { name: 'Posts', access_group: 'public' },
        index: { name: '$referenced_count', value: 10, condition: '>' }
    },
    { ascending: false }
);

Hierarchy. A compound index name such as Band.AsianSpiceHouse.year can be queried at any level: every band, bands by name, or one band's albums by year. Here is the write, and the index part of three queries on the same table.

await skapi.postRecord(album, {
    table: { name: 'Albums', access_group: 'public' },
    index: { name: 'Band.AsianSpiceHouse.year', value: 2023 }
});

// every album by a band
index: { name: 'Band.', value: '', condition: '>' }

// bands whose name starts with "Asian"
index: { name: 'Band.', value: 'Asian', condition: '>=' }

// one band's albums released after 2010
index: { name: 'Band.AsianSpiceHouse.year', value: 2010, condition: '>' }

Tags. Labels that cut across indexes. A tag narrows any query, and every tag carries its own record count.

await skapi.postRecord(album, {
    table: { name: 'Albums', access_group: 'public' },
    index: { name: 'year', value: 2023 },
    tags: ['Indie', 'Experimental']
});

// albums released after 2020 that are tagged Experimental
await skapi.getRecords({
    table: { name: 'Albums', access_group: 'public' },
    index: { name: 'year', value: 2020, condition: '>' },
    tag: 'Experimental'
});

Aggregates without scanning. Record counts per table, per tag and per index. Totals and averages of numeric indexes. The rate of true values for boolean indexes. All of it is kept up to date as records are written, so a rating board does not average votes at read time. The average is already there.

// each vote is a record with a boolean index
await skapi.postRecord(null, {
    table: { name: 'VoteBoard', access_group: 'public' },
    index: { name: 'Vote.Beer', value: true }
});

await skapi.getIndexes({ table: 'VoteBoard', index: 'Vote.Beer' });
// average_bool: the share of true votes, boolean_count: how many voted

await skapi.getTables({ table: 'Albums' });
// number_of_records and size, per table

await skapi.getTags({ table: 'Albums' });
// every tag in the table with its number_of_records

Per user. Every user's records, per table, and subscriptions and feeds on top of that. A user follows another user, and reads one feed of everything the people they follow have posted to it.

// everything one user posted to a table
await skapi.getRecords({
    table: { name: 'Posts', access_group: 'public' },
    index: { name: '$user_id', value: user_id }
});

// follow a user, then read the feed of everyone you follow
await skapi.subscribe({ user_id, get_feed: true });
await skapi.getFeed({ access_group: 'authorized' });

Notice what is not on the list: anything that would require reading the whole table to answer. That is not an omission. That is the point.

Permission is an address, not a filter

On most backends, access control is a filter. A policy is a predicate added to each query and evaluated per row by the same engine that may or may not have an index for it. It is a step in the read, and like any step it can be slow, and it can be skipped by any path that writes to the database without going through it.

On Skapi, the access group is part of the key a record is stored under. Public records, authorized records, numbered groups from 0 to 99, admin, private: each is a different address. A query names the group it wants to read. A user in access group 5 can ask for group 5 or any group below it, and the read lands on that group's keys alone. A user in group 3 who asks for group 5 is refused before a single key is read. The rows for group 50 are not filtered out of anyone's result. They are never read, because they do not live where the query is looking. Private records are reachable only by their uploader and by users the uploader explicitly grants, and that grant is an address too.

A query names the access group it wants. The read lands on that group's address and nowhere else. Higher groups and private records are not filtered out of the result. They are never read.

This is why security and cost come from the same mechanism. A permission check is not a stage that a badly written query can bypass or a busy engine can make expensive. It is where the data is.

Sealed in the browser

The model goes one step further for the data a user keeps to themselves. Turn on record encryption, and the data of a private record is encrypted in the browser before it leaves the device, with keys derived from the user's own password that never leave that device. A provider who dumps the database, the storage bucket and every request log cannot recover the contents without guessing the user's password.

Index-on-write is what makes this possible without breaking the database. The database reads structure: table, access group, index, tags, reference. It stores content. Because those are separate, the structure can stay readable, so every query above keeps working, while the content is sealed. The same is true of attached files: their bytes are encrypted, their names and sizes are not. The details, and the exact security claim, are in the encryption guide.

Why this is the database for AI agents

Agents write code fast and in volume, and they write it against a backend you did not fully review. A database has to be safe under that kind of writer.

Against a schema-on-write database, every change an agent makes is global. One more field means a migration, a policy per operation, regenerated types and a redeploy, and the loop starts again on the next request. We measured that loop in tokens. The deeper reason it costs so much is that a schema is shared state: an agent must hold the whole of it in context to change any of it safely.

Index-on-write has no shared state. Every decision is local to one write: this record, this table, this index, this access group. The agent decides at the point of maximum information and never has to reconcile the decision with anything else. When it needs to know the shape of the data, it asks the database, which lists tables, indexes and tags with their counts, maintained as the data was written. The schema is discovered from the data instead of being maintained beside it.

Three agents changing a schema-on-write backend all pass through one shared schema and the migrate, policies, types, deploy loop. On index-on-write, each agent writes its own record with its own rules, and nothing has to be reconciled.

And the cost guard holds for agents exactly as it holds for people. Agents will write queries you never read. On a relational database, one of them will be a scan. On Skapi it cannot be, because the only query that exists is a key read. The worst an agent can do is fetch a page it did not need.

For fifty years, database design has meant deciding structure before data and paying for every question nobody anticipated. Agents invert the workflow. Data first, structure as a property of each record, access as part of the address, and a database that stays cheap and safe no matter who, or what, is writing to it. That is index-on-write, and it is what the Skapi database has been from the beginning.

Start with a record

Create a Free project, write one record from the browser, and you have a database. The database guide shows every argument from the example above, and there is nothing to set up before you begin.

Newsletters on Skapi: simpler than Mailchimp

Skapi — Mon, 19 Oct 2026 07:46:39 +0000

Newsletters on Skapi: simpler than Mailchimp, for a fraction of the price

A marketing newsletter needs three things: a list, a form that fills it, and a way to send. Skapi ships all three inside the backend you already pay for, and the sending part is the mail app you already have. Here is how it works, click by click, and what it costs next to Mailchimp.

One page, one address

Open your project and choose Newsletters in the sidebar. The page has a tab per list: Newsletter is the public list anyone can join with an email address, Service Email is the list of your signed-in users, and every named group you create gets a tab of its own.

The Newsletters page. Every list has its own sending address, its own subscriber count and its own history of sent mail.

The first row is the whole sending story. Write your newsletter in your own mail app, the one you use every day, and send it to the address shown there. [Send] opens a new message to that address for you. Skapi forwards the email to every subscriber of that list, adds an unsubscribe link at the bottom, and the table below fills in with the subject, the date, and how many people read it, complained, or bounced.

Composing a newsletter in a mail app. The address in To is the one the Newsletters page shows, and the email goes out as written, with an unsubscribe link added at the bottom.

There is no editor to learn, no template gallery, no campaign builder. If you can write an email, you can send a newsletter.

Two guardrails sit behind that address. Mail is only accepted from the email address your project is registered with, so knowing the address is not enough to send as you. And the sending address has to pass the sender trust checks (SPF, DKIM and DMARC), which the large email providers already do. Anything else is refused, and Skapi replies to tell you why.

Before any of this works, register an email alias on your project's Settings page. It becomes the address your newsletters and automated emails are sent from, and the Newsletters page stays closed until you have one.

Adding subscribers by hand

Not every subscriber comes through a form. You may be moving a list from another tool, or you may have customers who wrote their address on a sheet at the counter. On the Subscribers row, click [Add].

Paste addresses, one per line or separated by commas, check the list, and add them.

Paste the addresses, one per line or separated by commas, and click Add to list. Anything malformed is set aside and shown to you, duplicates are folded together, and the addresses that remain are listed so you can remove one before committing. Then Add 3 subscribers, or however many you pasted.

Addresses added this way are subscribed right away, without a confirmation mail, so use it for people who have already asked to hear from you. Everyone else should come in through the form below, which confirms the address first.

[View] opens the list itself, with a search that matches the start of an address.

The subscriber list, searchable by the start of an address.

The Service Email tab has no [Add]. Its subscribers are your users, who subscribe and unsubscribe with their own account, so nobody can be added to it by hand.

Groups: several lists on one project

One project is not limited to one newsletter. Click + New group to create a named list.

A named group: a short name that becomes part of its sending address, an optional label for the tab, and who may subscribe.

The name is two to twenty lowercase letters and digits. It becomes part of the group's sending address and cannot change later. The label is what the tab shows. Subscribers decides who may join: anyone with an email address, any signed-in user of your app, or only users at or above an access group you choose. That last option is how you run a members-only or paying-customers-only list without writing any code.

Each group keeps its own subscribers, its own sending address and its own sent mail, so a subscriber of one never receives the other. A project can hold up to twenty of them.

A named group has its own address, its own count and an Access row. Deleting the group deletes its subscribers with it.

The signup form, without writing it

The form is the part most people expect to build. You do not have to. Open your project's Settings page and scroll to Application Examples.

Application Examples on the Settings page. Every row opens a plain HTML page that already runs against your project.

Click [Open] on the Newsletter row. What opens is a working subscription page, already pointed at your project.

The example page. Its address carries your project id, so it can be linked as it is.

You can use it three ways:

Link it. The address of that page carries your project id, so a link from your site, your Instagram bio or your email signature is a working signup form. Nothing to host.
Copy the form. Click [Download] on the same card for every example page as a ZIP, open newsletter.html, and paste the form into your own page.
Write it. It is a form with two fields, passed straight to the SDK:

<form onsubmit="skapi.subscribeNewsletter(event).then(res => alert(res))">
    <input type="email" name="email" placeholder="your@email.com" />
    <input hidden name="group" value="public" />
    <input hidden name="redirect" value="https://your.domain.com/thanks" />
    <input type="submit" value="Subscribe" />
</form>

Change public to a group's name to feed a named group instead, and redirect is where the visitor lands after confirming.

A visitor who subscribes this way gets a confirmation email and joins the list when they click the link in it, so every address on your public list is one that proved it wanted to be there. A signed-in user with a verified email skips the confirmation.

Rules that keep you out of the spam folder

The plumbing that a mailing tool charges for is switched on for every project:

Confirmation for every public signup, and an unsubscribe link on every newsletter.
Complaint shutoff. A project that collects five spam complaints in a month, or a complaint rate of half a percent once a hundred mails have gone out, stops sending newsletters. Nothing else about the project stops, and we clear the block after a look.
Sender trust. Only mail from your registered address, passing SPF, DKIM and DMARC, is forwarded.
Counted per recipient. One newsletter to a list of 1,000 uses 1,000 of your monthly sends, so the number on your plan is a number of deliveries, not of campaigns.

What it costs

Newsletters are part of every plan, not a separate product.

	Free	Standard $19/mo	Premium $89/mo
Subscribers, all groups	50	5,000	50,000
Newsletter sends per month	50	5,000	50,000
Email storage	50 MB	1 GB	5 GB
Past a limit	Stop	Stop	$1 per 1,000 extra sends or subscribers

The same plan carries your database, file storage, hosting, user accounts, automated emails and everything else a Skapi project does. The newsletter is not the thing you are paying for. It comes with it.

Now Mailchimp, from its pricing page at the time of writing. Its Free plan takes 250 contacts and 500 sends a month. The paid plans start at $13 a month for Essentials and $20 for Standard, both for up to 500 contacts, and the price climbs with every tier of contacts you hold. Premium starts at $350.

Contacts	Mailchimp Essentials	Mailchimp Standard
500	$13	$20
2,500	$45	$60
5,000	$75	$100
10,000	$110	$135
25,000	$270	$310
50,000	$385	$450

Put the two side by side for a monthly newsletter, one send to the whole list each month:

$19 for 5,000 subscribers, against $75 to $100. $89 for 50,000, against $385 to $450.

The same list at both companies, at the time of writing. Skapi's price is the plan the list fits in, Standard up to 5,000 subscribers and Premium above it, and that plan runs the rest of your backend too. Mailchimp's is its published tier for that many contacts.

Two honest notes. Below a few hundred subscribers, Mailchimp's entry tier is a few dollars cheaper than our Standard plan, and its free tier is larger than ours. And Skapi counts sends per recipient, so a weekly newsletter to 5,000 people is 20,000 sends a month, which puts you on Premium at $89, about what Mailchimp charges for the same list. At 25,000 subscribers sent weekly, Skapi is $139 with the extra sends billed, against $270 and up. The bigger the list, the wider the gap.

One more difference in how the count works. Mailchimp's tiers are based on the contacts in your audience, which by its own rules includes people who have unsubscribed until you archive them. Skapi counts subscribers. When someone unsubscribes, they leave the list and the count.

What Mailchimp has that we do not

Mailchimp is a marketing suite. It has a drag-and-drop editor, a template gallery, automation journeys, A/B tests, landing pages and deep reporting. If your business runs on those, keep it.

Skapi gives you a list, a form, an address, and a table that tells you who read, who complained and who bounced. You write in your own mail app, and segmentation is a group. For a great many businesses, that is the entire newsletter they ever wanted, and it is the part that Mailchimp charges for by the contact.

Where to start

Register an email alias on your project's Settings page.
Open Newsletters, add the subscribers you already have with [Add], and create a group if you need more than one list.
Link the example signup page, or paste its form into your site.
Write the newsletter in your mail app and send it to the address on the page.

The first one takes about ten minutes. Every one after that takes as long as writing the email.

How to cut the token bill of vibe coding: Skapi, backend built for AI agents

Skapi — Mon, 12 Oct 2026 06:34:46 +0000

Cut the token bill of vibe coding: Skapi, backend built for AI agents

Every prompt you send an AI coding agent costs tokens, and a surprising share of them go to the backend: schemas, policies, generated types, redeploys. We measured where the tokens go when the backend is built through an MCP server on Supabase or Firebase, why the spending never stops after the first build, and what the same app costs when it runs on skapi-js instead. We measured our own side the same way: the prompt file the agent loads, the pages it reads, and the Skapi MCP server. The short version: Skapi is the backend that costs your agent the least, because there is no schema to rebuild, ever.

Where the tokens go

An AI coding agent works in round trips. It reads its context, calls a tool, reads the result, and calls again. Every one of those trips sends the whole context back through the model: the system prompt, the instruction file your tool loads from the project root, the conversation so far, and the description of every tool the agent is allowed to use. Prompt caching makes the repeated part cheaper, usually to about a tenth of the price, but it never makes it free, and cache entries expire in minutes.

Build a backend through an MCP server and the loop looks like this. The agent lists the tables to learn the schema, writes a migration, applies it, writes a row-level security policy per operation per table, regenerates the TypeScript types, runs the security advisor, fixes what it reports, and only then edits the client code. Then you ask for one more field, and the loop runs again from the migration step.

The loop an agent runs for every schema change, and the loop it runs on skapi-js. The steps in the first row are the tools Supabase's MCP server describes for exactly this purpose.

Two things make the first loop expensive, and neither shows up on a pricing page. The steps are round trips, so the growing context is re-read at each one. And the artifacts are not small: a migration is hundreds of tokens, the policies are hundreds more, and the regenerated types file is re-read in full after every change.

We measured it

The numbers come from the real servers and the real files. We started the @supabase/mcp-server-supabase (0.13.0) and firebase-tools (15.31.0) packages over stdio, sent tools/list, and counted the payload the agent receives with the cl100k tokenizer. We counted Supabase's published AI prompt files the same way, from the examples/prompts folder of its repository on 2026-10-07, and on the Skapi side the prompt file, the documentation pages as published that day, and our own MCP server's tools/list. Claude's tokenizer differs a little, so read these as sizes, not invoices. The migration, policies and types on the Supabase side are our own minimal examples for a task app with profiles, projects and tasks, written the way Supabase's own guides say to write them.

What travels with every request

Two things ride along on every round trip for as long as the session lasts: the tool list an MCP server describes to the model, and the instruction file your coding tool loads from the project root (CLAUDE.md, AGENTS.md, .cursorrules and the rest). Supabase's tool list alone is 5,051 tokens in its default configuration, and 1,051 with only the database and development tools, but its documentation tells you to add its prompt files to that instruction file, for RLS policies, migrations, the declarative schema, the SQL style guide and the auth bootstrap, because the agent writes them wrong without the rules. Those eight files are 12,563 tokens; the five a task app needs are 6,552. On the Skapi side there is no server in the build loop, so the standing cost is the instruction file alone.

Compact JSON as the client receives it, plus the prompt files each side tells you to load. Firebase's number is large because its Firestore document tools carry their full JSON schemas. The Supabase rows are its default tool list plus its own published prompt files, all eight or the five a task app needs. The two Skapi rows are the same session: 5,847 tokens of prompt file, and no tool list, because the agent builds against the SDK, not through a server.

Firebase's --only flag and Supabase's features parameter cut those lists down, and you should use them. But the smallest Supabase set that can still apply a migration is about a thousand tokens, most people run the default, and the prompt files do not shrink with the flag. Take a modest working session of 40 tool calls. On Supabase, with the default list and the prompt files a task app needs, that is about 460,000 tokens of standing context passing through the model. On Firebase's default list it is 2.4 million before any instruction file. On Skapi it is about 230,000, and that is everything: the rules, the map and the whole method index.

The Skapi row is the whole instruction file: SKAPI.md is 24.7 KB, 5,847 tokens, and it holds the rules, a map of the documentation and an index of every SDK method, each linking to its page. It is sized to be loaded on every turn by every tool, Codex CLI's 32 KiB limit on AGENTS.md included, and the pages themselves are read only when a feature needs them, which is the next number.

The change loop, three steps

Now the artifacts. We built the same task app three times over: the first build, then "add a priority to tasks and filter by it", then "let me share a task with a teammate". For each step we counted what the agent has to write for the backend and what it has to read back.

Each Supabase bar is what one step costs in backend artifacts: the first segment is what the agent writes, the second is the regenerated types file it reads back afterwards. Three steps come to 6,705 tokens, and 5,253 of them, 78 percent, are the same types file read back three times. The skapi-js rows have no bar to draw.

Step	Supabase over MCP	skapi-js
Build: accounts, tasks with an attachment	Migration with 3 tables, 3 indexes, RLS on every table and 12 policies: 787 tokens. Storage bucket and 3 object policies: 159. Regenerated types, read back: 1,751. 2,697 tokens, plus `list_tables` and `get_advisors` responses we could not measure without a live project.	0. Accounts come with the project. A record carries its own table name, access group and index, so there is nothing to create before the first `postRecord()`.
Change 1: add a priority, filter by it	Migration adding the column and an index: 38. Regenerated types, read back in full: 1,751. 1,789 tokens	0. The change is an `index` key in the call that already exists: about 100 tokens of client edit.
Change 2: share a task with a teammate	New `task_shares` table, its RLS, and the two task policies rewritten with `exists` subqueries: 468. Regenerated types: 1,751. 2,219 tokens	0. One call: `skapi.grantPrivateRecordAccess({ record_id, user_id })`, 28 tokens.

The client code is roughly the same shape on both sides. Our supabase-js module for the build step is 408 tokens, the skapi-js one 202. The difference is not the client. It is everything the client needs to exist first.

Notice the pattern in the middle column. The migration for change 1 is 38 tokens. The regenerated types the agent then reads back are 1,751, and they are 1,751 again after change 2, and after every change after that, because the tool returns the whole file. The steady cost of a schema is not the schema. It is the re-reading.

And these are the artifacts alone. Each of those steps is a tool call, and each tool call is a round trip that re-reads the conversation and the tool list. A change that costs 1,789 tokens of artifacts costs several times that by the time the agent has listed the tables, applied the migration, regenerated the types, run the advisor and read every response.

What the agent reads instead

The fair question is what the agent reads on the Skapi side, since it is not reading a tool list. It reads documentation, once per page, when the feature comes up. The prompt file tells it which page to read: every page of the documentation is published as raw markdown under docs.skapi.com/md/, 94 pages, and the file links to the 71 on the sidebar; the rest are reached through the links between pages.

For the task app above the agent reads ten guide pages: getting started, signing up and logging in, creating, fetching, updating and deleting records, access restrictions, files and indexing. Measured on the published files, they come to 25,401 tokens. The reference entries it is told to check before writing a call live on three more pages, authentication, database and data types, 23,718 tokens if it reads all three in full, and the data types page is 11,280 of that. So the most an agent reads for this app is about 49,000 tokens, read once, and a careful agent that reads the entries it needs rather than whole pages reads less. The median sidebar page is 2,154 tokens.

The difference is what happens after the first read. On Skapi, nothing in the documentation changes when your app changes, so it is never re-read. Every schema change on the other side produces a new artifact that the agent has to read back. An agent building on Supabase reads its guides too; the RLS guide alone is the one that tells it to write a policy per operation per table. We did not measure those reads, so they are not in the charts, but they are not zero either.

Put the session together and it reads like this. On Skapi: 5,847 tokens of prompt file on every turn, the pages the app needs once, and no backend artifact, ever. Through an MCP server: the tool list on every turn, the guides once, and a migration, a policy set and a regenerated types file on every change.

Skapi's prompt file is what the dashboard downloads under the name your tool expects, CLAUDE.md, AGENTS.md, .cursorrules and the rest. Open your project's Settings page and look for For AI Agents.

The For AI Agents card. Click the prompt to copy it, then download the file under the name your agent reads.

And the Skapi MCP server

Skapi has an MCP server too, and it is useful: it lets an agent manage your project, read and write records, register tickets, store secret keys and set up OpenID login, signed in as you. Measured the same way as the others, its public tools/list is 17 tools and 7,610 tokens, in the same range as Supabase's default list. It is simply not part of the build loop. The agent writes code against skapi-js, and the backend answers; the server is for the moments when you want the agent to operate the project rather than write the app. It carries no documentation of its own: when an agent on a platform that cannot fetch urls needs a page, the server's readDocs tool returns that one page from the same source.

When the meter is credits instead of tokens

Web builders such as Lovable do not show you tokens. They charge credits per message, and the price of a message depends on how much work the agent did. At the time of writing, Lovable's own examples put "Make the button gray" at 0.50 credits and "Add authentication with sign up and login" at 1.20, the free plan grants 5 build credits a day, and the entry Pro tier is $25 for 100 credits a month, so a message that makes the agent do more costs you more of them.

The meter is different, the mechanism is not. A message that has to rebuild a schema, rewrite policies and redeploy is a message that does more work, and it costs more credits than one that edits a line of client code. The backend you choose decides what "add a field" means to the agent, and therefore what it costs you, on every platform that charges for the agent's effort.

Why Skapi is built for AI agents

An agent is at its best when the whole backend is one SDK it can write against, with nothing to provision, migrate or deploy in between. That is what Skapi is: accounts, database, files, CDN, emails, realtime, hosting and webhooks behind one JavaScript library, on a plain HTML page or in any framework, with a free plan to start on.

Skapi has no schema. A record is a piece of data with a few words attached: the table it belongs to, who may read it, and optionally what it is indexed by. The table exists because a record said so. That is what makes the agent's side so small: there is no relational schema to design before the first record, no policy language to learn, and nothing to deploy, so the design work an agent does is the one word that says who may read the record.

skapi.postRecord(form, {
    table: { name: 'tasks', access_group: 'private' },
    index: { name: 'priority', value: 2 },
    reference: projectId
});

That is the whole backend side of a task with an attachment. form is the HTML form the user filled in, file input included, and the file is stored and served from a CDN without another line. access_group: 'private' is the entire security policy: the record's owner can read it, nobody else can, until the owner grants someone access. Change 'private' to 'authorized' and every signed-in user can read it; change it to 'public' and everyone can.

The Database page after the three steps above. Six tables, none of them created by hand. The lock, group and globe icons are the access groups: private, authorized and public.

Open any record and you are looking at the entire data model of a Skapi project: the table name, the access group, one index, a reference, tags, and the data itself.

One record. Everything an agent would otherwise put into a migration is a field on this form, and every field is optional except the table name.

Accounts work the same way. skapi.signup(event) on a form creates the user, skapi.login(event) signs them in, and the confirmation email, the password reset, the welcome mail and the user list on your dashboard are already there.

The Users page. Signup, login, verification, password reset and the admin actions come with the project.

The same project also carries what a growing app asks for next, none of it a separate build: realtime messaging, automated emails and newsletters, secret keys and request forwarding for third-party APIs, tickets that accept webhooks, OpenID login and web hosting. Each one is a method on the SDK or a card on the dashboard, and each one is one loop of the second kind.

Where to start

The cheapest way to check any of this is to build something. A Free project costs nothing.

Create a project at skapi.com and copy its Project ID from the Settings page.
On the same page, download the prompt file for your tool from For AI Agents, and put it in the root of your project.
Start the agent with the opening prompt: My Skapi project ID is "<Project ID>". Build me a task board with accounts, private tasks and attachments.
Ask for the next change. Then the one after that.

The first build is an afternoon. Every change after it costs what a change to the client code costs, because that is all it is. Your agent's tokens go into your app, not into the plumbing under it.

The real price of a backend in São Paulo: $529 on AWS vs $19 on Skapi

Skapi — Fri, 02 Oct 2026 05:52:52 +0000

The real price of a backend in São Paulo: $529 on AWS vs $19 on Skapi

In the last article we said a Skapi project in São Paulo runs at a fraction of what a traditional server backend costs there, and that getting there was hard. Here is the bill, line by line: $528.71 a month for the traditional stack, $19 for the same backend on Skapi, and how we made that work.

Why São Paulo is expensive

AWS charges more in São Paulo than in most of its regions, and it is not a rounding error. Here is what the same building blocks cost in São Paulo (sa-east-1) and in N. Virginia (us-east-1), the region most tutorials silently assume you are in. List prices, on demand, as of September 2026.

Building block	São Paulo	N. Virginia	São Paulo costs
App server, t3.medium, per hour	$0.0672	$0.0416	62% more
Database, RDS db.t3.medium Multi-AZ, per hour	$0.302	$0.145	108% more
Database storage, gp3, per GB-month	$0.219	$0.115	90% more
Server disk, EBS gp3, per GB-month	$0.152	$0.080	90% more
NAT gateway, per hour	$0.093	$0.045	107% more
Application load balancer, per hour	$0.034	$0.0225	51% more
File storage, S3 Standard, per GB-month	$0.0405	$0.023	76% more
Data transfer out, per GB	$0.150	$0.090	67% more
CDN delivery, CloudFront, per GB	$0.110	$0.085	29% more
CDN requests, CloudFront HTTPS, per 10,000	$0.022	$0.010	120% more
Email, SES, per 1,000 messages	$0.10	$0.10	the same
User accounts, Cognito Lite, per monthly active user	$0.0055	$0.0055	the same

CDN prices follow the viewer, not the origin, so a Brazilian audience pays the South America rate wherever the files live.

Two things stand out. The parts that run all month, servers, databases and gateways, carry the steepest premium. The parts that only cost when someone uses them, email and identity, cost the same everywhere. Keep that split in mind. It is the whole story.

The bill for a traditional backend

Let's price a modest production app. Not a toy: 50,000 registered users, 20,000 of whom sign in each month, 3 GB of database, 120 GB of uploaded files, 100 GB served through the CDN each month, and 5,000 transactional emails. That is the exact ceiling of Skapi's Standard plan, so the comparison at the end is fair.

Built the traditional way in São Paulo, with the redundancy you would want for something real, the bill looks like this:

Line	What it is	Per month
App servers	2 × t3.medium, one per availability zone	$98.11
Server disks	2 × 30 GB gp3, plus daily snapshots	$13.20
Load balancer	Application Load Balancer, one capacity unit	$32.85
NAT gateway	Outbound access for servers in private subnets	$69.75
Database	RDS PostgreSQL db.t3.medium, Multi-AZ, 20 GB	$229.22
File storage	S3, 120 GB and its requests	$6.68
CDN	CloudFront, 100 GB and 2 million requests	$15.40
API traffic out	30 GB of responses to the internet	$4.50
Email	SES, 5,000 messages	$0.50
User accounts	Cognito Lite, 20,000 active users, first 10,000 free	$55.00
DNS and monitoring	Route 53 zone, CloudWatch basics	$3.50
Total		$528.71

You can cut that down. Run one server in a public subnet, drop the load balancer and the NAT gateway, run the database in a single availability zone, and it comes to about $256 a month. It also means the site goes down every time you deploy, reboot, or the database enters its maintenance window, and there is nothing to fail over to when the one server dies.

For scale: the same production stack in N. Virginia comes to about $311. São Paulo adds 70% to the bill for the privilege of being close to your users.

List prices, on demand, before discounts. A one-year reservation trims the server and database lines by roughly a third, in exchange for paying for capacity you may never use. AWS's always-free allowances would cover the CDN and transfer lines at this size; they are shown at list price because they are the lines that grow with success.

What the bill does not show

The monthly figure is the easy part. Every line in it is also a thing you have to build, and then keep.

Servers. Choose an image, harden it, open the right ports and only those, install a runtime, write a deploy pipeline, put TLS in front of it, and then keep it patched for the rest of its life. Two servers means doing everything twice and keeping them identical. Autoscaling means an image pipeline on top of that.

The database. A subnet group, a parameter group, a security group, a backup window, a maintenance window, a failover test you actually run, connection pooling so a traffic spike does not exhaust it, and a plan for the day the disk fills up. Multi-AZ doubles the price, and it is the only version you would put a business on.

Files and the CDN. A bucket with public access blocked, a policy that lets your servers write and nobody else, presigned URLs so users can upload without going through your servers, CORS rules, lifecycle rules. Then a CloudFront distribution with origin access control, cache policies, invalidations, a custom domain, and a certificate that, for CloudFront, must be issued in N. Virginia whatever region your files live in.

The network. A VPC, public and private subnets in two zones, route tables, an internet gateway, a NAT gateway, and IAM roles narrow enough to be safe and wide enough to work. None of this serves a single request. It is the price of admission.

And then the months after. Patches, certificate renewals, disk alarms, the 3 a.m. page, the database upgrade you have been putting off. If one developer spends even four hours a month keeping this running, that time alone costs more than the entire Skapi plan below, at any rate you would pay a developer in São Paulo, Buenos Aires or Bogotá.

Automated emails, compared

Email is the line that looks free and is not. SES charges $0.10 per thousand messages, so 5,000 emails cost fifty cents in São Paulo, exactly as in Virginia. The cost is everything around that number.

Before SES will send a real email you verify a domain, publish DKIM, SPF and DMARC records, and apply to leave the sandbox with a written description of how you handle bounces and complaints. Then you build that handling: notification topics, a suppression list, retries. Then the actual emails: a verification flow with a code that expires, a welcome email, an invitation, each one a template, a trigger and a queue so a burst of signups does not hit a rate limit. If you want to send a newsletter, add subscriber storage, a subscribe and unsubscribe flow that complies with the law in every country you send to, and a sending pipeline that paces itself.

On Skapi that whole list is a settings page. Verification, welcome and invitation emails go out from your project's own sending address with no code. Newsletters have subscribers, subscription and unsubscribe links, and a send button. Standard includes 5,000 sends a month and Premium 50,000, and the deliverability plumbing is done once, for everyone, and kept warm.

The same backend on Skapi

Same users, same data, same traffic, same city:

28 times less than the production stack. 13 times less than the one that goes down when you deploy.

Over a year, that is $6,345 against $228. The difference is not a discount. It is a different way of running a backend.

Here is what each side gives you for the money, one line at a time. First the cheapest of each: the AWS bare minimum next to Skapi Standard.

	AWS, bare minimum	Skapi Standard
Price per month	$255.85	$19
Database	RDS PostgreSQL with 2 vCPU and 4 GB of memory, one zone, 20 GB disk: $114.61	3 GB, included
File storage	S3, 120 GB: $6.68	120 GB, included
Web hosting	Served from your one server, or from a bucket you configure	Included, with a subdomain and HTTPS
CDN and bandwidth	CloudFront 100 GB, 2 million requests, 30 GB of API traffic: $19.90	100 GB, included
User accounts	Cognito Lite, 20,000 active users: $55.00	50,000 accounts, included
OpenID login	Set up by you in Cognito	Included
Automated emails	SES, 5,000 messages: $0.50. Templates built by you	5,000 sends a month, included
Newsletters	Built by you: list, opt-out link, sending	5,000 subscribers
Realtime data	Built by you, on the one server	Included
Push notifications	Built by you	Included
Webhooks	Endpoints you write and host	Included
API secret keys	Kept on your server	Included
App server	1 × t3.medium, 30 GB disk with snapshots: $55.66	None to run
Monitoring and DNS	CloudWatch and Route 53: $3.50	Usage meters in the dashboard
Redundant	No: one server, one zone	Yes
Backend deploys	The site goes down each time	None needed
Scaling	A bigger server, by hand	Automatic
Setup	A day	Minutes
Upkeep	Yours	Ours

And the full version of each: the AWS production stack next to Skapi Premium. To be generous to AWS, we added database overage to Premium until it matches the 20 GB database disk of the AWS stack, even though Premium already outdoes that stack everywhere else: five times the files, four times the bandwidth, ten times the emails.

	AWS, production	Skapi Premium
Price per month	$528.71	$94 ($89 plan, $5 overage)
Database	RDS PostgreSQL with 2 vCPU and 4 GB of memory, two zones, 20 GB disk: $229.22	20 GB: 10 GB included, 10 GB more at $0.50 per GB, $5.00
File storage	S3, 120 GB: $6.68	600 GB, included
Web hosting	Served from your servers, or from a bucket you configure	Included, with a subdomain and HTTPS
CDN and bandwidth	CloudFront 100 GB, 2 million requests, 30 GB of API traffic: $19.90	400 GB, included
User accounts	Cognito Lite, 20,000 active users: $55.00	100,000 accounts, included
OpenID login	Set up by you in Cognito	Included
Automated emails	SES, 5,000 messages: $0.50. Templates built by you	50,000 sends a month, included
Newsletters	Built by you: list, opt-out link, sending	50,000 subscribers
Realtime data	Built by you, across two servers	Included
Push notifications	Built by you	Included
Webhooks	Endpoints you write and host	Included
API secret keys	Kept on your servers	Included
App servers	2 × t3.medium, 2 × 30 GB disk with snapshots: $111.31	None to run
Load balancer	One capacity unit: $32.85	None to run
NAT gateway	For the private subnets: $69.75	None to run
Monitoring and DNS	CloudWatch and Route 53: $3.50	Usage meters in the dashboard
Redundant	Yes: two zones, set up and tested by you	Yes
Backend deploys	Rolling, through a pipeline you build	None needed
Scaling	Rules you write and tune	Automatic
Setup	Days	Minutes
Upkeep	Yours	Ours

That is $94 against $528.71. Even with the overage counted, Premium costs more than 5 times less.

The prices in each AWS column add up to the total at the top of it. The lines without a price are the ones the bill leaves out: they are paid in time instead. Both AWS columns are the bills from earlier in this article, sized for 120 GB of files and 20,000 active users. Sized for what Premium includes (600 GB of files, 400 GB of bandwidth, 50,000 emails, 40,000 active users) on the same servers, the AWS production bill comes to about $728 a month.

Standard is $19 a month in São Paulo, the same as in Oregon, Paris, Mumbai, Singapore or Seoul. For that you get the database, file storage, CDN, web hosting, user accounts with OpenID login, automated emails and newsletters, realtime data, API secret keys and webhooks, with room for 50,000 user accounts, 3 GB of database, 120 GB of files and 100 GB of bandwidth. Premium is $89 for 100,000 accounts, 10 GB of database, 600 GB of files and 400 GB of bandwidth. A small project runs on Free for nothing at all.

And all of that is before counting a single hour of anyone's time. The four hours a month from the section above cost more than the Skapi plan on their own.

How we got the price down

We are not going to draw you our architecture, and we do not have secret hardware. What we have is a set of rules we did not break, and in São Paulo they matter more than anywhere else.

Nothing idles. Look back at the first table. The steep premiums all sit on things billed by the hour whether or not anyone is using them. A traditional backend in São Paulo pays for 730 hours of servers, 730 hours of database and 730 hours of gateway every month, at 3 a.m. on a Sunday as much as at noon on payday. Every part of Skapi is metered by use: a request, a record read, a gigabyte stored, a message sent. When your users are asleep, so is your bill. That is what serverless means to us, and we applied it to every resource in the chain, not just the code.

Fixed costs are shared, not repeated. The expensive lines above, the redundant database, the load balancer, the gateway, are fixed costs a single project pays alone. In Skapi those costs exist once per region, and every project in that region shares them. Your project's share of a fixed cost is close to zero, and that, more than any clever trick, is where the fraction comes from.

Bytes go to the cheapest place that can hold them. Records live in a database that charges for what you store and read, not for a machine that waits. Anything large, files, uploads, hosted sites, record payloads over 32 KB, goes straight to object storage and is served from the CDN, so a download never touches a compute layer at all. Database storage is the most expensive byte in São Paulo, so we keep as few of them there as we can, and we made that change on every plan.

Identity and email are services, not servers. User accounts live in a managed directory built for that job, with verification, password reset and multi-factor flows already there. Email is a queue, with delivery, bounces, complaints and sender reputation handled once for the whole platform. These are the parts that cost the same in every region, and they are the parts nobody should rebuild per project.

Scale is a consequence, not a plan. Because every part is metered, a spike in traffic is a larger bill for that hour, not an outage, and a quiet month is a smaller one. There is no instance size to pick, no capacity to reserve, no failover to rehearse. The pieces that would go down are the pieces we do not run.

Security comes with the shape. There are no servers in your project to patch, no SSH, no open ports. Every request is authenticated and authorized on its own, every component talks to the next with the narrowest permission that works, data is encrypted in transit and at rest, and private records can be encrypted in the browser under your user's own password. A project's data never leaves the region it was created in. For Latin American teams, that last line often matters as much as the price.

Why São Paulo was hard

Here is the part we promised to explain. The rules above are how Skapi works everywhere. São Paulo tested every one of them.

Serverless does not escape the regional premium. It meets it on a different bill. Every meter we rely on runs faster in São Paulo: storage per gigabyte, requests per million, bytes out per gigabyte. Some managed services cost more there, some arrived later than in other regions, and a few of the shared pieces that make a fixed cost disappear had to be planned again so they would still disappear at São Paulo prices. Keeping the plan price flat, $19 in São Paulo exactly as in Oregon, meant wasting nothing: fewer hops per request, caching wherever it pays for itself, moving bytes as little as possible, and checking that no component, anywhere in the chain, sits idle on your behalf.

It was the hardest region we have opened, and we opened it on purpose. We want developers in Brazil and across Latin America to have affordable, efficient, solid access to backend infrastructure in their own region, at the same price as everyone else, without the tax the region has quietly charged for years. A student in Recife and a startup in Santiago should be able to run something real for the price of a few coffees a month. Now they can.

Where to start

Create a project, choose São Paulo, and run the numbers against your own AWS bill. If the difference is not obvious in the first month, we would like to hear about it.

Olá, São Paulo: Skapi now runs in São Paulo, its first South American region

Skapi — Wed, 30 Sep 2026 10:30:40 +0000

Olá, São Paulo

Skapi now runs in Brazil. São Paulo is our newest region, and it is the first place in South America where a project's database, its files and its user accounts all live on the same continent as the people using them.

Olá, Brasil! Olá, América Latina! A partir de hoje, a Skapi roda em São Paulo. Se você cria aplicações para usuários no Brasil ou em qualquer canto da América Latina, eles não precisam mais cruzar meio mundo a cada requisição: o banco de dados, os arquivos e as contas do seu projeto ficam pertinho, e cada login, cada consulta e cada upload responde bem mais rápido. Um abraço, e bom código!

The first South American region

Until now, the closest Skapi region to a user in Rio de Janeiro was in Paris, 9,167 km away on the other side of the Atlantic. A user in Lima was sent to Oregon, 7,720 km to the north. Every login, every query, every file upload made that journey and came back. It worked, and it worked well, but physics always took its cut.

São Paulo changes the shape of that map. Here is what the same requests look like now:

Your user is in	To São Paulo	Nearest region before
Rio de Janeiro	361 km	9,167 km (Paris)
Belo Horizonte	491 km	8,913 km (Paris)
Porto Alegre	852 km	10,254 km (Paris)
Brasília	872 km	8,725 km (Paris)
Buenos Aires	1,675 km	10,852 km (Oregon)
Santiago	2,585 km	10,099 km (Oregon)
Lima	3,454 km	7,720 km (Oregon)
Bogotá	4,328 km	6,339 km (Oregon)

A user in Rio de Janeiro is now twenty-five times closer to their data. A user in Buenos Aires, six times closer. That difference is not a benchmark you have to squint at. It is the feeling of a page that loads before the spinner has a reason to appear, a form that saves the instant it is submitted, and a file that starts downloading rather than thinking about it first.

From Colombia and Venezuela south, São Paulo is now the nearest region by a wide margin. Users in Mexico and most of Central America are still closest to Oregon, and Skapi keeps offering Oregon first there.

Where Skapi runs

Six regions across North America, South America, Europe and Asia, placed so that most of the connected world has a Skapi region within a short hop.

Every dot is a full Skapi region running the complete stack.

Region	Where it is	Project ID starts with
us-west-2	Oregon, United States	`us72`
sa-east-1	São Paulo, Brazil	`sa31`
eu-west-3	Paris, France	`eu73`
ap-south-1	Mumbai, India	`ap51`
ap-southeast-1	Singapore	`ap41`
ap-northeast-2	Seoul, South Korea	`ap22`

Read that list from west to east and the spacing is deliberate. Oregon anchors North America, and São Paulo now does the same for South America. Paris covers Europe, North Africa and the Middle East. Mumbai, Singapore and Seoul carry the largest concentration of internet users on the planet between them.

Every one of those regions runs the same Skapi. The same SDK call, the same API, the same authentication, the same record model. There is no South American edition with fewer features and no waiting for a region to catch up. A region is either serving your project completely or it is not serving it at all.

Now you choose where your project lives

When you create a project, you pick the region.

The new-project dialog. The closest region is offered first, every region is in the list, and the note under it says the one thing to know before you continue.

Skapi offers you the closest one first, worked out from where you are, so the fast choice is also the default choice. But the list is right there, and the right answer is often not your own city. If you are a studio in Lisbon with an audience in Rio, put the project in São Paulo. If you are three founders in São Paulo selling to Madrid, put it in Paris. Your users are the ones making the round trip thousands of times a day. You make it twice.

Pick deliberately, because a project stays where you put it. The region is baked into the first four characters of the project ID, which is why a São Paulo project announces itself as sa31... for the rest of its life. It is a permanent decision in the same way a good foundation is permanent.

Data that stays where you put it

There is a second reason to care about a region. A project created in São Paulo keeps its database records, its uploaded files, its hosted site and its user accounts in Brazil. Not routed through it. Stored in it.

For teams whose customers ask where their data is kept, and for anyone working under the LGPD, Brazil's data protection law, that single sentence is usually the one that unblocks the project.

Why São Paulo means so much to us

A new region is always satisfying to open, but this one means more to us than most, for two reasons.

The first is reach. South America is home to hundreds of millions of people who live on their phones, and until now every one of them was a long way from any Skapi project. That distance showed up in your business as slower pages, abandoned forms and users who quietly gave up. With São Paulo, your product can reach them properly. It loads faster, it saves faster, and it feels like it was built for them, because now it runs right next to them.

The second is cost. Running a traditional server backend on AWS in South America is expensive, noticeably more so than the same servers in North America or Europe, and that cost alone has kept many teams from serving the region well, or at all. We made sure a Skapi project in São Paulo runs at a fraction of that price. Making that possible was a real challenge for us, and it took a lot more than flipping a switch. That story deserves its own space, so we will cover it in the next article.

So: create a project, choose São Paulo, and let your Brazilian and Latin American users feel what their applications were capable of all along.

Bem-vindos a bordo. Bom desenvolvimento, e até breve.

Skapi 2.0 Is Out: Private Data Encryption, API Streaming, and Safer Backend Requests

Skapi — Mon, 07 Sep 2026 09:54:02 +0000

Skapi 2.0 is out

The stable tag has moved: npm i skapi-js installs 2.0 today. Private records can now be encrypted in the browser, under your user's own password.

npm i skapi-js

In August that command still installed 1.8.3, and we said nothing you were running would change until you asked for it. This is you asking for it. If you are not ready, npm i skapi-js@1.8.3 keeps you exactly where you are.

The release candidate post covered the naming, the polling queues and the session storage work. This one is about what landed on top of them.

Private records can be encrypted in the browser now

new Skapi("<Project ID>", { encryption: true }) encrypts the data of every record you write to access_group: 'private', and the contents of the files attached to it, before any of it leaves the page. The key is derived from the user's own password and never leaves their device.

const skapi = new Skapi("<Project ID>", {
    encryption: { iterations: 600000, minPasswordLength: 12 }
});

await skapi.postRecord(
    { diagnosis: 'confidential' },
    { table: { name: 'notes', access_group: 'private' } }
);

The calls do not change. postRecord() seals, getRecords() opens, and there is no key for your end user to manage. Sharing is the call it always was: grantPrivateRecordAccess() wraps that record's data key to the recipient's published public key, so the owner does not have to be online when the grantee reads, and removePrivateRecordAccess() rolls the data key, which makes revocation forward only.

Skapi has always decided who may read a record, on the server, against a signed identity the browser cannot forge. What is new is that the bytes stop being readable by the people running the database. In the words our documentation uses: a provider who dumps the database, the storage bucket and every request log cannot recover that record's data without a successful offline guess against the user's password.

An API response can render while it is still being written

clientSecretRequest() now takes stream: true and onStream(chunk, seq, via). The server reads the destination's response incrementally and relays the raw bytes as they arrive, so your page renders an answer while the destination is still writing it. Add realtime: true and each piece also comes over skapi's websocket the moment it is relayed, instead of on the next poll tick.

skapi.clientSecretRequest({
    clientSecretName: 'openai',
    url: 'https://api.openai.com/v1/chat/completions',
    method: 'POST',
    headers: { Authorization: 'Bearer $CLIENT_SECRET' },
    data: { model: 'gpt-4.1', stream: true, messages }, // the destination's own flag
    stream: true,    // skapi's flag: relay the answer as it arrives
    realtime: true,
    poll: 1000,
    onStream: (chunk, seq, via) => readEvents(chunk)
});

Your key still never reaches the browser: $CLIENT_SECRET is filled in on the server as the call goes out. Skapi parses nothing, so the framing and the buffering of a chunk that ended mid frame are yours, which is why this works against any destination on day one rather than only the ones we know about. The websocket is an accelerator and never the source of truth: a dropped socket is not an error, and the read continues at poll speed.

One trap. stream says how skapi reads the response; asking the destination to produce one incrementally is a separate flag in your own request body. Skapi inspects neither, so setting only one of the two goes wrong quietly, with no error from either side.

forwardRequest is the method we promised and never named

The release candidate post said 2.0 had one genuinely new method, then no section ever said which. It is forwardRequest().

skapi.forwardRequest({ question: 'How did last quarter go?' }, {
    url: 'https://api.yourbackend.com/chat',
    onStream: chunk => output.textContent += chunk
});

It relays a request to your own backend from skapi's servers and streams the response back, with your project's API key attached server side where the browser cannot read it. Your backend also receives x-skapi-user, taken from the verified session, and a request that tries to set an x-skapi- header itself is rejected, so that attribution is safe to trust. The first argument can be a submit event, a form element, a FormData or a plain object, and a form goes as multipart/form-data with its files.

Your backend has to resolve to a public address, so private ranges, loopback and cloud metadata addresses are refused. The destination instructions ride in a header capped at 4096 characters measured after escaping, where each non-ASCII character costs six, so put anything long in the body. And there is no re-attach call for this one: the response is yours once, as it arrives.

Three things to know before you upgrade

Your data is stored as JSON text, and the SDK is the only decoder. The API encodes it on every write regardless of which client wrote it, so an older SDK reading one of these records gets the raw encoded string instead of your object, quietly, with no error. The test is one line: a data you expected as an object that reads back as a string beginning !J% is this. If a project has more than one client on it, a mobile build, a Node worker, a REST caller, upgrade them together.

Two changes ship with the API rather than the SDK, so they are already true for you. Moving a record into or out of 'private' clears every private access grant on it, encryption or not, so grant those users again after the move. And only a record's owner may cross that line: a master account still reads, edits and deletes anything in its project, but it can no longer move somebody else's record between 'private' and a numbered group, because with encryption in play that would destroy the record while reporting success.

Four small changes arrive whether you ask or not. skapi.util.decodeServiceId() is decodeProjectId(), with no alias. table: 'name' on an update no longer moves that record to the public access group, so pass table: { name: 'name', access_group: 0 } if you wanted the move. deleteRecords() returns normalized records, so read record_id and table.name rather than the old short keys. And data: null stores a null instead of removing the field.

Everything else waits to be asked for, including the new require_login project setting, read from getConnectionInfo() as conf.require_login. It makes the SDK refuse record reads from a signed out session: a guard rail against a page leaking your public records by accident, not an access control, since the API still serves access_group: 0 to anyone who asks.

One correction while you have the changelog open. condition: '<=' on a string index value as an "ends with" search is a 1.8.0 change, not a 2.0 one, and the API serves it, so it already works from whatever version you are running today.

The bugs we could not have found on our own

None of the fixes in that data section came from reading our own code. A string containing *add destroying a record is not something a test suite finds: somebody has to be storing a sentence a real person wrote, in a real app, before the storage format ever gets the chance to misread it.

So thank you to everyone who put a project that mattered to them on a release candidate, kept skapi-js@rc installed while it settled, and wrote in with the boring exact detail: the record id, the payload, the call that came back wrong. That is the part of 2.0 we could not have written ourselves.

Encryption is the first place where Skapi holds something it genuinely cannot read, and widening that is where the next stretch goes. data is sealed and index.value is not, because a range read over ordered keys is what keeps a schemaless query cheap. Protecting what you query on without losing the ability to query it is a hard question, and we are not going to answer it badly.

There is one more thing your backend does not have now. A copy of your users' data it can read.

Go build with Skapi, and let your users keep their own keys.

The Fastest Way to Deploy a Site in 2026

Skapi — Thu, 11 Dec 2025 08:01:39 +0000

“Most developers don’t need a backend. They need a fast way to launch.”

By the end of 2025, the question many developers ask is no longer how to design a website or structure a backend. The question has become much simpler and far more urgent: What is the fastest way to deploy a site?

Time to launch has become a key competitive factor for indie developers, small teams, and even established engineers who want to move faster without getting caught in configuration loops and infrastructure overhead.

This article explores that question through the lens of Alex Lee, an early-career developer who has already grown tired of unnecessary complexity, juggling tools, and backend setup. His experience reveals a shift happening in the industry, and why platforms like Skapi are quickly becoming the fastest and most reliable way to deploy a site with zero configuration and no backend work.

The Development Pain Point Alex Can’t Ignore:

Alex Lee, a developer with two years of experience and a full-time job, decided to work on side projects he genuinely enjoyed. He was excited to get started, but quickly ran into problems he never expected.

His idea was clear, the frontend code was ready, and the user flow was straightforward. He wasn’t building a large-scale SaaS platform or a complex distributed application. He just wanted to deploy a clean, static site – a ticket pre-sale platform for his favorite music band – with a few simple functional components: email handling, a form submission endpoint, and some basic state storage.

Sounds simple, right? Looks even simpler:

Yet deploying that site turned into a cycle of dashboards, configs, environment variables, SSL settings, file structures, and DNS delays. What should have taken minutes routinely took hours. For an early-career developer, the complexity felt disproportionate to the goal.

This frustration is increasingly common, and it reveals the core of a major trend: developers want the fastest possible way to deploy a site without touching backend infrastructure at all.

The Search for the Fastest Way to Deploy a Site

In exploring options, Alex tried several of the popular hosting and deployment tools that have defined the industry over the past few years. Each one promised simplicity. Each one advertised speed. Yet most of them came with underlying complexity that slowed down the process:

build configurations
routing files
backend functions that required separation
authentication that needed setup
email APIs requiring external providers

Too much for a developer whose project did not require this level of machinery.

Alex realized the actual question was not What hosting tool should I use? but rather:

Why does deploying a small, functional site still require thinking about backend infrastructure at all?

And this is where Alex found Skapi.

A New Approach: Zero-Backend Deployment

Skapi stood out immediately because it answered the one question that mattered:
How fast can a developer deploy a site without touching backend configuration?

Alex discovered that Skapi’s architecture does something different from traditional hosting platforms:

It hosts static sites instantly through a simple file-drop interface. index.html becomes your root entry point. Files are served instantly through global CDN.
It removes the backend setup entirely.
It provides automatic email handling and newsletter flows.
It supports authentication without configuration.
It includes built-in storage and database-like record handling.

In other words, Skapi collapses multiple layers of development work into a single environment that requires no manual setup. For a developer trying to deploy a side-project, it represented exactly what the industry has been moving toward: the fastest way to deploy a site with AI-assisted backend logic and zero configuration.

“Skapi let me deploy my project without touching any infrastructure at all.”

Deploying the Side-Project: A Faster Workflow

Alex’s deployment process shifted dramatically once he tried Skapi.

The steps became straightforward:

Prepare the frontend folder.
Drag files into Skapi’s File Hosting.
The site is live instantly.

There were no DNS tasks, no build steps, and no backend endpoints to configure. Alex was able to add a form submission flow with Skapi’s built-in API handling. He integrated email automation without any third-party providers. He added basic data storage without provisioning a database.

This workflow matched exactly what many developers search for. When someone types the fastest way to deploy a site or how to deploy a website quickly, they’re not looking for server diagrams or configuration tutorials. They want a process that lets them build and deploy without obstacles.

Skapi delivered that experience by treating backend complexity as optional rather than required.

The industry is changing. Backends will always matter for large-scale systems, but most modern projects: side-project apps, landing pages, prototypes, microtools, and personal products do not require full backend environments.

This gap between actual requirements and traditional infrastructure has opened the door for tools like Skapi to reshape deployment workflows entirely.

Happy Alex’s Conclusion

Alex’s search for the fastest way to deploy a site ended not with a new tool to configure, but with a different approach to development itself. Skapi provided a clear path where the friction of backend setup disappeared, leaving space for building, refining, and launching a real side-project in a fraction of the time.

The fastest way to deploy a site in 2026 is to use tools that eliminate backend work entirely. For anyone searching for the quickest and most effective deployment workflow, the answer is becoming clearer each year: choose the tools that let you build without barriers.

In that landscape, Skapi is quickly emerging as one of the strongest options.

Vibe coding ultimate beginner tutorial 2025

Skapi — Fri, 28 Nov 2025 09:03:07 +0000

We’ve binged a ton of YouTube videos about vibe coding so you don’t have to. Here’s the basic workflow most vibe coders use, but if you don’t care about all the theory and just want an easy way to get a beautiful, working design, keep reading. We’ll give you an ultimate guide using only two tools to make your project good, fast, and free.

This is what tech bloggers usually do to build a “vibe-coded” website:

Hunt for references on Pinterest.
Ask an AI to generate unique images based on those references.
If they want extra flair, they add animations and interactivity in AI tools.
In a website builder, they describe the idea and build it step by step. Right now, Lovable and Bolt are the big names. If you already know some coding and don’t mind paying a subscription, a lot of people go with Claude Code.
Build backend logic and webhooks without traditional programming. n8n is the trendy choice for that right now.
Connect the website to a custom domain and publish it using a hosting service.

Sounds like a lot, right? Not very “vibe.” And imagine how much you end up paying for all those tools and subscriptions.

We’re going to save your time and your wallet, and show you how to do it in a short, fast, ultimate way using only AI and one smart tool (Skapi - as you’ve probably guessed already).

Our project concept is an online pre-sale platform for a concert, where people can sign up and join a waiting list to be the first to know when tickets go on sale, and get the earliest chance to buy them.

Even though we’re an IT company and know what we’re doing, for the sake of the experiment this project was built by our marketing manager, not a developer. If a marketing girl can do it, you can absolutely do it too.
So if you’re ready - let’s get started.

Looking for references

First things first - we want a pretty, stylish website. But let’s be honest, we’re not designers, right? So we head over to Pinterest and search for “band website”.

I literally grabbed the first one, because we don’t need any special functionality from the design. The AI will take care of that for us. And honestly, I chose this one because it’s Joy Division. Enough said.

Backend in a minute

Next, let’s go to Skapi. Create an account and start a free trial service. If you need help, you can find the full walkthrough here, but honestly, it’s straightforward even without instructions.

After clicking “Create,” you’ll land on your service page. That’s where you’ll see your backend credentials.

Download SKAPI.md file and copy the prompt. It already contains your credentials.

Give the prompt to AI

Now let’s jump into Lovable. That’s our tool of choice for this project, because it lets us visually tweak sections of the site and then download the generated code.

Here’s the prompt I’m using, and when sending it, don’t forget to attach SKAPI.md file and the reference picture:

Use the file "SKAPI.md" as a system prompt.
My Skapi service ID is: [YOUR CREDENTIALS HERE].
Build me a website for Joy Division. A PNG reference is attached.
Adapt it into an online pre-sale platform for a concert tour, where users can subscribe to a newsletter and join a waiting list to be the first to know when tickets go on sale and get early access to buy them. Send users a confirmation email using Skapi’s newsletter feature.

Here’s the functionality Lovable generated from my prompt:

Newsletter subscription via Skapi — visitors can enter their email and instantly join the waitlist
Email confirmation flow — users receive a confirmation email and must verify their address
Success handling — automatic redirect after successful verification
Tour information — clean layout with stats and pre-sale details
Fully responsive design
Skapi initialized in index.html using my service ID
Uses subscribeNewsletter() with group: 'public' for public newsletter subscriptions
Automatic confirmation email sent through Skapi
Redirect URL for after the user verifies their email

Testing ready website

Now let’s test it. We can do everything directly from Lovable’s preview.
And yes, it works. I entered my email and immediately received the verification link.

Customize your email
You can customize all automated emails directly in your Skapi My Services Dashboard.

Here’s a quick DIY walkthrough:

Open the Automated Emails section.
Create a new entry, give it a name, and register it.
Copy the generated email address (the one highlighted in red).
Open your regular email provider - Gmail, Outlook, whatever you use.
Write the email you want your users to receive and send it to that copied address.

That email becomes your template for the signup confirmation message. From now on, users will receive your version instead of the default one.

Deploy your website

Now, back to our Joy Division website.

The final step is deployment — and here’s the good news:
You can handle everything right inside Skapi, without hunting for third-party hosting or paying extra.

Here’s how:

Go to Skapi and open File Hosting from the left dashboard.
Create a new domain by choosing a name and clicking Register.

Next, head over to Lovable:

Click the GitHub button and connect your GitHub account to create a repository.
If it’s your first time, just follow Lovable’s guided steps.

Once the repo is generated, Lovable will give you a link, open it on GitHub and download the code as a ZIP file.

Inside the ZIP, locate your dist folder (you’ll need to build it through your Terminal) - that’s the production-ready build.

Go back to Skapi → File Hosting and upload all the files from the dist folder.

And that’s it - your Joy Division pre-sale site is live! You can check our version here: https://joydivision.skapi.com/

It’s honestly incredibly fast and simple. And if you want to go further, you absolutely can. You can ask the AI to build a full user dashboard showing upcoming tour details, their position in the waiting list, login/signup flows, and even an admin panel with restricted access so you can manage users and send notifications. Or you can push the design in a more complex or artistic direction.

With this setup, pretty much anything is possible.

You can also skip Lovable entirely and ask ChatGPT to generate the HTML code for you. But keep in mind that if you need visual changes later, raw code isn’t nearly as flexible if you don’t know how to code. Most AI models will regenerate the entire page, which often breaks everything you already built. That’s why a visual AI website builder is usually the more practical choice.

I hope you enjoyed this walkthrough. If you have any questions or need help while following the guide, let us know in the comments or send us an email at support@broadwayinc.com.

And remember: Skapi gives you a single, unified backend you can reuse across every AI-built project.

Whether you build in Lovable, Bolt, Claude, Cursor, or raw HTML, your backend remains stable, portable, and easy to understand.

How Skapi Helped Me Finally Get a Raise with Just 15 Minutes of Code

Skapi — Fri, 14 Nov 2025 10:10:39 +0000

A few weeks ago, my boss asked me to go through a huge stack of resumes to help shortlist candidates. It sounded simple until I realized just how many there were. I spent hours reading through pages, trying to pick out key skills and relevant experience. It was exhausting.

So instead of getting buried in paperwork, I did what developers do best, I automated the process.

The goal was to build a resume summarizer app that could generate short, clear summaries using AI. Since I'm a Skapi user, a serverless backend that makes things ridiculously simple, I figured it was the fastest way to pull this off.

In less than 15 minutes, I had a fully functional web app running on plain HTML and JavaScript, powered by Skapi for authentication and data handling, no server setup, no database stress.

The result? A clean AI-powered tool that saved hours of manual work and made me look like a productivity hero. My boss was impressed, and let’s just say it paid off in the best way possible.

[Frontend] ←→ [Skapi] ←→ [Google Auth + Gemini API]

Here’s what we’ll cover in this guide to achieve the screenshot above:

Google Login – implemented with Skapi’s OpenID (no backend code required).
Gemini AI Integration – to generate smart, professional resume summaries.
Skapi Records – to securely save and fetch summaries for each logged-in user.

And the best part? It all runs entirely on the frontend no backend servers required.

By the end of this tutorial, you’ll see exactly how our “15-minute experiment” ended up impressing the boss enough to get me a raise.

Core Implementation: The Magic Pieces

Step 1: Skapi Setup

1.Head to Skapi.com and create an account.
2.Once logged in, create a new service in your Dashboard.
3.You’ll find there your unique Service ID
4.Add it to your frontend script:

const skapi = new Skapi("SERVICE_ID");

These IDs connect your frontend directly to Skapi’s secure backend with no custom server setup required.

Step 2: Configure Secrets in Skapi
In your Skapi Dashboard → Client Secrets, add two secrets:

1.Google OAuth Client Secret

Name: ggltoken
Value: Your Google OAuth Client Secret from Google Cloud Console

2.Gemini API Key

Name: GEMINI_API_KEY
Value: Your Gemini API key from Google AI Studio

Skapi securely stores these secrets and injects them automatically when using clientSecretRequest() — meaning your frontend never exposes sensitive data.

Step 3: Set Up Google OAuth

Go to the Google Cloud Console:

Navigate to APIs & Services → Credentials
Create a new OAuth 2.0 Client ID
Set Application Type to Web Application
Add your redirect URL (e.g., http://localhost:5500/) under Authorized redirect URIs
Copy your Client ID and Client Secret
Add your GOOGLE_CLIENT_ID to the script:

const GOOGLE_CLIENT_ID = "YOUR_GOOGLE_CLIENT_ID";
const CLIENT_SECRET_NAME = "ggltoken";
const OPENID_LOGGER_ID = "google";
const REDIRECT_URL = "http://localhost:5500/";

Step 4: Google Login Flow

Integrating Google OAuth

A. Redirect User to Google

function googleLogin() {
  const state = Math.random().toString(36).slice(2);
  let url = "https://accounts.google.com/o/oauth2/v2/auth";
  url += "?client_id=" + encodeURIComponent(GOOGLE_CLIENT_ID);
  url += "&redirect_uri=" + encodeURIComponent(REDIRECT_URL);
  url += "&response_type=code";
  url += "&scope=" + encodeURIComponent("openid email profile");
  url += "&prompt=consent";
  url += "&access_type=offline";
  url += "&state=" + encodeURIComponent(state);
  window.location.href = url;
}

B. Handle the Redirect and Log In Securely

async function handleRedirect() {
  const params = new URLSearchParams(window.location.search);
  const code = params.get("code");
  if (!code) return;
  // Exchange auth code for tokens securely via Skapi
  const tokenResp = await skapi.clientSecretRequest({
    clientSecretName: CLIENT_SECRET_NAME,
    url: "https://oauth2.googleapis.com/token",
    method: "POST",
    headers: { "Content-Type": "application/x-www-form-urlencoded" },
    data: {
      code,
      client_id: GOOGLE_CLIENT_ID,
      client_secret: "$CLIENT_SECRET", // Skapi injects this securely
      redirect_uri: REDIRECT_URL,
      grant_type: "authorization_code",
    },
  });
  const accessToken = tokenResp.access_token;
  // Use OpenID login with the returned token
  await skapi.openIdLogin({
    id: OPENID_LOGGER_ID,
    token: accessToken,
  });
  const profile = await skapi.getProfile();
  console.log("Logged in user:", profile);
}

Refer to this for more insights Google-OAuth-Example

Skapi’s clientSecretRequest() handles the token exchange securely — the client secret is never exposed in your code.

Step 5: Summarize Resumes with Gemini

Once the user logs in, they can paste their resume text and summarize it using Gemini:

summarizeBtn.addEventListener("click", async () => {
  const text = resumeText.value.trim();
  if (!text) return alert("Please paste your résumé text first.");
  const response = await skapi.clientSecretRequest({
    clientSecretName: "GEMINI_API_KEY",
    url: "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash-lite:generateContent",
    method: "POST",
    headers: { "Content-Type": "application/json" },
    params: { key: "$CLIENT_SECRET" },
    data: {
      contents: [{
        role: "user",
        parts: [{ text: "Summarize this resume in 5 bullet points:\n\n" + text }],
      }],
    },
  });
  const summary = response.candidates?.[0]?.content?.parts?.[0]?.text;
  console.log(summary);
});

And retrieving past summaries:

const records = await skapi.getRecords({
  table: { name: "resume_summaries", access_group: "private" },
  limit: 10,
});

The access_group: "private" setting ensures that only the logged-in user can access their own data.

Step 7: Putting It All Together

Here’s the simplified flow:

User clicks Login with Google
Google redirects back → Skapi securely exchanges tokens
User pastes resume text
Gemini API summarizes it
Summary is saved securely to the user’s private database

What You’ve Built

Secure Google Authentication using OAuth and Skapi
AI-Powered Summarization with Gemini API
Private Data Storage per user in Skapi’s database
100% serverless and frontend-only implementation

This combination lets you build production-ready apps without deploying your own backend.

You can find the whole project in our GitHub.

When Telegram Cocoon Goes Live: The Future of the AI Internet

Skapi — Fri, 31 Oct 2025 09:39:35 +0000

At Blockchain Life 2025 in Dubai, Telegram CEO Pavel Durov unveiled Cocoon (Confidential Compute Open Network) — a decentralized AI compute network built on The Open Network (TON).

Cocoon will allow GPU owners around the world to contribute computing power for AI inference and get rewarded in Toncoin (TON). Telegram itself will become Cocoon’s first large-scale user, integrating this technology into its Mini Apps and AI tools for its billion-plus users.

Cocoon in a Nutshell

Compute: Decentralized AI tasks running securely across a distributed network of GPUs.
Incentives: GPU miners are rewarded in TON for powering these computations.
Privacy: Data remains encrypted end-to-end — even from the machines processing it.
Goal: To challenge centralized AI infrastructure monopolies like AWS and Azure.

Cocoon represents a privacy-first approach to AI infrastructure, aligning with Telegram and TON’s shared vision of user-owned digital freedom.

The Core Problem of Cocoon

While Cocoon decentralizes AI compute, building real applications requires much more than inference.

Developers still need to:

Handle user authentication
Manage data persistence
Store and serve user-generated content
Host frontend interfaces
Securely connect all these components

Cocoon offers a distributed engine for AI workloads — but it doesn’t solve the data and logic layer that connects these models to real users and applications.

The Missing Layer of Decentralized Infrastructure

Telegram will be Cocoon’s first client, embedding it into its vast ecosystem of Mini Apps.

But as the network expands, developers and businesses will be the next wave of adopters.

To participate in that ecosystem — to build AI-powered apps that leverage Cocoon’s decentralized compute — you’ll need a backend that:

Manages your users securely
Stores their data without central control
Authenticates AI access and app permissions
Scales automatically as your app grows

That’s exactly what Skapi provides. Skapi provides a serverless backend for web apps, purpose-built for the privacy-centric future Cocoon is enabling.

Developers using Skapi get:

Authentication & identity: Secure user accounts without traditional servers
Databases: Structured data storage with private, encrypted access
File hosting: For AI models, assets, and user uploads
Zero DevOps: No configuration, no server maintenance, no central authority

Skapi already supports a decentralized approach to data: users own their data, and developers never need to expose it.

A New Web Stack for Decentralized AI Apps

It’s important to note that Cocoon doesn’t store user data — it only processes it securely.

That means your application still needs a trusted layer to store, recall, and protect user information before and after AI computation happens.

This architecture keeps every layer decentralized, private, and user-owned.

This is what we can start calling Private AI-as-a-Service (PAaaS) — a model where both compute and storage are user-owned and secured.

Developers Build AI Web3 Applications

With Cocoon and Skapi together, developers can finally build truly independent applications:

AI-powered bots that process private data without central servers
Mini Apps that run entirely on decentralized compute and storage
Full-stack businesses where both compute and data belong to the users

Think of Skapi as your bridge into Cocoon’s ecosystem — the part that allows you to manage your users, data, and authentication without betraying the principles of decentralization.

Because if your AI runs on a decentralized GPU network, your users still log in through a centralized database, you’re only halfway free.

That’s where Skapi bridges the gap, enabling developers to build full-stack decentralized apps that align perfectly with Cocoon’s vision:

An internet where AI is private, infrastructure is open, and ownership belongs to the user.

Let us know in the comments what's your vision of future Internet!

The Meme Game That Changed How We Build Secure APIs — Skapi’s Story

Skapi — Fri, 17 Oct 2025 09:54:16 +0000

How a meme app improved Skapi’s backend logic (and made our cat very happy)

It started as a joke.

We wanted to make a tiny web app called “Should I Feed the Cat?” - a pixel-art voting game where anyone could click YES or NO, watch the scores rise in real time, and decide the fate of a digital cat.

But that dumb little cat ended up exposing something much bigger: a flaw in how we handled public data submission.

The meme cat web app in question:

In the process, this little web application changed how Skapi, our secure backend platform, works.

The Problem: Login Walls vs. Public Data

Originally, Skapi was designed with strict security in mind.

Everything a user sent to the database had to come from a logged-in session. That made sense for apps dealing with sensitive or user-specific data, things like notes, messages, or private uploads.

But for our cat game, this was absurd.

Did we really need to force people to sign up and log in just to click “YES, feed the cat”?

The cat didn’t care who you were.
It just wanted food.

Yet our system said:

“postRecord(): Login is required.”

That was the moment we realized something was off. The world needed a way to collect anonymous, public data safely.

When Security is a Problem

“Should I Feed the Cat?” was supposed to be a lighthearted test of Skapi’s frontend integration.

We added:

Pixel-style cats (waiting, happy, dead)
Eye blinks and tear animations
Confetti explosions for 10,000 “YES” votes
Thunderstorms if the “NO” side wins

Each visitor could spam votes as much as they wanted.
It was chaotic, hilarious, and strangely addictive.

But when we deployed it, reality hit:
No one could vote unless they logged in.

The backend was doing its job — protecting data integrity — but in this case, the protection was the problem.

We wanted people to interact instantly and just have fun without login.

The Breakthrough: Public postRecord()

That’s when we realized something powerful.

We could safely open part of Skapi’s data system to public anonymous writes, without exposing user data or compromising backend security.

How?

By allowing the postRecord() method to accept submissions from unauthenticated users when writing to public tables.

Here’s how it looked like:

await skapi.postRecord({ nickname, choice }, {
  table: 'cat_votes_open',
  index: { name: `choice.${choice}`, value: 1 }
});

It’s easy to just let anonymous users post data to a backend, but doing it safely was the hard part.

We needed a way to ensure that anonymous users couldn’t access restricted tables or modify anyone else’s data.

Normally, Skapi enforces permissions using profile information from a user’s JWT token. But since anonymous users don’t have one, Skapi now generates a randomized, temporary security hash derived from each client’s public address.

Behind the scenes, Skapi also fully separates public tables from restricted tables, ensuring that anonymous submissions can only write new records but never edits or deletes existing ones. Each anonymous client is tracked as its own isolated device identity, allowing open participation without compromising data integrity or security.

That’s it. No login. No auth token. The cat finally got fed.

Under the hood, Skapi still handles all security:

Public tables are isolated from private ones.
No user data is exposed.
The backend validates every request.

Rate limits and data shape protections still apply.
In short — anyone can submit data, but no one can break the system.

Technical Key of Viral Web Apps

This isn’t just about a cat. It’s about lowering friction in web apps that rely on public engagement.

Think:

Polls & surveys
Comment walls
Feedback widgets
Micro games
Anonymous reactions

For all these, forcing logins just kills the vibe.
But letting the world interact freely, while keeping the backend secure, is how you make lightweight, viral apps that spread fast.

With this Skapi update, developers can now collect public, anonymous data safely.

That’s something few backends do right.

Secure vs. Accessible Web Application

Our little meme experiment revealed a gap between “secure” and “accessible.” And fixing it made Skapi better for everyone.

Now, anyone can use skapi.postRecord() to collect open data, whether it’s a public poll, an art project, or a crowdsourced idea board.

We built a cat game. The cat changed our API.

Try It Yourself

If you want to play (or feed the cat), you can check it out here: https://shouldifeedthecat.skapi.com/, or build your own version in minutes.

Here’s the minimal setup:

<script src="https://cdn.jsdelivr.net/npm/skapi-js@latest/dist/skapi.js"></script>
<script>
  const skapi = new Skapi("SERVICE_ID"); 
  async function vote(choice) {
    await skapi.postRecord({ choice }, {
      table: 'public_votes',
      index: { name: `choice.${choice}`, value: 1 }
    });
  }
</script>

That’s how a real backend logic with zero setup works.

Skapi vs Firebase vs Supabase: Choosing the Best Backend for Performance and Scalability

Skapi — Thu, 02 Oct 2025 10:33:15 +0000

Choosing the right backend service is crucial for the performance, scalability, and user experience of your application. From query response times to concurrent user handling and file upload speeds, your backend directly impacts how smooth, fast, and reliable your app feels.

Pick the wrong backend, and you risk getting locked into infrastructure that slows down your app, limits scalability, and frustrates users with lag and downtime. Pick the right one, and you’re set up for growth and speed from day one.

While Firebase and Supabase are popular backend-as-a-service (BaaS) platforms, their added complexity can introduce performance overhead. Skapi takes a different approach: offering speed and scalability out of the box.

In this article, we’ll compare Firebase, Supabase, and Skapi across three key backend performance metrics:

Query Response Times (basic and complex)
Concurrent User Handling (scalability under load)
File Upload Speeds (media-heavy app performance)

1. Query Response Times

Basic Queries:

Basic query response time is the foundation of backend performance. If it lags, your whole app feels broken, from dashboards to search results to profile loads.

Here’s the query we will be requesting to the backend:

Skapi:

skapi.getRecords({ table: { name: 'performance_test', access_group: 'public' } }, {limit: fetch_limit});

Supabase:

supabase.from('performance_test').select('*').limit(fetch_limit);

Firebase:

query(
  collection(db, "performance_test"),
  limit(fetch_limit)
);

We will do simple data fetching query testing with various ranges of fetch limits.

In benchmark tests, Skapi consistently outperforms Firebase and Supabase in basic query speed, making apps feel instantly responsive without extra optimization.

Complex Queries:

Complex queries such as joins, sorts, or aggregations, push systems harder. Firebase and Supabase tend to slow down as complexity grows, while Skapi maintains low latency even under demanding query loads.

Each service uses a different underlying database model:

Skapi: NoSQL with auto-indexing and client-defined access control
Firebase: NoSQL document store (Firestore) with structured indexes
Supabase: SQL/Postgres with schema-driven indexes

To compare, here are equivalent examples of range queries:

Skapi:

skapi.getRecords({
  table: { name: 'performance_test', access_group: 'public' },
  index: { name: 'test_index', value: 20, range: 60 }
})

Supabase:

supabase
  .from('performance_test')
  .select('*')
  .gte('data->test_index_value', 20)
  .lte('data->test_index_value', 80)

Firebase:

query(
  collection(db, "performance_test"),
  where("test_index_value", ">=", 20),
  where("test_index_value", "<=", 80)
)

Notes on Indexing and Joins
Index condition queries rely on conditional lookups using comparison operators (>, <, >=, <=) on indexed fields.

For more complex operations such as joins, sorts, or aggregations, the approach differs by platform:

Skapi: Supports indexed conditional lookups directly, but for multi-table relationships or advanced aggregations, data is typically fetched in ranges and then joined or aggregated on the client.
Firebase (Firestore): Works similarly - queries can filter indexed fields efficiently, but there is no native join support. Developers usually fetch multiple datasets and merge them client-side. Composite indexes must be explicitly created for more complex queries.
Supabase (Postgres): Can handle joins, sorts, and aggregations directly in SQL, but these operations are heavier on the backend. While powerful, they often introduce more latency compared to client-side merges, especially under load.

Result: Skapi ensures your app’s navigation, filtering, and data-heavy features remain fast and smooth, no matter the complexity.

2. Concurrent User Handling

Scalability isn’t just about spinning up more servers, it’s about maintaining performance under heavy load. Some backends choke as traffic scales.

In stress tests, Skapi’s backend architecture holds steady, delivering fast, consistent response times even with thousands of concurrent users. This makes it ideal for apps expecting growth, viral traffic spikes, or global audiences.

Examples of concurrent test:

// Sends multiple requests simultaneously
const promises = [];
for (let i = 0; i < concurrentCount; i++) {
  promises.push(
    skapi.getRecords({
      table: { name: 'performance_test', access_group: 'public' }
    })
  );
}
await Promise.all(promises); // All execute at once

With Skapi, you get true horizontal scalability, meaning your app grows seamlessly without compromising speed or user experience.

Notes on Concurrency

Skapi: Designed with serverless elasticity; concurrency scaling is handled automatically by the platform.
Supabase: Concurrency depends on underlying Postgres + connection pooling; under extreme load, queries may queue or slow down.
Firebase: Firestore handles a high degree of concurrent reads and writes, but performance can degrade if many clients hit the same document paths, since hot-spotting leads to throttling.

3. File Upload Speeds

For apps handling images, video, or large files, upload performance is critical. No user wants to stare at a stuck progress bar.

Firebase and Supabase can slow down significantly on large file uploads.
Skapi maintains consistently fast uploads across small and large files.

In fact, the performance gap widens as file sizes increase, making Skapi the clear winner for media-heavy apps, SaaS platforms, and social apps.

How the Tests Were Conducted

To ensure a fair and transparent comparison, each test followed structured benchmarks:

Basic Query Test: Measured how quickly backends respond to simple database queries (profile loads, product lists, or recent posts). Average, min, and max response times were recorded, with success rates checked for 100% delivery.
Complex Query Test: Ran 16 variations across 8 categories, including index lookups, range queries, tag searches, sorting, aggregations, and multi-filters. Data sets included realistic fields like price, rating, category, and tags.
Concurrent User Test: Simulated loads from 5 to 100,000 simultaneous users, measuring how response times and success rates held up under spikes (such as flash sales, viral content, or product launches).
File Upload Test: Uploaded files from 1KB to 1GB, tracking average speeds and time-to-completion. These mirrored real-world use cases such as profile images, PDFs, audio, and full HD videos.

All tests were repeated multiple times under identical conditions to rule out anomalies. Data sets were auto-cleaned after runs to ensure fair results.

Why Skapi Wins on Performance

Across all three categories - query response time, concurrent user handling, and file uploads, Skapi outperforms Firebase and Supabase.

The key technical advantages that set Skapi apart are:

Fully serverless infrastructure: elastic scaling without servers to deploy or manage
NoSQL with unique indexing: optimized for high-speed lookups and range queries
Direct client-to-backend access: no middle-layer bottlenecks slowing things down

By choosing Skapi, you’re building on a backend that guarantees speed, scalability, and responsiveness from day one.

Final Thoughts: Skapi vs Firebase vs Supabase

If your app’s success depends on speed, scalability, and user experience, Skapi is the backend built for you. While Firebase and Supabase are solid options, their overhead can slow you down as your project scales.

Skapi delivers performance superiority across the board, ensuring your app stays fast, reliable, and scalable, whether you’re building a social media platform, SaaS product, or media-heavy mobile app.

In short: With Skapi, there are no delays, no bottlenecks, and no compromises, just the backend performance your project deserves.