Introducing the Scale Plan

Hello all,

Backendless Cloud pricing is undergoing a change. In order to provide pricing that better reflects resource consumption, we will be transitioning to a tiered pricing model based on daily API call usage.

Read the full details of the change here.

Under the new pricing system, described in detail in our article below, there will be a single paid cloud plan called the Scale Plan. The Scale Plan has starting limits equal to the current Cloud 9 plan, with pricing starting as low as $15 per month and increasing as you scale.

Scale Plan pricing is based on the daily peak API requests per minute. To review your API usage and view estimates of what your app would have cost historically under the new system, visit Backend > Manage > Analytics.

For some paid users, pricing will remain relatively the same as under the previous model. For others, pricing will change dramatically. If you fall into the latter category, we’ve launched improvements to Backendless Pro that you’ll find very exciting (discussed later in this post).

To give you time to adjust, the fixed-price Cloud 9 plan will remain available for existing apps until August 1st, 2023, and the Cloud 99 plan will remain available until May 1st, 2024.

Additionally, with this change in pricing philosophy, we are also adjusting how you are able to access the platform for free.

First, we are introducing a new Free Plan, which is designed primarily for initial exploration of the platform, completing Missions, and following along with our video courses.

New apps will no longer begin on a free trial of the Cloud 99 plan, but will instead begin on the Free Plan. You may have up to five apps on the Free Plan on your account.

The Springboard Plan will be transitioning out at the end of 2023. We recommend that users with apps in the development stage use the new Scale Plan during development as it provides ample features and allows for a smooth transition to publication, all at a nominal cost.

For more details on all of the changes, please read our article here. There we explain all of the changes and our reasoning behind them.

To further help you understand the changes, we will be hosting an open webinar this Wednesday, May 24th at 11:30 AM CST (GMT -6).

Register Now

We invite you to join and hear all about the changes, then share your thoughts and questions with our team here on the support forum.

Introducing Backendless Pro Manager

Backendless Pro is the Limitless Edition of the Backendless platform.

With Backendless Pro, you can install the Backendless platform on your own servers - on premise or in the cloud - to build and deploy with no functional limits whatsoever.

Previously, getting Backendless Pro up and running practically required a computer science degree, but not anymore. With Backendless Pro Manager , setting up your own Pro installation is easier than ever.

To help you see how the process works, we’ve released three video tutorials for installing Backendless Pro on popular cloud hosting services: Amazon Web Services, DigitalOcean, and Microsoft Azure.

We’ll add more examples in the future. Let us know if there’s a provider you’d like us to demonstrate with below.

Check out the new Backendless Pro pricing page to view pricing and better understand the benefits of going Pro.

If you have questions or comments about the changes, please share them below and we’ll do our best to address them all.


My preliminary studies were wrong !
I realized my access control system (3 years of development) is no longer profitable due to the new Scale Plan.
The cost changed from US$35 + US$10 (more records) to US$550,40.
Only during weekends with almost no visitors I’m in Tier 6 (US$ 127,50 monthly)
This chart shows the number of visits per month, it’s a small business of 600 employees.

Please let me know if someone can help me to adapt my coding to this new processing fee.

Thanks, Mario


Another question…
I found my Tiers and check with my API calls and found no clue what happened because some days are critical how to check the by minute factor?

Same 30 days the average 1700 API calls only in 4 days for the Tiers.

My operation is only access control of 600 persons per day.
It can’t cost US$1 per person the database we must find the problem and back to US$35.- (US$ 0,06 / person)

Thanks, Mario

I will wait the Optimization webinars to check if I can save my business.

Thanks for the new conference today, Mario

1 Like

Hi Chris,

It would be very useful if the team could provide a tool to see exactly which API calls are counting towards the scale plan. For example, is it only client API calls? Do push notifications count? Does server code API calls count?

It will be very difficult for us as developers to see which API calls are coming through, and therefore optimise the API calls in our apps, if there is not tool to list out the actual API calls themselves. For example in my app I have a vast array of calls to different database tables which are all triggered from different user interactions. It is basically impossible for me to predict the API usage without better tools to analyse historic data.

I am very concerned that moving forward I will have no way of optimising API calls in my client iOS app. Can you please have a tool that lists:

    1. API call type and description. For example, see the below code:
