Community Article
Community articles are authored by SitePoint Premium contributors. Content is screened before publication, and SitePoint reserves the right to moderate or remove articles that violate our guidelines. Views expressed are those of the authors and do not necessarily reflect those of SitePoint.
AI, DevOps and the Cost of Hosting: From Idea to Production for $0
Published inOctober 29, 2026
·Updated:October 30, 2026
The AI briefing for <a href="https://tooltechblog.com/building-a-human-review-pipeline-for-ai-search-a-practical-developers-guide/” title=”Building a Human Review Pipeline for AI Search: A Practical Developer’s Guide”>Developers
Stay up to date with AI tools, model releases, and developer workflows that matter.
Weekly. Free. One click to leave.
SitePoint Premium
Stay Relevant and Grow Your Career in Tech
- Premium Results
- Publish articles on SitePoint
- Daily curated jobs
- Learning Paths
- Discounts to dev tools
7 Day Free Trial. Cancel Anytime.
An AI coding agent rebuilt my photo-collage app as a distributed system and deployed it to a free server. The hard part turned out to be hardware: one free ARM CPU, 538 collages created during load testing, zero failed jobs, and $0 a month.
Like most developers, I have never been short of product ideas. Hosting them has always been the problem. I have tried shared hosting with SmartWeb, Azure free credits, Google Compute Engine’s free VM instances, SmartWeb’s virtual private servers, and Heroku dynos. None of them left me satisfied. The worst experience was a $200 charge for an AI address API on Google Cloud—for an application that never earned me a single kobo.
I am not a cheapskate, but I learned quickly that one of the easiest ways to kill a potentially good idea is to get the finances wrong. An application has to stay online until it reaches a critical mass of users, and hosting an untested, unverified product on expensive hardware can be wasteful.
Agentic AI coding has changed how quickly I can move from idea to production. Over about five weeks of intermittent coding—amounting to roughly three days of full work with Claude—my photo-stitching app went from an Angular 8 project that would not even build to a distributed system running in production.
Along the way, Claude upgraded the front end from Angular 8 to Angular 22 and fixed the build on Node 24. It set up RabbitMQ with Docker Compose so the message broker configures itself on startup, and added real-time notifications over SignalR with a progress spinner. It fixed a crash loop caused by an unreadable iPhone photo. It redesigned the system so any server can process any job, with switchable database and file storage, direct browser-to-storage uploads, and photos resized in the browser before upload. It added reliability work that a team might debate for a sprint: a dead-letter queue, confirmed publishing, idempotent workers, recovery of stuck jobs, and automatic clean-up. It fixed the stitching so photos keep their proportions and borders are even. It wrote 41 automated tests and scrubbed leaked passwords and personal photos from the Git history.
Coding, QA, DevOps, and production support used to be separate phases, often handled by separate people. Here they happened in one conversation. When code becomes this cheap to produce, the bottleneck moves. For me, it moved to hardware.
Bottleneck one: the machine on your desk
To check what the AI builds, you have to run it locally. A distributed app means running the whole system locally: a web app, a background worker, a message broker, a database, and storage emulators. Because Claude adds features quickly, and each one can add another container, it is easy to exhaust a laptop’s RAM and CPU.
My setup made this lesson concrete. I work on a MacBook Air, with Visual Studio in a Windows virtual machine. Docker cannot run inside that VM on Apple Silicon, so Claude ran Docker on the Mac and drove it from Windows over SSH. Later, my mobile connection started dropping large packets and broke uploads from the VM, so Claude moved the load testing onto the server itself. The software problems took minutes. The hardware and network problems took longer.
Then comes hosting. Heroku looked like the easy route, but it has had no free dynos since 2022. The cheapest option is an Eco dyno at about $5 a month, plus about $5 for Postgres. That is affordable, but running it for an idea that has no users yet did not seem prudent.
Claude suggested Oracle Cloud’s Always Free tier: an ARM server with up to 4 CPUs and 24 GB of RAM, free with no end date. I created a small instance with 1 CPU and about 6 GB. Claude wrote a production Docker Compose file and a one-command setup script: Caddy as the gateway, the web app, the stitching worker, RabbitMQ, and PostgreSQL, with data that survives restarts. My repository is private, so rather than put a GitHub token on a public server, it copied the code over SSH and deployed it. The last blocker was mine to fix: opening ports 80 and 443 in Oracle’s network firewall. Then the site was live.
I did not want to guess, so I asked Claude to load-test the live server. Simulated users ran the full flow: upload two photos, wait for the real-time notification, and download the stitched collage.
The server handled 64 people creating collages at the same moment without a single failed job: 538 collages, zero errors. Its ceiling was about 62 collages a minute—one per second. Beyond that, users queue. With 4 people creating at once, 95% of collages arrived within about five seconds; at 64, each person waited about a minute. If each active user makes a collage every couple of minutes, one CPU comfortably serves around 85 people at once, and a few hundred if they use it less often.
The test also showed what runs out first, and it is not the CPU. Each collage stores about 5 MB, mostly the PNG output, so at full speed the disk would fill in under two hours. Switching to JPEG and shortening retention fixes that, and when traffic grows, three more free CPUs are waiting. That is the value of measuring before paying: I know what to change, and when.
Why Oracle is giving this away
Oracle isn’t being charitable. Servers need applications to run—ideally ones that go viral—and the free tier is a play for loyalty. Oracle wants successful projects to stay and grow into its paid services instead of moving off the platform once they reach critical mass. It can also reclaim free instances that sit idle.
I think the bet is smart, and it points to a bigger trend. AI-generated code still needs energy to run and hardware to host it, even when far fewer people work on each project. As more people turn ideas into working software, demand for compute will keep growing, and I expect hosting and data centres to become a very profitable business.
For now, the combination works: Claude orchestrates the coding, QA, and DevOps, and Oracle’s free server keeps an idea online long enough to find out whether it deserves to grow.
