CI/CD Strategies: The Cost of Over-Complexity for Indie Hackers

When developing my own products or quickly setting things up with a solo team, my perspective on CI/CD (Continuous Integration/Continuous Deployment) processes is usually quite different. The massive, layered, meticulously thought-out pipelines seen in corporate projects are often an unnecessary burden in the indie hacker world. I believe the primary goal of CI/CD for an indie hacker should be to save me time, free me from repetitive tasks, and enable rapid value creation.

Recently, while updating the infrastructure for a side project where I developed financial calculators, I tried to simplify my CI/CD pipeline as much as possible. I want to share some points I encountered and experienced during this process. My aim is not to build the "best" CI/CD, but to explain how I achieve a sustainable, cheap, and low-maintenance workflow that is "best for me."

What Should a Simple CI/CD Flow Look Like?

As an indie hacker, my top priority is rapid iteration. Testing an idea, gathering user feedback, and continuously improving the product are vital. Therefore, my CI/CD flow must not slow me down; instead, it should facilitate my work. For me, a simple CI/CD flow should automate critical steps while avoiding unnecessary complexity.

Essentially, I need tests to run automatically when I write my code, followed by the application being built and deployed somewhere. Any layer beyond these steps usually gains significance as the project scale grows or the team size increases. For small-scale projects, consciously leaving some steps that might seem "manual" out of automation can significantly reduce the total cost (both time and money). For instance, while an enterprise ERP system might run dozens of integration tests with every commit, I limit myself to just unit and a few integration tests for my side projects. This gives me both speed and cost advantages.

Fast and Automated Tests

Tests are the heart of CI/CD. I generally expect tests to run immediately when I perform a git push. This is the most effective way to catch errors early, especially in small projects. If tests run slowly, I've noticed that I eventually give up running them, and even the quality of my commits declines. This became very clear after an experience in 2018 on a client project. During a refactoring, the tests took over 20 minutes to run, so instead of waiting with every change, I started pushing code that "looked like it worked" locally. The result: tests failed, and we had to roll back. Therefore, fast tests are my primary priority.

My testing strategies generally include:

• Unit tests: Test application logic at the smallest units, finish in seconds.
• Integration tests: Test interactions with external dependencies like databases or APIs, slower but still complete in a reasonable time.
• Linting/Static Analysis: Checks code quality and style, catches errors before the build.

💡 Tip for Fast Tests

Try to run your tests in parallel as much as possible. Tools like pytest-xdist in Python or Jest in JavaScript are very helpful for this. Also, quickly spinning up and tearing down a test database in-memory (e.g., SQLite) or within a Docker container can shorten the time. In an enterprise ERP system, copying the test database used to take 15 minutes; moving it to Docker reduced this to 30 seconds.

Automatic Build and Artifact Management

After tests pass, the application needs to be built and prepared for deployment. Since most of my projects run on Docker containers, this step is usually just a docker build command. For my own side projects, I either build this compiled image directly on my server or, for small projects, push it to a free registry like Docker Hub. While I've seen numerous artifact management solutions, from Maven repositories to Nexus, in an enterprise ERP system, this simplicity is sufficient for my own projects. What matters is that the build is repeatable and I can easily revert to a previous version at any time.

# A simple Docker build and push process
# An example I use on my own VPS
#!/bin/bash

APP_VERSION=$(git rev-parse --short HEAD)
REPO_NAME="my-indie-app"
REGISTRY="my.private.registry.com" # or Docker Hub

echo "Building Docker image for version: $APP_VERSION"
docker build -t $REGISTRY/$REPO_NAME:$APP_VERSION .

if [ $? -eq 0 ]; then
    echo "Image built successfully. Pushing to registry..."
    docker push $REGISTRY/$REPO_NAME:$APP_VERSION
    echo "Image pushed. Deleting local image to save space."
    docker rmi $REGISTRY/$REPO_NAME:$APP_VERSION
