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

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

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, under the Elephant Stripes 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 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.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

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 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

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, 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!

If you’re looking to rebuild your product or workflows for the AI era, feel free to contact ElephantStripes. 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