DEV Community: Skapi

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.

How to Create a Video Streaming Platform with HTML, CSS, JS, and Skapi

Skapi — Fri, 19 Sep 2025 09:02:16 +0000

These days, we all stream everything: movies, shows, random videos we find online. But the big streaming platforms often come with strict rules, changing algorithms, and sometimes even censorship.

For small creators, that can be exhausting. So many creators are taking a different path: building their own little streaming spaces. Smaller, more personal platforms where they can share what they want, connect directly with their audience, and stay in control over their content.

Building your own platform can be tough, especially when it comes to setting up the backend and database. In this guide, we’ll explain step-by-step so even beginners can follow along and create a working video-on-demand platform in a single afternoon.

Meet Skapi

Skapi is here to help you do it, taking away the stress of developing a web infrastructure and allowing you to focus on giving your viewers the best experience. Thanks to Skapi, a modern backend-as-a-service (BaaS), you can set up user accounts, video uploads, and content delivery using just HTML, CSS, and JavaScript. No servers, no complicated set up, just a few lines of code.

Getting Started

Connecting your project with Skapi is a very easy process. You can follow a step-by-step guide on how to do it in our No More Backend Setup: Launch Your App with Skapi in Minutes article.

Adding User Authentication

Every video streaming platform needs user accounts. Skapi makes this simple with built-in signup and login methods.

Signup Example


let parameters = {
  email: "user@email.com",
  password: "password", // Password must be between 6 and 60 characters.
  name: "User's name"
};

let options = {
  login: true // If set to true, users will be automatically logged in after signup.
};

skapi.signup(parameters, options)
  .then(res => u=>alert('Hello ' + u.name));

Login Example


let parameters = {
  email: 'user@email.com',
  password: 'password'
}

skapi.login(parameters)
  .then(user => window.href = 'welcome.html');

Once logged in, users can upload videos or view restricted content depending on your settings.

Uploading Videos

To upload videos and any other file, you can use the method highlighted in The Easiest Way to Add File Upload to Your Website article. But just as a quick example, here’s how to do it with a form:

<form onsubmit="skapi.postRecord(event, {
    table: {
        name: 'videos',
        access_group: 'public'
    })>
  <input name="title" placeholder="Video Title" />
  <input name="description" placeholder="Video Description" />
  <input name="video" type="file"/>
  <input type="submit" value="Submit" />
</form>

On submitting the form, your video will be uploaded to Skapi via the postRecord() method, making it instantly available to be watched.

Display Videos on Your Platform

Fetch all uploaded videos and display them in a simple gallery with HTML5 video tags.

<div id="videoGallery"></div>

<script>
async function loadVideos() {
  let videos = await skapi.getRecords({ table: 'videos' });

  const gallery = document.getElementById('videoGallery');
  gallery.innerHTML = videos.list.map(v => `
    <div>
      <h3>${v.title}</h3>
      <video src="${v.bin[0].url}" controls width="480"></video>
    </div>
  `).join('');
}

loadVideos();
</script>

This gives you a dynamic video feed — as soon as someone uploads a video, it appears for viewers.

Adding Premium Content

Sometimes you’ll want to control who can see your content.
When posting any type of record to Skapi, one of the config options is access_group. This is used to limit the visibility of the record, and is used as such:


let config = {
    table: {
name: string;
access_group?: number | 'private' | 'public' | 'authorized' | 'admin';  // Default: 'public'
}
};

The access_group config is optional and defaults to public if not specified. The possible settings are:

number: Integer from 0 to 99. Compares the record access requirement to the user profile access level. Only users with access levels equal or greater than the record’s requirement may see it. User's access level can be upgraded from the "Users" page in Skapi service dashboard.
private: Only the uploader is allowed to have access to the record. The uploader can give access to others.
public: Everyone can see the record. (Equivalent to number: 0)
authorized: Only people logged to the project may see the record. (Equivalent to number: 1)
admin: Only the admins of your service will be allowed to view this record. (Equivalent to number: 99)

Want to charge for videos or keep some content exclusive?

Set access_group: 2 to 4 for example, when uploading.
Now you have tiered content, all you need to do is charge to upgrade users accounts to higher tiers.

Subscriptions

Another important aspect of streaming is being able to subscribe to your preferred content creators. Using Skapi’s subscriptions system you won’t have to worry about designing a whole subscription pipeline. It’s all ready to be used.

When uploading a video, you can choose to make it available only to your subscribers, like this:

skapi.postRecord(videoData, {
  table: {
    name:'videos',
    access_group: 'authorized',
    subscription: {
      is_subscription_record: true
    }
}})

This will make it so that only users subscribed to the uploader will be able to see the video.
And to subscribe is even easier, just use the subscribe() method, like this:

skapi.subscribe({
  user_id: 'user_id_of_user_A',
});

And now you can have subscriber only content in your platform, allowing another type of exclusivity to your users.

That's it!

As you can see, Skapi empowers you to create a streaming platform with full user authentication, tiered content and subscriptions, all without writing a single backend line of code.

Simply connect your project to a Skapi service and you can start your own streaming platform today.

Build a Serverless FAQ Bot with Skapi + Vanilla JS (No Backend Needed!)

Skapi — Fri, 19 Sep 2025 09:02:05 +0000

I remember the first time I wanted to add a simple FAQ bot to a website. My plan was:

I’ll just throw the FAQs in a database, write a quick API… how hard can it be?

Spoiler: it turned into a mini backend project with hosting, endpoints, and authentication before I even wrote a single line of UI code.

So when I joined Skapi — a serverless backend for frontend developers, no coders, and anyone who wants to save their time on backend — the first thing that I did, I decided to see if I could build the entire FAQ bot with just frontend code.