else
    echo "Docker build failed!"
    exit 1
fi

This simple script provides me with version control and prevents unnecessary space usage. Last month, during a build process, my VPS disk filled up to 100%, and the build failed with an OOM (Out Of Memory) error. I then realized I wasn't cleaning up old images. By adding this script, I resolved this issue.

The Hidden Costs of Over-Complexity

Falling into the trap of "more automation, better" in CI/CD can be costly for an indie hacker. In the corporate world, the cost of automation is often negligible compared to human resource costs. However, in a solo team, designing, setting up, and maintaining the CI/CD pipeline falls entirely on my shoulders. This directly steals valuable time that I should be dedicating to product development.

Maintenance Burden

A complex CI/CD pipeline can, over time, become a project in itself. Dependency updates, tool version differences, configuration changes – finding the answer to "why did this pipeline break?" can sometimes take hours. I once spent 2 days debugging why the npm install command behaved differently on different runners and caused deployments to fail due to cache issues on a client project. Such time loss is unacceptable for my own projects. Therefore, I strive to build a system with as few moving parts as possible.

• Dependency Updates: When Node.js or Python versions change, the CI/CD environment also needs to be updated.
• Tooling Changes: Migrating from Jenkins to GitLab CI means a new learning curve and rewriting existing pipelines.
• Environmental Factors: External factors like disk space on the build server, network issues, or API limits.

⚠️ The Infinite Debugging Loop

Remember, while automation makes our lives easier, the automation tools themselves are software and can contain bugs. When a problem arises in a complex pipeline, finding whether the source is the code, the test, the build, or the deployment tool can be a real detective job. This can be frustrating and demotivating, especially when you're alone.

Resource Consumption

CI/CD services are usually billed based on the resources you use (CPU, RAM, storage). Popular services like GitHub Actions, GitLab CI, and CircleCI offer free tiers up to a certain usage limit, but these limits can be quickly exceeded on large projects or with frequent commits. For one of my side projects, when I needed to build for multiple platforms (web, mobile) with every commit, I saw my monthly GitHub Actions bill unexpectedly rise. This can become a significant cost item, especially when your project isn't yet generating revenue.

Using self-hosted runners on my own VPS has become a method I've adopted to control these costs. In an enterprise setting, I've even seen monthly electricity bills increase due to high CPU consumption by CI/CD servers. On my own small VPS, I have to use resources efficiently to keep these costs at a minimum. For example, I implement optimizations like intelligently managing build caches or recompiling only changed modules.

Learning Curve and Lock-in

Every new CI/CD tool or technology brings a learning curve. Learning Helm charts for deployment on Kubernetes, implementing GitOps with Argo CD, or integrating CI/CD services from different cloud providers requires a significant time investment for a solo team. This learning process sometimes takes more time than developing the core features of the product.

Furthermore, excessive dependency on a specific CI/CD platform or technology (vendor lock-in) also carries risks. If the platform changes or pricing policies shift, I might have to rewrite the entire pipeline. For my own side projects, I try to minimize such dependencies. I use standard tools as much as possible (Docker, Bash scripts, systemd units) so that if I decide to switch to a different VPS provider one day, I won't have headaches. In my post about [related: my VPS migration experience], I detailed how painful these migration processes can be.

My Indie CI/CD Choices

With the experience gained over the years, I've developed specific choices for CI/CD in my indie projects. These provide me with both speed and cost advantages while minimizing maintenance overhead.

Git Hooks and Simple Scripts

Most of the time, the simplest solutions are the most effective. In my own projects, I achieve local CI using git hooks and simple bash scripts. For example, with the pre-commit hook, I automatically run lint and format operations before pushing my code. This prevents dirty code from entering the repository and allows me to start with a cleaner slate on the remote CI.

# A simple hook example I added to .git/hooks/pre-commit
#!/bin/sh

