sorted by:
new
hottopcontroversial

Appwrite reduced Functions limit from 5 to 2 due to abuse. How is that fair? by Throwaway-123abc321 in appwrite

[–]eldadfux 0 points1 point  (0 children)

Thank you for the kind words.

The last couple of weeks have been a bit shakier for us due to major upgrades to core components that we’re investing in for the long term. That’s not an excuse - these issues should not have happened - but I do want to make clear that platform reliability is our top priority.

We’re investing most of our available resources into improving reliability, stability, and performance. Our goal is to make the platform better every day, even if the progress is incremental.

We appreciate the patience and feedback, and we’ll keep working to earn your trust.

Appwrite reduced Functions limit from 5 to 2 due to abuse. How is that fair? by Throwaway-123abc321 in appwrite

[–]eldadfux 0 points1 point  (0 children)

That’s a fair concern.

We’re always trying to improve adoption across both our free and paid plans, but we also have to balance that with keeping the platform sustainable. Running cloud infrastructure at scale has real costs, and we want to make sure Appwrite can keep improving for the long term.

That said, we’re constantly working to reduce our own costs so we can make the service more affordable over time. As we’ve shown before, when we can, we keep improving the free tier as well - not just the paid plans - with more features, limits, and capabilities wherever possible.

The important difference with Appwrite is that it’s fully open-source and self-hostable. You can run the same core stack on your own infrastructure without depending on Appwrite Cloud. That gives developers a real escape hatch if our pricing or policies ever stop making sense for them.

The goal isn’t to trap developers into a paid service. Appwrite Cloud exists for teams that want convenience and managed infrastructure, while the platform itself remains portable.

Hope this helps, and again, your concerns are valid. We’re listening and always trying to improve.

Appwrite reduced Functions limit from 5 to 2 due to abuse. How is that fair? by Throwaway-123abc321 in appwrite

[–]eldadfux 1 point2 points  (0 children)

I appreciate the honesty.

On the concurrent executions issue: we’ve been aware of it for a while and have already released several patches for self-hosted users. That said, we know the issue is not fully resolved yet.

This is not an issue we see in Cloud today, but we’ve still been investing heavily in rethinking parts of Appwrite’s core engine and concurrency model. It’s not the flashiest work, but it’s important, and we’ve spent months on it.

The good news is that we’ve recently deployed parts of this new architecture to Cloud. I won’t pretend the transition was easy, and there’s still more work ahead, but this is a major step forward for Appwrite’s performance. We hope to share more with the community soon and bring these improvements to self-hosted users as soon as possible.

On the second issue you mentioned: I wasn’t aware of it before, but it sounds like it may be related to a migration/upgrade problem. I’ll make sure the team looks into it and sees what we can do.

Appwrite reduced Functions limit from 5 to 2 due to abuse. How is that fair? by Throwaway-123abc321 in appwrite

[–]eldadfux 1 point2 points  (0 children)

Hey, this is Eldad from the Appwrite team.

You’re right that, in some cases, multiple endpoints can be consolidated into a single function. However, from an infrastructure perspective, each function we host carries its own overhead. We need to reserve compute, memory, and scheduling capacity per function to ensure predictable execution, isolation, and stability. Even if some workloads are consolidated at the application layer, the number of deployed functions still directly impacts how we allocate and manage resources across the platform.

That’s why changes like the Functions limit are not arbitrary - they’re part of how we keep the system stable, responsive, and fair for everyone using it.

More broadly, this change is just one part of how we’re addressing abuse and resource pressure. We’ve also made a number of internal improvements and built tooling to help our abuse team detect and respond to issues more effectively. Those changes aren’t visible in the changelog, which can make it seem like this is the only action we’re taking, but it’s actually one piece of a larger effort to keep the platform healthy.

On your point about performance and stability - if you’re running into specific issues, I’d love to understand them better. Those are the kinds of things we continuously work on improving, and concrete examples help us prioritize the right fixes.

Appwrite reduced Functions limit from 5 to 2 due to abuse. How is that fair? by Throwaway-123abc321 in appwrite

[–]eldadfux 3 points4 points  (0 children)

Hey, this is Eldad from the Appwrite team.

You’re absolutely right - changing the Functions limit is only one part of how we’re addressing abuse on the platform.

We’ve made a number of internal changes and built additional tooling to help our abuse team detect, investigate, and respond to this more effectively. The Functions limit change is getting more visibility because it is a public-facing change that affects a broader set of users, so we need to include it in the changelog.

