Official Announcement: Unity Teams and DevOps vision

Will it be possible to use a dockerized version of UCB to deploy on custom hardware in the near future?

 

This is rather disappointing. As a small indie team the current pricing is prohibitively expensive.

We were making many builds at a day, with an average build time of 15m, for Windows, Android and iOS.

Suffice to say we will have to abandon the service and make our own build machine.

 

sounds bad, imagine having random failed builds on those prices..

does the concurrent build price mean, you have to pay 10usd/mo for single machine,
even if you don't make any builds that month?

time to start looking for alternatives then.. : /

 

This can't be real - 1 DOLLAR FOR 1 BUILD?

Guys, please tell me someone somewhere made a huge mistake, because this is absolutely not acceptable.

 

This is vague, considering the potential huge impact it has on indies and smaller teams. The blog post is equally as vague.

Are you guaranteeing that existing (per month) pricing will remain (indefinitely)? (albeit it with smaller repository & concurrency limits). That is, UCB 2.0 pricing will always be opt-in?

If no to the above question, this will render CI builds utterly useless for all but larger studios who can afford such prices. I will only be able to afford a severely reduced number of beta\production builds at best. More than likely, this won't work for me and I'll be forced to move to an alternative (non-Unity) solution. I suspect a fair number of your smaller UCB users will also do the the same.

On-top of that, who will pay when a build fails due to Unity infrastructure\service issues?

Please could Unity clarify or re-consider...

 

Nice! Progress towards a new "vision" by throwing out the window the customers that helped build the product. We'll suffer the stress a bit, but land on our feet after migrating to other services.

But rest assured, this experience of what the Unity vision meant for us, and its services, wont be easily forgoten

 

if that's the selling point then i'd be fine with old features, if price stays as it is:
current slow build speeds, 25gb repo limit, 1 concurrent build limit..etc.

or if you must,
can make the current price tier even 2x slower, perhaps smaller repo limit too, or even daily build limits <10 or so..
but this new forced pay-to-use would mean cloud build would be used less and at that point the whole initial setup might not be worth it anymore.. (especially if there are alternatives to setup through github actions perhaps?)

 

Thanks for the reply @wrossmck-unity

I understand your point. Currently UCB better suits indies and\or smaller teams\projects. UCB 2.0 helps address that issue.

But if the intention is to replace UCB with UCB 2.0 completely (in-time) that will very likely be at the expense of indies & smaller teams. So the product is no better off, you've just replaced one preferred group with another (and alienated a large user base in the process)

As @mgear says, why not have multiple tiers?

I would happily live with the current repo size, current build times and\or reasonable daily build caps. But what I can't live with (and I'm sure this applies to 99% of indies etc) is far higher costs or far lower build limits (to keep costs down). That is almost 100% guaranteed to force a lot of devs into finding alternate solutions.

 

Like everyone here has said, I am very disappointed with the new pricing of UCB.
I'm working in a very small indie game dev team and we feel that current functionality is sufficient.
We now pay only $9/month for Unity Teams Advanced, but UCB 2.0 requires AT LEAST $10/month, plus about $1 per build.
(Because our game is developed for Windows, iOS and Android, the actual amount required is $3 per build.)
We cannot afford this, so we will probably have to revert to a local build.

 

I'd reckon better pricing could be found on much more reliable services...

You remember those times cloud build has been down for literal DAYS before Unity notices?
You remember those builds that build for 15 minutes then get an internal error?
You remember when they told us to workaround their authentication issues?
Remember when they told us moving to plastic would be seamless, and it gets unexpected errors looking for ProjectVersion.txt?
Do you think they'll finally sort out auto build? Today it's not done anything, for the past 6 months it's randomly built. Maybe this is their scheme to make their money back from the thousands of randomly triggered auto builds?? LOL


100% of the money given is probably going to end up in support staff pay
Maybe this is the kick in the ass our team needed to start moving away from Unitys "infrastructure"

 

would there be refunds or something, if build fails due to cloud server issue/bug?

and is there more info about what this means "$10 per build machine concurrency." ?

 

We had exactly this problem today.
1. Due to UCB issues, we were unable to build iOS and Android configurations for several hours, and we had to submit both builds to Apple and Google Play stores for review today.
2. We had to build it manually and submit.
3. Failed builds (due to UCB issues) cumulative time was around 30 minutes.

So I wonder now, aside from having to spend valuable time to build manually, will the failed builds be charged?

 

Lol, it becomes better and better. So we have to invest more of our time (on top of the already lost as per the failed build, for which UCB is accountable) creating a support ticket, and waiting (and hoping!) for some guy at a support desk to click on the right button, in order to not be charged for something that should never be done so.

