I Started Building a Personal AI App on the Cloud

I needed a runtime outside my local machine

As I wrote in the first post, the initial problem was simple.

The files were local, the notes were local, and much of the context I wanted to give AI was local.
If I did not open my MacBook, nothing really continued.

At first, this almost looked like a file syncing problem. Maybe I could just put everything in iCloud or GitHub. But what I wanted was not just file storage.

I wanted an environment where I could talk to AI, look at project history, read necessary files, and continue the work I had been doing. That was closer to a runtime than a storage folder.

I needed a place that was always on.
A place I could access even when my MacBook was closed.
A place I could open from my phone.
A place where the apps and data I made could keep existing.

So the direction naturally moved toward the cloud.

The existing state: many small Cloud Run services

ATLAS was not the only reason I started organizing servers.

At the time, I was running several projects at the same time. Digging Music, Campus Koe, my portfolio, and small experimental apps were all around. Many of them were deployed separately. Some were on Cloud Run, some were on VMs, and some databases were also managed separately.

Cloud Run was convenient at first. I did not have to manage a server directly, deployment was simple, and each service could be managed independently.

But the actual state of my projects became a little messy.

Most projects were sitting as separate Cloud Run services. Inside each project, there could also be separate services such as web, api, admin, or cms. Since I cared about response speed, I often kept min instance at 1 for services I opened frequently or showed to other people.

That made the experience feel better. The service did not feel asleep when I opened it. But it also meant that even small services were not completely cheap to keep around.

One service was not a big deal.
Several projects, each with several services, started to feel different.

The cost was not coming from huge traffic. It was coming from many small services that I wanted to stay immediately available.

The problem was also psychological

The cost mattered, but the bigger issue was the friction.

Every time I wanted to try something new, I had to think about creating another Cloud Run service, connecting a domain, setting environment variables, attaching secrets, and adding another deployment path.

That sounds small, but it changes how I work.

A small idea should feel light.
It should be easy to put up, test, and throw away.
If every experiment begins with another deployment unit, the experiment starts to feel heavier before it even begins.

I wanted to work like a small factory for experiments.

Make something small.
Use it.
If it is bad, kill it.
If it is useful, keep it.
Then make the next thing.

For that kind of work, I needed the cost of failure to be low. I did not want every tiny idea to become another independent cloud service that I would have to remember, pay for, and maintain.

A unified experiment environment

That is why a single VM started to make sense.

Instead of adding a new Cloud Run service every time, I could keep one GCE VM running and put multiple apps on top of it. Docker Compose could run the services, and Caddy could handle domains and HTTPS.

The mental model was much simpler.

There is one floor.
On that floor, I can place another container.
If the experiment fails, I remove the container.
If it works, I keep it running.

This was not only about saving money. It was about building an infrastructure that matched the way I wanted to work.

I wanted an environment where I could continue making small things and failing cheaply. The VM became that experimental floor.

ATLAS was one of the projects that came up on top of it.

Why not keep ATLAS on Cloud Run?

I could have kept using Cloud Run.

It is a good tool. Deployment is simple, scaling is managed, and there is no server to maintain. For many web services, it is a reasonable choice.

But ATLAS felt different.

It was not just a service that receives a request and returns a response. I wanted it to stay close to my working environment. It needed to access files, connect to several projects, store conversation history, and maybe later support longer-running workflows.

Also, the surrounding infrastructure was already moving toward a consolidated VM. Since I was already using Docker Compose and Caddy there, putting ATLAS on the same base felt natural.

This was not the perfect architecture for every case. If the traffic became large or reliability became the central issue, a more managed setup might be better. But at that stage, I needed an experiment environment more than a large-scale production platform.

The VM gave me that.