Build Once, Serve Everywhere: How an AI Agent Consolidated Our Infrastructure in One Session

On a single EC2 instance in Frankfurt, 7 Docker containers are running right now. They serve both staging and production traffic for a cashback platform. The source code is not on that server. The total configuration footprint is 72 kilobytes.

Three weeks ago, we had two EC2 instances, two separate CI/CD pipelines, Docker images that required separate builds per environment, and a git repository cloned onto the production server. One question started the cleanup: “Can we just merge demo onto the prod server?”

Four hours later, the answer was yes. Here’s what the session actually looked like.

---

The Starting Point

This is a follow-up to the original build session where we built this cashback platform from scratch in a single day, and the first round of production hardening that followed. The infrastructure had grown up but never been rationalized.

Before this session, it looked like this:

• demo: t3.small, x86, Ubuntu, with a local Postgres container. ~$20/month.
• prod: t4g.medium, ARM (Graviton), Amazon Linux, connected to Amazon RDS. ~$40/month.
• ~$60/month for something that could reasonably be one instance.

The different CPU architectures mattered: ARM builds don’t run on x86, so we had two separate Docker build targets in CI. Two separate deploy jobs. Two environments that drifted whenever one got a change the other didn’t.

The deeper problem was how environment configuration worked. Every API URL was a VITE_* environment variable baked into the bundle at build time. VITE_API_URL=https://backend.myapp.com got embedded into the JavaScript during npm run build. That meant you couldn’t take a production-built image and point it at a different backend. You had to rebuild.

The practical result: demo ran on older code, with different settings, on different hardware. It wasn’t a staging environment — it was a second production environment that nobody cared about as much.

---

The Conversation That Started It

I came to the session with the consolidation plan already in mind: one server, staging and production side by side, shared RDS with database-level isolation, and runtime config to eliminate the build-time environment variable problem. The architecture was clear. What I wanted was a second pair of eyes to validate the approach and think through the edge cases before committing to a 7-phase refactor.

The planning conversation was worth it. One thing that came out of it: resource limits on the staging containers. Running staging and production on the same host without CPU and memory constraints means a runaway staging process can take down production. We added mem_limit: 512m and cpus: 0.5 to the staging backend, mem_limit: 128m and cpus: 0.25 to the static container — the Docker Compose equivalent of Kubernetes namespace-level resource quotas. On a Kubernetes cluster you’d put staging and production on the same hardware pool and separate them with namespaces; this is the same principle. With the budget constraints of a side project on an oversized t4g.medium running at 10% capacity, it’s the right tradeoff.

The planning agent produced a 460-line document covering 7 phases. We went through it, agreed on the approach, and started executing. Across the full session, a fleet of specialized agents handled everything from SQL migrations and parallel frontend refactors to CI failure diagnosis and nginx config review — each focused on its own scope.

---

Phase 1: Runtime Config — The Hard Part

The VITE variable problem was the biggest blocker. If you can’t run the same Docker image in staging and production, you can’t have one CI/CD pipeline. So we had to fix this first.

The approach split into two strategies depending on the frontend:

For the admin panel: The admin backend URL is always predictable — it’s the same hostname, but admin. replaced with backend.. So instead of reading a config file, the admin derives its API URL from the current page location:

export function getApiUrl(): string {
  if (typeof window === 'undefined') return 'http://localhost:4000';
  const { hostname, protocol } = window.location;
  if (hostname === 'localhost') return 'http://localhost:4000';
  return `${protocol}//${hostname.replace(/^admin\./, 'backend.')}`;
}

Five lines. No config file. No environment variables. No rebuild needed. The admin running on admin.staging.myapp.com automatically points to backend.staging.myapp.com. It’s synchronous, which means no loading states to manage.

For landing pages: Campaign-specific landing pages needed more than just an API URL. They needed campaign metadata: start/end dates, cashback amounts, API keys, terms text. That information had lived in VITE_* variables baked into the build.

We replaced this with a runtime /config.json file fetched on startup:

{
  "apiUrl": "https://backend.myapp.com",
  "apiKey": "your-api-key-here",
  "startDate": "2026-04-01",
  "endDate": "2026-08-31",
  "cashbackType": "FIXED",
  "cashbackAmount": 5.0
}

The async loading pattern uses a lazy singleton so you don’t fetch multiple times per page load:

let configCache: Config | null = null;

export async function loadConfig(): Promise<Config> {
  if (configCache) return configCache;
  const res = await fetch('/config.json');
  // Intentionally no error handling — if config fails to load, the app
  // should fail loudly at startup rather than render with missing data.
  configCache = await res.json();
  return configCache;
}

