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

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

 

bump

 

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.

 

Unity charges by the minute for builds?

That explains a LOT of things!

 

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" https://unity.com/compare-plans 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.

 

here's the announcement thread,
https://forum.unity.com/threads/announcement-unity-teams-and-devops-vision.1277462/

and note that this license pricing will kick in soon also,
https://forum.unity.com/threads/question-to-unity-industry-changes.1420997/

 

Hi @wrossmck-unity

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.

 

@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.

 

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.

 

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.

 

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.

 

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?

 

Also would very much like an answer to this question.

 

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.

 

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?

 

I have the correct message (a simple warning for the right date according to my payments) in my case

So It doesn't seem to be a general issue

 

This makes sense, but I had to read the forum to fully understand how that works. On the pricing page it says you have 5GB of free storage, but then when I check my usage, it says I am using 15GB of storage usage (despite having deleted all my previous builds and making sure I keep only 1 or 2 per target, which shouldn't be anywhere near that 15GB)



But then when I check the usage detailed page, it is stated as "Storage-GB-Hours", so I am not really using 15GB of storage but 15GB of storage hour.

This should be stated more clearly, that "free 5GB storage" means nothing concretely, it should be stated that you get "3720 GB-hours" for free or something, and stated as such in the usage preview page, otherwise it just look like I already busted my free usage for the month...

Also, I know it has been mention already, but I'll reiterate because I did enjoy the product, this new pricing doesn't make any sense. You guys should have included a paid tier with a bunch of free minutes with metered billing if going above the limits and include more free minutes for Plus / Pro user than the standard free tier... And include some free Mac minutes as well, I think the major use-case here is people building iOS app using your service because they don't have a mac readily available. Doing some quick calculation I just can't justify using this, I'll revert back to self-host and get myself some used mac (which will pay for itself after a month or 2 based on this new pricing...).

 

I made this transition this week after using CB since 2014. Took 2 nights to set up, and cost less than a single month of CB. My iOS builds have gone from 40+ minutes on CB to 3 minutes on my local jenkins build machine. I cannot recommend enough making this transition at this point.

 

Oh yes, I didn't stressed enough how much faster the builds are on my own build machine compared to ucb.
(Whether cached or not)
I don't even have a big hardware, nore a Mac machine like ucb was using.
So yes, one more reason to say that doing your own machine is much better.

I just have to note some difficulties I had in the late days with triggering development build. It's not possible directly in command line with the build command, there's no parameter for that.

So this must be performed through command line that will call for a script in the project that will, himself, trigger the build with Dev option enabled.
Always a good thing to know ^-^.

 

Yup this is the right way to do it. I have per build config methods. This allows you to do more complicated build setup, inside unity itself. Very necessary for consoles, and supporting different stores with different integrations/defines. I also find it much less error prone having more of the build setup inside unity, than inside jenkins. It also allows you to expose the same methods as a button in the editor, which makes debugging issues in the build process much easier.

 

Just wanted to preface that I've used the UCB before but not for a while.

And right now I'm evaluating the Unity Devops solution for our company and I am absolutely shocked at these changes.

I just want to point out that I will not be recommending this tool. I guess we'll either build a Bitbucket pipeline or just host our own on Azure/AWS. Crikey. I don't know who in the Unity management team needs to hear this but this is not the way to treat customers, we're already paying thousands of dollars for Pro licenses. Seriously..

 

I would recommend removing outdated information from the Unity docs.

My first Google search regarding unity build pricing brings me to the Pay as you go with Cloud build page, and in it it states
You are not charged for storage in Cloud Build. Cloud Build has a project size limit of 40GB.
https://docs.unity3d.com/2022.1/Documentation/Manual/UnityCloudBuildMeteredBilling.html

 

Who is doing the discouraging?

 

So after charging an extortionate amount of money for builds now the product is still not supporting the latest x-code release (14.3.1). You have to be kidding me. How many build minutes are going to be wasted trying to get stuff to work with BETA iOS support?

 

Seconding this, we are Pro users, we just completed the migration and:
a) there's no way of knowing the minutes included in any part of the dashboard.
b) there's no way of estimating budget costs, as these depend on the build time, which could include build failures due to Unity issues. Or simply higher build time due to load? Because I'm sure that if I launch the same build two times it won't take the same build time.
c) on this topic, Unity Personal == Unity Pro, which in a way sends a message.

 

A note at the top that this service doesn't work this way any more and pointing to relevant pages might be good enough, and then you can preserve the rest of the page for historical purposes if you wish, as long as it's clear that's why it's still there.

 

If you don't mind me asking, where did you go to find this daily average storage usage in your account? I can't find that anywhere.

 

I just received notice that my cloud storage limits are exceeded. I am assuming this is caused by the old cloud build data that I no longer use. I thought you all were going to exclude this. Please let us know what we need to do.

 

For anyone that needs step-by-step instructions for purging old builds using the API, see:

https://twitter.com/AlanLawrance/status/1688927797081956352

 

Are people forced on DevOps? I was under the impression if we didn't explicitly migrate, our old builds would just be lost, which is fine with me.

 

We were not able to build using Unity Cloud Build until we migrated to DevOps. This occurred a few days ago.

 

Yeah, I don't actually care about cloud build, it was always a terrible service, the only reason we were using it is because some Unity versions years ago, kept re-enabling it and after disabling it a whole bunch of times we stop bothering ourselves with it and let it just do whatever.