# Lint staged Python files
echo "Running flake8 on staged Python files..."
git diff --cached --name-only --diff-filter=ACM | grep '\.py$' | xargs flake8
if [ $? -ne 0 ]; then
    echo "Flake8 issues found. Please fix them before committing."
    exit 1
fi

# Format staged files (e.g., with Black)
echo "Running black formatter on staged Python files..."
git diff --cached --name-only --diff-filter=ACM | grep '\.py$' | xargs black
if [ $? -ne 0 ]; then
    echo "Black formatter failed. Please check."
    exit 1
fi

# Run tests
echo "Running unit tests..."
pytest --ignore=integration_tests/
if [ $? -ne 0 ]; then
    echo "Unit tests failed. Aborting commit."
    exit 1
fi

exit 0

Thanks to this hook, I catch errors at the commit stage and resolve them before sending them to the remote CI. This saves me CI time and prevents faulty commits. I personally saw how valuable such local automations were for improving code quality when developing an enterprise ERP system.

Self-Hosted Runner and VPS Economics

As mentioned earlier, the costs of cloud-based CI/CD services can sometimes increase unexpectedly. Self-hosted runners running on my own VPS allow me to control these costs. Even a small VPS (e.g., 2 CPU, 4GB RAM) is sufficient to run multiple CI/CD jobs in parallel for most indie projects. This is a significant advantage, especially for a cost-conscious indie hacker.

I manage these runners with my own systemd units. I ensure my VPS runs stably by monitoring logs with journald and controlling resources with cgroup limits. Last month, I accidentally put a script into an infinite loop by writing sleep 360, which caused it to be OOM-killed. Thanks to the soft limit of cgroup memory.high, my other services were unaffected, and I quickly identified and resolved the issue. Such small touches increase the overall resilience of the system.

Deployment Strategies: "Rolling Restart" and One-Click Rollback

For indie projects, I generally don't need large-scale and complex deployment strategies like blue-green or canary. The most practical approach for me is to stop the existing Docker container and start the new version, essentially a simple "rolling restart." This process usually takes a few seconds, and I accept a brief downtime for the application.

However, things don't always go as planned. Therefore, having a one-click rollback mechanism is vital. If a problem arises with a new deployment, I must be able to quickly revert to the previous stable version. In my own scripts, I keep the last successful image tag in a variable, allowing me to redeploy this image if necessary.

# Summary of a simple deploy and rollback script
#!/bin/bash

APP_NAME="my-indie-app"
CURRENT_VERSION=$(cat /path/to/app_version.txt)
NEW_VERSION=$1

if [ -z "$NEW_VERSION" ]; then
    echo "Usage: $0 <new_version>"
    exit 1
fi

echo "Deploying $APP_NAME version $NEW_VERSION..."

# Pull the new image
docker pull my.private.registry.com/$APP_NAME:$NEW_VERSION
if [ $? -ne 0 ]; then
    echo "Failed to pull new image. Aborting deploy."
    exit 1
fi

# Stop and remove the current container
docker compose -f /path/to/docker-compose.yml down

# Bring up the new version
sed -i "s/$CURRENT_VERSION/$NEW_VERSION/g" /path/to/docker-compose.yml # Update image tag in docker-compose.yml
docker compose -f /path/to/docker-compose.yml up -d

if [ $? -eq 0 ]; then
    echo "$APP_NAME version $NEW_VERSION deployed successfully."
    echo "$NEW_VERSION" > /path/to/app_version.txt
    echo "Old version was: $CURRENT_VERSION. You can rollback using: $0 $CURRENT_VERSION"
else
    echo "Deployment failed! Rolling back to $CURRENT_VERSION..."
    # Rollback by redeploying the previous version
    sed -i "s/$NEW_VERSION/$CURRENT_VERSION/g" /path/to/docker-compose.yml
    docker compose -f /path/to/docker-compose.yml up -d
    echo "Rolled back to $CURRENT_VERSION."
    exit 1
fi

