My Ubuntu Development Environment Stopped, So I Moved Development to the Cloud

My familiar Ubuntu environment suddenly stopped

While developing ONSEMO, I had used WSL2 Ubuntu on a Windows PC as my main development environment. I ran Codex and other development tools there, recorded changes on GitHub, and deployed websites through Cloudflare's Git integration.

Codex Remote let me continue development from my phone without sitting at my PC. For a while, I thought that arrangement was enough.

Then the WSL environment stopped in the middle of a development task. The Codex connection dropped, and I had to check the interrupted work again.

The logs contained oom-killer and Out of memory entries. Available swap space had also dropped to zero. Multiple browser and development-tool processes had been consuming memory. A Chrome process was terminated by the OOM killer, and records showed that other processes were forcibly stopped afterward.

The logs demonstrated that a real out-of-memory event had occurred. They did not conclusively establish whether Windows itself had restarted WSL or whether another action was involved. I wanted to document that distinction between confirmed facts and what remained unknown.

What changed afterward: separating development from builds

This is the second record in the story of how my ONSEMO development environment changed. At that stage, I concentrated on identifying the OOM event and preparing to work again in Codex Cloud.

Later, I adopted Codex Cloud as the primary development environment, kept WSL2 for backup development and APK builds, and added GitHub Actions as an independent build and verification path. The final architecture and costs are covered in a follow-up Story.

The following account describes what happened between the original Ubuntu failure and the decision to prepare and validate a cloud environment, before the later redundancy work.

Remote control is not the same as cloud development

Codex Remote had been useful for controlling development from elsewhere. But the computer doing the work was still my own Ubuntu installation on the PC. When WSL or the PC stopped, Remote could no longer reach that development environment.

Controlling your computer with a phone is different from being able to continue developing when your computer is unavailable.

Earlier, I had considered using GitHub to preserve source code and change history. Now it was time to apply that idea to the independence of the development environment itself.

A GitHub repository does not include a ready-to-run environment

ONSEMO was already divided into seven independent GitHub repositories: BLOG, HOME, INVEST, TOOL, CART, FLOW, and ONSEMO Connect.

Cloning a repository retrieves the code and committed configuration. It does not automatically install Node.js or the Android SDK. Differences in tool versions can prevent the same code from building successfully.

My experience setting up WSL helped at this stage. I had already documented much of each project's dependencies, build commands, testing methods, and instructions in files such as AGENTS.md. I also knew that Connect needed the JDK, Gradle, and Android SDK in addition to its web/PWA and Cloudflare Worker tools.

This migration did not copy the entire WSL filesystem. It recreated a Linux execution environment using code stored on GitHub and configurations I had previously tested.

Seven repositories in one Codex Cloud environment

I initially planned to connect BLOG alone. Then I noticed that the cloud environment setup could include several repositories.

What if each Git repository remained independent, while the development tools were prepared and maintained in a single shared environment? I linked all seven ONSEMO repositories to that environment.

Codex checked each project's settings, prepared Node.js and Android development tools, and ran automated tests and local HTTP response checks.

The first environment setup reported these results:

That was a report of 286 automated tests passing. It did not mean I had manually verified every feature on a physical phone; the figures were automated validation results from the cloud development environment.

I did not test real Galaxy SMS delivery or Web Push on a phone at this stage. Nor did I create a Release APK signed with the existing signing key.

Still, the fact that I could build and test the Android code without starting WSL felt significant.

Should a better environment run every server?

One unexpected part of the setup caught my attention. The first startup instructions included a tool for launching all seven service servers together.

Having more development tools prepared does not mean they should all run constantly. Editing a paragraph on the BLOG did not require Android tooling and every unrelated web server to start.

After experiencing an out-of-memory failure, I did not want to ignore that distinction.

I changed the startup instructions to a simpler rule:

Start only the projects needed for the current task.

The option to start everything remained available when necessary, but it was no longer the default. Moving the development environment was about more than installing tools successfully; it also made me reconsider how much computing resource each task should use.

Pressing Publish does not complete verification

After reviewing the setup script and startup instructions, I published the environment. I also checked that supporting files did not contain unexpected direct deployment operations or code that printed secrets.

Later, I ran another BLOG build in the already connected cloud environment. Existing Node.js, npm, tools, and caches were reused without reinstalling them, and a build generating 21 BLOG posts succeeded.

But that did not prove the setup would automatically recreate itself in a completely fresh instance. The test had run in an existing connected environment.

I intend to keep separating what a test proves from what remains unverified.

Not one computer, but a workflow that can continue

I was not abandoning WSL altogether.

Testing SMS on a physical Galaxy or creating an Android Release APK with an existing signing key may still require a local environment. Code changes and automated tests, however, can be performed in the cloud.

At that point I was considering Codex Cloud for development, GitHub Actions for independent build verification, and Cloudflare's existing Git-based deployment process. The final arrangement is described in the follow-up Story mentioned earlier.

Having my development environment stop was inconvenient, but it left me with a useful question:

Can I continue working when the computer I was developing on stops?

What I want is not a computer that never fails. It is a development workflow that lets me start again when something does.