export function getConfig(): Config {
  if (!configCache) throw new Error('Config not loaded yet — call loadConfig() first');
  return configCache;
}

The top-level entry point calls await loadConfig() before anything renders. After that, the rest of the app can call getConfig() synchronously. Fail fast, fail early.

This wasn’t just a technical simplification — it changed what “deploying a campaign change” means. Before: edit a VITE variable, commit, push, wait for CI to rebuild and redeploy. After: edit a JSON file, push, the SCP deploy runs. Marketing teams can change campaign dates or cashback amounts without touching CI.

Three agents ran in parallel for this phase — one for admin, one for the main landing page, one for the generic landing page structure. This multi-agent parallel pattern is one of the cleaner ways to handle changes that touch multiple codebases simultaneously. Each agent handled the refactor in its own scope, and the orchestrator merged the results and verified builds passed across all three.

---

Phase 2-3: Database Isolation — The Careful Part

The merged-server architecture meant staging and production sharing the same Amazon RDS instance. The staging seed job that populates test data for E2E tests could not be allowed to touch the production database.

The safest approach: PostgreSQL-level isolation, not application-level trust.

From the AI agent’s terminal, SSHing into the EC2 and running psql against RDS:

CREATE DATABASE app_staging;
CREATE USER cd_staging WITH PASSWORD '...';
GRANT ALL PRIVILEGES ON DATABASE app_staging TO cd_staging;

-- Block cross-database access explicitly
REVOKE ALL ON DATABASE app_prod FROM cd_staging;

The production database got its own dedicated user with ownership of all existing objects:

-- RDS quirk: you need this before REASSIGN OWNED works
GRANT cd_prod TO postgres;
REASSIGN OWNED BY postgres TO cd_prod;

That GRANT cd_prod TO postgres line is an RDS-specific wrinkle. Without it, REASSIGN OWNED BY postgres TO cd_prod throws a permission error — RDS’s managed postgres superuser can’t act as a role it doesn’t have explicit membership in.

Watching the AI run SQL against production RDS made me nervous — I followed every query in the logs. The saving grace: this was a brand new system with no real customer data. No risk if something went wrong. And the agents did a thorough job: new users, new database schemas, password setup, environment file configuration — all without me having to type a single SQL statement. That said, this is exactly the kind of operation I’d think about differently if there were years of production data involved. The question of how much trust to extend to an agent operating on real infrastructure doesn’t have a simple answer.

After the migration, we verified isolation explicitly: tried connecting cd_staging to the production database, confirmed it failed with a permission error. Not trusting the SQL, confirming the result.

---

Phase 4-5: Compose and Pipeline — Two Bugs and a Security Insight

The docker-compose

Adding staging to the docker-compose was mostly mechanical: duplicate the backend and static services, gate them behind --profile staging, add staging hostnames to nginx, add resource limits.

Reviewing the nginx config surfaced something unexpected: an /api/ proxy block. This was a relic from before Phase 1 — back when landing pages used relative URLs like /api/submit that nginx had to proxy to the backend. After Phase 1, all API calls use absolute URLs pointing directly to the backend. The proxy block was dead code that had survived two sessions of infrastructure work without anyone noticing.

Removing dead code from infrastructure is satisfying. It’s not a feature, it doesn’t show up in metrics, but it’s one fewer thing to misunderstand in six months. Consolidation tends to reveal accumulation. You don’t see the cruft until you have to think about the whole thing at once.

The pipeline

The pipeline structure: Release Please handles versioning, Build creates ARM images, then Deploy Staging, Verify Staging (5-point smoke test), Deploy Prod, Verify Prod. Sequential. Staging gates production.

deploy-prod:
  needs: [release-please, deploy-staging]
  if: needs.release-please.outputs.releases_created == 'true'

Two bugs showed up immediately in CI.

Bug 1: Image tagging. The CI job built ARM images and tagged them :latest for the SCP transfer. The docker-compose file expected images tagged :prod and :staging. When Docker Compose tried to start containers, it couldn’t find the images. Fix: add explicit docker tag app-backend:latest app-backend:prod steps after loading the images on the server. Two CI iterations to find this.

Bug 2: Git conflict. The EC2 still had a git repository at this point. The deploy job ran git pull to get the updated docker-compose. But the config/ directory had been created manually and excluded from git clean with -e config/. That directory was now tracked in the repo. Merge conflict. Unresolvable automatically.

The breakthrough

