The first export is often straightforward. Keeping the repository useful raises harder questions: what happens when a page moves, an inventory fails halfway through, or someone edits generated files?
Conf2Git runs the synchronization on Atlassian Forge, so you do not host a sync server or maintain a separate cron job for the mirror. Its technical value is the behavior that keeps a recurring GitHub copy consistent as the source changes.
Follow the content through the pipeline
Confluence Cloud: authors edit pages
↓
Conf2Git on Atlassian Forge: read, convert, reconcile
↓
GitHub: generated files on a dedicated mirror branch
↓
Your checkouts, search indexes, or AI workflowsPage bodies and eligible images are processed transiently and written to the selected GitHub repository. Operational metadata is kept in installation-isolated Forge storage. The data-flow guide explains those boundaries.
Downstream tools must read the configured branch and folder. Conf2Git does not operate your retrieval system or configure an agent; see the coding-agent example for that part of the workflow.
Hosting is one decision; synchronization behavior is another
Hosted CI and cloud functions can also run an exporter without a server you administer. A custom job still needs rules for source inventory, conversion, repository publication, and recovery.
Conf2Git supplies those rules within its supported scope. That can fit a recurring Confluence Cloud-to-GitHub mirror. If you need custom transformations or a different destination, owning the job may be more appropriate. The exporter comparison covers those choices.
Build the complete candidate before updating GitHub
Each run inventories the in-scope pages, converts them, resolves paths and links, and builds the desired output before updating the target branch. It compares that output with GitHub and a validated ownership manifest.
When content changes, the engine publishes one complete commit. When the desired output is unchanged, it creates no commit. Incomplete inventory, unsafe conversion, a limit breach, or an ownership conflict prevents the branch update. The synchronization guide specifies these rules.
Example: a parent page moves
Suppose a synthetic Engineering space has a Deployment guide beneath an Operations parent. An author moves the guide to a new parent called Delivery.
- The next complete reconciliation discovers the new hierarchy.
- It plans the guide’s new path, affected descendant paths, and links from other mirrored pages.
- It adds the new output and removes only the old paths it can prove it owns, within the same candidate commit.
The result is a coherent revision to inspect in GitHub. Native OKF files use page.md; the format article explains their source metadata.
Example: an inventory fails halfway through
A failed inventory does not prove that pages missing from the response were deleted. Conf2Git publishes no branch update for that attempt. The previous successful mirror remains available, but it may now be stale.
An operator should inspect the failure, repair the cause, and review a later successful run. A consumer should check both the latest attempt and the last successful mirror. Commit age alone is insufficient because successful no-change runs do not create commits.
Example: someone edits a generated file
The ownership manifest identifies managed files only after its identity and publication provenance validate. A later sync may replace a human edit to a managed file because Confluence remains authoritative.
Unowned files are preserved. If a generated path would collide with an unowned file, the run fails rather than silently adopting it. Keep separately authored downstream documents outside managed output and give them an explicit owner.
The publication step also checks whether another writer moved the destination branch. It can retry within a bounded policy or fail safely; it does not force-push through the conflict.
Check access, scale, and freshness
Setup uses a GitHub App with Contents read/write and Metadata read permissions, a tested repository connection, and a dedicated non-default branch. No customer-managed personal token or GitHub App private key is pasted into the form. Use the setup walkthrough for installation.
The documented supported limits include:
- 1,000 pages per mapping and run.
- 1,500 generated files per run, including images and the ownership manifest.
- 100 MiB total generated output per run.
- 10 MiB per image and 64 MiB of image bytes per run.
- Five mappings that have not been removed per Confluence site.
Assess those limits together: images consume the file allowance too. General attachments and dynamic macro results are outside the mirror’s supported scope. Evaluate representative documents and review conversion diagnostics.
Scheduling starts disabled. After verifying a manual run, choose a daily, weekly, or monthly schedule. Schedules are checked hourly, with no exact execution or completion guarantee. Your team still owns acceptable freshness, source quality, repository access, and downstream refreshes.
The mirror follows current source changes, so use separate backup and retention controls where needed. To assess the fit, start a Marketplace evaluation, create one mapping, and inspect how its recorded runs and commits handle the changes your workflow needs.