And you totally can. In this tutorial, I’ll show you exactly how.

By the end, you’ll have a:

Serverless FAQ bot running entirely in the browser
Zero backend setup (Skapi handles the data for you)
Frontend-only guidance using plain HTML + JavaScript

Why Skapi Is Perfect for This

If you’ve ever spun up a backend just to store a few rows of data, you’ll appreciate this:

Serverless: No API endpoints or servers to maintain
Frontend-friendly: Works with plain HTML, React, Vue, anything
Data + Auth in one place: Store records, handle users, all from the browser

For this project, we’ll use it to:
1.Store FAQs in a Skapi table
2.Fetch them with getRecords()
3.Display answers based on user input

1. Setting Up Skapi

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Serverless FAQ Bot</title>
  <script src="https://cdn.jsdelivr.net/npm/skapi-js@latest/dist/skapi.js"></script>
  <script>
    // Replace with your real IDs from Skapi dashboard
    const skapi = new Skapi('your_service_id');
  </script>
</head>
<body>
  <h1>Serverless FAQ Bot</h1>
  <input id="questionInput" placeholder="Ask me anything..." />
  <button onclick="getAnswer()">Ask</button>
  <div id="answerBox"></div>
  <div id="faqList"></div>
</body>
</html>

2. Adding FAQ Data (One-Time Setup)

Here’s the fun part: instead of writing SQL or spinning up an API, you just run this once to store FAQs:

<script>
async function uploadFAQs() {
  const faqs = [
    { question: "What is Skapi?", answer: "Skapi is a serverless backend for your frontend apps." },
    { question: "Is Skapi free?", answer: "Yes! It has a free tier perfect for small projects." },
    { question: "Do I need a backend?", answer: "Nope. Everything runs in the frontend." }
  ];

  for (let faq of faqs) {
    await skapi.postRecord(faq, { table: 'faqs' });
  }
  alert("FAQs uploaded successfully!");
}
uploadFAQs();
</script>

It’s like having a mini Firebase, but simpler.

3. Building the FAQ Bot Logic

Now let’s make the bot actually answer questions:

<script>
async function getAnswer() {
  let userQuestion = document.getElementById('questionInput').value.toLowerCase();

  // Fetch all FAQs from Skapi
  let res = await skapi.getRecords({ table: 'faqs' });

  // Naive matching: find the first question that appears in user input
  let bestMatch = res.list.find(faq => userQuestion.includes(faq.question.toLowerCase()));

  document.getElementById('answerBox').innerText = bestMatch
    ? bestMatch.answer
    : "Hmm… I don’t have an answer for that yet.";
}
</script>

Yes, it’s basic string matching, but it works surprisingly well for FAQs.

4. Showing All FAQs

I like showing all FAQs below the search bar so users can browse manually:

<script>
async function showFAQs() {
  let res = await skapi.getRecords({ table: 'faqs' });
  let container = document.getElementById('faqList');

  container.innerHTML = "<h3>All FAQs:</h3>" + 
    res.list.map(f => `<p><b>${f.question}</b><br>${f.answer}</p>`).join('');
}

showFAQs();
</script>

5. What I Learned Building This

Skapi is stupidly simple: Adding data feels easier than copy-pasting it.
Frontend-only apps are underrated: For small tools, backend code is often overkill.

Final Thoughts

We just built a serverless FAQ bot in under 100 lines of code — no backend, no database headaches.

Skapi turned out to be the perfect tool for this:

Simple CRUD from the frontend
Scales without extra work
Free tier to experiment with
Easy and fast deployment using Skapi’s File Upload

If you’re a frontend dev who wants to ship full-stack features without writing backend code, Skapi is worth a look.

How to Link Records Without SQL: Skapi Makes It Easy

Skapi — Fri, 05 Sep 2025 08:15:27 +0000

Possibly the most important aspect of a relational database is that a record can reference other records in the same or different tables, allowing you to build a web of structured data. But setting up your own database, wiring primary key and foreign key constraints can be a headache, especially when you want to launch your app as soon as possible.

This is where Skapi can save you hours and hours of work. Using our top of the line API, you have access to a fully functional relational database. No more coding an entire database or setting a backend-server.

To start using Skapi on your project right now, follow this step-by-step guide and be ready to use our database and much more in just 5 minutes.

In our previous article, we gave you an overview of how to create and fetch some simple records and now we start to delve into some nuances of creating more complex data structures within Skapi.

Now, to illustrate let’s simulate a social media structure with posts and comments.

let data = {
    post: ‘this is my post’ 
};

let config = {
    table: {
name: 'Posts',
access_group: 'public'
}
};

let referenced_record_id;

skapi.postRecord(data, config).then(response => {
    reference_record_id = response.record_id;
});

Once the original post is created, Skapi returns its unique record_id. We’ll store this in the variable referenced_record_id. That ID now acts as the anchor for any related records, such as comments.

let commentRecord = {
    comment: ‘this is a good post’
};

let commentConfig = {
    table: {
        name: ‘Comments’,
        access_group: 'public' 
},

    reference: referenced_record_id
};

skapi.postRecord(commentRecord, commentConfig);

And like this, the comment is posted. As you can see, the reference property inside the config data is what governs the relationship between records.

You can easily fetch all data referencing the original post using the getRecords() method passing the reference property. Just like this:

skapi.getRecords({
table: { name: 'Comments', access_group: 'public' },
reference: referenced_record_id
});

With this powerful config you can build an intricate web of data without having to write any DDL code.

It’s like setting the foreign key without having to write any SQL, all is done automatically by Skapi’s top-tier backend API to deliver you high speed data transfers. You just focus on your app logic.