As per the costs of concurrent builds...

​

​

You guys at UCB are free to do whatever you consider right for commercializing the product. As for my part, I have been looking into alternative solutions (there are a few). So far Game.CI and Wololo look rather attractive, and much more cost effective, so I encourage others to try those and share experiences.

 

Large studios are not going to switch to UCB because the 25Gb limit has been removed.
Large studios are not going to switch to Plastic - ever. Artists can and do use Git on a regular basis, and it's free. And if something does go wrong, someone from the build team can fix it for them. Because large studios already have dedicated build teams and they don't rely on UCB like us poor folks.

Large studios are going to have massive headaches when they try to integrate all their custom post-build steps into a black box that costs them $3 just to try out a change in configuration.

I really feel for you guys, you have a workable and useful service for small to medium-sized studios. But someone with a V or a P (or both!) in their job title has said you need to make a profit (or at least break even) and this change is going to hose it for everyone

 

Hi @ValeryNikulina,

If the intention is to drop fixed pricing (completely) in favour of UCB 2.0 pricing, then for indies and smaller studios this refund policy will likely just burden us with unnecessary admin (on-top of the extra costs)

Apart from Unity service & infrastructure issues, what about non-UCB issues that require extra builds?

Currently I am working through an iOS rendering issue that only happens on device builds. I am almost 100% certain it's a Unity bug or if not a bug, a Unity/iOS incompatibility that isn't handled well by Unity. 15 builds later and I'm no closer to resolving it.

This is not the first time I've encountered this situation and it won't be the last.

So who would pay for those builds? Would that mean I have to submit 15+ refund requests? And would your support personal recognise that all these builds should be applicable for a refund?

Even if Unity agreed to refunds in that situation, as a developer I've already wasted several days working through an issue that is not mine, now I'm having to waste extra time chasing up multiple refunds.

UCB 2.0 pricing policy is just not going to work in the real world for smaller developers like myself.

 

This is absolutely devastating to the indie and smaller game studios. Here I am waiting 6 hours for a build that has to do a fresh import, not finishing and cancelling, even though it worked perfectly fine two days ago, and now I am going to be charged 25$+ for that??? This is not how you keep people from migrating to Unreal 5.

 

I've just finished setting up our infrastructure for cloud build from an internal VPS hosted solution and I've discovered this change on a hidden forum post. Throughout getting the CB set up with uploads to Valve' Steamworks, I've probably made 20 builds. As an indie developer, getting charged $5 / build would have made this initial setup impossible.

Considering the VPS for the infrastructure had costed less than $10 a month, was based on open source software, and took less than an hour to setup (whereas cloud build has taken nearly 6 hours) -- to make 5 (some days up to 10) builds a day (* 30 days); I am not ready to pay over 15X what a service ought to with less than stellar reliability and performance.

Y'all need to rethink how you're monetizing Unity Cloud Build.

 

Not to rub salt into the wound, but again the service becomes unusable if its not kept up to date with the absolute latest releases. Firebase and others now require xcode 13.3.1 which UCB doesnt support. ETA is unknown? https://forum.unity.com/threads/any-eta-for-xcode-13-3-1-support.1285982/#post-8185001

I'm throwing in the towel with UCB, I cant take the frustration anymore.

 

I thought that maybe build time being paid per minute means that you at least have capable hardware now. But nope, it takes more than 3 hours so almost $4 to build my small game. My potato PC can build it in an hour.

 

Just to add on top of what everyone already said about the unreasonable pricing:

1. Since UCB runs builds on shared hardware - when you run the build will affect your pricing.
Our builds usually take ~1.5 hours most days during our working hours. We've noticed that if we run builds on Friday night or Saturday the build time takes ~30-40 minutes...
So now we would also be "incentivized" to run our builds when we think there will be the least load on the servers? that crazy. It means our costs would just be unpredictable....

2. We've had issues that only happened in UCB, but after running multiple special builds for the support staff to debug - they came back with "oh its an Editor issue - so we can't fix it or do anything about it" even though it didn't happen when we did a local build, simply because UCB runs in batchmode or some other random flags causing rendering issues in specific targets... so now we'll also have to pay for that (or like everyone said, spend our precious time chasing after refunds request)

3. For us this mark up would be around 100x the cost with our current workflow - that's not just a red flag, its a deal breaker. We've started looking at other solutions.

And all of this cost hike - and you still don't provide and SLA and uptime guarantees - something that's unheard of in the SaaS ecosystem. If you want me to guarantee payment - then you need to guarantee the service I'm paying for! (This point TBH is a bit moot because, with this pricing plan I'm not going to continue being a paying customer anyway.. so you can keep your SLA)

