Plane GitHub integration: what it syncs and who it serves
The Plane GitHub integration connects a self-hosted Plane workspace with repositories in GitHub or GitHub Enterprise Server, so that work items and code activity stay aligned. It is designed for teams that plan and track work in Plane while their source code, reviews and pull requests live in GitHub. In practice, the people who benefit most are engineering managers, product owners and developers who want issue status to reflect what is happening in the codebase, without updating two systems by hand. Delivery leads in regulated organizations also gain a single, auditable record of which work items were linked to which code changes.
At a high level, the integration performs two jobs. The first is issue sync, which is driven by labels on GitHub issues. A label decides whether an issue is brought into Plane, so teams can control which issues cross over instead of mirroring every issue in a repository. The second is pull request state automation, which updates linked work items as pull requests change state. Before you rely on either behavior, confirm the exact label names, sync direction, and the state mapping in Plane's current documentation. Document the conventions your teams will use, because a label that means different things in different repositories will produce confusing work items.
The supported method is the GitHub App flow documented by Plane. In this model, your organization creates a GitHub App, grants it the permissions Plane specifies, and installs it on the repositories in scope. Decide early who owns the app, which GitHub organization hosts it, and who holds the administrator rights needed to create and install it. Ask your security team to review the permissions the app requests before installation, and plan how the app will be rotated, reviewed and removed if the integration is retired. Confirm whether your GitHub Enterprise Server version and network layout meet Plane's stated requirements.
Plan the operational side before go-live. Confirm how user attribution works, meaning whether actions taken in GitHub appear under the matching Plane member, and map Plane users to GitHub accounts ahead of time. Check the plan requirement in Plane's pricing and integration documentation, because the topic's plan terms determine whether your self-hosted edition can use the integration at all. If you run the Community Edition, confirm the steps and any license implications of moving to the Commercial Edition, since paid plans on self-hosted Plane depend on it. Ask Plane to confirm these points in writing before you commit to a rollout.
What you need before connecting Plane to GitHub
Connecting self-hosted Plane to GitHub depends on a short set of prerequisites that span Plane, your identity administration and your GitHub organization. Confirm each one before you create the GitHub App, because gaps here usually surface later as failed callbacks or missing webhook events.
A running self-hosted Plane instance
Plane must already be deployed and reachable before any GitHub configuration starts. Record which edition you run, because the Community, Commercial and Airgapped editions are built on distinct codebases with their own release cycles. Confirm that your edition supports the GitHub integration in Plane's current documentation, and check whether a paid plan or license key is required for the feature set you intend to use. Note the exact Plane version so you can match it against the integration documentation you follow.
Administrator access to the Plane workspace
Connecting a repository requires a Plane account with administrative rights in the target workspace, since the integration is configured at workspace level and links GitHub activity to Plane projects. Confirm which roles can enable integrations and which can map repositories to projects. If your organization splits platform administration from workspace administration, agree in advance who will perform the connection so the setup is not blocked during the change window.
Rights to create a GitHub App
Creating a GitHub App requires owner or admin rights in the target GitHub organization. On GitHub Enterprise Server, the equivalent rights apply on the instance, and your Enterprise Server administrators may need to approve the app before it is installed. Decide whether the app will be owned by the organization or by a service account, because that choice affects who can rotate its private key and who receives notifications about it later.
A reachable public HTTPS callback URL
GitHub sends webhook deliveries and callbacks to a URL that must resolve publicly and present a certificate trusted by GitHub. Plan the hostname, DNS record, TLS certificate and reverse proxy path that expose Plane for these calls, and confirm that no firewall or proxy rule blocks inbound requests from GitHub. Test the endpoint from outside your network before you register the app, since a misconfigured callback URL is among the most common reasons webhook deliveries fail silently.
Network path and certificate trust for GitHub Enterprise Server
If you connect to GitHub Enterprise Server instead of github.com, Plane's servers need their own network route to the GitHub instance and must trust its certificate chain. Confirm that outbound traffic from Plane reaches the Enterprise Server hostname, and that any internal certificate authority is installed in the trust store used by the Plane containers or pods. Verify this from inside the Plane runtime, not from your workstation, because the workstation may already trust a certificate that the Plane service does not.
A test repository and project
Prepare a non-production repository and a Plane project to validate the connection before real work depends on it. Use labels and a small set of issues that exercise labeled issue sync and pull request state changes, so you can observe each behavior directly. Confirm the exact GitHub App permissions and webhook events required by Plane in its current integration documentation, and record them in your change request so reviewers can compare the app configuration against the documented list.
Why the Pro plan and Commercial Edition change the install path
The GitHub integration requires the Pro plan, and on self-hosted Plane that requirement changes how the install is built. A Community Edition install cannot move to a paid plan directly. It must first switch to the Commercial Edition, which unlocks paid plans through a license key. Community Edition matches the feature set of the Plane Cloud Free tier, so a team that wants the GitHub integration has to settle the edition question before it configures a GitHub App. Treat the edition switch as a planned build step with its own check, not as a fix applied after the integration fails to appear.
Seat counting is the next decision. Plane counts seats by users with paid roles, and the Free plan includes 12 seats with the Free feature set and no license key. The Plane Kubernetes guide installs the Commercial Edition, and its Free plan works without a license key, so a Kubernetes install can start there and move to a paid plan later. Before you buy, list every person who will hold a paid role, including the administrator who creates the GitHub App and the maintainers who review synced issues. Those roles, not total headcount, drive the recurring license cost.
Identity and audit requirements may also push you toward a higher plan. On self-hosted Plane, SAML and OIDC are available on Pro and above, so an identity provider that speaks one of those protocols can be used at the Pro tier. LDAP support and API-enabled audit logs are listed as Enterprise features. If your directory only exposes LDAP, or if your security team needs API-level audit records of who changed issues through the GitHub automation, the Pro plan does not cover that need. Confirm these points with your identity and security owners before the plan is chosen, not after users are onboarded.
Pricing is the input that most often gets estimated too early. The Plane 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 priced on request. Multiply the paid-role count by the rate for the plan you need, then repeat the calculation for each year you plan to run. Confirm the current edition switch steps, the plan entitlements for the GitHub integration, and whether GitHub Enterprise Server is supported with Plane before you take a budget decision. Those details can change between releases.
A written quote should separate the two costs. The Plane subscription is paid to Plane, is recurring, and scales with paid seats. The implementation work, which covers the edition switch, GitHub App setup, sync rules and testing, is a one-time project cost that DeployOpen scopes in writing before work starts. Ask for the edition switch procedure as a numbered sequence, the license key handling process, the upgrade path between Community and Commercial releases, and a list of the roles that count as paid. Those answers make the install path and its cost visible before anyone commits.
How to configure the GitHub App and connect it to a Plane project
This sequence takes a self-hosted Plane workspace from a basic install to one where labeled GitHub issues create Plane work items and pull request events move them through states. Work through the steps in order, because the edition and plan must be in place before the GitHub App can be connected. Each step ends with a check you can run before moving on.
Switch to a plan with the integration
Confirm that your instance runs the Commercial Edition on a plan that includes the GitHub integration. A self-hosted Community install must first switch to the Commercial Edition, which uses a license key, before any paid plan can be applied. Your platform owner makes this change and checks with Plane which plan includes the integration, since feature availability is listed per plan on Plane's pricing page. Seats are counted by users with paid roles, so confirm the seat count with your procurement team. The step is done when the workspace settings show the paid plan and a workspace admin can see the GitHub integration option.
Set host and callback settings
Decide the public address Plane will use, then collect the callback and webhook values that Plane's integration documentation specifies for your install. GitHub sends requests to that address, so your network or ingress team must confirm that it resolves and accepts HTTPS traffic from GitHub. If you connect to GitHub Enterprise Server instead of github.com, the host name and API endpoints differ, so your platform team must confirm those host settings before any App is created. Write the final values down and share them with the person who will create the App. The step is done when someone outside your network can reach the callback path.
Create the GitHub App with Plane's permissions
A GitHub owner or organization admin creates a GitHub App under the account that will own the integration. Enter the callback and webhook values from the previous step, then select only the repository permissions and event subscriptions that Plane's documentation lists for issues and pull requests. Generate the private key and store it in your secrets manager, not in a shared document. Screen names and permission labels change between GitHub releases, so confirm the exact fields against GitHub's current app registration pages and Plane's setup guide before you submit. The step is done when the App appears in the owner's settings with the listed permissions.
Install the App on chosen repositories
Install the App on your organization and select only the repositories whose issues should sync into Plane. Repository selection limits what the App can read and which events reach Plane, so start with the repositories used by one pilot team. Record the installation identifier that GitHub assigns, because Plane asks for it when you connect the App. Check that the installation lists the chosen repositories and no others, and that the permissions match the ones you configured in the previous step.
Connect the App to the Plane workspace
A Plane workspace admin enters the App credentials and installation details in the GitHub integration settings of the workspace. Paste the App identifier, the private key and the installation reference, using the field names shown in Plane's current integration screens. Plane then authenticates to GitHub and lists the repositories it can see. The step is done when the connection shows as active and the repository list matches the installation. If authentication fails, check the private key format and confirm that the host settings match whether you use github.com or GitHub Enterprise Server.
Map a labeled issue flow to a project
Choose one Plane project for the pilot repository and decide which GitHub label should create a work item. Map that label to the project, then map any label changes to the Plane states your team already uses, so the workflow reads the same in both tools. Keep the mapping small, because each extra rule is one more thing to maintain. To check the flow, apply the label to a test issue in the pilot repository and confirm that a work item appears in the correct Plane project with the expected state and a link back to the GitHub issue. Then change the label and confirm that the state moves as mapped.
Enable pull request state automation
Turn on pull request automation for the same repository and map pull request events, such as opened, in review and merged, to Plane states. The supported event list depends on the Plane release you run, so confirm it in Plane's current integration documentation before you map anything. Open a test pull request that references the test work item using the reference format Plane documents, then confirm that the linked work item moves to the mapped state and that the activity shows the GitHub user. Merge or close the pull request and confirm the second state change. The step is done when both transitions match the mapping.
Which GitHub fields map to which Plane fields
This table compares each GitHub object the integration reads with the Plane object it would update, the direction of sync, and what to confirm before go-live. Field-level mappings are not confirmed in the Plane documentation used for this page, so treat every row as a question to answer in a test workspace before relying on it. The last column is your test plan: each entry names a behavior that decides whether your team's workflow holds once sync is switched on.
| GitHub object | Plane object | Direction of sync | What to confirm |
|---|---|---|---|
| Issue title | Work item title | GitHub to Plane (verify) | Whether edits made in Plane flow back to the GitHub issue, and which side wins when both change. |
| Issue body | Work item description | GitHub to Plane (verify) | Whether Markdown formatting, task lists and embedded images survive the sync intact. |
| Issue labels | Work item labels | GitHub to Plane (verify) | How label names are matched, whether missing labels are created automatically, and how Plane-only labels are handled. |
| Issue open or closed state | Work item state | GitHub to Plane (verify) | Which Plane states each GitHub state maps to, since state names are set per workspace. |
| Pull request state (open, merged, closed) | Work item state change | GitHub to Plane (verify) | Which pull request events trigger a change, and whether merged and closed pull requests are distinguished. |
| Link between pull request and issue | Work item link or reference | GitHub to Plane (verify) | How the link is detected, from branch names, pull request titles, or references in the description. |
| Assignees | Work item assignee | Two-way or one-way (verify) | Whether GitHub users match Plane members by email, username or manual linking, and what happens when no match exists. |
| Issue and pull request authors | Activity attribution | GitHub to Plane (verify) | Whether activity is attributed to the GitHub user or the GitHub App, which affects your audit trail. |
| Repository | Project | Linked at setup (verify) | Whether one repository maps to one Plane project, whether several repositories can feed one project, and how repositories are chosen during setup. |
How user attribution works and where identity mismatches appear
Synced GitHub activity is only useful if it is attributed to the right person. Each GitHub login that produces activity, such as an issue comment, a status change or a pull request event, needs to correspond to a Plane user who is a workspace member, holds a role that allows the action and occupies a counted seat. When the match fails, the activity lands on an identity that does not reflect who did the work, and reviews, audit trails and workload views become harder to trust. Confirm in the integration documentation which attribute the sync uses to match a GitHub account to a Plane user, because that choice determines every mismatch case below.
The first common mismatch is a GitHub account with no matching Plane user. This usually happens with contractors, people from partner organizations or contributors who were never invited to the workspace. Depending on the integration behavior, their activity may be skipped, assigned to a fallback user or recorded without a clear actor. The second is a bot or GitHub App identity appearing as the author. Pull requests opened by dependency tools or by the integration's own App can show the App as the author, so the person who triggered the action is not visible in Plane. The third is a user who changes their GitHub username. If matching depends on the username, history may stay under the old name or split into duplicate identities after the rename.
Teams should settle these questions before enabling sync, not after the first mismatched issue appears. Start by choosing the matching key and checking whether the integration matches on a stable GitHub identifier or on a mutable field such as the username or email address. Next, write a policy for unmatched contributors: invite them, map them manually, or accept that their activity is excluded. Decide how bot and App activity should be presented, and who owns the mapping list when people join, leave or rename their accounts. Export the members of the relevant GitHub organization or repositories and compare them with the Plane workspace members so gaps are found in advance.
Identity provider choices can also affect the rollout. On self-hosted Plane, SAML and OIDC are listed on the Pro plan and above, so a team that wants single sign-on for Plane users will need to plan for a paid plan and, for a self-hosted Community install, a move to the Commercial Edition first. These options change how users sign in to Plane, and seat counts depend on users with paid roles, so role assignments should be reviewed alongside sign-in. Whether a sign-in provider also changes how GitHub identities are matched is a question to confirm against the integration documentation before the matching policy is final.
Security settings for the GitHub App and webhook path
The GitHub App and the webhook endpoint are the two places where Plane trusts data from GitHub, so they need the same care as any service account. The controls below cover what the App can reach, where its credentials live, who can change it, how Plane checks incoming events, and what network path a GitHub Enterprise Server host requires. Confirm each one against your own environment before enabling sync.
Limit the App to sync repositories
Install the GitHub App only on the repositories whose issues and pull requests Plane needs to sync, and avoid an organization-wide installation by default. Each repository added to the installation widens what a leaked private key or a misconfigured webhook can touch. Review the repository list when a project closes or moves, and remove access that no longer serves a synced project.
Keep App secrets out of config files
The App private key and webhook secret should live in a managed secrets store that your platform team already operates, with read access limited to the Plane workload that needs them. Configuration files, Helm values committed to Git, and container images are common places where these values leak. Confirm how your Plane deployment reads secrets at runtime, and set a rotation procedure for both values before go-live.
Restrict who installs and changes the App
Only a small, named group of GitHub organization owners should be able to install, reconfigure, or delete the App. Plane administrators who set up the connection hold a separate permission, so record both groups in your access reviews. Plane audit logs can show who changed what, but API access to audit logs is listed as an Enterprise feature on Plane's pricing page. Confirm with Plane whether your audit needs require that tier.
Verify webhook signatures on the Plane side
Plane should reject any webhook delivery whose signature does not match the webhook secret, so forged requests cannot create or change work items. Follow the signature method described in Plane's GitHub integration documentation, and test it with a deliberately wrong secret before relying on it. Also confirm how your reverse proxy or load balancer handles the raw request body, because altering that body breaks signature checks.
Allow egress and trust certificates for GitHub Enterprise Server
A GitHub Enterprise Server host sits inside your network, so Plane needs an allowed outbound route to that host on the port GitHub uses, and GitHub needs a route back to Plane's webhook endpoint. Confirm the firewall, proxy and DNS rules on both sides. If the GHES host uses an internal certificate authority, add that CA to the trust store used by Plane's services, then test the TLS handshake from the same workload that makes API calls.
Review permissions when GitHub or Plane changes
The permissions a GitHub App requests determine what the integration can read and write, so each new permission deserves a fresh review before it is accepted. Watch the App's permission settings on GitHub and Plane's release notes for the integration, and compare any changes with the scope your team approved. Record the review date and the reviewer in your change log so the approval trail stays current.
How to test the sync before the team relies on it
Build a test plan that proves the sync does exactly what your team expects before anyone depends on it. Start with a dedicated test repository and a separate Plane project, so that test issues, labels and pull requests never mix with production work. Connect the GitHub App to the test repository only, and keep the test project's membership small and known. The goal is a repeatable script in which every step has a stated expected result, so a failure points to one action rather than to the whole integration. Cover the labeled and unlabeled paths. Create at least one issue that carries the sync label and one that does not. Confirm that the labeled issue appears in the linked Plane project and that the unlabeled issue does not appear at all, not even in a backlog or archive view. Then remove the label from a synced issue and add it to an unlabeled one, and check how each case behaves. Record whether Plane keeps, updates or ignores the existing work item, because teams often assume a label change is retroactive when the integration may not treat it that way. Confirm the exact behavior with the vendor documentation for your Plane edition and version before you write the expected results.
Walk the pull request lifecycle. For each state change, open the pull request as a draft, move it to ready for review, request a review, approve it, merge it, and then close a second pull request without merging. After each transition, check the linked Plane work item for the status, timestamps and any comment the integration posts. Do the same sequence for a pull request that references a synced issue and for one that does not, since the automation may depend on how the link is written. Confirm which transitions Plane is expected to act on in your configuration, and mark any transition that is not automated as an expected no-change result. Check attribution for each test user. Use at least two or three GitHub accounts, each mapped to a known Plane user, and perform the same actions from each. Verify that the Plane activity shows the correct author, and that actions from a GitHub account without a matching Plane user are handled as your configuration intends. Attribution errors are the most likely to surprise auditors and team leads, so treat them as blocking defects. Record expected and actual results. Keep a test log with a row for each step: the step number, the action, the expected result, the actual result, the date, the tester and the Plane and GitHub versions in use. When a step fails, you can trace the failure to one row and reproduce it. Repeat the full plan after each Plane or GitHub upgrade, after any change to the GitHub App permissions, and after any change to the label scheme. A short regression subset is useful for routine changes, while the full plan belongs to upgrades and permission changes. Ask your implementation partner or internal owner to sign off on the log before the integration is opened to the wider team.
Why GitHub sync stops and how to fix it
This table matches common GitHub sync symptoms with their likely causes and a check the team can run to fix each one. Start with the symptom you see, read across to the likely cause, and run the check on one test issue or pull request. Most failures trace to the GitHub App setup, the repository mapping or the Plane edition, so review those first.
| Symptom | Likely cause | Fix |
|---|---|---|
| Issue never reaches Plane | The GitHub issue lacks the sync label, or the label spelling differs from the configured one. | Compare the label text on the issue with the label set in the Plane integration settings, character by character. Add or correct it, then retest on that issue. |
| No events from one repository | The GitHub App is not installed on that repository, so GitHub never sends its events. | In the GitHub App installation settings, confirm the repository is selected. Add it if missing, then trigger a test event on that repository. |
| Events sent but nothing received | The Plane callback URL is unreachable from GitHub because of DNS, a proxy or a firewall rule. | From outside your network, request the callback address and confirm a response. Check recent failed deliveries in the GitHub App settings, then fix ingress or DNS. |
| Pull request merged but state stays the same | A pull request event the integration needs is not enabled in the GitHub App subscriptions. | Compare the App's event subscriptions with the integration's documented list. Enable any missing pull request event, save, then open a test pull request. |
| Pull request updates land in the wrong project | The repository is mapped to a different Plane project, or a similarly named repository was selected. | List each repository with its mapped project. Confirm the owner and repository name match exactly, and correct any mapping that points elsewhere. |
| Duplicate work items for one GitHub issue | Two integrations or two mappings cover the same repository, or sync was configured twice. | Search the target project for repeated links to one issue number. Keep a single active integration per repository, remove the duplicates, then retest on a new issue. |
| Activity shows the wrong author | The GitHub account is not linked to the matching Plane user, so activity falls back to another account. | For each contributor, confirm the GitHub account is linked to the correct Plane user and that user is a workspace member. Retest with a comment and check the author. |
| GitHub integration missing or unavailable | The workspace is on a plan or edition without the integration. The integration is listed with the Pro plan requirement. | Confirm the plan in Plane's current plan documentation and the edition in instance settings. If Community, plan the Commercial Edition move with a license key before retesting. |
| Certificate or host errors on GitHub Enterprise Server | The host name in the integration does not match the certificate, or the internal CA is not trusted by Plane. | Confirm the host name appears on the GHES certificate. From a Plane container, check the internal CA is trusted and the name resolves to the GHES address, then retest. |
Questions buyers ask before connecting Plane to GitHub
What does connecting Plane to GitHub cost?
The main cost driver is the Plane plan, because the GitHub integration requires the Pro plan. Plane's pricing page lists Pro at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month, so your seat count multiplies the subscription cost. Confirm current figures on the pricing page before budgeting. If you run Community Edition today, you must first switch to Commercial Edition, which unlocks paid plans with a license key, so plan that step too. Setup effort rises with the number of repositories, the label scheme, the number of GitHub organizations, your identity choices (SAML and OIDC are available on Pro and above, while LDAP is listed as an Enterprise feature), and whether you use GitHub Enterprise Server. DeployOpen's fee follows from a written scope, and it does not publish a price list.
How long does a Plane and GitHub setup take?
Duration depends on scope, and this page does not give a typical figure. A single repository with a simple label scheme is the shortest path. Time grows with each additional GitHub organization, each repository that needs its own mapping, GitHub Enterprise Server, identity rules such as enforced SSO with role mapping, and the test cycle you need before cutover. Your team's availability and change-approval windows also set the calendar. Ask any provider, including DeployOpen, to state the duration in the written scope along with the assumptions behind it. Before agreeing a date, ask your network and platform teams to confirm any dependency in your environment, such as the path to a public callback address.
What access does the GitHub connection need from our team?
The work needs four things. First, owner-level access to the GitHub organization, or a named owner who can create the GitHub App and install it on the right repositories. Second, a public callback path so GitHub can reach your Plane instance, which you may provide through a reverse proxy or ingress you already operate. Third, Plane admin access to the workspace so the integration can be configured. Fourth, a test project in Plane and a test repository in GitHub, so sync can be verified before production use. Ask your security team how the app's permissions will be reviewed and who approves each installation. Name one owner for each item so the work keeps moving.
Can our internal team set up the GitHub integration alone?
Yes, for a single repository with a simple label scheme. An engineer who already administers Plane and GitHub can usually complete that setup by following Plane's documentation. The work becomes harder with multiple GitHub organizations, GitHub Enterprise Server, strict identity rules that combine SSO enforcement with role mapping, or a multi-team label taxonomy that must stay consistent across repositories. In those cases the difficulty lies in design and testing. Before deciding, check whether your team can write and run the test plan, roll back a failed change, and own the GitHub App after handover. If any of those steps is uncertain, comparing an outside partner's written scope is a reasonable next step.
What should a quote for the Plane GitHub integration include?
A quote should start with a written scope. That scope lists the GitHub organizations, repositories and any GitHub Enterprise Server instances involved, the Plane workspaces and edition, the label and pull request state mapping, the identity approach, and the environments in scope, such as test and production. It should also include the test plan with clear pass criteria, handover documentation, and support terms after go-live, including whether ongoing support is a retainer. Check what the client provides (access, callback path, test project) and what is excluded. DeployOpen works from a written scope, and most engagements are fixed-scope, with ongoing support and continuous testing available as retainers. Compare quotes item by item so the assumptions match.
Does DeployOpen provide a compliance attestation for this integration?
No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform that work. DeployOpen can prepare systems, configuration records and evidence that an auditor may request, such as how GitHub App permissions were set, who approved each installation, how sync was tested, and how changes are recorded. Confirm with your auditor which evidence they need before implementation starts, because evidence is easier to capture during the build than to reconstruct later. Ask any provider the same question in writing so the answer is part of the agreed scope.
What should engineers verify after connecting Plane to GitHub?
Start with a test issue in GitHub that carries the sync label and confirm that it appears in the expected Plane project with the correct title, state and description. Next, open and merge a test pull request linked to that work item and check that the state updates as your mapping defines. Verify user attribution by confirming that comments and status changes show the correct person, and test the behavior when a label is removed or changed. Review webhook delivery records on the GitHub side for failed or retried deliveries, and confirm that your callback address is reachable from outside your network. Repeat these checks after each Plane upgrade, and confirm any behavior change against the release notes for the version you run.
How DeployOpen scopes and delivers the Plane GitHub integration
DeployOpen plans and delivers the Plane and GitHub integration inside infrastructure you control, whether that is GitHub.com or GitHub Enterprise Server. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- Confirm your Plane edition, because the GitHub integration depends on a paid plan that requires the Commercial Edition.
- Confirm whether you use GitHub.com or GitHub Enterprise Server, and which organizations and repositories are in scope.
- Agree in writing which labeled issue sync and pull request state rules the integration will cover.
How we build
- Create and configure the GitHub App with permissions limited to the repositories and events the agreed rules need.
- Configure labeled issue sync and pull request state automation, then test each rule against sample repositories.
- Set up user attribution so issues and pull request activity map to the correct Plane members, and document any gaps.
How we hand over
- Deliver a runbook covering the GitHub App settings, webhook configuration, secrets handling and rule definitions.
- Document how to add repositories, change labels, rotate credentials and review integration activity.
- Walk your platform and project leads through the configuration and confirm acceptance against the written scope.
How we support
- Offer ongoing support, upgrades and testing as a retainer after handover, if your team wants continued help.
- Review Plane and GitHub release notes when upgrades affect the integration, and plan changes through your change process.
- Confirm with Plane and GitHub the current requirements, plan features and API behavior for your environment before the build.
