The privileges, stated up front
Before you create a token we tell you what it has to be able to do and why. No blanket scope because it was easier to ask for, and no discovering after the fact that we wanted more than the job needed.
Source control
Deploy from the repository you already use — nine places to put it
Connect the GitHub or GitLab account you work in and deploy straight from a branch: to Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps or AWS Amplify — or onto our own managed hosting, where the repository and the site's files stay in sync in both directions. Every connection shows the privileges it needs, is checked against the provider's API before it is stored, and lives in Vault. You can sign in with GitHub or GitLab too.
- GitHub + GitLabconnect the account you already have
- Nine destinationseight edge hosts, plus our own fleet
- Two-way syncevery site, every line
- Vault-storedvalidated on entry, never in a log
- Token checked before it is storedan over-scoped token never lands
- Push to deploysignature-checked, and optional
- Your branch, your buildpublish a directory or run your own CI
- Disconnect cleanlywe remove exactly the hook we made
Connect once, and see what you are agreeing to
A connection is a credential you are handing someone else. Ours says what it needs before you make it, proves it works before it stores it, and can be taken back from either end.
Checked against the provider, not accepted on trust
We call the provider's own API with your token before storing it. A wrong, expired or wrongly-scoped token is refused at the form rather than accepted, shown as healthy, and failing at the first real deploy.
Stored in Vault, and nowhere else
Not in our code, not in an environment file, not in a log and not on a command line. Resolved at the moment it is used, by the workload that uses it.
More than one account, picked per site
Connect a personal account and an organisation's, or two organisations'. Each site chooses which one it deploys from, so a client's repository and your own never share a credential.
Nine places a repository can land
Eight managed edge hosts and our own fleet. The destination is a property of the site, not of the connection, so the same repository can publish one branch to a Pages host and another site can run on our hardware.
Cloudflare Pages
Unlimited bandwidth, commercial use permitted, and apex domains handled on the same provider that usually holds your DNS zone. It is the first destination we reach for, for those reasons.
Cloudflare Pages hosting →GitHub Pages
Publish straight from the repository the code already lives in. Flagged on the Footprint-Free line, because the shared github.io infrastructure is itself a footprint.
GitHub Pages hosting →GitLab Pages, Netlify, Vercel and the rest
GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps and AWS Amplify are all destinations you can point a site at, with the same connection and the same deploy history.
Static site hosting →Our own managed hosting
A full application rather than a built bundle — WordPress, PHP, Node. This is the destination that gets two-way sync, so the files on the box and the branch stay in step.
Managed hosting →Sites on somebody else's edge
A site published to a host we do not own still spends an allowance and still appears in your dashboard with its deploys, its uptime and its SEO data beside everything else you run.
External site allowances →Or edit it here
The in-browser editor works on the same files two-way sync pushes back, so a quick fix from the dashboard becomes a commit on your branch instead of a change nobody can find later.
The web editor →Two-way sync
Your repository and your live site, in step
Switch it on and the site's own files are committed back to your branch, while commits on that branch come back down to the site. It works on every site we host, on every line — the only requirement is that the machine underneath can run Git against its files, which is asked of the server rather than assumed from the plan.
You choose which directory syncs, because a WordPress customer wants their theme tracked and not forty thousand core files. And it is off until you turn it on: enabling a sync is a decision about somebody else's repository, and a migration must never take it for you.
- Edits on our hardware become commits on your branch
- Commits on your branch come back to the site
- Sync one directory — a theme, a plugin — not the whole document root
- Off by default, including on every site that already exists
Publish a directory, or let your own CI build it
Two modes, and the difference is where the build runs. Both end at the same place: a ref we fetch and publish, with the commit recorded against the deploy.
- Publish mode takes your branch as it is and publishes the directory you name — blank means the repository root.
- CI mode runs your build command in your provider's own pipeline and commits the output to a separate publish branch, which we fetch like any other ref.
- The branch a deploy publishes from is always named explicitly, never “the default branch” — a default can change under you, and a history that cannot say which branch it published is not a history.
- Auto-deploy is on by default and can be turned off without removing the webhook, so you can watch deliveries arrive before you let them act.
- Every deploy records its commit, its outcome and its time, and runs in the background — the page updates as the build completes.
- Disconnecting removes exactly the webhook we created, by its id, and nothing else on your repository.
From repository to live site
Connect the account
GitHub or GitLab, under Connections. The privileges are listed before you make the token and it is checked against the provider before it is stored.
Point a site at a repository
Owner, repository, branch, and whether we publish a directory or fetch what your CI built. We register the push webhook as part of it.
Push, or press the button
A push to the nominated branch starts a deploy, or you can deploy on demand from the site's Deploy tab. Builds run in the background.
Watch it, and sync back if you want to
The deploy history shows what was published and when. Turn on two-way sync and the edits you make here come back as commits on your branch.
When something is wrong
“Connected but never delivered” is a state we will actually tell you about
A repository connection that looks healthy and receives nothing is the classic silent failure — a token with the wrong scope, a delivery blocked at the provider, a hook somebody removed by hand. It is invisible on every other screen, so the repository card carries it directly: when the provider last delivered to us, and what it said.
Deliveries are signature-checked before we act on them, with each provider's own scheme rather than one we assumed applied to all of them. A delivery that does not verify is refused and recorded, not quietly ignored.
- Last delivery time and message, on the card
- Never delivered is stated, not left blank
- Signature verified per provider before anything runs
- The hook we created is removed by id when you disconnect
Identity
Sign in with GitHub or GitLab — or Google, or Microsoft
Alongside an email address and a password, you can sign in to your Zinn Digital® account with GitHub, GitLab, Google or Microsoft. The identity layer runs the handshake; we never see your provider password, and linking a social account to an existing Zinn® account still has to be confirmed by email.
Signing in with GitHub and connecting GitHub for deploys are separate decisions and separate credentials. Doing one does not do the other, and removing one does not remove the other.
- GitHub, GitLab, Google and Microsoft sign-in
- Passkeys and two-factor on the same account
- Sign-in and deploy credentials stay separate
FAQ
Which source-control providers can I connect?
GitHub and GitLab. Connect the account you already work in and we can deploy from its repositories, register a push webhook on them, and — if you want it — sync your site's files back the other way. Both go through the same connected-account seam, so everything below is true of either.
Can I sign in with GitHub or GitLab?
Yes, and with Google or Microsoft. Alongside an email address and a password you can sign in to your Zinn Digital® account with any of the four. The identity layer handles the handshake and we never see your provider password. Signing in with GitHub is a separate thing from connecting GitHub for deploys — you can do either, both, or neither.
Where can I deploy a repository?
To Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps or AWS Amplify for a static or built site — or onto our own managed hosting, where the repository and the site's files stay in sync in both directions. You pick the destination for the site; the repository connection is the same either way.
Can you build my site, or does it have to be pre-built?
Either. In publish mode we take the branch as it is and publish the directory you name. In CI mode your provider's own pipeline runs your build command and commits the output to a separate publish branch, which we then fetch like any other ref. The second keeps your build in your own CI, where your secrets and your caching already are.
Does a push deploy automatically?
By default, yes — we register a webhook on the repository and a push to the branch you nominated starts a deploy. You can turn that off and keep the webhook, which is more useful than it sounds: the delivery is still recorded, so you can watch your pushes arriving before you let us act on them.
What is two-way sync?
Edits made on our hardware become commits on your branch, and commits on your branch come back to the site. It is off until you switch it on, because turning it on is a decision about somebody else's repository and we will not take that for you. You choose which directory syncs — usually a theme or a plugin, not forty thousand WordPress core files.
What happens if both sides changed?
Nothing is overwritten and nothing is pushed. The sync stops, tells you the branch moved past the commit we based on, and asks which side you want — keep the repository, or keep the site. A site that has never synced and points at a branch that already has commits is its own state too, and it asks rather than guessing which one is the truth.
How is my access token protected?
We show you the privileges the connection needs before you create it, check the token against the provider's own API on entry — so a token that is invalid or wrongly scoped is never stored at all — and only then write it to Vault. It never touches our code, a log, an environment file or a command line. Revoke it at the provider or remove the connection here, whenever you like.
How do I tell whether you are actually receiving my pushes?
The repository card shows when the provider last delivered to us and what it said. Never delivered is the single most useful diagnostic on that screen, because “connected but never delivered” is exactly what a mis-scoped token or a blocked delivery looks like — and it is invisible everywhere else. Every delivery is signature-checked before we act on it.
Can I use Pages deployment on the Footprint-Free line?
It is offered and it is flagged. GitHub Pages and GitLab Pages share provider infrastructure and public github.io and gitlab.io hostnames, and that is a footprint — the one thing that line exists to avoid. For a zero-footprint network, deploy onto isolated hosting instead. Everywhere else, Pages is first-class.
Why do I have to choose Vercel explicitly?
Because its free tier is licensed for non-commercial use only. We infer a destination from the accounts you have connected where that is safe, and Vercel is deliberately excluded from that inference — connecting an account must never quietly place a commercial site somewhere its licence does not permit. Choose it and it works exactly like the others.
Can I see what was deployed and when?
Yes. Every deploy records the commit it published, when it ran and how it finished, and the site's Deploy tab shows the history with the live URL beside it. Deploys run in the background, so the page updates as the build completes rather than making you sit on a spinner.
Related
Deploy from your repository
Start a card-free 14-day trial, connect GitHub or GitLab, and point a site at a branch. Publish to an edge host, or onto our own hosting with the files syncing both ways.
Start free