The honest thing you should have done, at the very least, if you realized your pricing was not right was to only apply it to new companies/customers moving forward and leave existing accounts alone (and not lock us out of new features if we don't "upgrade" to this draconian plan)

I've previously worked at a SaaS company, and frankly, this move is just embarrassing for you (not any employee personally of course, ya'll are just doing your job.. but for Unity as a company).

 

It seems disrespectful to introduce per-minute build pricing at the same time when latest "most stable ever" LTS introduced a bug that causes URP build times to explode from minutes to hours for absolutely no good reason. If this is the vision of the Unity future, it looks like consumer satisfication is the last priority.

https://issuetracker.unity3d.com/issues/shader-variant-build-preparation-does-not-scale

 

This would give another easy way to offer 2 tiers:
keep old pricing: shared/slower hardware
metered pricing: priority/better/dedicated hw.

 

Are you kidding me?

 

It's absolutely shocking. Our whole studio relies on cloud builds and we have spent days in training resources on how to use cloud builds. We have developed integrations with different platforms including Slack in order to encourage developers to use cloud builds more often. Our customers and testers all rely on the cloud build link to test and iterate.

To suddenly, make this a 100 times more expensive is outrageous. I will reach out to influencers and people with a following to let Unity know how we indie studios feel because frankly, it's disgusting and monopolistic. Either not offer the service in the first place or if you have made studios so reliant on it now, you don't raise the price by a 100 times (yes that's true for us).

There could have been many solutions to this including paying more / month for dedicated or better hardware but how Unity has gone and implemented it right away shows what they think of their long term customers.

 

This community simultaneously complains that UCB is slow, unreliable and broken while *also* demanding that it remain nearly free forever, thus preventing Unity from ever improving it.

In the end, you really do get what you pay for.

Once you go through the effort of setting up those Github actions with Game.Ci (or other solutions mentioned above), you quickly find that there is no free lunch. (For the most trivial, tiny Unity projects, you can still get very low costs elsewhere, of course.) Maybe these UCB 2.0 prices really are higher than your received value and what you could pay for alternatives - but let's talk about those *specific* cost deltas, not compare them with some mythical "free forever" model.

I don't know how Unity recovers from this conundrum it has created: a large community of small devs who are addicted to nearly free, but very low quality, janky services that aren't truly production grade (precisely because they are so cheap). My heart goes out to everyone on both sides of that equation because that status quo can't be maintained forever so something has to give.

 

Here is another quite interesting and cost-effective alternative, that also manages deployment: Codemagic for Unity. https://unitycicd.com/

 

We've been using CB for years, paying for three concurrent builds right now.

The other day we started experimenting with switching to universal rendering for our project. A differential build targeting the Vive (Windows/SteamVR) typically takes 30min. A clean build maybe 1h. Not fast but ok.

Trying to build the URP branch, out of seemingly nowhere: 5h?!
Just to build three of our targets for that experiment a single time would cost us $13 under the new model.

Is it on our side? Too many shaders needing to build? Something else?
Or is it on the Unity side: CB machines too slow? Having a bad day?

How much would it cost us just to figure that out? Right now, more often than not, another build brings times back to normal.

With the current setup and the constant hiccups we are seeing with cloud builds, a per minute pricing model only punishes the customer and introduces a great deal of uncertainty every time someone hits "Build". Not doable for a small Studio.

Thanks for listening.
And as a side note, no, my "heart does not go out" for a company that just paid 4B USD to buy an ad monetization company that they "need to charge more for cloud builds in order to afford making it fast, reliable and robust".
No offense

 

They didn't pay 4B - it was a 100% stock merger.

 

Quick Update: When we tried to see if we can reduce build times on our side, we came across this from another forum. Linking to page 3 where the discussion is current. Title speaks for itself.
https://forum.unity.com/threads/build-time-taking-almost-a-day-urp.1133605/page-3

Thanks for clarifying the stock technicality. I deserve the correction for being snarky. The same technicality speaks to Unity's liquidity though and the point stands, we can hopefully all agree that Unity has PLENTY of funding to make CB robust if they wanted to. And do it before charging per minute, resolving the chicken and egg problem they have (as you correctly state) created.
At this point, without Unity FIRST putting in serious effort to make CB reliable and the engine build process stable towards a reliably forecasting of build times towards a "per minute" goal, we'd cancel CB immediately once they decide to change the model for legacy users.

This would disrupt our workflow greatly. If you are listening, Unity folks, please explain how you envision small studios to use CB with a per minute pricing if the above uncertainty is a constant occurrence still in 2022.

 

What self hosted options exist?

 

They are not a profitable company at the moment, so we don't know whether that's true. Also, their stock value has plunged, so there's less liquidity from that standpoint, too. Either way, continuing to pour money into net negative revenue services is probably not appealing to them right now.

Your point is well taken, though: per minute billing when the minutes are highly volatile and out of our control is going to reduce the customer base drastically. Maybe a smaller, higher paying customer base would be ok, I don't know.

But we can't keep shouting at the sky that it should somehow be nearly free forever.

 

We've had great results from using custom runners on GitHub, where the custom runners are either Amazon EC2 instances or bare metal machines of our own with unity licenses installed on them. You are probably looking at $100 to $200 per month (Plus unity license) for unlimited builds that way.

 

Hi @wrossmck-unity

Thanks for taking the time to reply.

Firstly, I think most\all of us understand that Unity ultimately need some return on investment here. Of course there is an argument for running some business units at a loss to promote others that will make up for it (and them some). But that's very off topic here.

We all expect services to increase in cost over time, especially in the current global climate. But the changes (certainly for me) would literally result in a cost increase an order of magnitude more than they are now (assuming like for like use)

So that just makes me feel like Unity dangled an unsustainable (but vital) product in-front of our eyes, waited until we're all invested & reliant on it, then cranked the prices into the stratosphere. It was obviously not going to be received well.

I can't speak for everyone here, but for me it's almost entirely about cost. I could live with smaller repo sizes (if need be). I could live with longer queues (if need be). I could live with slower builds (if need be)

But I can't live with the new costs. It's not even close.

I know I've said this before, but a multi-tiered system would be ideal (at the very least two tiers)...

1) Shared servers for the lower tier (existing fixed monthly price) with lower repo limits, longer wait\build times and a daily (reasonable) cap on builds (e.g. 10)

