Cannot touch your CI or workflows
GitHub rejects, server-side, any push to .github/workflows/ from an app without the separate Workflows permission. We never request it.
Security & permissions
This page doubles as our GitHub App registration spec: the permission set below is final and frozen. Adding any permission later would force a re-consent screen on every installation — we treat that as a breaking change, because it is one.
What MergePress can do
The MergePress GitHub App requests exactly three permissions. That’s the whole list — and with zero org-level permissions, a repo admin can install it without involving org owners.
install screen · verbatim
frozen scope set| Permission | Level | Why |
|---|---|---|
| Contents | Read & write | Read your site to learn its structure and voice; create branches and commits for proposed posts. |
| Pull requests | Read & write | Open the PR, read your review, merge only after you approve. |
| Metadata | Read | Mandatory GitHub baseline — repo name, default branch. |
What MergePress cannot do
Enforced by GitHub, not by our promises. These aren’t policies we follow; they’re operations the platform rejects because we don’t hold the permissions they require.
Cannot read secrets, settings, or deploy keys
Those are separate permissions we don’t have. There is nothing to leak because there is nothing we can reach.
Cannot push to your default branch
Our own broker refuses it, and every change arrives as a PR you can read line-by-line before anything happens.
Cannot deploy
We hold no deploy credentials for any platform. Publishing only happens when your approval merges the PR.
reference: dependency bots like Renovate must request the Workflows permission to do their job. a content service never needs it — and we never will.
How changes reach your repo
Two fences, one audit trail — GitHub’s server-side enforcement outside, our broker’s hard rules inside.
Every change is a pull request
On a mergepress/* branch, committed via GitHub’s API as mergepress[bot] with GitHub’s Verified signature badge. We never impersonate humans, and we never push to your default branch.
A merge needs a recorded approval
Your one-tap email approval, your PR review, or you merging the PR yourself. The approval record — who, when, via which channel — is kept as an audit trail, and it is the only thing that unlocks a merge.
Writes are confined to your content paths
Your blog directory (e.g. src/content/blog/) plus a .mergepress/ config folder. Our broker refuses everything else — including all of .github/ — as a second fence inside GitHub’s own.
Credentials & tokens
Per-job, down-scoped, short-lived tokens
Each job gets an installation token scoped to the single repo and the minimal permissions it needs, expiring within one hour. No long-lived tokens exist anywhere in the system.
No tokens in AI contexts, ever
The writing system is architecturally separated from the system that holds credentials. The model that drafts your content cannot see, hold, or use a GitHub token — a non-AI broker performs every git operation under hard rules.
Sign-only key storage, zero-downtime rotation
The app’s private key lives in a secrets vault, sign-only, and can be rotated with zero downtime.
Uninstall = clean revoke
One click in GitHub settings and every credential dies instantly. We retain no access of any kind after uninstall — there is nothing to ask us to delete, because GitHub already killed it.
Your content, your repo
Everything we produce lands in your repository. Cancel any time; every post, image, and config file is already yours, in your git history, portable to any other workflow.
Questions about the model? We answer them plainly.