From One PC to a Redundant Cloud Development Workflow

When I first started building programs, I did not imagine I would end up maintaining several development environments.

I began by creating a Linux development environment inside Windows and asking AI to help write code. Later I stored source code on GitHub and connected automatic deployment through Cloudflare. As the number of projects grew, I started developing an Android app too. During that work, WSL2 ran out of memory and interrupted a development session.

Today I use Codex Cloud as the main development environment, while retaining WSL2 Ubuntu as a separate development path. GitHub Actions performs builds and tests independently of either coding session, and Cloudflare deploys web services through Git integration.

The setup has become more involved, but the basic web infrastructure can still be built around free tiers. Earlier Stories covered my original WSL2 setup, the actual OOM failure, and the first move to Codex Cloud. This third account focuses on the operating arrangement that followed and its costs.

1. How did the development environment change?

Building a Linux environment inside Windows

I initially configured WSL2 Ubuntu on my Windows PC. I handled everyday work on Windows while developing in Ubuntu, installing Node.js, Git, and Codex CLI and creating projects one at a time.

One reason for this arrangement was that I did not want an AI coding tool to have unnecessarily broad access to all my Windows files and permissions. WSL2 is not, however, a completely separate security boundary. Actual access depends on filesystem permissions, mounts, and tool configuration.

When the projects expanded, GitHub became the source-control reference point and Cloudflare's Git-integrated deployment became the publishing route. A public site could stay online when my PC was off, and the source code could be continued from another computer.

I documented those early decisions in the first development Story. Here I want to concentrate on what changed afterward.

An out-of-memory event became the turning point

Adding Android development to web projects meant that Gradle, the Android SDK, browsers, and several development tools all consumed memory. WSL2 actually experienced an out-of-memory event. I found log evidence of exhausted swap and terminated processes.

The memory shortage itself was confirmed; I could not establish with certainty what initiated the final WSL restart.

I could have considered assigning more memory, but a more important question occurred to me:

Could I carry on if the computer I was developing on stopped?

That led me to use Codex Cloud in earnest. I did not upload WSL2's entire filesystem. I recreated the necessary Node.js, JDK, Android SDK, and other tools in the cloud, using GitHub repositories and their project configuration. Having built the local environment before made that easier.

Separating builds as well as development

A cloud development environment is still one execution environment. I therefore kept WSL2 and created a separate build and verification route using GitHub Actions.

Codex Cloud is currently my primary development environment. WSL2 can still handle local development, physical-device Android tests, and Release-signed APK builds. GitHub Actions can execute specified tests and Release-build workflows independently of a development session.

For the Android app ONSEMO Connect, I configured a manually triggered workflow for Release APK build and signing verification using the existing signing credentials.

Creating an APK and publishing it at the official download URL are separate steps. Only a reviewed and verified artifact should be placed at the official location.

This is not a zero-downtime infrastructure. GitHub and Cloudflare remain shared dependencies. But it is different from depending on a single PC for both development and builds.

2. ONSEMO's current development and deployment infrastructure

GitHub sits at the center. Codex Cloud and WSL2 are separate environments, but both work against the same repository history. GitHub Actions independently checks builds, while web publishing continues through Cloudflare's Git integration.

Not every project needs a database. When static files are sufficient, I prefer them. I add Workers, D1, or Durable Objects selectively when server processing or data storage genuinely requires them.

Web Analytics provides basic operating metrics without depending on cookies. For security, I configure DNS, HTTPS, and relevant Cloudflare protections according to each service's needs.

3. Basic annual web infrastructure cost

I had assumed that running several services meant paying for several servers. In practice, ONSEMO's basic web infrastructure can operate around the free allocations offered by GitHub and Cloudflare.

One domain can host multiple subdomains without paying a separate domain registration fee for each. BLOG, CART, and CONNECT can therefore have distinct addresses under the same domain.

This is not my entire development cost or a claim about every actual bill. It assumes existing hardware and connectivity and no usage beyond free allocations. It excludes equipment, electricity, connectivity, taxes, additional domains, and paid services. Domain renewal pricing can change.

AI development tools are a separate, optional cost

AI tools are important to ONSEMO, but I did not start with a paid AI product. I began with the free ChatGPT plan.

As I built small programs and tested ideas, I selected tools according to what I needed. AI subscriptions should therefore be considered separately from the cost of keeping a website running. Free plans have limits, and certain development features can require additional access.

Even registering a custom domain is not essential just to start programming. Start small and add costs only when there is a real reason to do so.

4. How far do free plans extend?

These are example free allowances that I reviewed as of October 2026, not permanent promises of account entitlements.

Not every limit is independent per project. Some allowances are shared across an account and depend on the runner or execution environment. GitHub Actions build usage and Cloudflare Workers Builds usage are calculated separately.

As long as actual usage stays within free allocations, I can test small services without provisioning another paid server. If usage grows, I can measure it and decide when expansion is justified.

5. What technology might be useful later?

As I reorganized development, I also found Cloudflare features worth experimenting with beyond what I already used.

In CART, I considered using OCR to read product details from personal screenshots. In INVEST, I explored gathering and managing publicly available market data. Those examples highlight how a technology choice should depend on both the data involved and the privacy requirements.

These are candidates under consideration, not an approved roadmap, confirmed schedule, or completed implementation:

Semantic search may make sense after BLOG accumulates enough writing. By contrast, private screenshots in CART and end-to-end encrypted messages in CONNECT need to follow the existing local-processing and encryption principles first.

I want to decide whether a technology is needed before adding it simply because it is available.

Learn moreHow Far Can You Go With Cloudflare's Free Features?

I gathered the published free allowances and possible applications of Workers AI, D1, Vectorize, R2, and other services in a separate Knowledge article.

↗

6. How these changes affected my thinking

At first, the goal was just to build programs with AI. That led to source control, then automatic deployment, and eventually the question of how to continue when the main computer stopped.

Now, whenever I consider a new feature, I first look for a way to build it with existing infrastructure rather than immediately adding a new server or database.

Free infrastructure is a way to reduce costs, but also an opportunity to test many small ideas before making larger commitments.

Start small, learn from actual use, and expand when there is a need.

ONSEMO's development environment continues to evolve through that process.

---

Based on published pricing and free allocations as of October 15, 2026. Features and limits can change; check the current provider dashboard for actual billing.