2) Exclusive (or near exclusive) servers for the higher tier (per minute billing) with higher repo limits, shorter wait\build times and no build caps.

I genuinely think something along those lines would keep the vast majority happy. Given your comments, I like to believe you're heading that way.

 

I'm not using this house of cards of a service, but do you expect customers to spend time creating a ticket per failed build to get credits worth a dollar or so? Why doesn't your system detect this scenario and automatically issue a refund or restart the build? Asking your customers to file a support ticket per failed build is a slap in the face to anyone who dares to use this "service", not to mention the salaries of the support engineers and everyone involved on your side for a 1$ refund support ticket.
You know very well that nobody has time to file support tickets to receive a dollar's worth of credits, that's completely unreasonable and you could automate that.
I mean if failed builds were rare I'd understand it but reading these forums it sounds like quite a common occurrence.

Also your prices are beyond prohibitive -- most companies would like to trigger CI builds on every commit that can yield several different builds (iOS, Android, WebGl etc). There can be hundreds of commits per day, so any larger company would pay several thousand dollars PER DAY for this "service". Do you think that companies who wanted to save a little bit of time by using this service would actually use it at half a million USD per year, or just roll their own (which they have done anyway)?

Not to mention that you block users from building for certain platforms for months at a time (like the current issue where new Xcode versions are not available). Do you think that companies, if they were crazy enough to spend half a million per year on this "service", would rely on a build service that may lock them out from shipping builds for several months?

It doesn't sound to me like you guys take this seriously and I'm curious about where this is heading.

 

Are you kidding me that the pricing is not based on CPU hours but actual time spent building on shared hardware? It can't be?

It's almost as if they didn't understand how a cloud service works -- the point is that pricing and all other factors should be agnostic of when it's run, what the load is etc. Not to mention the total lack of an uptime guarantee like you said.

What company could commit to a cloud service with that kind of TOS (even if the "service" actually worked)?

I am failing for words for how badly this is run. There must be a misunderstanding somewhere.

 

This post's title is so, so, so, so misleading.
It's as if they don't want to let you know that the Team Advanced plan is now gone and it's now just pay-to-go.

If I haven't found this post just in time (Our annual team advanced plan expires next week, and I have auto-renewal turned off) - We would have lost access to our team advanced subscription and thus the legacy pricing - which our team relies heavily on our development process.

I suppose I should start to set up our own dedicated build server now... At our current usage, we will be paying $1000+ each month, and at this price, buying a dedicated build machine would be much more cost-efficient.

 

This can't be right?

I temporarily paused my Team Advanced a couple of months ago and was going to turn it on now for a couple of new projects. But to my surprise the option was not available, replaced by this new "Pay as you go" schema.

