Deploying an app is like riding a bike.

Once you’ve done it properly, you can do it again. But if you haven’t ridden in six months, those first few wobbly metres are always a little nerve-wracking. You know you remember how, and then you put your foot on the pedal, and you’re suddenly not quite sure.

That’s the honest reality of DevOps for most developers on small teams. You don’t do it often enough to stay sharp on the details.

AI changes this. It doesn’t make you a DevOps expert, but it holds the details reliably while you focus on whether the broader approach is right.

I wanted to show you what that actually looks like, so here is the full deployment of a real client app, nine phases, an Oracle ARM64 server, and about thirty minutes of supervised execution.

## **What We Built and Where We Shipped It**

![Ethics Pilot by Elephant Stripes AI](https://miro.medium.com/v2/resize:fit:1400/1*R-qAsMB4he01YLA6k_8cFQ.png "Ethics Pilot by Elephant Stripes AI")

The app is called _Ethics Pilot_. It’s a simple document review system: upload files, select a few, and chat with an AI about their contents. Built for a client, running on a Next.js and PostgreSQL stack.

Because the product name isn’t final, it doesn’t have its own domain yet. We deployed it to \`[ethics-pilot.elephantstripes.ai](http://ethics-pilot.elephantstripes.ai), under the [Elephant Stripes](https://elephantstripes.ai/) umbrella, which we use for client builds in progress.

Production server: Oracle ARM64 instance. Docker for containerisation. Nginx as a reverse proxy. TLS via Let’s Encrypt. Self-hosted GitHub Actions runner. Google Chat webhook for deployment notifications.

That’s the full surface area. Here’s how we covered it.

## **The 9-Phase Deployment Blueprint**

The key to using AI effectively for DevOps is structure. You give the agent a clear plan, server access, and a set of success criteria for each phase. It executes. You steer.

### **Phase 1: DNS**

Before anything else, the domain has to exist.

We have a Cloudflare token scoped to the Elephant Stripes domain. Codex uses it to create the DNS record and validates that \`[ethics-pilot.elephantstripes.ai](http://ethics-pilot.elephantstripes.ai) resolves correctly.

Two minutes. No clicking around in dashboards.

### **Phase 2: GitHub Runner**

The self-hosted runner is what executes CI/CD jobs on our production server instead of on GitHub’s shared infrastructure.

This matters on ARM64. GitHub’s default runners are x86. If you build a Docker image on x86 and run it on ARM64, you get subtle failures that are genuinely unpleasant to diagnose. A self-hosted runner on the production server sidesteps all of that.

Codex registers the runner under Ubuntu, connects it to the repository, and confirms it’s online.

### **Phase 3: Repo production runtime**

Here the codebase gets ready for the real world.

Codex adds a `.dockerignore, writes a production` Dockerfile, and updates `next.config.js with the environment settings appropriate for a live server. It also creates the` [docker-compose.prod](http://docker-compose.prod).yml.

Think of this phase as the difference between “it runs on my machine” and “it runs where it needs to.”

### **Phase 4: Production seed mode**

In development, the database gets seeded with test users, fake organisations, and demo content. That’s useful locally. In production, it’s a problem.

Codex updates the seed configuration so that only a superadmin account gets created on first boot. Everything else is explicitly excluded.

### **Phase 5: CI/CD workflow**

This is the engine.

Codex builds a GitHub Actions workflow with three stages: validation, production deploy, and notification.

**Validation** catches linting errors, type issues, and missing environment variables before the build even starts. **Production deploy** builds the Docker image, copies it to the server, and restarts the containers. **Notification** pings a Google Chat group when the deployment succeeds.

We give Codex an existing workflow from another project as a reference. It patterns the output on that, which keeps things consistent across our project portfolio.

### **Phase 6: Production host environment**

The server needs to be ready before the app arrives.

Codex creates service accounts, sets up the directory structure, writes environment files, and sets file permissions. No root processes. Everything is owned by the right account.

### **Phase 7: Nginx and TLS**

Nginx sits in front of the Docker container and handles incoming HTTPS traffic. Certbot handles the SSL certificate and sets up automatic renewal.

If you’ve configured this manually before, you have a story. With Codex doing it, the story is just “it worked.”

### **Phase 8: First deploy**

Everything is committed. Codex pushes to main. The GitHub Actions workflow triggers.

We watch it go.

**Run one.** The build fails. Missing build-time environment variable placeholders in the .env file. Next.js couldn’t compile. Codex spots the error in the build log, fixes the file, and pushes.

**Run two.** Gets further. Fails at the release gate. The CI fix commit didn’t include a changelog entry. Codex adds one and pushes.

**Run three.** Validation passes. Docker image builds. Deployment runs. The Google Chat notification arrives.

Thirty minutes. Three iterations. No manual debugging, no log archaeology, no nervous Googling.

This is what a first deployment looks like. There will always be a few issues. The difference with AI is that Codex handles the diagnosis and the fix in one movement. You watch, you learn what to look for, and each subsequent deployment goes faster.

### **Phase 9: Runbooks and final checks**

Once production is live, document what just happened.

Codex writes runbooks for common operations like deployment, rollback, and database migration. It creates a changelog entry for the deployment itself. It notes the follow-up items: the missing build cache configuration, the npm version warning that appeared during the build.

These aren’t just notes. They’re the foundation for everything that comes next.

## **The Thing about Runbooks**

![Photo by apoorv mittal on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*wbF_d_gLDNgBqXKh "Photo by apoorv mittal on Unsplash")

When you work with an AI agent, runbooks are reusable prompts.

“Use the deployment runbook” triggers a defined sequence: pre-deploy checks, execution, post-deploy validation. “Use the end-to-end testing runbook” kicks off environment setup, test execution, and teardown, all in the right order.

You write them once, refine them after each project, and they compound. The concept comes from what the folks at [Every](http://every.to/) call compound engineering: skill books that improve incrementally over time. Three projects in, you have something genuinely powerful.

We also maintain a daily changelog that Codex can scan to understand project history before acting. One summary line per commit, with a full log underneath. It costs almost nothing to maintain and it means the AI always knows what the project looked like yesterday.

## **What You Should Actually be Thinking About**

![Photo by Mariia Shalabaieva on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*xvAyd9xk4xBOiVQv "Photo by Mariia Shalabaieva on Unsplash")

The mental shift is this: AI handles execution, you handle architecture.

Stop sweating the exact \`chmod flags. Start asking:

*   Are our Cloudflare token permissions correctly scoped?
    
*   Is the Nginx configuration locked down the way it should be?
    
*   Are Docker images being cleaned up between deployments?
    
*   Are dependencies patched? Stale packages are one of the most common security vulnerabilities.
    
*   Have service accounts accumulated permissions they shouldn’t have?
    

These are judgment calls. The YAML syntax, the certbot command flags, the GitHub Actions step structure, those are just execution. Let the agent handle them.

## **One last thing**

At [Elephant Stripes](https://elephantstripes.ai/), this is how we build. Structured, AI-assisted delivery from initial build through to production deployment, for clients who want something built well without the enterprise overhead.

If you’re building something and want a team that knows how to ship it, we’d love to hear about it! Drop your comments below.

The app wasn’t there before. Now it is. That’s all deployment ever really is.

Full deployment process available on Elephant Stripes Youtube account!

@[youtube](https://www.youtube.com/watch?v=CnOFBjkl-to)

* * *

_If you’re looking to rebuild your product or workflows for the AI era, feel free to contact_ [_ElephantStripes_](https://elephantstripes.ai/)_. We combine AI-driven speed with human judgment to build software that actually fits._

_Subscribe to our YouTube channel for daily AI tips:_ [https://www.youtube.com/@elephantstripesai](https://www.youtube.com/@elephantstripesai)

I Let AI Do My DevOps. Here’s What Happened.

Nine phases. One Oracle server. Zero terminal anxiety.

Nine phases. One Oracle server. Zero terminal anxiety. Deploying an app is like riding a bike. Once you’ve done it properly, you can do it again..

There’s a phrase that quietly runs most business software decisions: “good enough.”

It’s how companies ended up on WordPress, Shopify, or whichever open-source CMS more or less solved the problem.

It’s why internal tools are a patchwork of Notion, Airtable, and three integrations held together by an optimistic Zapier workflow.

“Good enough” made sense for a long time. Bespoke software was expensive. It required big teams, long timelines, and a budget that only enterprise companies could justify without flinching. So small and mid-market businesses made do. They bent their processes to fit their tools.

That era is ending. Bespoke software is back, and AI is the reason.

## **The Pendulum, and Why It Swung**

![Photo by engin akyurt on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*cgws-OOEaOzbv1H9 "Photo by engin akyurt on Unsplash")

Cast your mind back to the late 90s and early 2000s. Digital agencies were building bespoke content management systems for businesses of all sizes.

Every client got something crafted from scratch, tailored to exactly what they needed. It was expensive, sometimes messy, and occasionally out of date the moment it shipped, but it was theirs.

Then the economics shifted. Open-source platforms matured. WordPress became the default answer to almost any web problem.

Tools like Drupal, Joomla, and later Shopify, Webflow, and dozens of SaaS alternatives made standardised software the sensible choice. It had security updates, active communities, and enterprise tiers if you needed to scale.

Migrating to these platforms was smart. For most businesses, it was the right call.

Standardised software is built for the widest possible audience. By design, it’s a compromise. And the compromise starts showing itself the moment your needs drift even slightly outside the mainstream.

You want to restructure how SEO metadata is managed across your pages? File a request and hope it makes the roadmap. You want your blog, email sends, and contact management in a single admin panel that actually reflects your workflow? Good luck finding that out of the box. You need structured data configured exactly the way Google expects for your specific content type? You’re probably doing it manually, in multiple places, with no single source of truth.

That’s the ceiling of “_good enough._” And AI has just given us a way past it.

## **Why Bespoke is Suddenly Affordable**

![Photo by Growtika on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*TylBpeXKIlw60I4c "Photo by Growtika on Unsplash")

Building custom software used to come down to one constraint: time. Developers are expensive. Good developers are very expensive. A small team building a bespoke CMS or internal tool represented months of salary, testing, iteration, and maintenance. Most businesses simply couldn’t justify it.

AI has collapsed that constraint.

Done **_correctly_**, AI-assisted development doesn’t just speed things up. It applies best practices systematically, because it’s trained on them.

You’re not trading quality for speed. You’re getting both. What once required a team of five over six months can now be built by one person with the right process in a fraction of the time.

The gap between “bespoke” and “affordable” has essentially closed. And once that gap closes, the whole calculus of software procurement changes.

## **Our Own Path Through the Platforms**

At [Elephant Stripes](http://elephantstripes.ai/), we didn’t arrive at this conclusion theoretically. We went through it.

VideoTranslator, our core product, has had a few homes over the years. It started on Hugo: a static site generator that was genuinely fast and easy to work with. Blog posts were markdown files, GitHub Actions handled deployments, and there was no backend to speak of. Lean, performant, and exactly right for where the business was at the time.

As the product grew, so did the requirements. We moved to a frontend framework with Forestry as the CMS. Forestry was decent, but it had limits we kept running into, and the frontend wasn’t something we were proud of.

![VideoTranslatorAI’s website interface in early (Hugo frontend; Strapi backend)](https://miro.medium.com/v2/resize:fit:1400/1*BSZsFV12yTFUuz2rJX2oJw.png "VideoTranslatorAI’s website interface in early (Hugo frontend; Strapi backend)")

Then came a rebrand. We moved to Gatsby on the frontend with Strapi as the backend. Strapi is genuinely good software. Gatsby, another static site generator like Hugo, had real promise as a concept, but the project eventually stalled. Community support faded. It just didn’t age well.

Each of these platforms worked, in the way that “good enough” works. None of them was exactly what we needed. We were always working around something.

## **Building the CMS We actually wanted**

Early this year, my team and I started spending a lot of time with what people are calling vibe coding: using AI to build software quickly, iteratively, with a rough idea rather than a full spec. It was genuinely fun, and it was **fast**.

And at some point, it occurred to me that instead of adopting yet another platform, we could just build the CMS we’d always wanted.

What did that look like?

We wanted all our SEO in one place. Not scattered across plugins, settings panels, and meta boxes, living in three different corners of an admin interface.

We wanted to sit on a single page and see the page title, meta description, Twitter card image, and JSON-LD structured data all together.

Press enter or click to view image in full size

![Our Bespoke CMS for VideoTranslatorAI](https://miro.medium.com/v2/resize:fit:1400/1*_e24qm_kzIpzPePK89hYaw.png "Our Bespoke CMS for VideoTranslatorAI")

JSON-LD is the structured data format that tells Google explicitly what your content is about. It’s what powers those rich snippets in search results: the business name, hours, reviews, and product details laid out clearly beneath the main link.

In a generic CMS, getting JSON-LD right is fiddly. It involves plugins, workarounds, and guessing whether something fell back to a default.

In a bespoke CMS built for our specific needs, every single page has an SEO section. Right there, next to the content. Set it, confirm it, done.

We also wanted our blog system to handle email sends. We wanted project pages, recognition sections, and contact management in the same admin interface, so our team didn’t have to context-switch between platforms.

We wanted the whole thing to reflect how our business actually works, not how an open-source contributor imagined a generic user might manage content.

Building this even five years ago would have been a significant investment. This year, it took weeks.

![VideoTranslatorAI’s website interface today. Powered by our bespoke CMS.](https://miro.medium.com/v2/resize:fit:1400/1*3YVYEIYVW8WwZrSTypnfeQ.png "VideoTranslatorAI’s website interface today. Powered by our bespoke CMS.")

## **What The Improvement Process Looks Like**

Bespoke software gives you something else that off-the-shelf platforms can’t: genuine ownership of the improvement loop.

When I identified recently that our CMS needed better SEO hygiene across pages, I didn’t file a feature request and wait.

I ran an audit of the current site state, cataloguing what was missing, what was inconsistent, and what was falling back on defaults that weren’t quite right.

With that audit, I created a deep-dive analysis to validate the gaps in detail. From there, an implementation plan with clear phases: what to fix, in what order, with what expected outcomes.

After that, I set an AI agent to work executing the plan. It ran for about 28 minutes, worked through each phase, wrote a changelog for each one, and handled the database migrations I’d flagged. I tested the output, and I’m confident to say that it looked good.

The whole cycle, from spotting the problem to reviewing the result, happened in a single working session.

Compare that to the experience of trying to get a similar fix done inside an off-the-shelf platform: filing support tickets, waiting on plugin updates, hoping a third-party integration doesn’t break when the platform updates underneath it.

The bespoke path is faster, more predictable, and leaves zero mystery about what changed and why.

_Watch how I optimise website SEO with Codex:_

@[youtube](https://www.youtube.com/watch?v=yaSKUoxpfuI)

## **The Benefit Nobody Mentions**

Something that surprised me when I went through this process, and I think it’s genuinely underrated.

Building bespoke software forces clarity about what you actually need.

When you can’t point at a feature on a pricing page and say “that one,” you have to define it yourself. You have to think about what the tool should do, how your team will use it, what the edge cases are. That process of definition is uncomfortable at first. But it produces real understanding of your own business.

People often come out of a bespoke build with sharper workflows, cleaner thinking about their product, and a much better handle on what matters versus what they thought mattered.

The software becomes a side effect of getting clear.

![Photo by Balint Mendlik on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*eeTuRUb5Zgfcx7OO "Photo by Balint Mendlik on Unsplash")

## **Is Bespoke Right for Everyone?**

My honest answer to this question is: No. Not automatically.

If your requirements genuinely match a standard product, or if your team needs something deployed tomorrow with no time to build, off-the-shelf can still be the right call.

But if you’ve ever found yourself fighting your tools, building workarounds, or paying for features you’ll never use while missing the one feature you actually need, bespoke is worth taking seriously.

The cost is lower than you assume. The timeline is shorter than it used to be. And the outcome: software that fits your business rather than asking your business to fit the software, is genuinely hard to replicate.

At Elephant Stripes, this is what we do. We build software that reflects how your business actually works. Whether that’s a custom CMS, an internal tool, or a full application with its own admin system, we build it to fit exactly, not approximately. If that sounds like something worth a conversation, drop us a message [here](https://elephantstripes.ai/contact).

Bespoke software is back. And this time, the economics are on its side.

* * *

_If you’re looking to rebuild your product or workflows for the AI era, feel free to contact_ [_ElephantStripes_](https://elephantstripes.ai/)_. We combine AI-driven speed with human judgment to build software that actually fits._

_Subscribe to our YouTube channel for daily AI tips:_ [https://www.youtube.com/@elephantstripesai](https://www.youtube.com/@elephantstripesai)

AI just changed the maths. Here’s what that means. There’s a phrase that quietly runs most business software decisions: good enough It’s how companies ended up on WordPress, Shopify, or whichever open-source CMS more or less solved the problem...

Bespoke Software is Back in Vogue

AI just changed the maths. Here’s what that means. There’s a phrase that quietly runs most business software decisions: good enough It’s how companies ended up...

Your SEO score drops after a hosting migration. You know something broke. You just don’t know what, where, or how deep it goes.

That’s exactly where I was after moving [Elephant Stripes](https://elephantstripes.ai/), our consulting firm’s website, from Namecheap to Cloudflare over the weekend.

PageSpeed Insights flagged a robots.txt error and knocked us down from a clean score to a 92. Not bad, but not right either. Something was off.

I used Codex to find it, fix it, and automate the whole process going forward.

## **Why Bother Connecting AI to Your Site Infrastructure?**

![Photo by Justin Morgan on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*iunCofKdbJEhdncq "Photo by Justin Morgan on Unsplash")

Most developers manually check PageSpeed, manually poke around Cloudflare, and manually toggle settings until things look right.

Well, that works. But when you’re running multiple client sites, it doesn’t scale.

The approach I’m showing you here connects AI directly to your APIs. That means Codex can pull live data, reason about it, and take action, all without you clicking through a dozen dashboards.

It’s a small workflow change with a big compounding effect.

Now, let me show you how I do it, step by step.

## **Step 1: Run a PageSpeed Insights Audit**

Start at [PageSpeed Insights](https://pagespeed.web.dev/). Put your URL in and run both the mobile and desktop reports.

Desktop will almost always score higher. That’s expected. You’re working over fixed connections with more predictable load speeds. Mobile is the harder benchmark.

![PageSpeed insights from Elephant Stripes’ website](https://miro.medium.com/v2/resize:fit:1400/1*fiOM0x1eHTL0nNdOQOSP9Q.png "PageSpeed insights from Elephant Stripes’ website")

What you’re looking for is your SEO section specifically. In my case, the score was 92 out of 100. Solid, but PageSpeed flagged one thing:  
**_the robots.txt was invalid_**_._

That single issue is what we’re going to trace and fix.

Don’t try to investigate manually at this point. You won’t have enough context to know where the problem actually lives. That’s what the next steps are for.

## **Step 2: Set Up Your Project Context for Codex**

Before you open Codex, make sure your project is structured properly. This is something people skip, and it makes AI-assisted development significantly worse.

At minimum, your project should have:

[**AGENTS.md**](http://AGENTS.md): This file contains your instructions for how AI agents should work in this project. Think of it as your team handbook for Codex. What tools it can use, what conventions to follow, what to avoid.

![](https://miro.medium.com/v2/resize:fit:1400/1*hfJ5Vsdex0nbQCOH9OQHow.png)

[**README.md**](http://README.md): This tells the project context. What the site does, how it’s structured, what the key rules and constraints are.

![](https://miro.medium.com/v2/resize:fit:1400/1*GTH5J7URlq0a_XAU8dqieg.png)

Codex reads both of these before it does anything. That grounding makes every subsequent prompt more targeted and useful.

If you don’t have these files yet, start simple. Even a hundred words in each file is better than nothing.

## **Step 3: Create a New Branch Before Touching Anything**

Open VS Code and fire up Codex. Before you ask it to do anything, have it create a dedicated branch.

For this task, I named it: **seo-robots-txt-optimisation.**

You don’t have to work this way. You can work directly on main if you want. But branching is cleaner, safer, and makes it easy to review what changed before you merge anything back.

Codex can create the branch for you with a simple prompt. Something like:

**_“Switch to a new branch called seo-robots-txt-optimisation and read_** [**_agents.md_**](http://agents.md) **_and_** [**_README.md_**](http://README.md) **_before we start.”_**

![The prompt used to instruct Codex to create the dedicated branch.](https://miro.medium.com/v2/resize:fit:1400/1*o4oa1cF5OH60Izn8dF0pjw.png "The prompt used to instruct Codex to create the dedicated branch.")

The prompt used to instruct Codex to create the dedicated branch.

That one step sets the context for everything that follows.

## **Step 4: Connect to the PageSpeed Insights API via Google Cloud**

This is where things get useful.

Rather than reading PageSpeed results manually through a browser, you can pull the data programmatically through the PageSpeed Insights API inside Google Cloud.

The setup looks like this:

1.  Create a Google Cloud project for your site (I have one for Elephant Stripes)
    
2.  Enable the PageSpeed Insights API in that project
    
3.  Create a service account with the right permissions
    
4.  Download the service account JSON key and store it in a secrets/ folder in your project (not committed to GitHub)
    

Once that’s done, you can tell Codex to use that service account to pull the PageSpeed report directly.

My prompt was essentially:

**_“Use the service account in secrets/ and the PageSpeed Insights API runbook to download the PageSpeed report for_** [**_elephantstripes.ai_**](http://elephantstripes.ai)**_. Save it to the working folder.”_**

Codex runs the report, pulls the data, and surfaces exactly what PageSpeed Insights would show you in the browser, but now it’s in your project where Codex can reason about it.

The report confirmed: SEO score 92 on mobile, 100 on desktop. And the robots.txt issue was flagged.

## **Step 5: Understand What Codex Found**

This is the part that would have taken me ages to figure out manually.

Codex read the live robots.txt being served at the domain and compared it to the robots.txt in the codebase. They didn’t match.

The finding was this:

**Cloudflare was prepending its own Managed Content Signals block to the live robots.txt.** This added a series of Disallow rules for AI crawlers before the app’s own Allow rules. The local file didn’t include any of that. So what PageSpeed Insights was reading, and what my actual codebase said, were two different things.

This is a Cloudflare edge configuration issue, not a code issue. The code was fine. The problem was how Cloudflare was serving the file at the network layer.

Without API access and Codex reasoning across both systems, I probably would have spent an hour checking the wrong things.

![](https://miro.medium.com/v2/resize:fit:1400/1*qyrG9E0nI9Aw9FZBKCQy0w.png)

## **Step 6: Check Cloudflare via API**

Now that we knew where the problem was, the next step was to look at Cloudflare’s bot management settings directly.

![](https://miro.medium.com/v2/resize:fit:1400/1*K4IvYwTxrTmIDerXFkT3Rg.png)

I already had a Cloudflare API token set up for Elephant Stripes with the right permissions: specifically, bot management read and update access.

I also had a Cloudflare performance runbook in my project docs that tells Codex how to interact with the Cloudflare API.

My prompt was:

**_“Use the Cloudflare API token in secrets/ and the Cloudflare performance runbook to check the bot management endpoint for_** [**_elephantstripes.ai_**](http://elephantstripes.ai)**_. Identify what’s being prepended to the robots.txt and fix it if you can.”_**

Codex hit the bot management endpoint, found the configuration that was causing the prepend behaviour, and reset it.

That’s it. The fix took less than two minutes once we knew what to look for.

## **Step 7: Verify the Fix**

After Codex resets the configuration, go back to PageSpeed Insights and re-run the audit.

Check that:

*   The robots.txt is now marked as valid
    
*   Your SEO score has held or improved
    
*   No new issues have appeared as a result of the change
    

In our case, the robots.txt came back clean. The Cloudflare prepend was gone, and the SEO score came up.

The whole process from the first audit to the verified fix took under 20 minutes.

## **The Bigger Picture: Automate It**

![Photo by Possessed Photography on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*sQzmjjr37__95q0S "Photo by Possessed Photography on Unsplash")

Running this manually is fine when something breaks. But the real value is in scheduling it.

You can set up an automated job using something like a cloud scheduler to run this exact process weekly. Codex (or another agent) pulls the PageSpeed report, checks it against your thresholds, and flags anything that needs attention.

If the report looks clean, nothing happens. If something looks off, you get an alert and you go fix it.

This is how you maintain consistent site performance across multiple clients without logging into dashboards every week. You get the report, review the flag, take action. Simple.

## **What This Workflow Actually Gives You**

![Photo by Mohammad Rahmani on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*WkUym9rO9asfW9jm "Photo by Mohammad Rahmani on Unsplash")

The specific fix here was a robots.txt misconfiguration caused by a Cloudflare migration. But the workflow transfers to almost any site health problem.

When you connect your AI tooling to Google Cloud and Cloudflare APIs, you can:

*   Pull performance benchmarks automatically
    
*   Detect configuration drift after deployments
    
*   Review nginx and server settings via script
    
*   Check security configurations at the edge
    
*   Run CI/CD health checks as part of your deployment flow
    

It’s not magic. It’s just connecting systems that would otherwise live in separate dashboards and giving Codex the context to reason across all of them.

The migration to Cloudflare introduced a subtle edge-layer issue that PageSpeed caught and Codex diagnosed. Manually, that’s a rabbit hole. With this setup, it’s a twenty-minute fix.

## **Quick Summary**

@[youtube](https://www.youtube.com/watch?v=QKbkdtCXBBE)

Here’s the process end-to-end (TL;DR)

1.  Run PageSpeed Insights and identify your SEO issue
    
2.  Set up [agents.md](http://agents.md) and [README.md](http://README.md) in your project
    
3.  Create a new branch in Codex before making changes
    
4.  Connect to the PageSpeed Insights API via a Google Cloud service account
    
5.  Let Codex pull and interpret the report
    
6.  Use the Cloudflare API token to investigate edge-layer configurations
    
7.  Apply the fix and verify with another PageSpeed run
    
8.  Automate the whole thing on a weekly schedule
    

If you’ve already got Google Cloud and Cloudflare set up, steps 3 through 6 take minutes. The groundwork is the only slow part, and you only build it once.

* * *

_Planning to cover how Google Analytics and Google Tag Manager connect to this same setup in the next video. Stick around if that’s on your radar._

_Subscribe to Elephant Stripes’_ [_YouTube channel_](https://www.youtube.com/@elephantstripesai) _for more AI updates and tutorial!_

How I Used Codex to Fix My SEO in 20 Minutes

A step-by-step guide to AI-driven site fixes


A step-by-step guide to AI-driven site fixes Your SEO score drops after a hosting migration. You know something broke. You just don’t know what, where...

Imagine you run a business. Sixty employees. Every workflow, every automated process, every AI agent your team depends on runs through one cloud provider.

Then one morning, the account gets flagged. Locked. And the only way to reach anyone is through a contact form.

That actually happened. A Spanish entrepreneur I came across on X was in exactly that position with his Claude account.

I do not know how it was resolved. But the story is the real point: this is what happens when you build your entire AI agent operation on someone else’s infrastructure.

The industry needs to have this conversation right now.

## **Everyone is Betting on The Wrong Thing**

![Photo by Nick Fewings on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*IcO0ma1J4EyyKhOL "Photo by Nick Fewings on Unsplash")

AI agents are going to be how the majority of businesses use AI in the future. That is not a particularly original prediction at this point.

What often goes unaddressed, however, is the question of **_where_** those agents will actually run.

Most businesses currently think about AI as a subscription service: they pick a provider, pay per token, and scale as needed.

It feels straightforward. But there is a structural problem underlying that model, and it will become very obvious over the next two to three years:

> **_Cloud AI pricing is not real yet. It is subsidised by investor capital._**

Anthropic, OpenAI, and every other frontier lab are spending far more on compute than they are collecting from customers. That gap is filled by venture funding. Investors are underwriting cheap AI access to drive adoption. That strategy has a shelf life.

When those investors start demanding returns, the AI cost equation changes. Token costs go up. Variable costs baked into your agent workflows go up with them. And if your entire operation is running through one provider’s API, you have no leverage when that happens.

## **Apple Spotted This Before Anyone Else**

![John Ternus, Apple’s likely next CEO, whose hardware background signals the company’s strategic bet on local AI.](https://miro.medium.com/v2/resize:fit:1400/1*scm6Lsl9DmeCMn-SDbwwHg.png "John Ternus, Apple’s likely next CEO, whose hardware background signals the company’s strategic bet on local AI.")

A detail makes all of this click into place.

Apple recently appointed two hardware executives to the very top of the organisation. That is a strange move for a company that has been behind on AI.

The move is about cornering the market on local AI compute.

Nate Jones made this argument compellingly in his video “**_Apple Just Positioned Itself for the Next Trillion Dollars_**,” and I think he is right. Apple is making the same bet it made in the 1970s and 80s.

Back then, computing lived in mainframes. Expensive, centralised, and controlled by a handful of vendors. Power users paid the cost because they had no alternative.

Then the Apple II arrived. It was not as powerful as a mainframe. But it was good enough, cheap to run, and most importantly, it was yours.

Power users left the mainframes. The personal computer era began.

Apple is betting that history repeats. Cloud AI is the mainframe. Local AI, running on personal hardware or on-premises servers, is the Apple II. And the transition is already starting.

The Mac Mini craze around open source tools like OpenClaw was an early signal: developers running capable AI locally, not because local models beat GPT-4 on benchmarks, but because they were controllable and the AI cost was essentially just electricity.

## **What Enterprises Actually Want**

![Photo by Nguyen Dang Hoang Nhu on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*dJeovD_xH8J1oq2x "Photo by Nguyen Dang Hoang Nhu on Unsplash")

When the conversation gets practical, businesses say this.

They do not necessarily need the smartest model. They need a model that is predictable, that does not expose sensitive data to third-party infrastructure, and that does not come with variable costs that make financial planning impossible.

Maybe that model is not as sharp as Claude or GPT-5 on complex reasoning tasks. Fine. If it runs on _your_ servers, it handles your data, and you pay for electricity rather than per-token fees, the trade-off is often worth it.

This is especially true for sectors like law, healthcare, finance, and government. These industries have compliance requirements that make cloud-everything a non-starter.

They also have large volumes of routine human labour that AI agents can absorb, but only if those agents are reliable and cost-controlled over the long term.

## **The Agent Stack that Actually Makes Sense**

![](https://miro.medium.com/v2/resize:fit:1400/1*T_Nd0aKNrCXt6VhDD4c7qA.png)

At [Elephant Stripes](https://elephantstripes.ai/), this is how we think about building agent systems that hold up.

You start with a single interface. Something the organisation already uses, whether that is Slack, Teams, Discord, or any other chat platform. Staff interact with agents the same way they already communicate at work. No new interface to learn.

Behind that interface sits an open source orchestration layer. Frameworks like OpenClaw and Hermes are the ones we follow closely.

They give you genuine control over how your agents work: memory management, both short-term and long-term, and the ability to route calls to different models depending on what the task actually requires.

From that layer, you can send calls to frontier model APIs when the task demands it. But you can also fall back to an open source model running on-premises.

A cheap VPS. A Mac Mini sitting in a server room somewhere. Something that is yours, that runs on your infrastructure, and that works even when everything else goes wrong.

Built-in redundancy is not a bonus feature. It is the whole point.

## **IT Teams are About to Have a Very Different Job**

![Photo by Shamin Haky on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*EIcA4su1o5nUJiG8 "Photo by Shamin Haky on Unsplash")

The traditional IT function, managing software licences, user accounts, and system security, is not disappearing. But a new layer is being added on top of it.

The IT teams that will matter most over the next five years are the ones that can manage agents. That means tracking which agents are running, how much compute each is consuming, and what models are powering them.

It also means prototyping new functionality on frontier models, then actively working to shift that functionality to smaller, cheaper, or open source models as quickly as the task allows. Frontier models for research and development. Smaller or open source models for production and everyday operations.

That cycle is where the cost discipline comes from, and it is also where the technical skill is going to sit. Demand for people who can build and optimise this kind of stack is going to be significant.

I think it is actually a great time to be a programmer who understands this space.

## **Why Open Source Wins the Critical Layer**

![Photo by Markus Winkler on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*pGKF7_y_mmxy167p "Photo by Markus Winkler on Unsplash")

Between enterprises and the big model providers, there is going to be a layer of open source tooling that businesses depend on deeply. That layer is where the control sits.

Proprietary cloud platforms give you convenience. Open source agent frameworks give you something more valuable: the ability to make your own decisions.

Which model gets called for which task? Yours to decide. How much memory does each agent carry? Yours to configure. What happens when a provider goes down, changes its pricing, or locks your account? You have a fallback because you built one in.

That is the core of why I am enthusiastic about open source frameworks in this space. They are well-built, and they shift the power dynamic back toward the people building with them.

## **The Realistic Picture**

I want to be clear about something: **I am not saying cloud AI is going away.** Frontier models are getting better at a remarkable pace, and for genuinely complex reasoning tasks, they remain impressive tools.

But the current model, where businesses pipe everything through a single cloud provider’s API with variable AI costs and a contact form as their primary support channel, is not a stable long-term arrangement.

The Spanish entrepreneur with 60 staff and one form to submit is not an edge case. It is a preview.

The businesses that figure this out early will build agent infrastructure they control. They will use frontier models as a high-performance tier, not as a foundation. They will treat open source frameworks as their backbone, and local compute as their safety net.

AI agents are going to be how most businesses run on AI. The ones that win will make sure those agents are not someone else’s to switch off.

My thinking on all of this is still developing. But the direction feels clear.

I would genuinely like to hear _your_ take.

* * *

_This article grew out of a longer video I recorded for the Elephant Stripes YouTube channel. You can watch the full video here:_

@[youtube](https://www.youtube.com/watch?v=iTm5AcHCofY)

_At Elephant Stripes, we help businesses build AI agent systems that they actually own and control. If that is the direction your organisation is heading, come find us at_ [_elephantstripes.ai_](http://elephantstripes.ai)

The Trillion-Dollar AI Bet: On-Premise, Not Cloud

Why Apple, enterprises, and smart builders are going local. Imagine you run a business. Sixty employees. Every workflow, every automated process, every AI agent your team depends on runs through one cloud provider. Then one morning, the account gets flagged...

Why Apple, enterprises, and smart builders are going local. Imagine you run a business. Sixty employees. Every workflow, every automated process, every AI...

Naval Ravikant had his AI epiphany in December 2025. He called it “A Return to Code” and described the moment he could ship one-shot custom apps with Claude Code or Codex. It’s a great podcast. You should watch it.

My epiphany hit a few months earlier. Same tool. Completely different use case.

I do not use Codex like a junior developer assistant. I use it as a **DevOps** partner.

And that shift changes everything.

## **Why DevOps specifically?**

![Photo by Luca Bravo on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*orIUlDwE0HwYyM0i "Photo by Luca Bravo on Unsplash")

It all started with a server audit.

I was staring at our production server, which runs PM2, Docker, and a handful of different apps, trying to figure out whether our security posture was actually any good.

**_Were our DNS entries correct? Was our nginx setup tight? Were we caching properly? Were there vulnerabilities we’d missed?_**

These aren’t coding questions. They’re DevOps questions. DevOps is a discipline with an enormous surface area. DNS, caching, server configuration, CI/CD pipelines, security hardening, and error monitoring.

It touches everything, it requires specialist knowledge across multiple tools, and it has historically been expensive to get right.

You either pay for a dedicated DevOps person, contract a specialist, or you do what most small teams do: wing it and hope nothing catastrophic happens.

The AI cost argument here is straightforward. The human labour involved in proper DevOps oversight used to be substantial.

Now it doesn’t have to be. And it’s because I decided to give Codex access to everything.

## **Connecting The Whole Stack**

![Photo by Omar:. Lopez-Rincon on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*PRv8PTmfW0Eg9IYe "Photo by Omar:. Lopez-Rincon on Unsplash")

I set up access in a fairly straightforward way.

First, a GitHub personal access token so Codex could see what actions were running. Then I built out a Google Cloud project, gave it ownership permissions, and wired up APIs for Google Analytics, PageSpeed Insights, and Tag Manager. After that, Cloudflare access and direct server access.

Five or six services, all connected.

Then I just asked it questions.

> **_“Look across all of these and tell me what our cybersecurity looks like. How do we harden it? What does our caching look like? PageSpeed is flagging these errors. You can see our nginx config. What should we change?”_**

That was the AHA! moment.

It wasn’t “write me a function” or “fix this bug.”

It was a systems-level conversation across every service we run, all at once.

## **The Answer was Better Than I Expected**

![Photo by Robert Wiedemann on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*n8mUmvaLdg_2TYKK "Photo by Robert Wiedemann on Unsplash")

Our CI/CD pipeline is now several orders of magnitude better than it was. The improvements compound: tighter security, better caching, DNS entries that are actually correct, and error monitoring that catches things before users do.

Codex checks the server. It checks available disk space. It flags DNS issues. It reads error logs and tells me what’s wrong.

The amount of human labour this replaces is significant. It doesn’t do everything, but it closes the gap between “_something is probably wrong somewhere_” and “_here’s exactly what’s wrong and here’s how to fix it._”

I genuinely can’t believe more people aren’t using AI for DevOps.

## **Building the CMS I Actually Wanted**

The DevOps breakthrough changed what I thought was realistic to build and maintain.

Our website had been through a few different configurations. It started as a Hugo site: static, markdown-powered, genuinely fast. Then we moved to Forestry for proper CMS features. Then to Strapi because VideoTranslatorAI needed proper multilingual publishing support. That meant a Strapi and Gatsby stack, and the maintenance overhead was significant.

Then Gatsby started to quietly lose momentum as a project.

That was the point where I stopped trying to maintain the existing setup and built something new from scratch.

The process was iterative. Build what you think you want. Use it for a while. Discover the gaps you hadn’t imagined. Close them. Repeat.

What came out the other end is a bespoke CMS with email capability built in, no dependency on third-party projects that might stop being maintained, and performance numbers that most agencies would be proud of.

![The CMS that i built for Elephant Stripes.](https://miro.medium.com/v2/resize:fit:1400/1*tInkzU2eSCfpOZ2-tUE7mw.png "The CMS that i built for Elephant Stripes.")

PageSpeed scores are excellent. The site is fast in a way the Strapi-Gatsby setup never was. It does exactly what we need. The maintenance overhead compared to what we were running before is dramatically lower.

Human labour: **down**. AI cost to maintain: **minimal**.

## **You Can Have This Too**

![](https://miro.medium.com/v2/resize:fit:1400/1*x4Qlnm71zS5q7EVjlJ8bPQ.png)

If you want a CMS built the same way, with the performance, the bespoke fit, and none of the bloat, that’s exactly what [Elephant Stripes](https://elephantstripes.ai/) does.

Elephant Stripes is a bespoke app development service. We don’t sell templated solutions. We sit down with you, usually for a few hours in the first session, and we build in front of you. You see it take shape in real time. You can redirect it, add to it, and push back on scope when needed.

By the end of that session, you know what you’re getting. You’ve seen it built. And the gap between what’s in your head and what ends up in production is a lot smaller than it would be if you handed over a spec doc and waited six weeks.

If that sounds like something you need, reach out via [Elephant Stripes](https://elephantstripes.ai/contact)!

## **The Bigger Point**

Naval frames the current moment as a renaissance for individual software creators. I think he’s right, but the frame is slightly too narrow.

Coding has been democratised, and so have operations, infrastructure, and systems oversight; the disciplines that used to sit between developers and the rest of the business.

The teams that realise that AI isn’t just a code editor but an entire operational layer will build much stronger foundations than those who use it only for features.

Vibe coding got me back into building. DevOps is what made the building worth doing properly.

That’s the part nobody’s writing about.

* * *

_If you want the full context behind these ideas, you can listen to Naval Ravikant’s A Return to Code podcast here:_ [](https://nav.al/code)[_https://nav.al/code_](https://nav.al/code)

_I also shared my complete reaction and breakdown on YouTube:_

@[youtube](https://www.youtube.com/watch?v=DkJI-3pzaYU)

I Gave My AI Server Access. It Became A Great DevOps Partner.

They fired engineers. AI bills hit $15K. Still won’t rehire. Something interesting is happening on X right now. A handful of viral posts are declaring that soaring AI costs are reversing the great layoff wave...

I Gave My AI Server Access. It Became A Great DevOps Partner

I gave my AI server access, and it became a great DevOps partner. Naval Ravikant had his AI epiphany in December 2025. He called it “A Return to Code”...

We use cookies to improve site performance and understand how the portfolio content is being used.

Turn AI use cases into production workflows, internal tools, and customer-facing products with senior delivery judgment.

Practical AI Consulting That Ships

Elephant Stripes is a consulting firm that designs, builds, and ships AI products and delivery systems.

Elephant Stripes

Elephant Stripes designs and ships practical AI systems for real business workflows.

Consulting

Practical AI Consulting

Where Consulting Fits

Consulting articles

I Let AI Do My DevOps. Here’s What Happened.

Bespoke Software is Back in Vogue

How I Used Codex to Fix My SEO in 20 Minutes

The Trillion-Dollar AI Bet: On-Premise, Not Cloud

I Gave My AI Server Access. It Became A Great DevOps Partner.