Most posts about building a blog go straight into frameworks, build pipelines, and code snippets. This one isn’t that. I want to share something more practical — how I actually use GitHub Copilot and GitHub Pages every week to keep this blog alive, and a constant list of half-finished ideas.
If you’ve ever wondered “do I really need to be a web developer to run a technical blog?” — the short answer is no. With the right pair of tools, you just need to be someone who has something to say.
The Two Tools That Do All the Heavy Lifting
Everything about this blog runs on two GitHub products:
- GitHub Copilot — my writing partner, editor, and rubber duck, all in one
- GitHub Pages — the free, reliable place where this site actually lives
I don’t use a CMS, I don’t pay a hosting bill, and I don’t have a “web team.” Just these two tools, a Markdown file, and an idea.
How I Use GitHub Copilot
I treat Copilot less like a code generator and more like a patient colleague who never gets tired of my drafts. Here’s what that looks like in a typical week.
Turning a rough idea into an outline
When I sit down to write, I almost never start with a blank page. I describe the idea to Copilot Chat in one or two sentences:
“I want to write a post about how I use AKS node pools to run GPU workloads cost-effectively. What are the key sections I should cover?”
Copilot gives me a structured outline — intro, problem, approach, gotchas, wrap-up. I can tweak, delete, or reorder. In five minutes I have a skeleton to write into, instead of staring at the cursor.
Polishing what I’ve already written
I write the first draft in my own voice. Then I highlight a paragraph, open Copilot Chat, and ask something like:
“Is this paragraph clear? Can you suggest a tighter version without changing the meaning?”
It comes back with a cleaner alternative. Sometimes I take it word for word, sometimes I steal one phrase, sometimes I ignore it. But it’s always faster than re-reading the same sentence ten times trying to fix it myself.
Catching what I missed
Before I publish, I ask Copilot to read the whole post as a reviewer:
“Read this post as a reader who is new to Azure. Flag anything that’s unclear or assumes too much knowledge.”
That one prompt has saved me from publishing plenty of posts that would have been confusing to a beginner. It’s the kind of second pair of eyes you’d normally need a friend or editor for.
Writing once, reviewing often
The core principle for me is simple: Copilot writes the scaffolding, I write the voice. The personal stories, the hot takes, the “here’s what bit me in production” moments — those have to come from you. But the structure, the summaries, and the polish can absolutely be handed off.
How I Use GitHub Pages
Hosting a blog used to be one of the biggest chores of running one. Servers, SSL renewals, hosting bills, CDN configuration — it all added friction that made me not want to write. GitHub Pages removed every one of those chores.
Here’s what my publishing flow actually looks like:
- Write the post — a single Markdown file on my laptop
- Commit and push — one command, takes two seconds
- Open a pull request — GitHub automatically runs checks to make sure nothing is broken
- Merge — within two minutes, the post is live at kasunrajapakse.me
That’s it. No dashboards, no “deploy” buttons, no waiting for support tickets.
Why I Stick With GitHub Pages
A few things keep me here instead of jumping to Medium, Substack, or a paid platform:
- It’s free. No monthly bill, no tier limits, no “upgrade to unlock analytics.”
- I own everything. The Markdown files, the domain, the design. If GitHub disappeared tomorrow, I could move the whole blog to any other host in an afternoon.
- My custom domain works out of the box. I pointed
kasunrajapakse.meat GitHub and got automatic HTTPS for free. - It’s fast. GitHub serves the site from a global CDN, so readers anywhere in the world get the same snappy experience.
- It stays out of my way. I’ve never had to troubleshoot an outage, scale a server, or renew a certificate.
For a technical blog with mostly static content, this is honestly hard to beat.
What Actually Matters
Whatever stack you end up with, the real insight is this: the best publishing setup is the one that removes friction between your ideas and your readers. For me, GitHub Copilot removes the friction of getting words onto the page, and GitHub Pages removes the friction of putting those words online.
Everything else — the framework, the theme, the custom domain — is just details. Pick tools that let you focus on what you’re trying to say, and the writing will follow.
If you’ve been sitting on the idea of starting your own blog, my honest advice: don’t over-engineer it. Open a GitHub repo, write a Markdown file, turn on GitHub Pages, and publish. You can always improve the setup later — but you can’t improve a post you haven’t written.
Have questions about my setup, or want to swap notes on blogging? Feel free to reach out on X or LinkedIn — I always enjoy hearing how others are doing it.