Base ng kaalaman

Mag-deploy ng static site sa sarili mong Azure Static Web Apps account

Gumawa ng isang Azure service principal na may Contributor sa isang resource group at ikonekta ito, upang ang iyong mga static site ay mag-build mula sa iyong repository sa sarili mong subscription sa Azure.

Ang nagagawa ng pag-connect nito para sa iyo

Ang pag-connect ng sarili mong Azure Static Web Apps account ay nagbibigay-daan sa iyong mag-publish ng static site sa iyong Azure Static Web Apps account mula sa iyong Zinn® dashboard. Sa iyo ang project at ang bayarin; kami ang bahala sa pag-deploy, sa custom domain, at sa mga DNS record.

Bago ka magsimula

Isang Azure subscription, isang resource group para sa mga site, at isang naka-connect na GitHub, GitLab, o Bitbucket account na naglalaman ng code — nagbi-build ang Azure Static Web Apps mula sa isang repository. Pinapayagan ng libreng plano ng Azure ang pangkomersyong paggamit at dalawang custom domain bawat app.

1. Gawin ang key sa Azure Static Web Apps

Tinatawag ito ng Azure na isang service principal. Sa Microsoft Entra admin center, buksan ang Entra ID → App registrations → New registration, bigyan ito ng pangalan at i-Register ito. Sa overview page ng app, kopyahin ang Application (client) ID at ang Directory (tenant) ID. Pagkatapos ay buksan ang Certificates & secrets → Client secrets → New client secret, pumili ng tagal at i-Add ito — kopyahin agad ang value ng secret, isang beses lang itong ipinapakita ng Azure.

Sa Azure portal, buksan ang resource group na gusto mong gamitin namin, pagkatapos ay Access control (IAM) → Add → Add role assignment. Piliin ang Contributor na tungkulin, italaga ito sa User, group, or service principal, hanapin ang app gamit ang pangalan, at Review + assign. Tandaan ang pangalan ng resource group at ang Subscription ID kung saan ito kabilang (hanapin ang Subscriptions sa portal).

2. I-connect ito rito

Buksan ang Integrations sa iyong dashboard at piliin ang Connect an account. Piliin ang Static hosting (Netlify, Vercel) bilang grupo at Azure Static Web Apps bilang account, punan ang Client ID, Client secret, Tenant ID, Subscription ID, at Resource group, at pindutin ang Connect account.

Sinusubukan muna namin ang iyong ipinapaskil bago ma-save ang anuman. Ang key na hindi gumagana ay hindi kailanman itinatabi, at sinasabi sa sagot kung ano ang naging problema rito. Ang key na gumagana ay pinananatiling naka-encrypt sa aming secrets vault — hindi kailanman sa aming database — at hindi na muling ipapakita, kahit sa iyo.

Ang susunod na mangyayari

  • Kapag gumawa o naglipat ka ng static site, lalabas ang account na ito bilang target ng pag-deploy.
  • Nagbi-build ang Azure Static Web Apps mula sa isang repository — wala itong paraan para tumanggap ng na-upload na build — kaya dapat magmula ang code ng site sa isang naka-connect na repository ng GitHub, GitLab, o Bitbucket. Mag-connect muna ng isa kung wala ka pa nito.

  • Ginagawa namin ang serbisyo sa iyong account, itinuturo ito sa repository, ikinakabit ang iyong custom domain,
  • at pinasisimulan ang mga pag-deploy. Ipinapakita ng page ng domain ang anumang DNS record na kailangan ng Azure Static Web Apps.

  • Ang paggamit at pagsingil ay nasa iyong account, na makikita sa sarili mong vendor dashboard.
  • Bineberipika ang isang apex domain sa pamamagitan ng TXT record at ang subdomain sa pamamagitan ng CNAME nito; ipinapakita ng page ng domain kung alin ang kailangan ng iyong domain.

Kung hindi ito kumokonekta

Tinanggihan ng Azure ang service principal. Maaaring nag-expire na ang client secret — palagi itong nag-e-expire, batay sa tagal na pinili mo — o wala nang Contributor na access ang app sa resource group. Magkamukha ang dalawang mensahe, kaya suriin ang role assignment bago gumawa ng bagong secret.

Walang nahanap. Tiyaking ang Subscription ID at Resource group ay ang mga itinalaga mo ng tungkulin, at ang Tenant ID ay ang directory kung saan nakarehistro ang app.

Sinasabi nitong tinanggihan ang key. Halos palaging isa sa tatlong bagay: may space o line break na nakopya kasama nito, isang key na nag-expire na, o isang key na binawi o muling ginawa pagkatapos mong kopyahin ito. Gumawa ng bago at i-paste itong muli.

Kumokonekta ito, ngunit may nabibigo sa kalaunan. Nagpapatotoo ang key ngunit kulang sa pahintulot na kailangan ng aksyon. Gumawa ng bagong key gamit ang mga pahintulot na nakalista sa itaas, pagkatapos ay i-disconnect ang lumang koneksyon at i-connect ang bagong key.

Pag-disconnect

Buksan ang Integrations, hanapin ang account at pindutin ang Disconnect. Agad nitong buburahin ang nakaimbak na key. Ang anumang gumagamit nito ay hihinto sa susunod nitong aksyon, at sasabihin ito ng mga screen na nakadepende rito sa halip na tahimik na mabigo.

Hindi pinapawalang-bisa ng pag-disconnect ang mga nagawa na — ang mga record, deployment, o setting na binago namin sa iyong account ay mananatili sa kanilang kasalukuyang estado. Kung sa tingin mo ay maaaring na-leak ang mismong key, bawiin din ito sa vendor; ang aming kopya lamang ang inaalis ng pag-disconnect, hindi ang sa kanila.

Pinakabago mula sa blog

Ang aming mga isinulat tungkol sa hosting, SEO, at pagpapatakbo ng mga site nang malawakan.

SEO at Pagbuo ng Link mula sa Hosting Layer: Pananaw ng isang Operator sa 2026

Kung paano hinuhubog ng hosting ang pag-index at link equity sa 2026: pagpapanatiling naka-index ang mga page, pagsusuri sa mga lumang domain bago magtayo sa mga ito, pagbuo ng link nang walang bakas ng search engine, at tapat na pagtingin sa kung ano ang kaya at hindi kayang gawin ng imprastraktura para sa SEO.

Basahin ang post →

Paggawang Mabilis at Ligtas sa WordPress: Isang Checklist sa Pagganap at Plugin

Isang praktikal na checklist para sa mabilis at ligtas na WordPress: pag-cache sa antas ng server, isang object cache bawat site, ang iilang plugin na sulit patakbuhin, pagpapanatiling updated sa stack, at ang mga pahina ng WooCommerce na hinding-hindi mo dapat i-cache.

Basahin ang post →

Paano Pumili ng Managed Web Hosting sa 2026: Gabay ng Mamimili

Kung ano talaga ang nagtatangi sa mahusay na pinamamahalaang hosting mula sa isang murang kahon na may control panel — mga migrasyon, backup, paghihiwalay, totoong pag-cache, at tapat na pag-scale — at kung paano ito huhusgahan bago kayo magpasya.

Basahin ang post →

Basahin ang blog →

Kailangan pa rin ng tulong?

Kasama ang suporta sa bawat plan, bukas ang desk 24 oras bawat araw, at maaari kang sumulat sa amin sa alinman sa aming 58 na mga wika — sasagutin ka namin sa iyong wika.

Makipag-ugnayan sa suporta → Lahat ng artikulo →