Can someone at Unity better explain the pricing of Unity Cloud Build (now 'Automation')

Unity Services
,
1

The way the new pricing is explained is very unclear and it seems like we may now be facing $1000s in costs per month vs something that used to cost less than $50. Can someone at Unity explain what subscriptions are actually needed to make cloud build work. Also - what happens with older builds under the previous model - do we start getting charged for all of those now? Do we need to start deleting previous archived cloud builds to not get charged for storage space on them. We are concerned that UCB / Automation has become something where we can count on a clear price any more and will just get a bill from Unity that might be lots more than we expected thus making it not useable.

It seems that over all cloud builds price has gone up multiple times under the new pricing. Previous it was $9 dollars per month per instance. Now it appears to be $15 for the instance (30 days * $0.50). The 0.14 per GB is an unclear number (is that per stored build, size of the project being built - what is that?? is that charged per month as the stored builds accumulate or what?)

Using an example of storing a build that is 1GB with 10 being built per day, that would be 300 gb after the first month and then 3600 gb after a year so does that mean on the first month we would be charged $42 and then $504 on the last month since there are more builds being stored? Please share how the math works on this, and how it is billed so we can understand if we are now facing $1000s of dollars to use this service per month where as before it was less than $50. Do we also need to extra for everyone that used to be able to access cloud build for free (the seat fee?). Thanks for any help on answering this.

Here’s what is said on the pricing page that I am referring to:

Free Tier
Basic DevOps Seats
Three (3) seats

Standard Compute (Build iOS, Android, Windows, WebGL)
200 Windows minutes

Storage
5 GB

Machine Concurrency
1 machine

Standard Pricing
(once Free Tier is consumed)
Basic DevOps Seats
Seats 4-15: $7 per seat
Seats 16+: $15 per seat

Standard Compute (Build iOS, Android, Windows, WebGL)
$0.07 / build min (Mac)
$0.02 / build min (Win)

Storage
$0.14 per GB

Machine Concurrency
Up to 3: $0.50 per machine/day
4+: $2 per machine/day

2

bump

3

Yeah the email they sent is very unclear but uses lots of terms, Unity creates so many new names for things at a regular clip it gets a bit ridiculous.

Are Unity Pro subscriptions no longer able to access Unity Cloud Build (now Unity Automation)?

Unity, stop writing content to developers that looks like it is to public markets. Just use regular speak please. Nobody wants to solve a jargon puzzle on each new change.

I have been a user of Unity Cloud Build since inception and it is key to Pro users.

4

Unity charges by the minute for builds?

That explains a LOT of things!

5

Looked into it further and yep, they sheathed off Unity Cloud Build / Teams Advanced into a pay per use thing now.

It is now “additional costs” Compare Unity Plans: Personal, Pro, Enterprise, Industry | Unity on “Build Server license capacity”

This is earth shaking in the amount of work you’ve just given users with many clients all who have their own licenses and builds. I wonder what will be ripped off from Unity Pro next…

Not only that Cloud Build is as slow as molasses, and now you’ve just given yourselves no incentive to speed it up… you’ve again put the work on developers to have to optimize and do more work for a sideways movement…

I can’t believe having Unity Pro gives us no additional minutes/storage/builds than Unity Basic or Plus. In many cases the whole reason we got clients Unity Pro was for Cloud Builds. We’ll have to look at all those now and maybe even take some down to Plus and just move to another build service or local builds.

Unity is supposed to help you, but for the last 5ish years it has been rug pull after rug pull that makes users/devs do all the legwork.

Seriously consider giving Plus and Pro users additional minutes/storage/builds otherwise this changes the economics not only on development but maintenance/updates. It makes it more costly to develop and more costly to maintain and in a way it is a rug pull as Unity Pro always had this as a benefit.

Unity, you’ve almost made it more economical for non console games to be only Unity Plus with pay per use Unity Automation (Cloud Build) at $399 /yr per seat for Plus than $2,040 /yr per seat for Pro. My guess is we are going to use about $1k per client in build costs now and it would make more sense to go to Plus for many of these since Cloud Build is no longer included and there is no benefit to Plus or Pro users in terms of extra DevOps credits/minutes/builds/storage.

Seriously, seriously consider giving Pro at least some additional minutes/storage/builds or you’ve just made it beneficial for people to go to Plus over Pro for non console games.

6

here’s the announcement thread,

