Please reconsider removing multi-organization support from self-hosted Appwrite

[RafaelTuber]

Hi Appwrite team,

I’d like to share some feedback about the recent change that limits self-hosted Appwrite instances to a single organization.

I personally did not like this change, because multi-organization support was one of the main reasons I migrated all of my projects from Supabase to Appwrite.

I manage multiple companies, and the previous organization model worked extremely well for my use case.

For example, I could structure my Appwrite instance like this:

• Organization: Company A

  • Project 1
  • Project 2
  • Team members from Company A

• Organization: Company B

  • Project 1
  • Project 2
  • Team members from Company B

• Organization: Company C

  • Its own projects and team members

This allowed me to keep everything inside a single Appwrite installation while maintaining a very clear separation between companies, projects, and development teams.

For someone managing multiple businesses, agencies, clients, or internal development teams, this is a very valuable feature.

I understand where the organization limit is implemented, and technically I know that I can modify the source code to remove the restriction. However, I don't think maintaining a custom fork should be necessary for such an important use case.

Every time a new Appwrite version is released, I would need to:

• Update my fork
• Check whether the organization logic changed
• Reapply the modification
• Build and maintain my own Docker image
• Make sure the customization remains compatible with future versions

This creates unnecessary maintenance for something that previously worked natively.

I strongly believe the Appwrite team should reconsider this decision.

At minimum, it would be great to have an official self-hosted configuration option, such as an environment variable, that allows administrators to enable multiple organizations if they choose to.

Something conceptually like:

_APP_CONSOLE_MULTI_ORGANIZATIONS="enabled"

This way, users who prefer the simplified single-organization model could keep the default behavior, while developers and companies that need multi-organization architecture could enable it themselves.

In my opinion, multi-organization support is actually a competitive advantage for Appwrite.

It makes Appwrite much more attractive for:

• Developers managing multiple businesses
• Agencies managing different clients
• SaaS builders
• Software houses
• Consultants
• Teams that want strong separation between different companies or business units

In my case, this capability was important enough that it influenced my decision to move away from Supabase and adopt Appwrite.

Removing it from self-hosted installations feels like a significant step backward for this type of workflow.

I really like Appwrite and I want to continue using it, which is exactly why I think this limitation should be reconsidered.

Please consider bringing multi-organization support back to self-hosted Appwrite, or at least provide an officially supported option to enable it.

Possible implementation

A simple approach could be to keep the current behavior as the default while allowing self-hosted administrators to explicitly opt in to multiple organizations.

For example:

_APP_CONSOLE_MULTI_ORGANIZATIONS="enabled"

I understand that the actual implementation may require additional internal changes, but conceptually the behavior could be controlled by an opt-in environment variable like this.

The existing check:

protected function isOrganizationLimited(Document $project): bool
{
    return $project->getId() === 'console';
}

could conceptually become something like:

protected function isOrganizationLimited(Document $project): bool
{
    return $project->getId() === 'console'
        && getenv('_APP_CONSOLE_MULTI_ORGANIZATIONS') !== 'enabled';
}

This would preserve the current single-organization behavior by default:

• Variable missing → single organization
• disabled → single organization
• enabled → multiple organizations

This would be fully opt-in and would not change the default behavior for existing self-hosted installations.

Thanks for considering this feedback.

[kazepoy]

Since Appwrite 2.1.0 (released September 11, 2026; PRs #13585 and #13608), a self-hosted instance refuses to create an organization once one exists (403 organization_creation_prohibited). Appwrite Cloud is not affected.

Up to 2.0.0, including 1.9, an instance could have several: the one-organization rule was only enforced by the console and per account, so each new account could get its own. No environment variable lifts the new limit.

We are worried that this change, shipped as a minor fix with no setting to disable it and liftable only by other "editions", We hope this is not a sign that features of the open-source self-hosted edition are moving to a paid edition.

NB: An organization is just a row (with Postgres) in _console_teams (members in _console_memberships), with no flag: the check only counts rows at creation time. Upgraded instances therefore keep their existing organizations but cannot create new ones.

[RafaelTuber]

Since Appwrite 2.1.0 (released September 11, 2026; PRs #13585 and #13608), a self-hosted instance refuses to create an organization once one exists (403 organization_creation_prohibited). Appwrite Cloud is not affected.

Up to 2.0.0, including 1.9, an instance could have several: the one-organization rule was only enforced by the console and per account, so each new account could get its own. No environment variable lifts the new limit.

We are worried that this change, shipped as a minor fix with no setting to disable it and liftable only by other "editions", We hope this is not a sign that features of the open-source self-hosted edition are moving to a paid edition.

NB: An organization is just a row (with Postgres) in _console_teams (members in _console_memberships), with no flag: the check only counts rows at creation time. Upgraded instances therefore keep their existing organizations but cannot create new ones.

I managed to create a shell script that re-enables this multi-tenancy functionality, and I'm thinking about releasing it to the community.