The infrastructure bill you’re not auditing is the one eating your margin
Most cross-border sellers I talk to obsess over ad spend, freight rates, and Amazon referral fees. Almost none of them look at what their backend actually costs to run. That’s a mistake, and it’s about to get more expensive as agentic tooling rewrites the economics of small-stack hosting. This week a small team called elim.io shipped Exodus for Google Cloud Run — an agent-driven migration tool that audits an app, prices it against Google Cloud Run, and hands your coding agent a step-by-step plan to move it. On the surface it’s a developer tool. Under the surface it’s a template for how cross-border operators should think about every piece of software they rent: audit it, price it, plan the exit, then move.
What Exodus actually solves — and why it isn’t just a DevOps toy
The pitch is narrow and honest. Cloud Run scales to zero, bills only while code runs, and sits on Google’s network — but getting there is painful. As the maker Abdugafur Ali puts it, “many common architectures break on them quietly: a cron inside the process fires late or twice, a worker waiting on a queue stalls, uploads on local disk vanish, sessions in memory sign people out.” So teams stay on a PaaS and keep paying for idle hours.
Exodus attacks that inertia in four moves. First, a one-line install of an open-source CLI checks the repo locally — processes, data stores, env names, and the patterns that break or keep billing. Second, it prices today’s bill against Cloud Run at Google’s list prices across 16 regions with a 12-month forecast. Third, it draws the target architecture and rebuilds it via 50+ playbooks, each change carrying a reason, a replacement, and an order. Fourth, your coding agent executes the plan one commit per task, and exodus check in CI keeps it honest.
The constraints are the interesting part. Code never leaves your machine. No AI runs on elim.io’s side. They never sign into your Google Cloud. It’s free, no paid tier, and the CLI is open source. A no-signup demo report is public.
Why Amazon sellers should care more than Shopify ones
Here’s the operator angle. A Shopify DTC brand on Shopify Plus is mostly renting managed infrastructure — you’re paying for the privilege of not thinking about servers. An Amazon FBA brand with its own stack is different: you’re running a listing-optimization service, a repricer, a review-request automation, a PPC bidder, a returns portal, and probably a middleware layer syncing Amazon Seller Central to your ERP. That stack has cron jobs, workers, and database writes that all run 24⁄7 whether you have orders or not.
If you’re paying a PaaS for that idle time, you’re subsidizing your vendor’s margin with your own. Exodus’s audit logic — “every pattern that breaks or bills while idle” — is exactly the lens an FBA operator should apply to their own backend before renewing a contract.
How it stacks up against the incumbents you’re probably already paying
The obvious comparables are Heroku, Render, Railway, and Fly.io — the PaaS layer most cross-border sellers end up on because it’s easy. Exodus’s CLI reads deploy files from all of them: Procfile, railway.json, render.yaml, fly.toml, app.json, docker-compose, and the Dockerfile. That’s not accidental. The product is explicitly positioned as the exit ramp from those platforms.
Against Vercel and Netlify, the comparison is less direct — those are frontend-first, and Exodus is aimed at apps with databases, workers, and scheduled jobs. Against a raw AWS or GCP migration consultant, Exodus is free and self-serve, but it also won’t hold your hand through IAM or DNS.
The most honest comparison is against doing nothing. Most sellers do nothing because the migration looks riskier than the bill. Exodus’s bet is that a deterministic Rust CLI plus a coding agent changes that risk calculus.
Where the math breaks
The maker is upfront that Cloud Run isn’t always the answer. In a reply to a Google Cloud Run team member, he notes that “for a stateful service or a steady heavy load the verdict can be ‘stay.’” That’s a real limitation, and it matters for cross-border sellers running persistent websocket connections for live inventory sync, or long-running batch jobs for catalog imports. If your stack has a 24⁄7 steady load, Cloud Run’s scale-to-zero advantage evaporates and you’re just paying list prices on a different cloud.
The other soft spot: billing controls. Exodus doesn’t create budgets itself — it never touches billing or IAM. Anything that costs money waits for a human “yes.” That’s the right default, but it means you still own the guardrail. After Sara Ford from the Cloud Run team asked about spend caps, the team shipped a “Budget and alerts” step in v0.2.10 that sets a Cloud Billing budget at the report’s estimate with email alerts at 50%, 90%, and 100%. Details are in their budget guide. Good response time, but it’s a patch, not a philosophy.
What cross-border sellers can borrow from this playbook
Three things, and none of them require you to migrate anything this quarter.
One: audit the patterns, not just the price. Exodus scans for statefulness — sessions in memory, files on local disk, timers inside the process, workers waiting on queues, long-lived connections, work after the response. Every one of those patterns has a cross-border analogue. Sessions in memory = your login state on a marketplace integration. Files on local disk = your order export CSVs. Timers inside the process = your repricing cron. If your vendor’s architecture has these patterns and you’re paying for idle time, you’re paying for fragility.
Two: price the alternative before you renew. The Exodus report gives cost per part of the app, today versus Cloud Run, with a 12-month forecast. Most sellers I know renew their SaaS stack on autopilot. If you can’t answer “what would this cost on a different substrate?” you’re not negotiating — you’re accepting.
Three: treat your coding agent as a migration crew. Exodus works with Claude Code, Codex, Cursor, and others. The pattern — agent reads the plan, one task, one commit, one test — is the same pattern you should use for any internal tooling migration. If you’re still doing platform migrations by hand in 2025, you’re leaving weeks on the table.
The data-migration question nobody asks until it’s too late
Andrew Shu asked the sharpest question on the thread: how does Exodus handle large, no-downtime data migrations? The answer is worth reading in full, but the short version is a two-track approach. Small databases get a rehearsed pg_dump/pg_restore with row-count and checksum comparison, then a write freeze equal to the rehearsed time. Large databases use Google’s Database Migration Service for continuous replication — no extra charge for Postgres to Cloud SQL — with a pause only for the final drain and promote.
The limits are the part every operator should internalize: schema changes aren’t replicated, sequence values must be set after the copy, tables without a primary key only get inserts, large objects aren’t migrated, and the source needs logical replication (Advanced tier on Heroku, Pro workspace on Render). The full order with commands is in their Postgres migration guide. If you’ve ever lost a weekend to a botched database cutover, this is the section to bookmark.
Where my judgment says it falls short
Three concerns, in order of how much they’d slow me down.
First, macOS and Linux only. No Windows support mentioned. That’s fine for most modern dev teams but excludes a chunk of the ops people I know at mid-market sellers who still live in Windows.
Second, the “stay” verdict is honest but unhelpful. If Exodus tells you Cloud Run is a bad fit, you’ve spent an afternoon to learn nothing actionable. A useful next step would be a “here’s what would fit instead” branch — but that’s a product roadmap call, not a bug.
Third, the free-and-open-source model raises a sustainability question. No paid tier, no AI costs on their side, no sign-in to your cloud. That’s a beautiful privacy story. It’s also a business model that has to be funded by something. The maker’s parent company elim.io presumably has other revenue, but for operators betting on this tool as part of their stack, that’s a dependency worth tracking.
The bigger pattern: agents are eating the migration tax
Zoom out. For a decade, the reason sellers stayed on expensive PaaS was that migration was expensive. The tax was real: consultants, downtime, risk. What Exodus demonstrates is that the migration tax is collapsing. A deterministic CLI does the audit. A coding agent does the work. A report ticks itself. The cost of switching substrates just dropped by an order of magnitude, and that changes the negotiating position of every operator who rents infrastructure.
If you’re a cross-border seller running a proprietary backend, this is the moment to re-run the math on every vendor in your stack — not just hosting, but your Klaviyo tier, your Helium 10 plan, your ShipStation contract. The tools to audit and migrate now exist. The excuse of “it’s too risky to move” is getting thinner every quarter.
What I’d watch / test next
This week, three concrete moves.
First, run the Exodus demo report on one internal service you own — even if you have no intention of migrating. The audit output alone will tell you which patterns in your stack are fragile, and that’s worth the hour.
Second, pull your last three months of PaaS invoices and compare them to a Cloud Run pricing estimate using your actual traffic. If the delta is more than 30%, you have a project. If it’s less than 10%, you have peace of mind.
Third, watch the Exodus product page for Windows support and the budget-alert workflow maturing. If both land in the next quarter, this becomes a default recommendation for any seller running a custom backend. If neither lands, it stays a useful audit tool and nothing more.
The infrastructure layer of cross-border commerce is being quietly rewritten by agentic tooling. The sellers who notice first will be the ones whose margins survive the next ad-cost spike.