let queryBuilder = DataQueryBuilder()
            queryBuilder.setWhereClause(whereClause: "revenueCatID = '\(purchaserInfo.originalAppUserId)'")
            print("Backendless pro user - checking object ID")
            let dataStore ="ProUsers")
            dataStore.find(queryBuilder: queryBuilder, responseHandler: { foundUsers in
                if !foundUsers.isEmpty {
                    let data = foundUsers as [[String:Any]]?
                    objectID = data?.first?["objectId"] as! String
                    print("Backendless pro user: \(objectID)")
                    userExists = true
                }else {
            }, errorHandler: { fault in
                print("Error: \(fault.message ?? "")")

The proposed tool should return something like "Database query to table “ProUsers” using whereClause ““revenueCatID = ‘(purchaserInfo.originalAppUserId)’””

i.e. show me information that is specific to that particular API call so that I can correlate usage shown in the dashboard with calls within my iOS app

  1. The tool should be integrated into the current “performance” tab of the app dashboard i.e. alongside where the projected usage is currently shown

Without a tool like this I have a lot of concerns that I will not be able to keep control of my costs. Surely there are records on the backend of what API calls were made, please consider a tool to make these user facing.

Thank you


I think that a pay as you go pricing is the right model to customize the price according to the use of each application.

But here, if I understand correctly, an application that consumes 10 requests per minute all day will cost less than an application that consumed 11 requests for a single minute even if the other 1439 minutes of the day have no requests ?

If so then I don’t think the price fairly reflects the consumption of server resources.

Thank you.


Quick question about API calls and “file downloads” — in our analytics, we have nearly a million (!) file download events, even though our app doesn’t have any such feature (there’s nothing to download for anyone). I suspect these API calls are happening when we fork a container. Can someone confirm? If it’s the case that copying files/containers produces super high spikes in “API calls per minute” during a day, is there a way to mitigate this? Thnx

1 Like

Any time you retrieve a file from the Backendless file system, it is counted as File Download API. Moving your UI app (I assume it is created with Ui Builder) to a separate web host) is a simple solution to avoid these calls being counted. Any app created with UI Builder is decoupled from the server-side by design. This means the UI can be hosted anywhere.

Would love to learn more about this — is there a blog article or other description somewhere about how one moves a UI app to a separate web host?

It is as simple as zipping up the directory where you published your UI container to and moving the zip file to another web host.

I will write up a support topic to make these three steps as obvious as possible.

OK, thanks much… so is it true that forking a container can produce a massive spike in API calls for the minute or so when we do that? Or that publishing a container does that also? And/or maybe the same thing happens when we zip up the directory where we published our UI container? So for example: if we make some tweaks to our app in a container and then publish that, we trigger a few thousand file download APIs in a few minutes (placing us into tier 10 for the day)? Just trying to understand how publishing a container or cloning a container affects our costs on the new scale plan :grimacing:

Hi @Alex_Klein

No, when you are working with the Console you do not run any public API Calls because it uses a system API. It means when you work with UI-Builder Designer (including publishing) you do not do any API Calls as well as work with FilesBrowser (zip/move/create/etc) neither


1 Like

@vladimir-upirov ah great, thanks for the clarification! So in the chart for API calls for our app (Analytics part of manage app), we should just ignore the file download entries? Like this one:

Also, question about logging events… these also count as API calls? We have a lot, perhaps we should not be logging things so much:

No =)

Everything you see on the analytics screen is public API Calls, so they will be counted.

When you develop your UIBuilder app on the Backendless console it works with system API but when you open a preview it uses public API (appId/apiKey or custom-domain)

According to the “Batch log” you can configure log levels on the “Manage=>Log Management”,
For instance If you set “Error” log level all clients will send only errors to the server and ignore any lower logs

1 Like

OK, more questions :grimacing: : when someone visits a page, lots and lots of files are downloaded from Backendless just to make the page run, is that correct? And this is why moving the UI App to a different web host might make sense, if I understand correctly… Can you say roughly how many API calls are consumed by downloading various files from Backendless when a user visits a page, without any explicit data base queries? It is something like 100? Much less? Or even more? So when 10 users (or some bots) visit a page in the same minute, is it possible we rack up 1000 or so API calls in that minute? And if so, there’s no way to “optimize” our app in that regard, right? Sorry if my questions are dumb… not coming from the techie developer world :blush:

It will be as many API calls as many files are fetched from the Backendless servers.

Just a little comparison:

Cloud9 plan : 10,000,000 API calls for 35$/month.

Scale plan : 10,000,000 API calls for minimum 217$/month (assuming that the 10,000,000 requests are perfectly distributed among the 44640 minutes of the month).
Calculation details: 10 000 000/44640 (number of minutes in one month = 31 * 1440) = 224 api calls per minute. 224 is in the pricing tier 7 which is 7$ for the day. So 7$ * 31 = 217$/month.

In one year, we went from $25/month for Cloud9 to $35/month then to $217/month, an 868% increase.

I completely understand that the great work of Backendless must be valued at the right price, but there is still something that escapes me in the price system of the new Scale plan.

For me the new Scale plan is clearly not in favor of the Backendless user financially speaking. Maybe I’m wrong.

Yes, users that put the greatest strain on the Backendless infrastructure will be paying more for their service. However, in the past, those users were being subsidized by the many users that used nowhere near that level of resources. The change is not meant to “punish” heavy users, but rather to appropriately distribute the cost of resources based on the greatest level of usage.

Any “flat rate” plan will inevitably favor heavy users over light users. By switching to a consumption-based pricing system, light users, such as users still in the development stage, will be able to run their apps for less than before, while heavier users will pay the true cost of their app’s usage.

If the end result of this change is that users improve the efficiency of their apps and reduce strain on the shared cloud infrastructure, then this is a net positive to all users, big and small.

Hello @Chris_Fanchi,

Thank you for answering and for the explanation. I completely agree with you that heavy users have to pay more than light users. This is the purpose of a pay as you go pricing model. So here is my question.

With the Scale plan, an application that consumes 11 api calls in one day but all in one minute will cost more than an application that consumes 14400 api calls distributed evenly over the 1440 minutes of the day.

Is that correct ?

An application that consumes 11 API calls every minute within an entire day or even just for a single minute would cost $1.75 for that day.

An application that consumes 10 API calls every minute within an entire day or even just for a single minute would cost $0.99 for that day.

When there is a peak API/minute traffic in a 24-hour cycle, Backendless allocates additional resources to support that level of traffic. We do not know if there is going to be additional volume of the same kind, but we need to be ready to handle it. These additional resources (memory, CPU, cache, etc) stay around for 24 hours, as a result, the cost for that day is defined by its peak.

Hope this helps.