The Art of Continuous Maintenance

In the 6th century, imperial embassy personnel brought the horticultural practice of penjing (tray scenery) from China to Japan, where it eventually evolved into what we now know as Bonsai. A common misconception about Bonsai is that it refers to a specific species of dwarfed tree. In reality, almost any woody-stemmed tree can become a Bonsai; what makes it a Bonsai is the method — the continuous, deliberate, and routine pruning, wiring, and care administered over decades. You do not create a Bonsai in a single weekend marathon of cutting; rather, you create it through a rigorous schedule of small, consistent maintenance.

Software engineering, and specifically the maintenance of long-lived Ruby on Rails applications, operates on a strikingly similar principle. For many organizations — especially B2B SaaS companies — maintaining a Rails application is both a matter of code hygiene and a strict regulatory requirement for passing SOC2 compliance audits.

Yet, many engineering teams treat framework upgrades as a rare, monumental event. They ignore the growing technical debt until a critical vulnerability is disclosed or an auditor flags an End-of-Life (EOL) Ruby version. This leads to what we might call the “Big Bang” upgrade: a massive, risky, and expensive overhaul that halts product momentum.

There is a better approach. By adopting the “Bonsai Method” — establishing a routine, incremental maintenance schedule — we can systematically mitigate SOC2 risks, improve application security, and transform upgrades from panic-inducing emergencies into mundane operational tasks.

The SOC2 Compliance Challenge

Before we get into the mechanics of the Bonsai Method, let’s take a step back and talk about SOC2 itself. System and Organization Controls 2 (SOC2) is an auditing procedure designed to ensure that service providers securely manage data to protect the interests of the organization and the privacy of its clients.

For a Rails application, SOC2 compliance typically focuses heavily on the “Security” and “Availability” trust services criteria. Auditors will look for evidence that you are:

• Promptly patching known security vulnerabilities (CVEs) in your dependencies.
• Using supported, non-EOL versions of your underlying language (Ruby) and framework (Rails).
• Following a defined, predictable change management process.

When you defer maintenance, you accumulate risk. A legacy Rails application running on an outdated Ruby version with hundreds of stale gems is a compliance liability. If a zero-day vulnerability is announced in a core dependency, patching it in a neglected application might require upgrading Rails itself — a process that could take weeks or months, leaving your system exposed and your SOC2 status in jeopardy.

Exploring the Alternatives

When managing the lifecycle of a Rails application, organizations typically default to one of three approaches. Depending on the particular circumstances you find yourself in, one of them may seem more appealing than the others, though the long-term costs differ wildly.

The first approach is Reactive Maintenance. In this model, the team only updates dependencies when absolutely forced to — either by a critical security disclosure, a failing third-party API, or an impending compliance audit. This is inherently risky; it guarantees that when an update does happen, it will be done under extreme time pressure.

The second approach is the Big Bang Rewrite or Upgrade. Here, the organization accepts that the application is hopelessly outdated and pauses new feature development for months to modernize the entire stack at once. While this eventually resolves the technical debt, it starves the product of new features and introduces a massive surface area for regressions.

The third option is the Bonsai Method — routine, scheduled, and incremental maintenance. Generally speaking, this is the most sustainable approach, particularly for organizations bound by SOC2 requirements.

The Bonsai Method in Practice

The core philosophy of the Bonsai Method is that maintenance should be small, frequent, and strictly scheduled. Rather than waiting for a major Rails release, we systematically prune and update the application’s dependencies on a recurring basis.

Establishing the Schedule

The first step is establishing a non-negotiable cadence. For example, a team might dedicate the first Tuesday of every month to routine dependency updates.

Executing the Routine

During this scheduled window, developers execute a controlled update of the application’s dependencies. Of course, before you use any commands that modify your state, it is wise to ensure the latest “known good” version of your Gemfile and Gemfile.lock are committed to source control.

We can start by identifying which gems have newer versions available using the bundle outdated command:

$ bundle outdated
Fetching gem metadata from https://rubygems.org/..........
Resolving dependencies...

