Recently, I woke up to three different Docker containers being OOM-killed in a row on my VPS. It was 04:30 AM when PagerDuty went off, and my first reaction was “Again?” This was a typical morning start in the world I call living on my own server, where I manage all my personal projects and side products.
This situation is a concrete example of a years-long search for balance: the time and effort I spend in exchange for the freedom and control I possess. Living on my own server has become a choice, a philosophy for me.
The Price of Freedom: Time and Effort
I have a long-standing habit: building and managing everything with my own hands. This is actually a reflection of the experience I’ve gained in system architecture and operations since 2006 into my personal life. This applies to this blog, as well as projects like hesapciyiz.com, spamkalkani.com, and islistesi.com, all of which I host on my own server.
Of course, this freedom comes at a price. Sometimes, like on April 28th when the disk hit 100% capacity or when I saw kcompactd using 92% CPU, I have to spend hours at the terminal with a coffee in hand. Situations like an sshd failing to accept connections, a Docker disk fire, or blacklisting kernel modules like algif_aead to mitigate CVEs are the responsibilities that come with this freedom.
Why Do I Live on My Own Server? My Philosophy
So, despite all these problems and sleepless nights, why do I choose this path? There are a few fundamental philosophical reasons:
Full Control and Independence
On my own server, everything is my choice. I select every component from the operating system to the web server, from the database to the application layer. Astro, Node, SQLite, Nginx, systemd, GitHub Actions, and Cloudflare make up my daily toolset. I can shape this ecosystem according to my own needs without getting stuck in any vendor’s limitations. This level of control is invaluable, especially when developing complex pipelines or specialized AI applications.
Continuous Learning and Experience
Even with 20 years of field experience, the technology world is constantly changing. My own server serves as a sandbox for testing new technologies, tools, and approaches. Moments when my Astro build eats up 2.5 GB of RAM and triggers an OOM, or when Docker clogs the disk with 33 GB of build cache and 23 GB of unused images, turn theoretical knowledge into practical experience. These real-world scenarios constantly push me to find better solutions.
Economic Efficiency and Scalability
In some cases, hosting on my own server provides a cost advantage. Specifically, using a self-hosted runner to avoid exceeding GitHub Actions quotas provides me with both flexibility and cost savings. Managing 13+ Docker containers (including Postgres, Redis, and Next.js apps) on my VPS allows me to host multiple projects on a single server at a low cost. This is particularly important for side products.
Innovation and Paving My Own Way
When it comes to setting up an AI-powered content pipeline or transferring my experiences onto a Knowledge Graph, my own infrastructure gives me total freedom. I can step outside standard solutions and develop my own algorithms, integrations, and troubleshooting mechanisms. This transforms me from being just a consumer into a creator and problem solver.
Managing My Own VPS: Practical Challenges and Solutions
Living on my own server isn’t just a philosophical stance; it also brings daily operational challenges. I frequently see how I deal with these challenges and what practical solutions I develop.
Resource Management: The Resource Dilemma
Managing 13 containers on a VPS means if one starts behaving badly, they can all end up in swap. Especially under heavy load or during a critical operation, system resources can become insufficient.
- VPS Overload Scenarios: Situations where swap is constantly thrashing,
kcompactdis doing kernel memory compaction with 92% CPU, orsshdcannotacceptnew connections indicate that the system is overloaded. In these moments, even accessing the system remotely can become impossible. - Astro Build OOM: Even the build process of my own blog can sometimes consume 2.5 GB of RAM, causing the 7.6 GB of RAM on the system to be insufficient. This creates a headache, especially in CI/CD pipelines.
To handle these situations, I have an active monitoring system. Additionally, I set limits on containers to optimize resource usage, turn off unnecessary services, and sometimes switch to more optimized software. For instance, if an Astro build goes OOM, I try solutions like running the build process in an environment that consumes less RAM or optimizing the build steps.
Disk Management: Hidden Space Consumers
Docker’s disk usage habits can sometimes be a nightmare. Especially on a system that builds images frequently or runs many containers, disk fullness becomes inevitable.
- Docker Disk Fire: There were moments on my server where I experienced 100% disk fullness due to an accumulation of 33 GB of
build cacheand 23 GB ofunused images. This led to all services stopping and blocked access to the system. - Solutions: To counter this, I regularly clean up old images and cache using the
docker system prune -acommand. I also configure log rotation and try to minimize the impact of disk fullness by keeping critical data on separate volumes. These routine maintenances are indispensable for system health.
Automation and Reliability: Keeping Pipelines Alive
Managing my own pipelines constantly reminds me of the intricacies of automation and the importance of reliability. Even GitHub Actions runners can cause problems on their own.
- GitHub Actions Runner State Corruption: Sometimes, directories within
_work/_tempcan get corrupted, preventing the runner from working correctly. In this case, it might be necessary to manually delete these directories and restart the runner. These types of situations show that even automation may require manual intervention. - Pipeline Reliability: In my own AI generation pipeline, I use
preflight resource guardandauto-fixmechanisms. Also, thanks todedup-alertpatterns, I prevent the same error from alerting me repeatedly. These mechanisms allow the system to self-heal and alert me only in truly critical situations. - Cloudflare Cache Strategies: Astro returns
max-age=0by default, which prevents Cloudflare from caching. I solved this by overriding theCache-Controlheader in my Nginx config. This way, my static content can be properly cached by Cloudflare. - CVE Mitigation: Critical security vulnerabilities sometimes require intervention at the kernel level. For example, I manually mitigated a vulnerability like CVE-2026-31431 on my own server by blacklisting the
algif_aeadmodule. Such cases require the responsibility and proactivity that come with managing your own server.
AI Pipeline Management: Character Incompatibilities and Data Integrity
AI-powered content generation comes with many interesting problems of its own. Unexpected “quirks” can arise, especially in text processing and data transfer.
- AI Quirks: Using slash characters in tags, the
publishDatefield arriving as a quoted string, or character encoding issues like the “dotted-i” are just a few of the specific problems I’ve encountered in my AI pipeline. These issues generally show how critical data validation and sanitization steps are. - Solutions: I usually solve these character problems using regex or special character conversion functions in the middleware layers that process the output from the AI model. My goal is to ensure the data is consistent and in the expected format. Having this flexibility in my own system allows me to quickly detect and fix such issues.
Between Business and Passion: My Side Products
Living on my own server is not just a technical challenge for me; it’s also a tool for bringing my side products to life. hesapciyiz.com (Turkish financial calculators), spamkalkani.com (Android spam blocker), islistesi.com (Turkish task management), and this blog are some of the projects I host on my own infrastructure.
Each of these projects is a learning and application area for me. Because I manage them on my own server, I can keep costs low, optimize performance, and add new features whenever I want. I get the chance to apply the experiences I’ve gained at a large Turkish e-commerce site or a bank’s internal platform to these small but meaningful projects. This provides me with both technical satisfaction and potentially opens new doors for revenue.
Finding Balance: Time Management and Priorities
Living on my own server is a constant search for balance. I walk that fine line between the desire to do everything myself and the limitation of time. I have some approaches to find this balance:
What to Build, What to Buy?
I don’t do everything myself; I can’t. I don’t hesitate to use external services for critical infrastructure components (e.g., Cloudflare for CDN). But I prefer to keep control over core parts like the application layer, database, and CI/CD. This is a strategic decision for me. I determine which areas I want to have deep knowledge in and which ones I can use as a general service.
What Am I Spending My Time On?
Fixing a Docker issue or writing a new blog post? This is a dilemma I frequently face. Generally, I prioritize tasks that directly add value to the user or allow me to learn something new. Even though routine maintenance is automated, I see the time I spend on unexpected problems as an investment. Because every problem allows me to understand my system better and prevent possible future issues.
Pragmatism in My Technology Choices
I’m always open to new and shiny technologies, but I make my choices with a pragmatic approach. The reason I chose SQLite is the simplicity and performance it offers for projects at my scale. The reason I use Nginx is the experience and stability I’ve gained over the years. Every technology choice I make is based on the answer to the question, “How much time and effort will this require from me?”
Conclusion
Living on my own server is a struggle, a learning process, and most importantly, a declaration of freedom for me. Even though it occasionally costs me sleepless nights, knowing every corner of my own system and shaping it with my own hands is an invaluable experience. Being able to apply the experiences I’ve gained in large corporate projects to my own small world is one of my biggest sources of motivation.
Every error and every problem I encounter on this journey develops me a little more and makes my system more robust. Currently, I’m in the process of further optimizing my own AI generation pipeline. Let’s see what new surprises I’ll encounter next month. I wonder if you’ve had similar experiences. Perhaps in the next post, I’ll dive deeper into the details of this AI pipeline.