Publishing a site with GitHub and Netlify: atomic deploys, previews and the workflow I use every day

For years, publishing a site meant dragging files onto a server via FTP and hoping not to overwrite the wrong one. Today all my new projects go through GitHub and Netlify, this site included. It is not a fashion choice: it is the workflow that lets me work more safely, verifiably and quickly, and show every change to the client or agency before it goes live.

The workflow, in short

The code (and often the content, in Markdown) lives in a GitHub repository. Netlify is connected to it: on every push it runs the build in a clean environment and publishes the result to its CDN. Every pull request generates a Deploy Preview, a separate test address with the complete, working site. When the change is approved and merged into the main branch, the production deploy starts.

What changes technically

Atomic, immutable deploys

With FTP the site goes through an in-between state while files upload: half old, half new. On Netlify the new version is built in full and activated in a single step: visitors see either the previous version or the new one, never a hybrid. Every deploy is kept exactly as it was, with its own identifier.

Instant rollbacks

Because deploys are immutable, going back requires no rebuild: you reactivate the previous one. In parallel, every change has a commit on GitHub that can be reverted and republished.

A preview for every change

This is the most visible benefit for whoever commissions the work. The Deploy Preview is the real site, with real data, viewable on a phone and shareable. The agency or client approves the product, not screenshots.

Reproducible builds

The build runs in a clean environment with Node and dependency versions pinned by the lock file. If it works in the preview, it works in production. It is the end of "it worked on my machine".

Configuration in code

Redirects, security and cache headers and per-deploy-context rules live in project files, versioned and reviewed like everything else. No dashboard someone edits by hand without leaving a trace. Environment variables are separated by context: production, previews, branches. A production key never ends up in a preview.

Serverless functions and forms

Dynamic parts are written as serverless functions that run only when needed: this site's AI chat, for example, is a server route that reads the knowledge base and calls the model API, with the key never reaching the browser. Contact forms go through Netlify Forms, with no server to maintain. HTTPS is enabled and renewed automatically.

A smaller attack surface

A pre-generated site has no exposed database and no public login panel. What remains to protect are the GitHub, Netlify and domain registrar accounts, with two-factor authentication. The comparison with WordPress is in Hacked WordPress site.

My workflow

It is the same one I use for this site:

1. one branch per topic, with a name that says what it contains;
2. small, described commits;
3. a pull request on GitHub, with the Deploy Preview generated by Netlify;
4. review on the preview, together with whoever approves;
5. merge into the main branch, which is never touched directly, and an automatic production deploy.

That way every change has a history, a preview and a way back.

Domain, DNS and email

Two recommendations I often see neglected. The domain must be registered to the site owner, with auto-renewal and registrar access under their control. Email stays on a dedicated service, separate from the site hosting, with SPF, DKIM and DMARC configured: moving the site to Netlify must not touch email, and DNS records have to be changed with that in mind.

When it is not the right fit

• Large non-technical editorial teams without a connected headless CMS: Git is not a writing tool for everyone.
• Applications with lots of real-time data that need servers and databases always on: Netlify can host the front end, but the backend lives elsewhere.
• Complex WooCommerce stores that work well: moving them costs more than it rarely returns.
• Sites that already work well on traditional hosting, fast, secure and up to date.

My take

Since working this way I would not go back. The difference is not only technical: it changes the relationship with whoever commissions the work. Instead of "I've uploaded it, take a look", I send a preview link and the real site to look at. Instead of "let's hope the update doesn't break anything", there is a deploy that can be undone with one click. It is also why, when a project does not need a dynamic admin panel, I suggest moving from WordPress to Nuxt and publishing this way.

There is also a transparency aspect clients appreciate: the repository history is a readable record of everything that was done, with dates and descriptions. There is no need to trust a report: the work is there, verifiable, and it remains the client's property even if one day they choose another developer.

Why work with me

I have been programming since 1999, delivered more than 300 projects and work as an external developer with about 30 agencies, from Rome and remotely. This site is built with Nuxt and published with GitHub and Netlify: I set up the same workflow, with previews, redirects and per-context variables, and leave it documented for you or your agency.

If you want to know whether this way of publishing suits your site, get in touch: in a call of about 20 minutes we look at how you publish today. The service is in Hosting and infrastructure.