and note that this license pricing will kick in soon also,

7

Hello @ianstead1p and apologies for the delay.

Thanks for sharing your concerns! Your input is invaluable. We aim for transparent, flexible pricing so you can make smart choices and keep using our services with ease.

Please allow me to provide some detailed explanations to your specific questions, below:

  • Storage Costs: We calculate the cost of storage based on the average hourly storage (GB-hours) over the entire month to more accurately reflect not just how much you store but for how long you store it. When calculated hourly, these values would be:

  • 5 GB free each month = 5 GB x 1 month x (31 days / 1 month) x (24 hours / 1 day) = 3720 GB-hours for free per month

  • $0.1387 per GB for each month = ($0.1387 / 1 GB-month) x (1 month / 31 days) x (1 day / 24 hours) = $0.00019 per GB-hour

In months with fewer than 31 days, you would be able to store slightly more than 5 GB for free because we used the longest month to determine the size of the free tier to accommodate all months in a year.

Example 1: If you store 15GB for an entire month, you will store 15GB for an average of 730 hours per month (672 in february, or 744 on 31-day months, for 730 average per month). That results in 15GB * 730 hours = 10950 GB-hours. However, because we offer the 3720 GB-hours as part of the free tier, you would only be charged for 10950-3720=7230 GB-hours at a rate of $0.00019/GB-hour. The total charge would be 7230GB-hours * 0.00019/GB-hour = $1.3737 total.

Example 2: If you store 100 GB for 4 days and then delete the data, the end of month bill would work out to be: (100 GB x 96 hours - 3720 GB-hours) x $0.00019 per GB-hour = $1.1172

Your Example: if you produce 10x 1GB builds per day, every day continuously, spread out evenly across the day, and never delete any build ever, you will then create an average of 150GB per month, and each month will start with the 300GB total that was produced in the previous month. This means that after the first month you will pay for 150 GB-months, or 109500 GB-hours (using 730 hour months as the yearly average of hours per month) minus the 3720 free GB-hours. So the first month will be 109500 - 3720 = 105780 GH-hours, or $20.09. At the end of the next month there will be 300GB from the previous month, and a new 150GB, so the total will be 450GB * 730 hours/month = 328500 GB-hours, minus the free tier. Costing $62.415 assuming you are never deleting any builds. At the end of the year, you will have 11 months of 300GB being produced, and 1 month with only 150 average, and since no builds are ever deleted then it will accumulate to 11*300 + 150 = 3450GB stored, which will bring the monthly bill to 2518500GB-hours, or $478.515.

  • Instance Costs: Your first machine is free. If you decide to add additional concurrency, then yes, these will be billed at a rate of $0.50 per machine per day up to 3 machines, and anything beyond 3 machines will incur a charge of $2.00 per machine per day. An instance only incurs cost when it is used, so for many customers this will result in savings since most customers are not building 24x7 using all their available concurrency.

  • Seats: Seats pricing does not apply to UBA, only to users of Version Control in DevOps. To your point about whether you would need to pay extra for additional Build Automation ‘users’, the answer is no.

I hope this helps provide clarity to our pricing model. Please don’t hesitate to respond with any further questions or clarifications needed, we’ll be happy to help! If you would like some more specialized advice based on your specific account, please send a support ticket so that we can look into the specifics of your usage.

8

Hi @ianstead1p

I do appreciate that this is out of your hands and that you’re trying to help as much as possible. But posting that example then stating you hope it provides some clarity, just highlights how problematic DevOps is. Especially as it’s being forced upon us. The pricing model is not only expensive, but overly complex and flawed in so many ways.

Unity have been told this by so many, but it’s fallen on deaf ears. I’m already seeing many indie devs looking elsewhere and even smaller studios. Unity’s core audience, or so you would think.

At the very least, why not add a calculator to the dashboard taking into account an average number of builds made\retained and their platforms\sizes etc. At-least it will help devs make informed decisions with DevOps.

I’ve done some rough calculations and it looks like my build costs (with DevOps) will be almost three times what they were before. And that doesn’t take into account failed builds (resulting from Unity issues) that I will have to try and claw back the costs for. Holding back UWP builds from Teams Advanced users was the final straw. DevOps BA is a big no from me.

So when my Teams Advanced plan runs out, I’ll be re-structuring my development & build processes (to greatly minimise costs) whilst looking for an alternative solution. Which is a waste of time for me and a shame for Unity. C’est la vie.

