Rethinking My Deployment Architecture on a Tiny VPS

In my previous role as a full-time engineer, I had access to more powerful servers and could isolate my components into Swarm services. I currently run several projects on a very small VPS with around 50 GB of SSD storage, 1 GB of RAM, and a processor running at approximately 1 GHz. It's incredibly cheap, costing me around ¥500 per month. And I can tell you that being resource-frugal back then really pays off now.

The server hosts a monorepo containing several projects: my Django-powered website and store, games, tools I've built for my students, and various personal projects. The store images alone take up around 15 GB, but fortunately, I keep those on Cloudflare R2 rather than storing them directly on the VPS.

My current setup uses Cloudflare Tunnel to route incoming traffic to Nginx, which runs directly on the VPS. Nginx then handles traffic routing to my Docker container, where the applications are hosted.

While resource management is challenging with the monorepo at idle eating up 40% of my RAM, maintaining and updating everything has become increasingly difficult.

Because everything is bundled into one large container, updating one component can mean restarting the entire container. This takes down everything else running inside it, even when those applications aren't affected by the changes.

For simple changes, I can Docker exec into the container and edit HTML, JavaScript, or other files directly. But for more substantial changes, I often have to rebuild or restart the entire thing.

I've already implemented a maintenance notification system to minimise disruption. Before a restart, users are notified and are told to please wait. For games and interactive tools, server-side content is cached outside the container in persistent storage. Once the container has been rebuilt, that content is restored so users can continue where they left off.

If there's nothing to restore, users simply receive the usual update-completed message.

While this works, it's a bit of a pain and isn't particularly practical as the platform continues to grow.

A Different Approach

I think this is a problem that smaller businesses and independent developers can relate to. Not everyone has the resources to run larger VPS instances, multiple servers, Docker Swarm, or Kubernetes.

When you're working with limited resources, you have to make the most of the infrastructure you can actually afford.

My current thinking is to retain containerisation where it makes sense, potentially keeping Django and the main website inside Docker, but moving the individual applications and services outside the container to run independently on the VPS itself.

I'd retain my existing Cloudflare Tunnel and Nginx configuration, allowing Nginx to continue managing incoming traffic and routing requests to the appropriate services. Where necessary, those services could communicate with Django over the local network.

This would allow me to update and restart individual applications without rebuilding the entire container or interrupting everything else running on the server.

It would also give me an opportunity to gradually dismantle the monorepo and separate the projects into their own repositories. That would make maintenance more manageable and give each application a much more independent deployment lifecycle.

I don't necessarily think every application needs its own container, nor do I think every small deployment needs a full orchestration platform. Sometimes, a simpler architecture is enough.

What's Next?

My next step, in my free time, is to start dismantling the monorepo, testing the individual services, and gradually redeploying them using this new approach.

It's going to be a lot of work, particularly making sure everything communicates correctly and that existing functionality isn't broken during the transition.

However, I think the long-term benefits will be worth it. Maintenance should become much easier, future changes should be less disruptive, and I'll have considerably more flexibility when deploying new features.

There's also a personal benefit: this gives me an opportunity to gain practical experience with service isolation, independent deployments, and managing applications on resource-constrained infrastructure.

Those are skills I can take into my professional work as well.

Sometimes the best way to learn how to solve an engineering problem is to encounter it in your own projects first.