Outdated gems included in the bundle:
  * nokogiri (newest 1.16.2, installed 1.15.5)
  * puma (newest 6.4.2, installed 6.4.0)
  * rails (newest 7.1.3, installed 7.1.2)

You might be tempted to run bundle update without any arguments. However, this is an aggressive approach that attempts to update every gem to its latest possible version simultaneously. Instead, a safer approach for routine maintenance is to update gems conservatively.

For example, we can update a specific gem, like puma, without upgrading its shared dependencies unnecessarily:

$ bundle update --conservative puma
Fetching gem metadata from https://rubygems.org/...
Resolving dependencies...
Using nio4r 2.7.0
Using puma 6.4.2 (was 6.4.0)
Bundle updated!

We can notice a few things in this output. The --conservative flag instructs Bundler to update the target gem (puma), but it prevents Bundler from updating other dependencies (like nio4r) that satisfy the requirements, even if newer versions exist. This intentionally limits the scope of the change.

Maintenance also involves taking away what is no longer needed. Over time, applications accumulate unused gems. Pruning these dependencies is equally important as updating them, as every gem represents potential compliance risk and security surface area. You can identify unused gems, remove them from your Gemfile, and then clean up your local environment:

$ bundle clean --force
Removing unused gems...

After updating and pruning our dependencies, we run the test suite, review the changelogs of updated dependencies for breaking changes or deprecation warnings, and deploy the changes through the standard CI/CD pipeline. By making this a routine occurrence, the team builds “muscle memory” for the upgrade process. The delta between the old code and the new code is intentionally small, making regressions straightforward to isolate and fix.

Mitigating Security and Availability Risks

This incremental approach directly addresses SOC2 compliance criteria.

From a Security perspective, routine maintenance ensures that your application is rarely more than a few weeks behind the latest security patches. When a critical CVE is announced, applying the patch is trivial because the application is already running on a modern, fully updated stack. You don’t have to cross a chasm of breaking changes to bump a single gem version.

From an Availability perspective, small, frequent deployments are statistically much safer than massive, sweeping changes. If a minor gem update introduces a memory leak, it is immediately apparent which pull request caused the issue, and rolling back is a low-risk operation. This predictability protects your Service Level Agreements (SLAs) and satisfies auditor requirements for system stability.

Documenting the Process

Of course, passing a SOC2 audit requires more than doing the work; you must prove that you did the work.

The Bonsai Method naturally generates a continuous paper trail of compliance. Because updates are scheduled and predictable, they map perfectly to standard change management procedures. Every monthly maintenance cycle produces a documented pull request, a passing CI/CD build log, and a deployment record — exactly the evidence an auditor wants to see.

Acknowledging the Complexity

The Bonsai Method is not entirely without friction, though. Strictly speaking, dedicating engineering hours to routine maintenance means those hours cannot be spent building new features.

Product managers often push back against this scheduled “downtime.” However, we must view this through the lens of long-term economics. The compounding interest on technical debt is notoriously unforgiving. The hours spent on monthly maintenance pale in comparison to the weeks of lost productivity — and potential loss of enterprise clients — caused by a failed SOC2 audit or a botched, panic-driven Rails upgrade.

Additionally, note that some dependencies require more effort to update than others. You may occasionally encounter a gem that requires significant refactoring to update. In these cases, the Bonsai Method gives you the visibility to identify the complex upgrade early, allowing you to schedule the refactoring work properly rather than discovering it in the middle of a crisis.

Tip: When you encounter a gem that requires significant refactoring, you can temporarily pin it to its current version in your Gemfile with a comment explaining why, and create a separate ticket to handle the complex upgrade. This allows the rest of your routine maintenance to proceed uninterrupted.

Conclusion

As Antoine de Saint-Exupéry famously noted, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. The same principle applies to our technical debt.

By treating our Rails applications like Bonsai trees — applying routine, scheduled, and meticulous care — we ensure their long-term health and stability. The Bonsai Method transforms the unpredictable risk of framework upgrades into a boring, predictable operational cadence. For organizations navigating the rigorous demands of SOC2 compliance, this predictability is a fundamental business necessity.