Šta je Netlify?

Netlify je cloud platforma za build, deploy i hosting veb-sajtova i veb-aplikacija. Povezuje kod iz Git repozitorijuma sa automatizovanim build procesima, verzionisanim deployment-ima i isporukom preko globalne Content Delivery Network (CDN) mreže. Tim za to ne mora da održava sopstvene veb-servere.

Platforma podržava statičke sajtove, kao i aplikacije sa server-side rendering-om i dinamičkim funkcijama. Dostupne funkcije i način njihovog izvršavanja zavise od framework-a, njegove Netlify integracije i konfiguracije.

Za kompanije je ključna korist pregledan release proces: izmene mogu da se provere pre puštanja u produkciju i objave kao celovita verzija. Netlify preuzima deo infrastrukturnih zadataka. Arhitektura, kontrola kvaliteta i odgovornost za ceo sistem ostaju na razvojnom timu.

Tipičan workflow počinje povezivanjem Git repozitorijuma, na primer na GitHub-u, GitLab-u ili Bitbucket-u. Tim podešava production branch, build command i publish directory. Push na odabrani branch zatim može da pokrene build, a nakon njega i deploy.

Build konfiguracija i CI/CD

Build podešavanja mogu da se održavaju u dashboard-u i u datoteci netlify.toml. Važni delovi konfiguracije tako se verzionišu zajedno sa kodom. Secrets ne pripadaju repozitorijumu, već odgovarajućim environment variables. Produkciono i preview okruženje treba da koriste različite pristupne podatke i odgovarajuće dozvole.

Netlify može da izvršava testove u okviru konfigurisanog build procesa. Automatizovan deployment, međutim, ne znači automatsku kontrolu kvaliteta: tim mora da podesi linting, unit i integration testove, kao i pravila odobravanja. Tek te kontrole pretvaraju automatizovani deploy u pouzdan CI/CD pipeline.

Atomski deployment i rollback

Kod atomskog deployment-a nova verzija postaje dostupna tek kada se otpreme sve pripadajuće datoteke. Korisnici zato tokom otpremanja ne dobijaju mešavinu starih i novih datoteka. Ako nastane problem, raniji uspešan deploy koji je i dalje dostupan može ponovo da se postavi kao produkciona verzija.

Takav rollback ne poništava automatski migracije baze, izmene CMS sadržaja ili promene u spoljnim API-jima. Za te zavisnosti potreban je zaseban plan oporavka. Naredni produkcioni deploy pokrenut iz Git-a može ponovo da zameni verziju vraćenu rollback-om.

Deploy Previews za review i odobravanje

Deploy Previews prikazuju izmene iz pull request-a ili merge request-a na zasebnom URL-u. Razvojni, dizajnerski i poslovni timovi mogu da provere istu verziju pre nego što kod stigne u produkciju. Branch Deploys podržavaju dodatna test okruženja. Zaštita pristupa i povezivanje sa test podacima moraju posebno da se podese.

Deploy Preview za izmene koda nije automatski i preview neobjavljenog CMS sadržaja. Za to Headless CMS, frontend i odgovarajući preview režim moraju da rade zajedno.

Statički resursi i server-side rendering

Statičke datoteke mogu da se isporučuju preko globalnog CDN-a. Kod dinamičkih stranica aplikacija određuje koji sadržaj nastaje za svaki request i koji odgovori se keširaju. Framework-ovi kao što su Astro, Next.js, Nuxt ili Remix zahtevaju odgovarajuću konfiguraciju ili integraciju.

Sam CDN ne garantuje brz sajt. Veliki JavaScript bundle-ovi, neoptimizovane slike i spori backend API-ji ostaju uska grla. Rendering, pravila keširanja i spoljne zavisnosti moraju da odgovaraju stvarnom načinu korišćenja.

Serverless Functions i Edge Functions

Netlify Functions izvršavaju backend logiku bez potrebe da tim održava sopstvene servere. Tipični zadaci su API endpoint-i, obrada podataka iz formulara i povezivanje sa spoljnim servisima. Edge Functions izvršavaju JavaScript ili TypeScript na network edge-u, na primer za routing, redirect-e ili prilagođavanje request-a.

