Putting the site live with Cloudflare Pages

In the previous post I wrote about backing up the site and keeping records on Google Drive. This part is different. Now the subject is the day the site left the notebook and started opening at rodrigoesporto.com.

What I wanted to solve

On 3 October 2026 the personal site went live. I work during the day, and at night and on Sundays I build with AI agents. I already had the domain, the page generator, and the code stored. What was still missing was the step other people feel: they type the address and the pages are there.

Publishing by hand is an extra step, and it is easy to get wrong. You build the files, upload them, check, and on the next change you do it again. I wanted something else: save on GitHub and have the new version show up on the domain on its own.

I use Cloudflare. I pay them for the domain. I am not reviewing the company from the outside. I am telling you how I published.

Quick summary

• On 3 October 2026 the site went live on Cloudflare Pages, at rodrigoesporto.com.
• Each time a change is saved on GitHub, Cloudflare publishes the new version on its own.
• The texts I had approved that day: Home, About, Contact, and the first post, in Portuguese and in English.
• Contact only through X.
• In the report from Analista, on 3 October 2026, the Lighthouse audit scored speed 99 to 100 and SEO 100.

First: what Cloudflare Pages is

Cloudflare Pages is the service that takes the site and puts it on the internet. In my case, it reads what is on GitHub and serves the pages at the domain address.

Hosting, in this text, is the place where the published site lives. Pages is that hosting, tied to the repository. A repository is the code folder with history, on GitHub.

Think of a print shop that, every time you hand in a new original, prints the issue and puts it on the newsstand. You do not carry the box of papers to the corner.

The real mechanism is a trigger. You save a change on GitHub. Cloudflare sees that change, publishes the new version, and points the domain at it. The print-shop comparison stops here: a paper stand may still have yesterday’s issue on the shelf until someone swaps it. On Pages, the version the visitor asks for is the one just published. A pile of old editions does not sit at the same address.

What publishing is (and GitHub in this step)

Publishing, in this text, means making the pages reachable at my own address. I am not mixing that with writing the post, or with generating the site on the notebook. It is the moment someone opens rodrigoesporto.com and finds what I approved.

GitHub, in this step, is the vault for the code. Each change saved there becomes the signal for Cloudflare Pages. No new original, no new issue. GitHub keeps the history. Pages reads what is there now.

A paper original does not start the press on its own. Here, saving is already the request to publish.

Lighthouse and SEO in this measurement

Lighthouse is a Google audit for web pages. It opens the page the way a visitor would and gives scores. In the report from Analista, on 3 October 2026, speed landed between 99 and 100, and SEO landed at 100.

SEO, in this measurement, is the set of checks on whether the page is organized to be found: title, language, the basics Lighthouse itself tests. It is not first place on Google. I do not have a search ranking to report in this part.

It is a pre-trip checklist for a car: lights, tires, brakes. A high score says those items on the list passed. It does not say the road is empty.

Analista is the agent that follows the X profile and the site visits and sends a short summary each day. The numbers from this audit came from that report. That is what the report brought. It is not a study published by someone else.

What I used

I used the domain rodrigoesporto.com. I used GitHub as the source of the code. I used Cloudflare Pages to publish. I used Hugo to generate the static pages, the choice I had already made. Hugo, in one sentence, is the program that turns texts into finished pages. A static site, in this text, is a page already built: the server delivers the ready file, without writing the text at the moment of the click.

I used the texts I had approved myself: Home, About, Contact, and the first post, “O início de uma jornada”, in Portuguese and in English. I used X as the only contact. I used the report from Analista for the Lighthouse scores.

Login, dashboard, and account stay out of this text.

How it went

If you want to copy the logic, without copying the brand, the path is this:

1. Keep the site in a GitHub repository. In my case, the code was already there.
2. Connect that repository to Cloudflare Pages. Hosting then reads the vault.
3. Point your own domain at the published site. The name people type has to reach that publish.
4. Save a change on GitHub. Cloudflare publishes the new version on its own. You do not upload files by hand.
5. Open rodrigoesporto.com and check the pages you approved. In my case, on 3 October 2026: Home, About, Contact, and the first post, in both languages.
6. Check Contact: only X. No other channel on this site.

In my case the repository was connected, publishing became automatic, and the domain opened the pages. I am not going to invent the dashboard screen.

What went wrong, or what I learned

In this part I do not have a publish error message to tell. What I have is the relief of dropping the manual step.

Publishing by hand is the kind of task you get right once and forget the second time. An old file still live. The wrong folder. A version you swear you uploaded. Connecting the repository to hosting cuts that queue.

The lesson for beginners: connect the repository to hosting and let publishing be automatic.

What I would do differently: check the address on a device that is not the notebook I published from, on the same day. The browser cache and habit fool you. Cache, here, is the old copy the device keeps so the page opens faster. I do not have a case in this part where that failed. It is the habit I want.

None of these tools replace judgment. They shorten the path from “I know what I want” to “it is live.” Pages publishes what is on GitHub. If what is on GitHub is wrong, the mistake goes live at the same speed.

Costs and limits

In this part there is no extra money figure to report. I already had the domain. The price of that purchase belongs to the post about the choices, not this one.

What this setup does well: publishing stops being a separate, risky step. It is saving.

What it does not do: write the text or approve the text. It is also not site security.

This is what I did on 3 October 2026, not a ranking of tools. Cloudflare Pages is the tool I used. I am not saying it is the only one.

Who it is for, and who it is not for

It is for you if you already have a static site on GitHub and your own domain, and you do not want to upload files by hand on every post.

It is not for you if you still have nothing to publish. Connecting empty hosting does not create the diary. It is also not for you if you need a program on the server assembling a page on every click. This site is static. Pages, in this setup, serves finished pages.

Closing

I wanted to type the address and find the pages, without uploading files by hand. On 3 October 2026 that became true at rodrigoesporto.com. Cloudflare Pages publishes when I save on GitHub.

The rule to copy: connect the repository to hosting and let publishing be automatic.

In the next post I start site security: the lock, TLS 1.2, and HSTS.

If you want to follow the journey, I am on X: @RodrigoesPorto.

Sources and links

• Cloudflare Pages: https://developers.cloudflare.com/pages/
• This site: https://rodrigoesporto.com/
• Report from Analista, 3 October 2026 (Lighthouse scores)