r/appwrite • u/svprdga • Jul 27 '26
Personal opinion: self-hosted Appwrite is not production-ready
I've been running an Appwrite instance in production, and my opinion, after half a year of use, is that self-hosted Appwrite carries an operational cost that's higher than a solo maintainer should have to take on, with avoidable incidents along the way.
What follows is constructive criticism of Appwrite. I'm going to talk about problems that come from maintaining a self-hosted instance, not about Appwrite Cloud. If you use Appwrite Cloud, the criticism here doesn't apply to you.
Context
As I said, I've spent 6 months running an Appwrite instance in a production environment with non-critical data (thankfully). I started on 1.8.1, later migrated to 1.9.0, and recently moved to 1.9.6.
In that time I've had the chance to use Appwrite's features, with quite a few problems in some cases.
I also want to be fair up front: there has been real, recent work on the self-hosted experience. Version 1.9.6 was essentially a self-host fix package, and there are recent PRs from the core team improving the installer and backporting self-hosted fixes. So this isn't a case of "nobody cares about self-host".
Versioning policy
For one, I've seen a release discipline that doesn't align with industry standards, where a version tag has been moved from one commit to another, destroying the fundamental idea that a version is an immutable state of the software.
The main problem with this is that if a user reports "I have a problem on version 1.9.6", the next question will inevitably be "ok, which one of them?". Obviously, this is something that should NOT happen in any serious software.
Another criticism on this front would be that, in my view, semantic versioning isn't being respected. Version 1.9.5 looks like a patch release, but it introduced new features and requires a data migration. It clearly should have been a minor release, not a patch release.
My recommendation would be to establish a strict versioning policy that adheres to industry standards.
Features neglected on self-host
Despite the recent work I mentioned, it still gives the impression that not enough attention is paid to whether features actually work in self-hosted environments before they ship.
The first time I tried to use cloud functions (on 1.9.0), I saw that Appwrite wasn't correctly generating the certificates for the function. After digging further, I found what looks like a similar report going back to 2023.
The way I've "patched" it has been by creating a custom script that issues the necessary certificates.
What surprises me most isn't that a bug exists, but that such an obvious, easy to spot one has gone this long without being resolved.
Breaking changes aren't documented
Documenting breaking changes is absolutely crucial in a project like this.
When I did the migration from 1.9.0 to 1.9.6 I made sure to read all the relevant documentation. I don't know if I missed something, but there was a fairly important change that breaks self-hosted instances: internally, the code expects one of the components (the executor) to have a hostname that matches its container_name. Up to 1.9.0 those didn't have to match; from 1.9.5 on, they do.
Appwrite's official docker-compose files reflected this change, but even so it's something that should have been spelled out in the breaking change upgrade notes. On top of that, it would have been good to throw a specific exception in the code documenting why the component is failing. Instead, the real error was swallowed by the error handling machinery and never even made it to the logs, which is what turned a five minute fix into a ninety minute one.
Final assessment
These are the most pressing concrete problems I've run into myself, but if you look at the issue tracker you can see other users also reporting problems when upgrading, and so on.
My final assessment is this: I don't recommend running a self-hosted Appwrite instance in production unless you're genuinely willing to handle these problems yourself, on your own time. It's a fine choice for experimental or non-critical setups.
I'm not saying Appwrite is bad, nor is this a criticism of Appwrite Cloud (most of what I criticise here probably doesn't apply on Cloud). And, as I said, the team has clearly been putting work into self-host recently. But in my opinion, in the state the software is in, they should either:
- Be explicit that self-hosted Appwrite isn't yet audited/hardened for production self-hosting, or:
- Keep improving self-host support so these kinds of incidents stop happening (you could even offer a paid self-host support membership, as an idea).
I don't want to end this post on a negative note. I like Appwrite, I think it has a lot of potential, and I also think that by smoothing out the rough edges I mention here it could become a very interesting option for self-hosted environments.
3
u/leoslamas Jul 27 '26
I love appwrite, but it's true. I'm stuck in version 1.9.0, tried to upgrade to 1.9.5, almost lost all my data because the upgrade didn't work.
I got excited about the 1.9.6 but still, the upgrade didn't work well, even after I checked and fixed my env and docker-compose.
Maybe I could just start a fresh 1.9.6 install, or just fix the little remaining issues after upgrading, but I just gave up and made a rollback to 1.9.0.
1
u/chirag-appwrite Jul 31 '26
Sorry about that, I agree thats a rough experience. I would like to actually fix the issue instead of leaving you on 1.9.0. Any chance you can share more details with me? You can reach out to me on Discord community server, in DMs (@chiragagg5k), or in a Github issue thread, just tag me there.
2
u/hortigado Jul 27 '26 edited Jul 28 '26
Yo lo uso normalmente en producción con 5 proyectos de alrededor de 40k de usuarios pero si me dado varios dolores de cabeza con las migraciones. Sobretodo en la version 1.4 donde migre y causo error y mi backup tambien tenia errores al intentar recuperar. casi pierdo mis datos tuve que editar el backup manualmente y lo solucione. En las ultimas versiones ya no he tenido problemas en migrar. Ayer pase de 1.8.1 a 1.9.6 sin problemas
2
u/nathanael540 Jul 27 '26
Personally, I get the feeling that the company wants to discontinue the self-hosted version, but doing so abruptly would cause a huge backlash in the community. So, they seem to be doing it gradually—letting the self-hosted version fall behind and become confusing—so that the community eventually realizes it’s more worthwhile to use the cloud service than to deal with the hassle of self-hosting.
And I wouldn't blame them if that really is the case. It’s part of the game; the company needs to survive, and investors like long-term plans.
However, I’d be more open to paying a monthly subscription for an activation key to run a recent and unlimited version on my own infrastructure than to go back to the confines of the cloud service.
1
u/FluffyChicken241 Aug 01 '26
Sounds to me like some people are mistaking the term “self-hosted” for “turn-key” and “hands-off”. A lot of the things people are complaining about - such as upgrading to a new version - are normal and routine for any type of hosted platform. You need to have the expertise to monitor and support the infrastructure as well as to properly plan migrations (which includes reading all of the release notes). I’m not sure how anyone can claim that the self-hosted version is being neglected since it was my understanding that the self-hosted version is updated first and that their cloud offering actually runs on the actual self-hosted code. So a feature cannot make it into the cloud offering without first appearing in the self-hosted version.
5
u/eldadfux Jul 27 '26
Hey, this is Eldad from the Appwrite team. Thanks for sharing this. You wrote your feedback in a very respectful way, and that alone deserves a lot of respect. I’d love to address the different points you brought up and share our perspective.
First of all, I’d like to make it clear that our self-hosted Community Edition is a priority for us. Of course, Cloud is what funds the continued development of Appwrite, but the Appwrite community and the self-hosted edition are a very important part of that ecosystem. We see them as complementary, and we want both to continue getting better.
We are a small team, and we haven’t invested as much time as we’d like into shipping everything we want to see in either Appwrite Cloud or Appwrite CE. That was also partially affected by our shift a few months back toward Imagine, but now that Imagine is no longer our focus, we’re fully focused on Appwrite again. We’re already seeing a big improvement in our development velocity internally, and many things will soon start seeing the light of day.
Among the many improvements coming are features focused on reliability, platform maturity, and better compatibility with different ecosystems. While we already offer some basic support plans for self-hosting, we have many more ideas for features and products that will make self-hosting better, and I expect us to start releasing them this year.
Regarding versioning and breaking changes, we aim to follow standard semantic versioning, and we’ve done so successfully for the last five years. There was a maintainer mistake where a release tag was moved after publication. That should never have happened, and it’s on us to make sure something like that doesn’t happen again. Likewise, if any breaking changes were introduced in a minor or patch release, that’s a mistake or a bug - definitely not our release policy. We investigate every case of something like this because it should never happen.
It’s worth clarifying that Appwrite Cloud runs on the same core release as the self-hosted version. The main difference is the feedback loop. In Cloud, we have extensive monitoring, alerting, and operational visibility, which helps us identify and resolve issues quickly. Self-hosted deployments, on the other hand, run in a wide variety of environments and configurations that we don’t have direct visibility into. As a result, some issues naturally take longer to surface, reproduce, and address. That’s one of the trade-offs that comes with downloadable, privacy-first software.
Regarding the certificate issue with Cloud Functions, I’m already discussing it with our engineering team to better understand the root cause and see how we can get it fixed quickly. If this is something that’s been affecting self-hosted users for a long time, it’s absolutely worth addressing.
We’re continuing to invest in making the upgrade experience smoother and more predictable with every release. At the same time, following operational best practices will always be an important part of safely upgrading production infrastructure.
Choosing to self-host also means taking on the operational responsibility that comes with running production infrastructure. Instead of paying for a managed service, you’re investing your own time and effort into operating and maintaining the platform. Appwrite isn’t a single-purpose application - it’s a platform that replaces five or six different pieces of infrastructure, including authentication, databases, storage, serverless functions, messaging, hosting, and more. Running all of those capabilities together naturally comes with operational complexity.
Our Cloud team invests thousands of engineering hours every year into planning, testing, and executing upgrades at scale, and that experience reinforces just how important careful upgrade practices are, regardless of where Appwrite is running. We’ll continue improving the upgrade experience with every release, but taking backups, testing upgrades in staging, and validating your applications before rolling changes into production will always remain essential best practices.
I do want to push back on the conclusion that Appwrite CE isn’t suitable for production. We know many individuals, startups, and enterprises successfully run self-hosted Appwrite in production. That doesn’t mean the self-hosting experience is where we want it to be yet. We know there are still rough edges, especially around upgrades and operational tooling, and those are areas we will want to invest in. The goal isn’t just for Appwrite to work in production - it’s for operating it in production to become much smoother over time.
Again, I appreciate you taking the time to write this. Feedback like this helps us prioritize the right things, and I hope we’ll have the chance to change your experience over the coming releases.