This script offers me a safe deployment and a quick rollback capability. I recall experiencing stressful monitoring sessions lasting hours after every deployment while working on an internal platform for a bank. With this simple method, I minimize that stress on my own projects.

Monitoring and Feedback: The Essentials

No matter how simple the CI/CD process is, knowing how the application behaves after it's deployed is critical. I never adopt a "deploy and forget" approach. A simple yet effective monitoring and feedback mechanism helps me detect potential issues early.

Log Tracking and Simple Alerts

Regularly tracking application logs is the first step in troubleshooting. In my projects, I collect logs using journald and search with grep when needed. Even a very simple tail -f /var/log/syslog | grep "ERROR" allows me to see many problems instantly. For more advanced projects, I use lightweight solutions like Promtail and Loki.

I also set up simple alerts for critical errors. For example, while blocking SSH brute-force attempts with tools like fail2ban, I use simple scripts I wrote to send me an email or Telegram message if the application returns a specific error code. When a WAL rotation alarm triggered at 03:14 one night, this simple alert allowed me to intervene early in the morning. Such proactive measures prevent major crises.

Performance Metrics

Monitoring application performance directly impacts user experience. For me, tracking basic metrics like CPU usage, memory consumption, disk I/O, network traffic, and API response times is sufficient. I install and use tools like node_exporter and Prometheus on my own VPS. I also create simple dashboards with Grafana to observe the overall status.

In the backend of one of my side projects, I noticed an inexplicable increase in Redis memory usage. Upon examining the metrics, I realized that a specific dataset was being constantly evicted from Redis and reloaded due to the OOM eviction policy. I resolved this issue by changing the policy from allkeys-lru to volatile-lru. Such observations are only possible with monitoring.

When to Look for More Complex Solutions

Everything I've discussed so far is ideal for scenarios where an indie hacker starts alone or with a very small team. However, every project has growth potential. So, when does my current simple CI/CD flow start becoming insufficient, and when should I turn to more complex, enterprise-level solutions?

Team Size and Project Scope

As your team grows, coordination and standardization of processes become more important. When multiple developers are working on different features simultaneously, every commit needs to be integrated and tested automatically. In this situation, a more advanced CI system (e.g., parallel test execution, branch-based pipelines) becomes inevitable. When we had more than 10 developers working on an enterprise ERP system, manual processes were completely paralyzed. An automated, comprehensive CI/CD was our savior back then.

As the project scope expands, different services and microservice architectures may come into play. Having a CI/CD pipeline for each service increases overall complexity but allows each service to be deployed independently. This is a common trade-off encountered in monolith vs. microservice decisions. In my post about [related: Transitioning from Monolith to Microservices], I discussed these decisions in detail.

Regulation and Security Needs

If you operate in regulated industries such as finance, healthcare, or government, your CI/CD processes may need to meet specific security and compliance standards. This means stricter access controls, security scans (SAST/DAST), audit logs, and approval processes. For example, every deployment on an internal bank platform required approval from at least two different people. Such requirements necessitate more enterprise CI/CD platforms beyond simple script-based solutions.

Tracking security vulnerabilities (CVEs), and issues like kernel module blacklisting (e.g., algif_aead, CVE-2026-31431) become important, especially when dealing with sensitive data. Integrating these security checks into the CI/CD pipeline is much more reliable and automated than doing them manually.

Conclusion

My perspective on CI/CD as an indie hacker has always been centered on being "good enough and sustainable." The massive pipelines seen in corporate projects are often an unnecessary burden for my own small but agile projects. In my experience, simple git hooks, basic bash scripts, and self-hosted runners on my own VPS have allowed me to keep costs low and iterate quickly.

The important thing is to remember that CI/CD is a tool, not a goal. Our aim is to create value rapidly and reach our users. On this path, avoiding any complexity that slows us down or consumes unnecessary resources can be an indie hacker's greatest advantage. Remember, the best CI/CD is the one that costs you the least time and provides the most benefit.