Knowledge base
Create an Azure service principal with Contributor on a resource group and connect it, so your static sites build from your repository on your own Azure subscription.
Connecting your own Azure Static Web Apps account lets you publish a static site to your Azure Static Web Apps account from your Zinn® dashboard. You own the project and the bill; we handle the deploy, the custom domain and the DNS records.
An Azure subscription, a resource group for the sites, and a connected GitHub, GitLab or Bitbucket account holding the code — Azure Static Web Apps builds from a repository. Azure's free plan allows commercial use and two custom domains per app.
Azure calls this a service principal. In the Microsoft Entra admin center open Entra ID → App registrations → New registration, give it a name and Register it. On the app's overview page copy the Application (client) ID and the Directory (tenant) ID. Then open Certificates & secrets → Client secrets → New client secret, choose a duration and Add it — copy the secret's value straight away, Azure shows it once.
In the Azure portal, open the resource group you want us to use, then Access control (IAM) → Add → Add role assignment. Choose the Contributor role, assign it to User, group, or service principal, search for the app by name, and Review + assign. Note the resource group's name and the Subscription ID it belongs to (search Subscriptions in the portal).
Open Integrations in your dashboard and choose Connect an account. Pick Static hosting (Netlify, Vercel) as the group and Azure Static Web Apps as the account, fill in Client ID, Client secret, Tenant ID, Subscription ID and Resource group, and press Connect account.
We test what you paste before anything is saved. A key that does not work is never stored, and the answer says what was wrong with it. A key that works is kept encrypted in our secrets vault — never in our database — and is never shown again, not even to you.
target. Azure Static Web Apps builds from a repository — it has no way to accept an uploaded build — so the site's code must come from a connected GitHub, GitLab or Bitbucket repository. Connect one first if you have not.
and trigger deploys. The domain's page shows any DNS record Azure Static Web Apps needs.
which one your domain needs.
Azure refused the service principal. Either the client secret has expired — they always do, on the duration you chose — or the app no longer has Contributor on the resource group. The two messages look alike, so check the role assignment before creating a new secret.
Nothing is found. Check the Subscription ID and Resource group are the ones you assigned the role on, and that the Tenant ID is the directory the app is registered in.
It says the key was rejected. Almost always one of three things: a space or a line break copied with it, a key that has expired, or a key that was revoked or regenerated after you copied it. Create a fresh one and paste it again.
It connects, but something later fails. The key authenticates but lacks a permission the action needs. Create a new key with the permissions listed above, then disconnect the old connection and connect the new key.
Open Integrations, find the account and press Disconnect. That deletes the stored key at once. Anything that was using it stops at its next action, and the screens that depended on it say so rather than failing quietly.
Disconnecting does not undo what was already done — records, deployments or settings we changed on your account stay as they are. If you think the key itself may have leaked, also revoke it at the vendor; disconnecting removes our copy, not theirs.
What we have been writing about hosting, SEO and running sites at scale.
How hosting shapes indexing and link equity in 2026: keeping pages indexed, vetting aged domains before you build on them, link building without a footprint, and an honest line on what infrastructure can and cannot do for SEO.
Read the post →A practical checklist for fast, secure WordPress: server-level caching, a per-site object cache, the handful of plugins worth running, keeping the stack current, and the WooCommerce pages you must never cache.
Read the post →What actually separates good managed hosting from a cheap box with a control panel — migrations, backups, isolation, real caching and honest scaling — and how to judge it before you commit.
Read the post →Support is included on every plan, the desk is open 24 hours a day, and you can write to us in any of our 58 languages — we answer you in yours.
Contact support → All articles →