Ova dva modela imaju različite uslove izvršavanja i limite. Dugotrajne procese, složenu obradu podataka ili specifične zahteve za mrežni pristup zato ne treba prebacivati u funkciju bez prethodne provere. Presudno je koji deo arhitekture može pouzdano da izvrši konkretan zadatak.

Headless CMS i Composable Architecture

Headless CMS kao što su Sanity ili Prismic upravlja sadržajem i isporučuje ga preko API-ja. Frontend obrađuje taj sadržaj, dok Netlify preuzima build, deploy i hosting. Build Hooks mogu da pokrenu novi build kada se sadržaj objavi u CMS-u. Druga opcija je učitavanje sadržaja tokom rada aplikacije, u zavisnosti od rendering i cache strategije.

Ovakva podela odgovornosti relevantna je za B2B sajtove, stranice proizvoda, dokumentaciju, marketinške sajtove i e-commerce frontend-e. Pretraga, commerce backend i drugi API-ji ostaju nezavisne komponente. Razdvajanje olakšava promene, ali zahteva jasne interfejse i definisanu obradu grešaka.

Ponovljivi build procesi, zajednički preview i verzionisani deployment-i smanjuju broj ručnih koraka pri predaji izmena. To posebno pomaže kada više programera i poslovnih timova redovno proverava i objavljuje promene. Korist dolazi iz jasno definisanog workflow-a, ne samo iz izbora hosting platforme.

Odgovornosti za produkcioni sistem ipak moraju da budu jasne: ko reaguje na neuspešan build? Ko upravlja secrets vrednostima i pravima pristupa? Kako se otkrivaju greške u CMS-u, pretrazi ili backend-u? HTTPS i funkcije platforme ne zamenjuju bezbednu aplikativnu logiku ni proveru spoljnih integracija.

Skaliranje je takođe svojstvo celog sistema. Frontend može da prihvati dodatne zahteve dok povezani API dostiže svoje limite. Load testovi, timeout-i, cache strategije i budžet zato se definišu pre puštanja u produkciju, a ne tek nakon prve kampanje.

Build logovi, function logovi i observability pomažu da se razumeju greške, zahtevi i potrošnja resursa. Netlify Web Analytics koristi podatke o pristupu zabeležene na serverskoj strani. Real User Monitoring (RUM), nasuprot tome, meri ponašanje u browser-u preko ugrađenog JavaScript snippet-a. To su različiti izvori podataka.

Za performanse koje korisnik doživljava važni su, između ostalog, Largest Contentful Paint (LCP), Interaction to Next Paint (INP) i Cumulative Layout Shift (CLS). Dostupne funkcije i periodi čuvanja podataka treba da odgovaraju izabranom paketu.

Tehnički monitoring odgovara na druga pitanja od marketinškog tracking-a. Za konverzije, kampanje i slanje event-a drugim sistemima potrebna je zasebna Measurement Infrastructure. Consent, tokovi podataka i plan merenja moraju da odgovaraju konkretnoj implementaciji.

Netlify razlikuje aktuelne pakete zasnovane na kreditima i legacy pakete postojećih naloga. Ranije navedeni fiksni limiti za bandwidth ili build minute zato ne mogu automatski da se primene na novi nalog.

Pored osnovnog paketa, za planiranje troškova važni su produkcioni deployment-i, zahtevi, prenos podataka i compute potrošnja. Dodatne funkcije i spoljni servisi mogu da donesu nove troškove. Sajt koji se često ažurira ima drugačiji profil potrošnje od sajta sa velikom posećenošću i retkim izmenama.

Stanje na dan 6. novembra 2026. Pregled služi za razumevanje opcija, a ne kao obavezujuća ponuda. Konkretne cene, kredite i dodatne troškove proverite prema aktuelnim Netlify paketima i uslovima svog naloga. Za produkcione sisteme preporučujemo budžet potrošnje i definisane pragove upozorenja.

Netlify ima smisla kada tim želi da poveže build, deploy i hosting u pregledan workflow. Platforma smanjuje infrastrukturni posao. Ne zamenjuje odluke o modelima sadržaja, rendering-u, testovima, bezbednosti i radu sistema.

U okviru usluge Platform Engineering hosting zato posmatramo kao deo arhitekture. Polazimo od zahteva sajta, povezanih sistema i ljudi koji ih razvijaju i održavaju.

Tehnički detalji u Netlify dokumentaciji: build konfiguracija, deployment, Functions i monitoring.