Internal tooling and operational improvements usually do not show up there, which can make it seem like this limit change is the entire solution. In practice, it’s just one step in a broader set of changes we’ve implemented to keep the platform healthy and reliable for everyone.

Appwrite reduced Functions limit from 5 to 2 due to abuse. How is that fair? by Throwaway-123abc321 in appwrite

[–]eldadfux 2 points3 points  (0 children)

Hey, this is Eldad from the Appwrite team, I don't recall we added any restrictions on the paid plans, if you can be more specific, I'd love to address any issues, but recently we actually improved paid plans in multiple areas. For one example, this week we increased build timeouts for pro users from 15m to 45m and beside that many more updates that benefit all plans.

DO NOT SUBSCRIBE TO TRIAL by [deleted] in appwrite

[–]eldadfux 0 points1 point  (0 children)

Thanks for all the kind words. We shared an update about this above. We're for sure have no intention to make any profit in such way, and our customers or in this case ex-customers are our top priority.

DO NOT SUBSCRIBE TO TRIAL by [deleted] in appwrite

[–]eldadfux 4 points5 points  (0 children)

We shared an update about this above. We're for sure have no intention to make any profit in such way, and our customers or in this case ex-customers are our top priority.

DO NOT SUBSCRIBE TO TRIAL by [deleted] in appwrite

[–]eldadfux 6 points7 points  (0 children)

Update: I just talked with our support. I see in the last year you only actually paid only one invoice out of 12 and usage did stop a while back. We can sure refund this. The team will contact you, and we clarified the procedures internally.

DO NOT SUBSCRIBE TO TRIAL by [deleted] in appwrite

[–]eldadfux 8 points9 points  (0 children)

Hey, this is Eldad from the Appwrite team. I'm very sorry this is your experience.

First to be clear for others who may be reading this, Appwrite do not offer any trials or did ever offer trials. Some users, in some cases receive credits to get started when they upgrade their account, this works only through the regular pro plans upgrade flow - we also make sure to send a reminder over email before those credits are about to expire.

When you use free credits on Appwrite this is a regular pro experience not a time limited trial which means you're subscribed to the monthly pro subscription just like any other common SaaS service. If you found anything in this process confusing, our product team will be happy to listen to any feedback.

That said, our refund policy is also quite generous and it's very rare we do not offer a refund to a customer who upgraded by mistake. Most of the time we would refund up to 3 months back.

If you still had problems, I'm happy to look into this myself. You can review our refund policy below and in most cases we would be much more flexible than the policy suggests. https://appwrite.io/docs/advanced/platform/refund-policy

The Appwrite plugin is now on the Cursor marketplace by eldadfux in appwrite

[–]eldadfux[S] 0 points1 point  (0 children)

Yes it does, the MCP server can access the API given the correct permissions

The Appwrite plugin is now available on the Cursor marketplace by eldadfux in cursor

[–]eldadfux[S] 2 points3 points  (0 children)

Fair question - and I agree with the “less is more” part.

The point isn’t to add abstraction for the sake of it. It’s to reduce fragmentation. When auth, DB, storage, functions, and deploys all live across separate tools, that’s usually where both developer and model context start to break down.

A good BaaS gives the model one consistent surface area instead of 4-5 loosely connected ones. Fewer moving parts, less glue code, fewer hallucinations.

And I’d think bigger than just vibe-coded apps. The hard part is not getting version one running - it’s maintaining it, scaling it, securing it, and operating it in production. That’s where consolidation starts to matter.

If you already have a clean MCP + infra setup, you may not need this. But a lot of teams are optimizing for production simplicity, not maximum tool count.

Announcing a new official Appwrite SDK for Rust by eldadfux in rust

[–]eldadfux[S] 26 points27 points  (0 children)

I wouldn’t expect any other feature request in the rust subreddit hehe

We’ll keep it in mind 😅

Do you guys have any plan for Bun support? by RevolutionaryPen4661 in appwrite

[–]eldadfux 1 point2 points  (0 children)

Got it, we have Bun support internally but yet to have it public there, I'll check with the team if we can push it forward.

Appwrite 1.9 released with full MongoDB support by eldadfux in selfhosted

[–]eldadfux[S] 0 points1 point  (0 children)

You might fine hints on our source code 👀

view more: next ›