After just a quick calculation it seems like I Instead of the monthly $10, my one person company, would have to pay around $1000+ a month with this price model.

Not a chance Unity...

Looks like I have to setup my own build environment locally.

Also frustrating that all hours setting everything up on Unity Cloud is down the drain...

 

I am really shocked to see the new pricing. I have no problem with billing by credits, minutes, VPU's or time. But the price is grossly over inflated compared to your competition in CI. I appreciate the investment in the project needs to be clawed back, but Indie developers could do with some support here.

If you invest in your Indies like you do in other areas by the time they turn good revenue they will be locked in to your platform.

Sadly I am making the change back to CircleCI. I love CircleCI but was hoping to have my CI in Unities unified cloud platform.

On a side note, custom runners would be nice to have.

 

I see this earlier. I might move away from PlasticSCM and back to GitHub - Although I do like the integrated interface of Plastic within Unity Editor.

https://github.com/marketplace/actions/unity-builder

 

I get the need to leave a model that was probably too good to be true - aka unlimited builds - albeit quite unstable and we were clearly your paid beta users.
I can even accept the pricing model. With EA's CEO, I don't expect this whole thing not to be come 'services everywhere'.
But still.

First:
It's literally 10 times too costly. Just that. everybody assumes you've made a typo for a reason.
In the process, you're mainly impacting the small studios, while the big ones will use their own solution anyway.
Every other solution on the market, when I look at AWS, azure, gitlab and such, is 10 times less costly.
Sure Unity provide additional services so the price 'can be higher', but not really, because the whole selling point is to say that we can choose the parts of the service we want to pay...

If it was at an affordable price, I could even accept the strong issues that have been pointed out:
-Not based on CPU hours
-Requesting manually refunds (or even more considering how cloud build takes time)
-Cancelling builds - I assume, don't get refund
-Unstable service (As a SaaS, Unity has sadly a bad record at services stability, so it's sadly the default stance until proved otherwise)

Second:
The basic fact that the company handles the service that way is problematic:
The goal is to make money from build time, so why bother making our cloud build faster now ? I mean one could argue that tomorrow, some of the Unity director put that nasty mindset in that place.
(I'm exagerrating, I see all the workload and efforts and plans put into it of course, but you see the potential issues there)

So yeah. Like everyone else, unless there's a drastic change in the prices plans, I'll have to look out for another solution. CircleCi + GitLab will always be much cheaper sadly. https://circleci.com/blog/install-runner-in-five-minutes/

Are we supposed to wait for May for a clearer plan ? At the moment, seeing how we're supposed to accept this overpriced thing as a normal one (again, it is not, even for medium studios), I don't expect that the 'options' will satisfy us

 

I think I can summarize the issue again
I'd like to point out that this strategy:

Unity: we can't sustain the product (lack of talent and/or organization), but thanks users for doing beta for us
User: I want reliable, I feel the product doesn't match the criteria, I give Unity bad rep
Unity: we run out of money
Unity: we throw away people rather than keeping them to fix the product
Unity: we hire new people
Unity: we add new functonalities rather than fixing the product
Unity: please pay more for the stability and features
User: I don't want more features. I don't see the stability. only then we can discuss legitimate price increase
Unity: Here's half baked new features and a huge price increase

This is now a trope in unity services and continuing this trend will simply continuating alienating users, which is the thing that should change. one day.

Anyway.
wrossmck-unity MikeSaverUnity Any clearer plan? options ? anything to make it affordable to regular user or Plus User like me ?
As everybody else, I'm ok to pay more.
10 times ? Okay if more reliable, stable and performant than UCB 1 (but I don't see any sign of that).
100 times(Aka what you're offering right now, with builds at 1$ or more) ? Nope

thank you

 

I didn't notice this new pricing because we has team advanced licence. Though this price are insanely expensive. Who will use this? Is it affordable? OK, on my desktop, my project will be compiled less than 5min, but it's possible on CB 2? On CB1, it takes more than 1 hour.

 

I guess its over to circle CI then.

 

I had this issue. I think if you have a lot of new/modified shaders, this happens, but once you stop modifying them, build times are as expected.

 

I see this feedback was for nothing.

Just received an e-mail stating that Teams Advanced is being phased out in the next month in favour of DevOps (therefore pay as you go billing, from what I can tell)

There are many approaches Unity could have taken, but pulling a perfectly good service and replacing it with another less favourable (to a lot of users) is just not a good way to treat loyal customers (and early adopters)

I'll need to review the impact, but have a feeling UCB\UBA will no longer be viable and that I'll be looking elsewhere. Which would be a shame.