Looking at that git conflict in the CI failure log, I started thinking about a different problem: what happens if someone compromises this server? With a git repository there, we’d essentially be handing them the complete source code as a gift. All the application logic, the configuration patterns, the service structure — wrapped up and ready to be analyzed.

That’s the real reason to separate source code from a production server. Not cleanliness. Security.

The server doesn’t build anything. It needs exactly five things: the docker-compose file, the prometheus config, the environment config JSONs, the nginx vhost configs, and the secrets.

SCP those five items. Remove everything else. A production server is not a development environment. It shouldn’t know how to build what it runs. The source code belongs in version control — not exposed on every machine that needs to execute the result.

---

The Unexpected Bug Hunt

While the CI pipeline was stabilizing, we looked at E2E test coverage to define what the staging smoke tests should check. That investigation led to an uncomfortable discovery: this was the first time we’d ever tried to create a customer and campaign by hand in the admin panel. Not through a seed script — manually, through the UI.

It didn’t work. Eight forms were broken.

Customer creation was broken. Campaign creation was broken. User CRUD was broken. Export generation was broken.

The root cause: a ts-rest React Query v5 migration from months earlier had changed how mutation calls needed to be structured:

// Broken: passes formData directly
await createCustomer.mutateAsync(formData);

// Correct: wraps in { body }
await createCustomer.mutateAsync({ body: formData });

All eight call sites had the old pattern. None had been caught because the E2E tests used a seed script to create test data — they never exercised the creation forms directly. The features existed, the tests passed, and the forms silently failed to create anything.

The question that stuck: why didn’t the E2E tests catch this? They only tested the happy path with pre-existing seeded data. The creation flows were assumed to work because they’d worked before the React Query migration. Adding staging as a real pre-production environment — one where we actually tried to use the product before deploying — was what finally surfaced it.

Infrastructure work reveals application bugs. You add a staging environment, you start verifying behavior systematically, and you find things that production never surfaced because nobody was checking end-to-end.

---

The Final State

One EC2. Seven containers. 72KB of configuration. One Docker image built once on ARM, served everywhere.

The pipeline runs end-to-end without manual intervention. A merge to main builds the image, deploys to staging, runs smoke tests (health check, login, dashboard load, API response, container status), and only if all five pass, deploys to production and verifies there.

Campaign configuration changes don’t require a rebuild. Edit a JSON file, push, the SCP deploy runs. Marketing changes to dates or cashback percentages go live without touching CI.

Before:

• 2 EC2 instances, different CPU architectures
• 2 CI/CD workflows, 2 separate deploy targets
• VITE vars baked at build time = separate images per environment
• Source code cloned on production server
• ~$60/month

After:

• 1 EC2, 7 containers, ARM throughout
• 1 CI/CD pipeline, staging gates production
• 1 Docker image, runtime config via JSON
• 72KB of files on the server, no source code
• ~$40/month (shutting down the demo EC2 is the full $20 reduction)

What we gave up: testing on x86 before deploying to ARM. In practice, this was never meaningful — the demo instance was too outdated to catch anything real. Actual staging on the same hardware as production is strictly better.

---

What This Says About Agentic Infrastructure Work

The most distinctive thing this session produced wasn’t the unified docker-compose or the runtime config refactor. It was the insight about source code on the server — and that came from me thinking about the attack surface, not from the plan.

That’s the real division of labor. The AI tracked 50+ file changes across 7 phases, coordinated three parallel refactors, SSHed into production to run SQL migrations, and diagnosed two CI failures by reading GitHub Actions logs. I couldn’t have done all of that in parallel without losing the thread. But I could think about what it means to have source code on a server that might get compromised.

The AI executes at a scale and parallelism that’s genuinely beyond what I can do alone. I bring the architectural judgment and risk assessment that shouldn’t run automatically. The question of where to draw that line on production infrastructure is worth thinking about carefully — but for a side project with no customer data yet, the answer was: watch closely, verify results, and trust the execution.

This session took about 4 hours. Doing it manually — writing the CI pipeline, updating 20+ files for runtime config, running the SQL migrations, debugging two CI failures, and discovering the eight broken mutations — would have been two or three days of focused work. Some of it would have been deferred indefinitely.

Infrastructure consolidation is unglamorous. It doesn’t ship features, doesn’t show up in a changelog anyone reads, and the complexity reduction is only visible to the people who maintain the system. Agentic tooling makes it tractable to do that work when it needs doing — not when you can finally justify a maintenance sprint for it. Some of it would never have gotten done otherwise.