Rails maintenance and support should cover five things: security and dependency patching, Ruby and Rails upgrades on a schedule, monitoring and incident response, small fixes, and a written record of what changed and what is coming. How much to budget depends less on the size of the app and more on how far behind it is, how much test coverage it has, and how fast you need someone to respond when it breaks. Agree the scope, the capacity, and the response expectations in writing before you agree a monthly number.
This guide is for founders and CTOs who run a business-critical Rails application and want to know what they should pay for each month.
What Rails maintenance actually includes
- Security and dependency updates. Applying Rails, Ruby, and gem security releases, and replacing gems that are abandoned or have known vulnerabilities.
- Version upgrades. Moving Rails and Ruby forward one step at a time, before the version you run stops receiving security fixes.
- Monitoring. Error tracking, uptime checks, background job alerts, and slow query reports, reviewed by someone who knows the app.
- Incident response. Investigating and fixing production problems, including the ones caused by an external API or a hosting change rather than your code.
- Small fixes and hardening. Bugs, flaky tests, missing database constraints, and the deploy step that only works if you run it twice.
- Reporting. A short monthly summary in plain language: what shipped, what is at risk, and what decisions are needed from you.
What it usually does not include: new features, redesigns, large integrations, and rescue projects. Those need their own scope. A maintenance arrangement that quietly absorbs feature work stops doing maintenance.
The clock that drives the work
Rails maintenance has a calendar you do not control. Under the Rails maintenance policy, each release series gets bug fixes for one year and security fixes for two years after its first release. As of October 2026, the policy lists Rails 8.0 security support ending on November 7, 2026, and Rails 8.1 security support ending on October 10, 2027. Ruby has its own schedule on the Ruby branches page: Ruby 3.2 reached end of life in April 2026.
Once your version is out of support, new vulnerabilities are your problem to patch. That is why upgrades belong inside maintenance, not in a separate project you schedule when something breaks. We cover how to catch up in Upgrading an old Rails app without a rewrite.
How maintenance is usually structured
| Model | How it works | Works well when | Watch out for |
|---|---|---|---|
| Fixed monthly capacity | A set amount of engineering time each month for maintenance work | The app is critical and you want steady progress on upgrades and patches | Whether unused time rolls over, and what happens when an incident uses it all |
| Prepaid block of hours | Hours bought in advance and drawn down as work happens | The app is stable and changes are occasional | Upgrades slipping because nobody spends hours until something breaks |
| On-demand, billed hourly | You call when you need help | Low-risk internal tools | No one watching the app, slow response, and a new person learning the codebase each time |
| Ongoing ownership | One team runs maintenance, upgrades, and new work together under one plan | The app is central to revenue and you have no in-house technical lead | Keeping maintenance work visible so features do not crowd it out |
What drives the budget
Two Rails apps of the same size can need very different amounts of maintenance. The main factors:
- Version gap. An app one minor version behind needs routine work. An app several major versions behind needs a catch-up plan first, then routine work.
- Test coverage. With good tests around critical flows, upgrades and patches are quick to verify. Without them, every change needs manual checking, and the first months go into building a safety net.
- Dependencies. Many gems, forked gems, or gems with no recent releases add work to every upgrade.
- Integrations. Each external API, payment provider, or data sync is something that can change or fail without warning.
- Response expectations. Someone available within the hour during business hours costs more than next business day. Out-of-hours coverage costs more again.
The practical way to budget is to start with an audit. It tells you the version gap, the state of the tests, and the riskiest areas, which turns a guess into a plan with a first phase and a steady state.
If you want to know what your app actually needs each month, bring the Rails and Ruby versions and a short description of how it is deployed to a Systems Discovery Call. We will tell you what the first phase should cover.
Questions to settle before you sign
- What is in scope, and what is a separate project? Get the boundary in writing, including how borderline requests are decided.
- How fast will someone respond to a production problem? Ask for business-hours and out-of-hours expectations separately.
- What happens when an incident uses the month's capacity? Find out whether upgrades pause or extra time is added, and who approves it.
- Who decides the upgrade schedule? It should be tied to the support dates above, not to whenever there is spare time.
- What will we receive each month in writing? Ask to see a sample report.
- Who else can deploy if the main developer is away? A good answer names a person who already knows your app.
- What do we own? Code, credentials, hosting, and monitoring accounts should all be under your company.
If the person who maintained the app has already left, start with Taking over a Rails app from a previous developer.
What long-term maintenance looks like
Zentap, a real estate marketing platform used by more than 20,000 US agents, is a Rails product we maintain long-term. The same team keeps it current, watches production, and ships new work on top of a codebase it understands. That is the point of maintenance: the app stays safe to change. Our Rails app takeover and maintenance page describes how we work, and the rest of what we do is on our services page.
Common questions
Can we skip maintenance if the app is stable?
Stable today does not mean supported. Security fixes for your Rails and Ruby versions end on a fixed date, and gems and external APIs keep changing. Quiet months are when upgrades are cheapest to do.
Do we need out-of-hours support?
Only if downtime outside business hours costs you customers or revenue. Many internal tools do not need it. A checkout or customer-facing platform usually does.
Next step
If you are deciding what Rails maintenance your app needs, book a Systems Discovery Call. It is 45 minutes on your application, its versions, and what the business depends on. You leave with a clear picture of the first phase and the ongoing work, whether you hire us or not.
Farooq Ch
Oct 2026