9

Fully understand that perspective @PeachyPixels , and agree that a calculator would be useful. We are facing some technical challenges in making that available, and I’m not able to guarantee that it will get launched.

we do want to make the pricing easy to understand, and also make it easier to do a like-for-like comparison with some of the competitors out there who offer a similar but, in my opinion, inferior solution. The new pricing allows us to invest considerably into the platform and deliver new features such as advanced caching and multiple machines types/sizes at different price points. I’m working on introducing lower cost machines for folks so that they can make the right choice based on performance/wall-time/budget etc. Also working on higher spec machines to make builds go faster too.

10

@wrossmck-unity Thanks for the details on this.

While I understand the move to this business model, I do think the current tools aren’t that compatible with it. It seems to me most companies will now have actively delete builds they don’t need manually. Two UX issues:

  • We’re a fairly small company that don’t run builds automatically, and I still had to go through our history of 1000 builds and delete the irrelevant ones page by page. I imagine lots of companies will have it way worse.

  • We’re often making builds to conduct tests that don’t need to be archived past a certain duration. With the current tools we’d have to ask every employee to remember to delete their build the next day. Or we do a sweep every X days. A solution for us would be to add a “delete build after X hours” field we could set per configuration. When we create a release candidate, we do that on the official configuration that don’t have auto-delete. When we do tests, we do that on other temporary configs.

Both of these feel like features that should be built in before you start charging anything for storage. Maybe I’m missing another way to reduce manual work here, if that’s the case please let me know. But basically the business model is adding manual work, and reducing manual work was the main reason why we invested
in having automated builds.

Thanks.

11

Thanks for the feedback, @Swah .

I like the idea of build retention and think it’s an important way for folks to manage their consumption.

I’m thinking of retention on the following schemas, would these work? alternatives?

  • total number of builds (per config, per project)
  • total GB used (per config, per project)
  • age of builds (per config, per project)

any other way we can split it up to make it easier?

12

I might be interpreting this wrong but technical challenges suggests to me that the calculations are too complex which as far as I’m concerned means that I’ll never be able to recommend this to anyone.

13

Yeah these are good ideas. Maybe the option to mark specific builds to prevent them from being deleted by automation? I could see developers wanting to keep a particular build around for longer than usual for whatever reason, and not wanting to edit the whole configuration just for that. But a first pass with items you mentioned seem critical before this new business model starts.

Just in case: to address the issue of companies with thousands of builds, whatever automation should apply the rule to past builds as well.

14

The calculations are pretty straightforward. Charges are determined by GB-Hour: storage is measured in GBs and is calculated per hour.

The complexity comes because builds of different sizes can be created at any hour of any day, and then builds can be deleted at any time or all at once or never.

Yeah good idea, we probably want to save specific builds that have been released/etc so that they are always retained. We could also do specific retention per branch of SCM or per target platform etc, will need some design so that the inheritance/override of retention settings works in a predictable way.

15

Right - this is actually a need we have a well. We currently mark shipped builds with label and put them as favorite. I was thinking we would manually delete unwanted / non released builds in the official release configurations, but relying on something that indicate a build was shipped could also work. Ideally a simple system that can be used for both needs yeah.

16

What is unity going to do about past builds before this pricing took effect. I don’t actually need any of them and don’t want to be charged for storage. Am I going to need to spend days deleting them?

17

Also would very much like an answer to this question.

18

It would be pretty hilarious if everyone with thousands of builds they don’t want from old cloud build gets enormous bills because of that. Having no way to automatically delete builds is a big oversight for this transition.

19

there are details about this in the email everyone would have received. I’ll paste the relevant piece here for clarity:

We do plan on charging for historic data in the future, but we plan on making more tools available to manage the data before then.

For now, the best way to bulk delete all historic build artifacts from a given target configuration is to delete the target configuration (you can Clone a config first and then delete the original to delete all the associated artifacts)

20

Hi @wrossmck-unity

The attached message starting showing in the dashboard on Friday. It looks like others have received similar messages.

It’s clearly not correct.

My last payment for UTA was made on the 2nd May, so I still have time left and that’s also nowhere near the 60 days notice that your terms of service stipulates.

Hopefully this will be corrected ASAP?

9028627--1246018--TeamsAdvancedMessage.png
9028627--1246018--TeamsAdvancedMessage.png1367×98 19.5 KB