Watch the live training this came from
This article is drawn from Shanee Moret's Day 2 live training on Codex, websites, agent-ready infrastructure, and real business-owner implementation.
Watch the replay →There is a version of Codex that clicks around in your website portal, waits for pages to load, and hopes nothing breaks between actions. I used to have that version. It was slow, unreliable, and consumed a disproportionate amount of what the agent could otherwise do.
Then Codex recommended I move to GitHub and Cloudflare.
I did not come to this recommendation on my own. I ran an audit prompt, let Codex evaluate my Kajabi setup, and it told me the architecture was limiting what it could accomplish. I had not been maintaining the Kajabi site anyway. The recommendation made sense, and I moved.
What changed after the move is the subject of this post.
For the complete framework on why infrastructure decisions compound into everything else your agent can do, read the full guide.
What Codex Actually Needs to Work at Full Capacity
The mistake most business owners make when they experience slow or unreliable agent performance is to blame the tool. The actual problem is almost always the environment.
When Codex needs to make a change to a platform like Kajabi, it has to use what is called computer use or browser use — it navigates a browser interface the way a human would, clicking through menus and waiting for pages to render. Every action requires a page load. Every update is contingent on the interface cooperating. If the session times out, the work stops. If the interface changes, the agent loses its place.
This is not a Codex failure. It is what happens when a highly capable tool is given indirect access to a system that was not built for agent interaction.
GitHub and Cloudflare operate differently. When Codex has an API token for GitHub, it is not navigating a browser — it is communicating directly with the platform at the code level. A change I prompt becomes a deployed update without a single click. There is no interface to navigate. There is no session to maintain. The communication is direct, and the execution is immediate.
This is the core of why Codex recommended the move. Not because GitHub and Cloudflare are superior platforms in every dimension, but because they give an agent 100% of its capacity to do actual work rather than spending that capacity on overhead navigation.
Watch me explain this live during the session where I walked through the audit prompt and the recommendation in real time.
What GitHub and Cloudflare Each Do
Business owners who have never touched either platform hear these names and assume they are developer tools. They are. They are also, increasingly, the most practical infrastructure choice for anyone who wants agents to manage their web presence without friction.
Here is what each one actually does:
GitHub is organized storage for code and content with version history built in. Every change your agent makes is recorded as a commit with a unique identifier. If an update breaks something, you can revert to the previous state without rebuilding from scratch. If you are working with multiple agents — one handling design changes, one handling content, one handling SEO updates — you can see which agent made which change and when. Think of it as Notion for your website's code, except every edit is traceable and reversible.
Cloudflare is the layer that takes what is stored in GitHub and makes it live on the internet under your domain. It handles domain hosting, security, and publishing. When Codex pushes a change to GitHub, Cloudflare picks it up and deploys it to your live site. That chain — prompt to GitHub to Cloudflare to live website — happens without you logging into anything.
Both platforms are free to start. A full application with security features for a team of 10 or more users runs on Cloudflare's paid plan at $5 a month. One client is running exactly that configuration.
The Platform Capability Ladder
Not every business needs to move. That is the most important thing to understand about this decision. Before I recommend anything, the right move is to run an audit — because the infrastructure decision follows the audit, not the other way around.
One client runs a construction company in Houston. Years of weekly blog publishing. Strong local Google rankings built over time. When Codex audited the setup, it recommended staying on WordPress — the established SEO and AI search presence was too valuable to risk by migrating. Instead, the strategy became having certain pages receive signals from GitHub without moving the entire site.
With that caveat stated, here is how the options stack up:
| Infrastructure Type | Agent Access Method | Speed | Reliability | Version History | Cost |
|---|---|---|---|---|---|
| Locked SaaS (Kajabi, Squarespace) | Browser/computer use — clicking | Slow | Unreliable | None | $100–$300/month typically |
| Open CMS with plugins (WordPress) | Partial API + browser | Moderate | Variable | Plugin-dependent | Hosting costs vary |
| GitHub + Cloudflare | Full API token access | Instant | Consistent | Built in, full | Free to start; $5/month paid tier |
The farther up this ladder you are, the more of your agent's capacity goes to actual work instead of navigation overhead. Position on the ladder is a business decision about how much productive capacity you want to recover.
What Changes After the Move
When I moved my site to GitHub and Cloudflare, here is what became possible from a single prompt:
- Design changes deployed without opening a dashboard
- Blog posts written and published without logging into a CMS
- Security audits run and patched without navigating settings menus
- Shareable development links generated for team members to review work in progress before anything goes live
- Backend settings updated without a support ticket
One client had a website with hundreds of pages — multiple blogs, outdated content across the site, images without alt text. Codex rebuilt the entire thing in under 90 minutes. The client did not log into a single portal. That speed is a function of direct API access. On a locked SaaS platform, the same project would have required a developer and weeks of manual work.
The other change is harder to quantify but more important in the long run. When I never have to log into a portal to manage my website, I never context-switch away from whatever I was actually working on. The agent enters the portal. My thinking stays on the problem I was solving. That is not a small thing compounded over weeks and months.
For more on how environment access determines everything that comes after, read Setting Up Environments Before Activating a Goal.
The Audit Prompt to Run First
Do not make a platform decision without running this prompt. Copy it exactly and replace the brackets with your information:
"I have a website at [URL] in [platform]. I want you to edit the material, make it agent-friendly, and do weekly updates. Is it worth keeping in [platform] or do you suggest a more agent-friendly setup like GitHub + Cloudflare? What do you recommend? If you recommend staying, what credentials do you need and how do I get them to you?"
Codex will typically run an audit before making a recommendation. During a live session, audience members ran this prompt in real time. Codex recommended GitHub + Cloudflare for most. For one participant, it confirmed the site was actively blocking AI crawlers — a configuration the business owner had no idea was in place. For the construction company, it recommended staying.
Let the audit drive the decision. Do not pre-decide based on platform familiarity or switching anxiety.
Common Mistakes at This Step
Moving before auditing. The right sequence is: audit first, decision second. Some sites have established SEO value that outweighs the efficiency gains of a platform switch. Codex knows how to evaluate this. Let it.
Assuming this requires coding knowledge. It does not. Once the accounts are connected, every change happens through a prompt. If you need the GitHub personal access token, tell Codex: "Help me get the token you need. I have GitHub open in my browser." It will navigate Chrome and retrieve what it needs. You do not write code. You write prompts.
Treating the free tier as a limitation. Both platforms start free. The $5 Cloudflare paid plan is for applications with 10 or more company users requiring security features. For most small business owners building a website or a content hub, the free tier is sufficient to start.
Underestimating version history as a safety net. Every change has a commit number. Every commit is reversible. This is not a developer feature — it is the reason you can let an agent make changes to your live website without fear of permanent damage. The rollback is always available.
For more on how the infrastructure decision connects to your site's visibility in the agent economy, read The Agent-Readiness Test: What Your Score Actually Means.
The architecture of your web infrastructure is not a technical preference. It is a business decision about how much of your agent's capacity you want available for actual work. Every hour an agent spends navigating a locked interface is an hour it is not spending on your clients, your pipeline, or your growth.
The move to GitHub and Cloudflare is not the finish line. It is the foundation that makes everything after it faster, more reliable, and compound.
This is Part 18 of a 43-part series. Start from the beginning.
Use the skills behind this system
The Growth Academy Skills Dashboard includes 100+ Codex skills and prompts for SMB owners, including website audits, GitHub and Cloudflare setup, permissions, business intelligence, sales, and operations workflows.
See the Skills Dashboard →