Last Tuesday morning at 6:00 AM, I woke up to a “DEGRADED” email from the Pipeline-health monitor. My blog’s AI content pipeline was having issues again. This is just one of countless “moments” I’ve faced while running my own projects as an indie hacker. From the outside, it paints a romantic picture – “being your own boss,” “coding freely” – but the reality is often very different.
While managing my side products like hesapciyiz.com, spamkalkani.com, and islistesi.com, and feeding this blog, I’m constantly under an operational burden. In essence, what I do is a miniature version of my system architecture and operations experience from large companies. The only difference is that this time, I’m taking on all the roles myself.
Behind the Romantic Curtain: Operating Your Own Business
Most successful indie hacker stories you see online focus on product development, marketing, and sales. But no one tells you about having to restart a systemd service at 3:00 AM, a Docker container unexpectedly filling up disk space, or why a GitHub Actions pipeline suddenly failed. This requires a constant state of vigilance.
For me, being an indie hacker isn’t just about generating ideas and coding; it also means being a DevOps engineer, a system administrator, a QA specialist, and sometimes even a customer support agent. Ensuring that each of the more than 13 Docker containers running on my own VPS is healthy, performing regular updates, and taking precautions against potential issues is part of my daily routine.
The Drama of Your Own Server: VPS Overload and OOM Scenarios
On my own VPS, I usually run a series of containers. When memory and CPU resources are limited, even the slightest hiccup can create a domino effect. For example, in an incident last month, due to an application’s unexpected memory consumption, I saw the kcompactd process on the system start using 92% CPU. Even establishing an SSH connection became impossible because sshd couldn’t accept new connections.
In such situations, I’m forced to watch the swap area swell, the system slow down, and eventually critical services get OOM-killed. I’ve spent days trying to find and resolve the source of the problem. I even remember accidentally causing the system to be OOM-killed while trying to temporarily stop a service with a simple sleep 360 command. These kinds of errors are experiences you can pragmatically dismiss as “it happens,” but they’re still annoying.
Docker Disk Fires and New Headaches from Automation
The flexibility of using Docker is undeniable, but it also brings new problems. Especially build caches and unused images filling up the disk over time is a major issue. On April 28th, I experienced exactly this on my own VPS: the disk was 100% full. Looking back, I saw 33 GB of build cache and 23 GB of unused images. This forced me to perform an urgent docker system prune -a operation.
Automation tools like GitHub Actions are vital for my continuous integration and deployment processes. However, these tools also have their own specific issues. While using my self-hosted runner, my pipelines once failed due to a corrupted state in the _work/_temp directory. No matter how much manual cleaning I did, I couldn’t resolve the issue and eventually had to reset the runner. Such situations clearly demonstrate the maintenance burden that automation brings alongside the convenience it offers.
My Encounters While Developing the AI Pipeline
The AI-powered content pipeline I set up for this blog showed me another side of being an “indie hacker.” The outputs of AI models are not always perfect. For example, I encountered “quirks” like sometimes using slash characters in tags, returning the publishDate field as a quoted string, or having issues with Turkish characters (especially dotted-i). These situations forced me to add robust “auto-fix” and “dedup-alert” mechanisms to the pipeline.
Astro build processes are another story. For a blog like mine, which generates a lot of content, Astro’s build process can consume significant resources. There were times on my server when the Astro build consumed 2.5 GB of RAM, and the total system RAM usage climbed to 7.6 GB. For a small VPS, this means a serious OOM risk. In such cases, setting up preflight resource guard mechanisms becomes essential to prevent unexpected outages.
Development or Maintenance? A Constant Trade-off
As indie hackers, we constantly want to develop new features, improve our product, and market it. However, the reality shows that a significant portion of our time goes into keeping existing systems running, fixing bugs, and resolving operational issues. This is a continuous cycle of trade-offs.
For example, the decision to use my own self-hosted runner to avoid exceeding GitHub Actions quotas provided me with a cost advantage. But the price of this advantage meant that I had to take on the maintenance and updates of the runner myself. This occasionally led to surprises like the runner experiencing state corruption. We would have done X, but because of Y, we chose Z and accepted the consequences.
Even CVE mitigations are my responsibility on my own server. For example, a seemingly simple operation like blacklisting the algif_aead kernel module can be essential to close potential security vulnerabilities like CVE-2026-31431. I have to track the work that security teams do in a corporate environment all by myself for my own projects.
Conclusion: A Tired But Ongoing Journey
Being an indie hacker, beyond romantic dreams, is a continuous journey of learning, problem-solving, and adaptation. Yes, developing your own projects and creating things brings incredible satisfaction. But the price of this satisfaction is often late-night alarms, unexpected operational issues, and a constant maintenance burden.