Organization membership limit (100) is hardcoded and not configurable for self-hosted instances

[nizepart]

What problem will this feature address?

Self-hosted Dokploy instances hit a hidden member limit when an organization reaches 100 members. Users attempting to accept an invitation receive the error:

Organization membership limit reached

This limit comes from the better-auth organization plugin which defaults membershipLimit to 100 when the option is not explicitly set.

The current configuration in packages/server/src/lib/auth.ts does not expose this parameter:

organization({
    ac,
    roles: { owner: ownerRole, admin: adminRole, member: memberRole },
    dynamicAccessControl: { enabled: true, maximumRolesPerOrganization: 10 },
}),

Expected Behavior
Self-hosted administrators should be able to configure or remove the organization membership limit without modifying source code.

Actual Behavior
Once an organization has 100 members, no new invitations can be accepted. The only workarounds are:

Deleting existing members
Splitting users across multiple organizations (which fragments access to projects/servers)
Environment
Dokploy: self-hosted (canary)
better-auth: 1.5.4
Plugin: better-auth/plugins → organization()

Describe the solution you'd like

Add support for an ORG_MEMBERSHIP_LIMIT environment variable that gets passed to better-auth's membershipLimit option in the organization plugin configuration.

• When ORG_MEMBERSHIP_LIMIT is set (e.g. 10000), use that value as the limit
• When not set, preserve the existing default behavior (100)
• Extract limit resolution into a small testable helper for clarity and validation

This requires a one-line addition to packages/server/src/lib/auth.ts and a small helper module — no database migrations, no breaking changes.

Describe alternatives you've considered

1. Splitting users across multiple organizations — each org has its own 100-member limit, but projects/servers/git-providers are not shared between orgs, fragmenting the team's access.

2. Deleting inactive members via SQL — temporary fix, doesn't scale, and risks removing users who may return.

3. Hardcoding a higher value directly in auth.ts — works for a single fork but not configurable per-deployment and not suitable for upstream.

4. Patching better-auth itself — unnecessary since the plugin already supports membershipLimit as an option; Dokploy just doesn't pass it through.

Additional context

No response

Will you send a PR to implement it?

Yes