[claystraw]

Both! :)

Ory Cloud is still in it's early phases and we have not been very good at communicating it well. Basically, we run Ory Kratos in Ory Cloud and it has full API and configuration and data compatibility with the version that is on GitHub! Our goal is to also allow users to easily switch from self-hosted to ory cloud and back - but it's still a bit of work until we get there.

If you just want to check our Ory Kratos and don't want to use the docker-compose command in the blog post, you can create an Ory Cloud account and use that instead of your local docker environment. That's basically the trade off you're making in a local environment. We have of course tons of plans for Ory Cloud but it's yet too early to share them with a broad audience.

We're currently focusing on gettin all of this much better communicated, and to make it easier to understand what the differences are. So totally get your confusion on it and can only say, we're working on making it better :) Hope this helped at least a little bit!

[Sytten]

If I have a suggestion for the cloud pricing, I would move away from the per user model that every competitor uses. It is a non-starter for all the B2C startups where a user might login once to buy a thing and never login again during the month/year. That is will I am not suggesting any auth provider to my clients and I recommend they use passport/build it in house. I really prefer to have pricing per API calls (in case of shared machines) or per machine (in case of dedicated instances).

[claystraw]

Thank you Sytten, this comment makes me happy because it confirms our bias! MAU pricing has always been my personal enemy. Ory is and never will charge on a MAU basis. Instead, we'll be working with CPU, Memory, and Disk usage (like any other cloud provider) and with additional services on top. We're not fully there yet to communicate this clearly, but if you're interested check out the pricing page to understand where we want to land at: https://ory.dev/pricing/

[bsid]

MAU pricing is terrible! love this idea.

Heads up, I don't quite get this from your pricing page at all right now.. It says "First 900 free" and "First 100 free" without any indication of what those numbers mean.

[claystraw]

Clerk (your profile says you're CTO) has a per-user pricing though? Or are you planning on changing it?

> It says "First 900 free" and "First 100 free" without any indication of what those numbers mean.

Thank you, we'll clarify that! It means that we're giving the first 900 "start up" and 100 "growth" plans away for free for a year

[bsid]

Ahh, that makes sense, cool!

Yes, I am the CTO @ Clerk, and we do have per-user pricing right now, however, that doesn't mean we like it. It's something we've struggled with - how do you make pricing scale in some way, while still being clear, while also being predictable. There's also value in being in-line with the status quo - when your numbers are priced competitively using the "industry standard (auth0)" scale.

Every method, I think, has it's issues, and it's something we would like to make as frictionless as possible in the decision making process. I imagine with a "per CPU/mem usage model", you will run into a lot of questions.. (how am i supposed to know how much CPU/mem you, as a cloud provider, uses?). I also don't necessarily think gcloud/aws/etc. are the bastion of clear pricing.

Per API call seems more predictable, but still not as clear as the "at a glance, MAU number" Do product managers know how many API calls your average user would use? Yes, auth is most often implemented by devs, but are they always the buyer?

I do think there's something better, and I like thinking about new options :) We don't have a clear plan to change from MAU right now, but I hope we get there. Love ory btw, been following it for quite some time!

[rad_gruchalski]

> Per API call seems more predictable, but still not as clear as the "at a glance, MAU number" Do product managers know how many API calls your average user would use? Yes, auth is most often implemented by devs, but are they always the buyer?

I’ve done some research into Hydra: https://gruchalski.com/posts/2021-05-23-do-you-really-need-a....

[Sytten]

I suggested that because the pricing page said 900 free users and that got me worried. Glad to see you are moving in the right direction!

I think you might want to try the API calls pricing model (a la S3) because as a dev I usually don't know how much resources I need. But I can estimate that if I have X user that login each day that makes Y API calls which translate to Z$ (with proper spamming protection of course).

[Aeolun]

I think the pricing page suggests that if you sign up now, you won’t be paying the $21/month fee (for one year).

It’s hard to use the correct terms when you have users signing up to user management as a service xD

[mooreds]

@sytten, interesting feedback. How would you feel about MAU pricing that varies?

If you are an app for schools and students, you might have 300k users in Sep-May, but 10k users in Jun-Aug.

Would you feel comfortable if the cost went down during the low traffic months to a lower band, based on the 10k users?

Or is that still a non-starter?

[Sytten]

Everything that is per user is a non-starter in my book.

Because the vast majority do 1-2 API calls to login once, are considered active and then never login again during the month. But you still have to pay as if it was active for the whole month.

That is why per API call pricing (a la AWS S3) or resources based pricing (1 CPU) is the best.

[mooreds]

Thanks for the feedback!

[prpl]

It would be nice if you could get some polish on some no-code examples of kratos and hydra working together, beyond a branch in an example app repository

[claystraw]

We actually want to have it work natively together, but just can't find the time to implement it. But the team is growing, so we'll definitely have something here soon! :)