When the Community Edition is enough and when Plane's paid edition is needed
A team that wants a self-hosted Plane tracker has to decide whether the free edition covers its identity and workflow needs. The Community Edition is AGPL-3.0 and matches the Cloud Free feature set, according to Plane's editions documentation. It is the better choice when the team is small, nobody has mandated single sign-on, and the team is comfortable with the AGPL-3.0 license and with running its own upgrades. Community changes deliberately and has its own codebase and release cycle, so the team takes on upgrade timing itself. Before committing, confirm with Plane which upgrade cadence and security notification process applies to the Community line, since those details are the operating cost of staying free.
The paid path starts with the Commercial Edition. On the self-hosted side, SAML and OIDC are unavailable on Free and become available on Pro when self-hosted, LDAP is Enterprise only, and workflows start at Business, per Plane's pricing page. Choose the Commercial Edition when your identity provider must enforce single sign-on, when access must follow directory groups, when approval or status workflows are required, or when you need vendor support rather than community support. Note that the switch is a prerequisite: a Community install must move to the Commercial Edition before a paid plan can be applied, so plan that change as part of the purchase, not after it. Check Plane's pricing page against your required features before deciding.
Treat the decision as a checklist rather than a preference. List every requirement that depends on SSO, directory sync, workflows or audit logs, then map each one to the plan that includes it. Ask Plane to confirm in writing which plan and edition covers each item, the seat count your roles require, and whether license and seat sync are the only outbound calls in your environment. If none of those requirements apply and your team stays under the free seat limit, Community remains a sound starting point, and the Commercial Edition can still be evaluated later without changing your data model.
Feature split between Community and Commercial editions
This table compares the Plane features that the documented edition split affects, with the Community Edition on one side and the Commercial Edition on the other. Read each row against the plan that unlocks it, because a capability marked as available on a paid plan still requires the Commercial Edition and a license key. Confirm current feature lists on the Plane pricing page before you buy, since plan contents can change.
| Capability | Community Edition (AGPL-3.0) | Commercial Edition (proprietary) |
|---|---|---|
| Feature parity | Matches the Plane Cloud Free tier | Full feature parity with Plane Cloud |
| Free seats | Free tier limited to 12 users | 12 free user seats per workspace, then billed by paid-role users |
| SAML and OIDC | Not available on the Free tier | Available on Pro only when self-hosted; included on Business and Enterprise |
| LDAP | Not available on the Free tier | Enterprise plan only |
| Workflows | Not available on the Free tier | Start at the Business plan |
| API-enabled audit logs | Not available on the Free tier | Listed as an Enterprise feature |
| Jira importer | Not stated for Community; confirm with Plane | Available on all plans of the self-hosted Commercial Edition, including Jira Cloud and Jira Server or Data Center |
| Airgapped deployment | Not part of the Community Edition | Airgapped Edition extends the Commercial Edition for offline networks |
| Edition switch to buy a plan | Must switch to Commercial before any paid plan applies | Paid plans apply through a license key on this edition |
How licensing, support and updates differ by edition
Plane ships three self-hosted editions, and each one has its own codebase and release cycle. The cards below cover what each license and edition implies for your team, so you can decide which one fits before you install anything.
Community under AGPL-3.0
The Community Edition is licensed under AGPL-3.0 and matches the feature set of the Plane Cloud Free tier. It has no paid plan of its own, so a self-hosted Community install cannot buy SSO, LDAP or workflows directly. Its codebase changes deliberately, so check whether the features your team needs are already in the Community release line. If you modify the code and offer the modified version to users over a network, the AGPL-3.0 source-sharing duties may apply, so confirm them with counsel.
Commercial as closed source
The Commercial Edition is proprietary and carries full feature parity with Plane Cloud. Its codebase and release cycle are separate from Community, and it moves faster. Plan for a license key and seat counting: the Commercial Edition includes 12 free user seats per workspace, and billing counts users with paid roles. Before you buy a paid plan, you must switch from Community to Commercial, so budget the switch as a planned change window.
Airgapped as offline extension
The Airgapped Edition extends the Commercial Edition for networks with no outbound internet access. It is the option to evaluate if your change control or data residency rules block the license and seat sync traffic that Plane describes for Commercial. Confirm with Plane how license validation, updates and seat reporting work on an offline network, and who in your organization owns the offline update process.
No forced migrations between editions
Plane states there are no forced migrations between editions. You are not pushed onto Commercial or Airgapped on a fixed date, so a Community install can stay where it is for as long as it meets your needs. The trade-off is that moving to a paid plan is always your decision and always a switch. Ask Plane to confirm in writing what a switch involves for your version, data and upgrade path.
How seats and license keys work on the Commercial Edition
A self-hosted Plane install that moves to the Commercial Edition does not need a license key to start. Plane says Commercial Installs run on the free tier until a license is applied, and that tier includes 12 free user seats per workspace. Plan the seat count against that allowance before you buy anything, because the first paid decision is whether your active users fit within 12 or whether you need a plan that bills for more. The Commercial Edition is only needed as a step toward a paid plan, so a team that stays within the free seats gains nothing from the switch except access to the code path that paid plans use.
Seats are not counted by workspace members in general. Plane counts users with paid roles for billing, so the number to track is how many people hold roles that trigger a charge, not the total invite list. Review role assignments before a renewal or a plan change, and record who holds which role in your change log. Ask Plane to confirm in writing how guest, viewer and admin roles are counted on the plan you are considering, since role-based billing rules are the most common source of surprise invoices.
Plane states that license and seat sync are the only required outbound calls for a self-hosted Commercial install. Before you plan a restricted or air-gapped network, confirm with Plane exactly what is sent, how often, and what happens to a license when the instance cannot reach the service for an extended period. The Plane self-hosted page describes the sync behavior at a high level, but the Airgapped Edition is the separate product for offline networks, so ask whether the Commercial Edition with a license key is acceptable under your network policy or whether the Airgapped Edition is the correct route.
What you pay for in each edition and what Plane publishes
This table separates what Plane publishes from what you pay for in your own environment, by edition and by cost type. Read it as a checklist: published plan fees are a fraction of total ownership, and the rows marked one-time or recurring show where the rest of the spend sits.
| Cost component | Who is paid | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Community Edition software | Nobody; the code is AGPL-3.0 and free to run | Not applicable | Licence cost is zero, so the total depends on infrastructure and staff time |
| Infrastructure for PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage | Your cloud provider or data center vendor | Recurring | Team size, attachment volume, high availability design and whether you use managed services |
| Commercial Edition with 12 free seats | Nobody for the first 12 users per workspace | Recurring at no charge within the free tier | Keeping paid-role users under 12 avoids plan fees; the edition switch itself is a one-time change |
| Pro plan per user | Plane, per paid user | Recurring; published at 6 to 8 US dollars per user per month on Plane's pricing page, depending on billing cycle | Number of paid-role users and whether you pay monthly or annually |
| Business plan per user | Plane, per paid user | Recurring; published at 13 to 15 US dollars per user per month on Plane's pricing page, depending on billing cycle | Adds workflows and other Business features, so compare the feature list against your needs before upgrading |
| Enterprise Grid | Plane, by negotiated agreement | Recurring; priced on request, so ask for a written quote | LDAP, audit logs and scale requirements; get the scope and renewal terms in writing |
| Migration, installation and setup | Your internal team or an implementation partner such as DeployOpen, under a written scope | One-time | Data volume, the edition switch and integrations; DeployOpen does not publish prices of its own |
| Operations: updates, backups and on-call | Your internal team or a retained support provider | Recurring | Release cadence, uptime targets and whether Plane is self-hosted on your own cluster |
Moving a self-hosted Community install to a paid plan
This sequence takes a self-hosted Plane Community install to a paid plan through the Commercial Edition, with a tested backup, a verified seat count and a license key applied before any SSO or LDAP is turned on.
Confirm the feature need first
Before any change, the platform owner lists the features that justify a paid plan, such as SAML or OIDC single sign-on, LDAP, or workflows. Check the current feature split on Plane's pricing page, since SAML and OIDC, LDAP and workflows sit on different plan tiers. Ask Plane which plan includes each required feature for self-hosted use. The step is complete when the team has a written list of required features mapped to a named plan and a named owner who approves the purchase.
Back up and test the switch in staging
Before touching production, take a full backup of the PostgreSQL database and the S3-compatible object storage that holds attachments. Restore that backup into a staging environment that mirrors the production deployment, then run the switch there. The platform team or DeployOpen, if engaged, performs the restore and records the results. The step is complete when the staging instance starts cleanly, users can sign in, and issues and attachments open as expected.
Switch from Community to Commercial Edition
Switching to the Commercial Edition is the required step before any paid plan can be bought, because the Community Edition does not accept a license key. Plane documents this as a move the self-hosting team performs on its own install, so the platform owner should follow the editions documentation and the installation method the team already uses, Docker Compose or Kubernetes with Helm. Confirm the exact procedure with Plane before the production change. The step is complete when the instance reports the Commercial Edition and still runs on the free tier.
Install through the Prime CLI on the free tier
Plane's self-hosted documentation states that Commercial Edition installs through the Prime CLI run on the free tier until a license is applied. The platform engineer completes the install on the staging instance first, checks that the free feature set and the 12 free seats behave as expected, and confirms the outbound calls. Plane states that license and seat sync are the only required outbound calls, so the network team should allow those and review any firewall rules that block them. The step is complete when the install is stable on the free tier and the outbound traffic matches what Plane documents.
Apply the license key and check the plan
The workspace owner applies the license key obtained through the purchased plan to the staging instance, then confirms in the admin console that the plan name and enabled features match the order. Review any feature that depends on the plan, such as SSO or workflows, and note any feature that stays disabled. Repeat the same steps on production during an agreed change window. The step is complete when the admin console shows the purchased plan and the license is active on both environments.
Verify seat counts against paid roles
Plane counts billable seats by users with paid roles, and the Commercial Edition includes 12 free user seats per workspace. Before the license goes live, export the user list with roles, compare the count of paid-role users with the number of seats the team has purchased, and remove or downgrade accounts that should not be billed. The team should also agree on who approves role changes, since new members with paid roles increase the bill. The step is complete when the paid-role count matches the purchase and the finance owner signs off on it.
Enable SSO or LDAP after testing
Enable SAML, OIDC or LDAP only after the license is active and the directory settings have been tested on staging with a pilot group of accounts. The identity engineer checks sign-in, group mapping and the behavior of users who should be blocked, then records the test results. Enable the feature in production during an agreed window and keep the local admin login available as a recovery path. The step is complete when test accounts sign in through the identity provider or directory, and the recovery path is documented and tested.
Confirm the rollback route with Plane
Before the change, ask Plane in writing how the team would return from the Commercial Edition to the Community Edition if the paid plan no longer fits, and what that move would require for data, license keys and seat sync. Plane's editions documentation states that there are no forced migrations between editions, but the reversal path should be confirmed for the specific deployment rather than assumed. The step is complete when Plane's answer is filed with the change record and the backup from the earlier step is verified as restorable.
Questions teams ask before buying a Plane plan
What does switching from Community to Commercial Edition cost in effort, and who does the work?
The switch itself is a deployment change, so the cost is mostly effort, not a license fee. Plane's editions documentation says a self-hosted Community install must first move to the Commercial Edition before a paid plan can be applied. Your own platform team does this work if it runs the install, or DeployOpen can do it under a fixed scope agreed in writing. Ask Plane which steps the switch involves for your install method, and ask your team how long a change window and rollback plan would take in your environment.
Can our team switch Plane editions without outside help?
A team that already runs containerized services can usually handle the switch, but it needs the right skills and components in place first. Docker Compose or Kubernetes with Helm knowledge is required, along with PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage such as MinIO. Plane's Kubernetes documentation notes that the Helm chart can point each of these at an external managed service, which changes what your team operates. Confirm with Plane which components your chosen method needs and check your own skills before deciding who holds the change.
How long does the switch take, and what drives the duration?
Plane does not publish a duration for the switch in the sources available for this page, so confirm the timeline with Plane and with your own team. The main drivers are the install method (Docker Compose is positioned for small and mid-size teams, Kubernetes with Helm for high availability), whether the database and object storage are external or bundled, the number of environments that must be updated, and how many change approvals the production instance needs. Backup and restore testing before the change usually takes more time than the switch command itself, so plan for it explicitly.
Do the 12 free seats cover a pilot?
The 12 free seats work for a small pilot if the pilot stays within that count. Plane's editions documentation says the Commercial Edition includes 12 free user seats per workspace, and billing counts users with paid roles. Count the people who will hold paid roles, not just the people who log in, because the seat count is driven by role assignments. If the pilot needs more users or paid features such as SSO, you will move to a paid plan, so confirm the seat rules with Plane before you invite a wider group.
Do LDAP and SSO require the Enterprise plan on Plane?
It depends on which protocol you need. Plane's pricing page lists SAML and OIDC as unavailable on Free, available on Pro only when self-hosted, and included on Business and Enterprise. LDAP is listed as an Enterprise feature. If your directory is LDAP and you need that integration, you will need the Enterprise plan. Confirm the current feature matrix on Plane's pricing page before you commit, because plan contents can change.
What should we ask Plane for in a quote?
Ask for a written quote that names the plan, the seat count and how Plane counts users with paid roles. Request the price per user per month for the billing period you choose, since Pro and Business are listed at different monthly and annual rates. Ask which features the plan includes for self-hosted installs, including SAML, OIDC, LDAP and workflows, and whether the license and seat sync outbound calls fit your network policy. Ask for the support terms, the upgrade cadence for the Commercial Edition and any conditions on Airgapped use if your network is offline.
What does DeployOpen do if we need help with the switch?
DeployOpen plans, implements, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. For a Plane switch, that could cover preparing backups, applying the Commercial Edition and license, and documenting the result. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the scope in writing before any work begins.
When outside help is worth it for an edition decision
Moving a self-hosted Plane install to a paid plan means switching from the Community Edition to the Commercial Edition first, and that switch is the point where an internal team takes on real work. The steps are identity integration testing for SAML or OIDC sign-in, reconciling seats so that users with paid roles are counted correctly for billing, taking a verified backup of PostgreSQL and object storage before any change, and then running upgrades on whichever codebase you choose. Plane states that there are no forced migrations between editions, but the reader still owns the test plan, the rollback path and the upgrade calendar on the new codebase. Confirm with Plane which of these steps its documentation covers for your deployment method, and which you must design yourself.
An internal team can usually handle this alone when it already runs Plane (or a similar PostgreSQL, Redis and S3-compatible stack) in a staging environment, has an identity administrator who can test sign-in against a non-production workspace, and can take the change in a planned window with a tested restore. Under those conditions the work is mostly configuration and verification, and keeping it in-house preserves knowledge. If your team has not restored a backup of this stack before, or the Kubernetes deployment with Helm is new to them, the first switch is a poor place to learn. The same applies when the only identity test is a live login by one administrator. A fixed-scope engagement helps when the written scope can name the systems to be tested, the acceptance criteria for each identity path, the seat reconciliation method and the rollback steps, with deliverables agreed before work starts. DeployOpen plans, implements, integrates, backs up and documents self-hosted platforms inside the client's own infrastructure, so it fits when a defined switch and a documented handover are the goal. It does not produce audit evidence or certification, and it does not estimate prices here, so request a quote against a written scope.
Outside help is also worth weighing for ongoing upgrades, which recur after the switch. Each edition has its own codebase and release cycle, so the Commercial Edition will move on its own schedule, and a Community install changes more deliberately. Ask whether your internal team can absorb a regular upgrade, regression test and rollback drill on the codebase you select, and who owns that work after the first release. If the answer is unclear, a retainer for upgrades and continuous support is the structure to ask about, with the upgrade window, test coverage and escalation path written down. Before committing, read Plane's editions documentation and confirm the current seat and license rules directly with the vendor.
How DeployOpen scopes, delivers and supports a Plane deployment
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Plane, that means working out which edition and seat model fit your team before any install, then delivering the chosen setup in your cloud account, data center or air-gapped network under a written scope.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We confirm whether you need Community Edition parity with Cloud Free or the Commercial Edition with paid plan features.
- We document your user count, paid-role mix, SSO and LDAP needs, and whether an edition switch is in scope.
How we build
- We install Plane with the deployment method that matches your team, using Docker Compose or the Helm-based Kubernetes guide.
- We connect PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage, either bundled or as external managed services you choose.
- We test sign-in paths, backups and upgrade steps in your environment before handing anything over to your team.
How we hand over
- We document the edition in use, license key handling, seat counting rules and the outbound calls your network must allow.
- We deliver runbooks for upgrades, backups and restores, written for the operators who will run Plane after the engagement.
- We provide an itemized handover list so your team can confirm each deliverable against the written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial delivery.
- We can prepare an upgrade plan for each Plane release channel, so your team knows when and how changes land.
- Before any future edition switch or plan change, we review the impact on seats, licensing and your identity setup with you.
