What upgrading and supporting self-hosted Plane involves
An upgrade to self-hosted Plane starts with one question: which edition does this instance run? Plane offers three self-hosted editions, Community, Commercial and Airgapped, and each is built on a distinct codebase with its own release cycle. A release published for Community does not automatically apply to a Commercial or Airgapped install, so the upgrade plan must follow the release line of the edition you actually operate. Confirm the edition and the exact running version before anyone pulls a new image or changes a chart value.
Upgrades usually come from one of five triggers. A new Community release is the most common. A move from Community to Commercial is a deliberate switch, needed when you want paid plans with a license key. Security patches arrive on their own timing and may be urgent. Dependency changes, such as a PostgreSQL major version, Redis or Valkey, RabbitMQ or the S3-compatible object store, can break an upgrade even when Plane itself is unchanged. A Kubernetes or Helm chart change carries the same risk. Each trigger should have a named owner and a short written record of what changed.
Small teams running Docker Compose with a dedicated administrator often handle routine upgrades in-house, provided they take a backup first and read each release note. Teams that need a fixed change window, a documented rollback, a Helm-based cluster or an edition switch usually benefit from a partner for the planning and the first upgrade cycle. Ask any partner for a written scope that names the edition, the target release, the backup and restore test, the rollback steps and who signs off the cutover. Ongoing support after that first cycle is a separate decision with its own scope.
What the work includes
The engagement breaks into one-time work that moves a self-hosted Plane instance to a current, supported state, and recurring support under a retainer. Each item below is agreed in writing before work starts.
Upgrade assessment
We record the current Plane edition, version, deployment method (Docker Compose, Kubernetes with Helm, Podman or an air-gapped install) and the external services each deployment depends on. The assessment identifies the target release and the upgrade steps between your version and that target. Confirm with us which edition your install runs before any other step begins.
Community to Commercial switch
A self-hosted Community install must move to the Commercial Edition before it can use a paid plan with a license key. We handle the edition switch, license key entry and seat mapping, so paid roles are counted correctly against your plan. This is one-time work, though seat counts change as people join or leave and should be reviewed when they do.
Pre-upgrade backup plan
We define and test a backup for each stateful component: PostgreSQL, object storage holding attachments and uploads, and the configuration and environment files. The plan records where each backup is stored, how it is restored, and who signs off before the upgrade starts. Ask us to demonstrate a restore, not just a completed backup job.
Upgrade run and rollback
We run the upgrade against the agreed target release in a planned window, following the sequence set in the assessment. A written rollback procedure restores the previous containers or Helm release and the verified backup if a step fails. Each upgrade is one-time work, and later upgrades are scheduled under the retainer.
Post-upgrade verification
After cutover we check that workspaces, projects, cycles, modules and pages open with their data intact, that integrations still send and receive events, and that identity login works through the configured SSO or local accounts. Results are recorded against a checklist you approve. Verification ends when you sign off, not when the upgrade job finishes.
Ongoing support scope
Under a retainer we review patches and new releases, triage release notes for changes that affect your deployment, and schedule upgrades with you. Support scope, included channels and any response expectations are defined in the retainer agreement, so confirm them there. Recurring work is quoted separately from the one-time upgrade scope.
What drives upgrade and support effort
This table lists the factors that change how much work each Plane upgrade and ongoing support cycle takes, why each one matters, and how to keep it manageable.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Edition in use and version gap | Plane ships Community, Commercial and Airgapped editions on separate codebases and release cycles, so each edition has its own upgrade path. The further an install sits behind the current release, the more changes must be reviewed and tested at once. | Confirm which edition you run, track its release notes, and upgrade in small steps on a regular schedule rather than letting the gap grow. |
| Deployment method | Docker Compose, Kubernetes with Helm, Podman and air-gapped installs each have different upgrade steps, rollback options and access to images. Air-gapped installs also need packages moved in by hand. | Document the exact method and its upgrade procedure, and keep a tested runbook for that method only. |
| Self-managed or external PostgreSQL, Redis or Valkey, RabbitMQ and object storage | Each self-managed service has its own version, patching, backup and failover work. Helm can point these at external managed services, which moves some of that work to the provider but adds connection and permission checks. | Decide early which services you run yourself, pin their versions, and confirm the upgrade order with the service owners. |
| Number of workspaces and seats | More workspaces mean more data to validate after each upgrade and more permissions to check. Seat counts also determine which plan and license terms apply, which can change the upgrade and support scope. | Keep the workspace list current, test a representative workspace from each group, and confirm seat counts against your license before scheduling changes. |
| Custom integrations and identity connections | SAML, OIDC or LDAP connections, importers, webhooks and any custom scripts depend on Plane's API and login behavior, so each upgrade may require retesting them. | Keep a list of every integration with its owner and a short test script, and retest them in staging before each production upgrade. |
| Number of environments | Each environment such as development, staging and production needs the same upgrade, data copy and verification. Environments that drift apart make results hard to compare. | Keep environments as close in configuration as practical, and promote the same tested version through each one in order. |
| Change-control and compliance evidence | Audit or internal review may require approval records, change tickets, backup proof and post-change test results. Gathering this evidence after the fact takes extra time. | Define the evidence list before the first upgrade, store records with each change, and confirm the required format with your assessor or internal audit team. |
| Backups before each upgrade | A restorable backup is the rollback path if an upgrade fails. Without a tested restore, every upgrade carries more risk and more troubleshooting time. | Take a backup of the database and object storage before each change, test restoring it in a separate environment on a set schedule, and record the results. |
How an upgrade engagement runs
The sequence moves a self-hosted Plane instance from its current release to a planned target with a tested rollback point and a documented handover.
Discover the current edition and deployment
We record the installed edition (Community, Commercial or Airgapped), the running version, the deployment method (Docker Compose or Kubernetes with Helm), and the external dependencies: PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage. The output is a written inventory that the client's platform team confirms against their own records.
Write the upgrade plan
The plan names the target release, the edition path (including any switch from Community to Commercial, which requires a license key for paid plans), the change window agreed with the client, and the order of dependency updates. It also lists who approves the change. The plan is complete when the client signs off in writing.
Rehearse the upgrade in staging
We restore a fresh backup of the production database and object storage into a staging environment that matches production's deployment method and configuration. We run the full upgrade there and record every step, error and manual correction. The rehearsal is done when the staging upgrade completes and the runbook reflects what actually happened.
Apply the production change
Immediately before the change, we take a new backup and record it as the documented rollback point. We then run the rehearsed steps in the agreed window and watch service health throughout. The step closes when the rollback point is recorded and the upgraded services report healthy.
Verify against a checklist
We check workspaces and projects for expected content and permissions, confirm each integration still syncs, test login through the identity provider, and send and receive a test email through the configured mail path. Each item is marked pass or fail with evidence. The step is done when every item passes or has an agreed follow-up.
Hand over the runbook and support scope
We deliver the updated runbook covering the new version, backup and rollback steps, and known issues from the rehearsal. The written support scope states what the client's team owns and what DeployOpen covers under any retainer. The handover closes when the client's operators walk through the runbook and the scope is signed.
What usually goes wrong and how to prevent it
Most Plane upgrade problems come from a small set of repeatable mistakes around editions, backups, configuration drift and silent integration failures. Each card below names one pattern and the check that prevents it.
Upgrading without the right edition line
Plane ships Community, Commercial and Airgapped editions, each on its own codebase and release cycle. Before any upgrade, confirm which edition is installed and that the target version belongs to the same edition's release line. Mixing lines can leave you on a version your edition does not publish, so check the editions and versions documentation first.
Switching to Commercial without a plan
Moving from Community to Commercial to unlock a paid plan requires a verified backup and the license key process in place before you change editions. Confirm who holds the license, how seats are counted by paid roles, and that a restore path exists if the switch fails partway. Test the procedure on a non-production copy first.
Backups that were never restored
A backup of the PostgreSQL database and the S3-compatible object storage is only useful if it restores cleanly. Schedule a restore into a separate environment before each upgrade, then open projects, cycles, modules, pages and attachments to confirm the data is complete. Record how long the restore took so the rollback window is known in advance.
Helm values drifting after upgrades
Chart upgrades can add, rename or remove values, and a file carried forward from an older release may silently override new defaults. Diff your current values file against the target chart's default values before applying changes. Keep environment-specific settings in version control so each upgrade produces a reviewable change.
External services changed out of sync
Plane can point PostgreSQL, Redis or Valkey, RabbitMQ and object storage at external managed services. When a database endpoint, credential, bucket name or storage region changes, the deployment keeps running on stale settings until something fails. Keep a register of every external endpoint and update it in the same change record as the Plane configuration.
Integrations and SSO failing quietly
SAML, OIDC and other identity connections, along with importers and any webhooks, can stop working after an upgrade without a clear error for users. Build a short post-upgrade test that signs in with a test account through each identity path, checks that role mapping still works, and confirms that outbound integrations deliver. Do this in staging before production.
Skipping release notes
Release notes are where configuration changes, removed environment variables and required migrations are announced. Skipping them is how an upgrade breaks a setting that appeared to work for months. Read every release between your current version and the target, list the required configuration actions, and assign an owner to each one before the upgrade window opens.
Which upgrade tasks stay in-house and which go to a partner
This table separates the Plane upgrade tasks that most teams keep internally from those they often hand to a partner, with the skills each task needs so you can match them to your staff.
| Task | Usually kept in-house | Usually outsourced | Skills the task needs |
|---|---|---|---|
| Routine patch review | Reading each Community release note and deciding whether it affects your workspace | Not usually outsourced | Release-note review, basic knowledge of your Plane feature usage |
| Owning the backup schedule | Setting frequency, retention and who can restore | Setting up the first backup and restore tests for PostgreSQL and object storage | PostgreSQL administration, object storage (S3-compatible) administration, backup tooling |
| Edition path planning | Deciding whether you need Community, Commercial or Airgapped | Mapping the edition change to your deployment, data and identity setup | Plane edition knowledge, architecture review, licensing review |
| First Helm or Compose upgrade cycle | Attending the change window and checking users after the upgrade | Running the first upgrade with pinned versions, config diffs and health checks | Kubernetes and Helm, Docker and Docker Compose, configuration management |
| Community to Commercial switch support | Confirming seat counts and which users hold paid roles | Executing the switch, license key setup and post-switch verification | Plane administration, Docker or Kubernetes, PostgreSQL migrations |
| Rollback rehearsal | Approving the rollback decision and communicating downtime | Rehearsing restore of database and object storage to a known-good version | PostgreSQL administration, Kubernetes and Helm, object storage restore, identity administration for test users |
| Business sign-off on workspace changes | Approving changes to projects, cycles, modules and permissions | Not usually outsourced | Workspace administration, knowledge of team process |
| User communication | Announcing maintenance windows and new behavior to teams | Not usually outsourced | Internal communications, support desk coordination |
| Runbook for future upgrades | Reviewing and adopting the runbook for your team | Writing the step-by-step runbook from the first cycle | Technical writing, Kubernetes and Helm, Docker, identity administration |
How the work changes by starting point
A single-node Community install on Docker Compose is the simplest upgrade path, but the plan still depends on the Community release cycle, which runs separately from the Commercial and Airgapped editions. Confirm the target version against the editions and versions documentation before scheduling anything.
- Plan: Read the release notes for each Community version between your current release and the target, and check whether any compose file or environment variable changes.
- Backup scope: Dump the PostgreSQL database, copy the object storage volume, and save the compose file and environment file together so you can restore the exact prior state.
- Verification: Log in as the admin, open a project with recent work items, upload and download an attachment, and confirm background jobs such as notifications still run.
- Approval: The single admin usually approves the change, but record a second sign-off from whoever owns the workspace data if the instance holds client or regulated project information.
Moving a Community install to a paid plan is a change of edition, not only a version bump. The instance must switch to the Commercial Edition before a license key can unlock paid plans, so the upgrade plan covers both the codebase switch and the seat count.
- Plan: Confirm the target plan and how seats are counted, since the Commercial Edition counts users with paid roles. Decide the cutover date and whether a rollback to Community is needed.
- Backup scope: Take a full database and object storage backup before the edition switch, and keep the Community images so the previous state can be restored.
- Verification: Confirm the license key activates, the expected plan appears in the admin console, and existing workspaces, roles and attachments remain intact.
- Approval: The budget owner approves the plan and seat count, and the workspace owner approves the cutover window. Ask the vendor or your procurement contact which terms apply to the license key.
The Kubernetes guide installs the Commercial Edition, and an external PostgreSQL and S3-compatible object storage add upgrade dependencies outside the Helm release. Each external service has its own backup and change window, so the plan must cover them together.
- Plan: Review the Helm chart changes between versions, the pinned image tags, and any changes to how the chart connects to the external database and object storage.
- Backup scope: Back up the external PostgreSQL database with tested point-in-time recovery, snapshot or export the object storage bucket, and export the Helm values file and secrets.
- Verification: Run a helm diff before applying, then confirm pods become ready, migrations complete, and uploads and background workers respond after the rollout.
- Approval: The platform team approves the Helm change, and the database owner approves any schema migration that touches the external PostgreSQL instance.
The Airgapped edition is proprietary and installed without internet access, so the upgrade needs offline media and a transfer process that your security team has approved. Plan the media transfer before the maintenance window, because the instance cannot pull new images on its own.
- Plan: Confirm the release package and images you need, verify their integrity against the vendor's published information, and list every artifact to carry across the boundary.
- Backup scope: Back up the database and object storage inside the network and store a copy of the current media set so the previous release can be reinstalled.
- Verification: Check the imported images match the expected versions, run the health checks offline, and confirm the license still validates without an external call.
- Approval: The security office approves the transfer process and media handling, the change board approves the release, and the owner of the cross-domain transfer records each import.
An instance that has missed several releases, or has manual changes to its compose file, Helm values or database settings, needs an audit before any upgrade. Upgrading a drifted install without a baseline makes it hard to tell whether a later problem came from the upgrade or from an earlier change.
- Plan: Record the running version, every local configuration change, and any custom environment settings. Plan intermediate upgrade steps if the vendor documents them for your path, and confirm this with the vendor.
- Backup scope: Capture the current configuration and a full backup before the first step, and take a fresh backup before each intermediate version.
- Verification: Compare the live configuration with the documented baseline, run the smoke tests after every step, and keep a log of each version reached.
- Approval: The platform owner approves each intermediate step, and the change owner signs off on the documented configuration baseline before the final release is accepted.
What your team needs to provide
Before any upgrade work starts, your team needs to provide access to the Plane host or cluster with privileges that allow pulling images, changing the running configuration and restarting services. For a Docker Compose install that means the Compose file and environment file in use; for a Kubernetes install it means the current Helm values file and the release name, so the upgrade can be planned against what is actually running rather than a default template.
Provide the database and object storage details as well: PostgreSQL and S3-compatible storage (for example MinIO) credentials, the locations of the most recent backups, and the restore procedure your team already uses. Also name a business owner who can approve the workspace after the upgrade, since the people who sign off on functionality are rarely the people who run the server. Agree a change window and any freeze dates for the project and for your organization in general, so the cutover does not land in a sprint close or a reporting period.
Decide on the license and plan position early. If you intend to use features that require a paid plan, a self-hosted Community install must first move to the Commercial Edition and be given a license key. Confirm which plan you are on, who holds the license, and who can approve a change of edition. Also confirm with Plane the supported upgrade path for your edition and check the edition and version documentation and the release notes for the target release. Finally, provide a staging environment or permission to create one, so the upgrade is rehearsed on a copy of your data first.
Questions about Plane upgrades and support
Can our own team upgrade self-hosted Plane, or should we outsource it?
Often yes, if your team already runs containers and PostgreSQL in production, because Plane publishes its self-hosting methods and upgrade steps. Plane offers Community, Commercial and Airgapped editions, each built on a distinct codebase with its own release cycle, so every upgrade starts with confirming which edition you run and which release notes apply. Consider outsourcing if no one on staff owns the stack, if upgrades keep slipping, or if you want a fixed scope with written deliverables. DeployOpen plans and runs these upgrades in your infrastructure and offers ongoing upgrades as a retainer.
How much effort does a Plane upgrade take and what drives it?
Effort depends on your install and the version gap, so no single figure fits every team. The main drivers are the edition, whether you run Docker Compose or the Helm chart on Kubernetes, and whether PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage are bundled or external. Customizations, identity integrations such as SSO, and the number of environments you must test also add time. Ask any partner for a written estimate that lists each of these inputs, and review the release notes for every version between your current release and the target.
Does moving from Community to Commercial keep our existing Plane data?
Plane's editions and versions documentation says a self-hosted Community install must first switch to the Commercial Edition before it can use a paid plan with a license key. Because the editions are built on distinct codebases, treat the switch as a planned migration and confirm in that documentation exactly what carries over for your install method. Test the switch on a copy of your data first and keep a restorable backup of the original instance. Plane's pricing page lists Pro at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month, with Enterprise Grid on request.
What must we back up before each Plane upgrade?
Back up everything the instance needs to restore to the exact version it runs today. In practice that means a consistent PostgreSQL dump or snapshot, the object storage bucket that holds attachments and uploads, and your environment files or Helm values. Record the current image tags so you can roll back. Check the release notes for whether anything in Redis or Valkey or RabbitMQ also needs saving. Restore the backup into a test environment and confirm logins, attachments and a sample project before you upgrade production.
What does ongoing Plane support cover, and what does it leave out?
Support scope is whatever your written agreement names. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Common items to list include upgrade execution, backup verification, monitoring follow-up and infrastructure changes. Items to confirm as excluded are fixes to Plane's own source code, new feature development, and your cloud or hardware costs. Make sure the quote states response expectations in writing before you sign.
Do we need a partner for an air-gapped or Kubernetes Plane install?
Not always, but a partner usually saves time when the install must run offline or on a high-availability cluster. Plane documents Kubernetes with Helm for high availability and air-gapped installs, and its Kubernetes guide installs the Commercial Edition, while the Airgapped edition is a separate proprietary build. Plan for external PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage, and for how images and updates reach an isolated network. Confirm with Plane which edition fits your air-gapped requirement and what its update path looks like.
How DeployOpen runs Plane upgrades and support
DeployOpen plans and carries out Plane upgrades inside your own infrastructure, starting from the edition you run and the release line you plan to reach. Ongoing support is available as a retainer once the instance is handed over.
How we scope
- We confirm which Plane edition you run, since Community, Commercial and Airgapped each follow their own release cycle.
- We inventory the deployment method, such as Docker Compose or Kubernetes with Helm, and the external database, Redis or Valkey, RabbitMQ and object storage in use.
- Engagements are fixed-scope, so the written scope states the upgrade path, any edition switch, the backup and rollback steps, and the deliverables before work starts.
How we build
- We take a verified backup of the database and object storage before each upgrade step, and confirm it can be restored.
- We run the upgrade first in a non-production copy, then check sign-in, projects, cycles, modules, pages and integrations against a written test list.
- When a switch from Community to Commercial is in scope, we plan the license key, seat counts by paid role and the change in edition as explicit steps.
How we hand over
- You receive a runbook covering the versions tested, the order of upgrade steps, the rollback procedure and the backup restore check.
- We document configuration changes, environment variables and any deviations from the vendor's standard deployment method.
- Handover includes a review with your platform and admin team so they can repeat the upgrade process without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, with the scope agreed in writing.
- Support covers upgrades across Plane release lines, backup verification and reviewing changes in each vendor release before rollout.
- Confirm with us what response times, maintenance windows and escalation paths the retainer includes before you sign.
