Just wasted half a day debugging why our pipeline queue was backing up. Turns out Hailuo has a hard concurrency limit per runner type, even if your plan says "unlimited".
* Our plan: "Pro, 5 concurrent jobs"
* Reality: Max 3 concurrent jobs on their `linux-2xlarge` runners. Support finally confirmed it after I sent logs.
* Hit it when we tried to run 4 parallel integration test suites.
The limit seems tied to the runner *size*, not just your total job count. Nowhere in the pricing page or docs.
Check your runner types. If your builds are slowing down, you might be capped.
That's sneaky. So even though your plan allows 5 total concurrent jobs, they're splitting that allowance across runner sizes? Did they say if smaller runners like `linux-medium` have the same per-type limit?
I'm using their free tier for my side projects and haven't hit any limits yet, but now I'm worried. Thanks for the heads up, gonna check my setup. 😅
Containers are magic, but I want to know how the magic works.
Yep, ran into that exact limit last month. We were on the same plan and couldn't figure out why our large runner jobs were queuing. Support told us it's to "guarantee runner availability" for the larger sizes.
You can actually see it if you check the pool status in real time, but it's buried. Super annoying way to find out, sorry you lost half a day on it too.
Always optimizing.
Of course they're splitting it. "Unlimited" runner types, but the fine print is in the resource allocation. Classic vendor move.
It's not just about availability - it's a pricing sleight of hand. They sell you on the 5 concurrent jobs, then quietly throttle the expensive resources. Bet the `linux-medium` runners let you use all 5, making you think the limit isn't hitting until you scale up. Now your "Pro" plan needs an Enterprise upgrade.
Seen this same pattern with three other CI/CD platforms last year. They all start with per-job concurrency, then bake in secret caps once you need real horsepower.
Trust but verify.
You're spot on about the pattern, but I think the motivation is a bit more nuanced. It's not just a hidden upsell, it's also a resource isolation problem they're solving poorly.
Having benchmarked the latency on several platforms, I've found that large runners often share underlying physical hosts. If they let every Pro user spin up five `linux-2xlarge` jobs simultaneously, the noisy neighbor problem would be severe. They'd be guaranteeing hardware they likely don't have.
The failure is in calling it "unlimited" and not documenting the caps per SKU. It turns a technical constraint into a perceived bait-and-switch. A transparent table of concurrency per runner tier would solve the community outrage instantly.
Ah, the "noisy neighbor" excuse. Always a favorite.
If they can't guarantee the resources, they shouldn't sell them as discrete, dedicated units. A `linux-2xlarge` runner implies a specific resource block. If it's just a slice of an overbooked host, that's a different product entirely.
Calling it a technical constraint is letting them off the hook. It's a capacity planning and marketing failure. They built a pricing model they can't support at scale.
Your stack is too complicated.