Standing service upgrade-keep-runtime-and-dependencies-supported · revised 11 October 2026
Standing service
Keep your app's runtime and dependencies on supported versions, month after month
We check one repository each month against vendors' published support dates, open tested pull requests for patch and minor updates, and warn you early when a major step is coming.
This starts a conversation by email. Nothing is charged, and nothing is changed, until we have agreed scope and terms with you in writing.
The responsibility you hand over
Versions drift because nobody owns them. Small updates are skipped because each is a nuisance, support dates pass unnoticed, and the next major step then arrives as an emergency with several versions of change stacked up. An update tool such as Dependabot opens pull requests, but GitHub's documentation says you confirm that your tests pass and you merge, and the page we read describes no tracking of vendor end-of-support dates.
Who it’s for: A founder or engineering lead whose team does feature work first and finds out an upgrade is overdue only when a host, a customer or a scanner says so.
Usually starts when: A one-off upgrade has just been finished and you want to stay there, or a recent scare showed that nobody owned keeping versions current.
The result: Each month the runtime, framework and direct dependencies of one repository are checked against the vendors' published support dates. Patch and minor updates arrive as pull requests with the tests run, known advisories are fixed or explained, and you are told whenever a vendor's published end-of-support date comes within six months, with a quote for the matching one-off upgrade. A date already inside six months when the service starts, or published later than that, is reported in the first summary after we see it.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A target is agreed in writing before it starts, set to what a service at this stage can actually keep.
Hours are agreed in writing before the service starts. At launch the service is not staffed round the clock, so we do not offer round-the-clock cover.
What must remain true
- Every runtime, framework and direct dependency in the repository is on a version its vendor still supports, or has a dated plan that you have agreed to
- Patch and minor updates in the same major line are proposed every month with the tests run
- Every advisory reported for a dependency in use ends in a fix pull request or an explanation
What we watch
- The manifest and lockfile on your default branch, read through a read-only token you create
- Each vendor's own published support dates for the runtime and framework you run
- The advisory reports from your package manager for the dependencies in use
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A month starts. | We refresh the inventory, open the update pull requests and run the tests on each. |
| A vendor's published end-of-support date for your runtime or framework is within six months. | We tell you in the monthly summary and in a separate note, with the date and its source, and offer a quote for the matching one-off upgrade. |
| Your package manager reports a new advisory for a dependency in use. | We open a fix pull request, or explain why no fix exists and what the options are. |
| A month ends. | We send the written summary: versions, support dates, pull requests and what remains. |
We do on our own
- Read the manifest, lockfile and vendor support pages
- Run the tests on a branch
- Open pull requests for patch and minor updates in the same major line
We ask you first
- Merging, or any change to your default branch
- Any change of a major version or of the runtime
- Removing or replacing a dependency
- Anything that changes secrets, hosting, runners or billing
We escalate to you when
- An advisory has no fix and the dependency has no maintained alternative
- An update breaks the tests and the cause is not in the update
- A vendor's end-of-support date falls within six months
- A dependency has no release for a runtime that you must move to
How you know it held. Each month you get the versions, the support dates with source links, the pull requests and what remains. A passing test run on the branch is the evidence for each update.
How we keep it true
This service is never finished. Each month's summary shows what stayed supported and what is coming, and it continues until you end it.
Get a tested, ranked upgrade plan for one app's runtime and dependencies Job Each time it fires
One repository: every runtime, framework and direct dependency checked against the vendor's published support dates, the existing tests run as a baseline, and a ranked upgrade path.
Offered when the repository has never had an inventory, or the stack has changed.
Move one Node.js 18, 20 or 22 app to Node 24 LTS with builds and tests passing Job Each time it fires
Run one Node.js app on Node 24 LTS: clean install from the lockfile, native modules rebuilt or replaced, the test suite and the container or CI configuration all on 24, checked on a copy.
Quoted when the Node.js line you run nears its published end of support.
Move one Python 3.9 or 3.10 app to Python 3.13 with removed modules and wheels sorted Job Each time it fires
Run one Python 3.9 or 3.10 application on Python 3.13: dependencies installed from a clean environment, removed standard-library modules replaced, and the tests and named flows passing on a copy.
Quoted when the Python version you run nears its published end of support.
Move one Rails 7.0–7.2 app to Rails 8.1 with its key flows tested Job Each time it fires
Take one Rails 7.0, 7.1 or 7.2 app to Rails 8.1 one minor version at a time, on the Ruby each step supports. Tests and five named business flows pass on a staging copy before your release.
Quoted when the Rails series you run nears its published end of support.
What is included, and what is not
- Update pull requests with passing test runs
- An explanation for each advisory that cannot be fixed by an update
- A written monthly summary of versions, support dates, pull requests and what remains
Included
- One repository with one application, one language runtime and one lockfile, with up to 150 direct dependencies
- A monthly check of the runtime, framework and direct dependencies against each vendor's published support dates, each with a source link and the day we checked it
- Pull requests for patch and minor updates within the same major version line, up to six a month, each with the repository's tests run on the branch
- Triage of the advisories your package manager reports for dependencies in use: a fix pull request, or an explanation when there is no fix. A fix that needs a major version is quoted as a one-off upgrade, or as the one-off job that clears dependency vulnerability findings in one repository
- A written monthly summary, and a quote for the matching one-off upgrade when a published end-of-support date is within six months
Not included
- Merging to your default branch, which stays with your team
- Major version upgrades or runtime changes, which are separate one-off jobs, quoted when needed
- Security audits, compliance reviews or any promise that every advisory has a fix
- Changing secrets, hosting, runners or billing
- Out-of-hours cover or any guaranteed response time
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each month's summary lists the runtime, framework and every direct dependency with its current version, newest same-major version and the vendor's support status with a source link and the day it was checked.
Evidence: The written monthly summary, which you can compare with the manifest and the vendor pages.
Each update pull request shows a passing test run on its branch and changes no major version and no runtime version.
Evidence: Links to the passing runs and the pull request diffs.
Every advisory your package manager reports for a dependency in use at month end is fixed in an open or merged pull request or explained with the reason no fix applies, including that the fix needs a major version and is quoted separately.
Evidence: The advisory list in the monthly summary with one outcome per line.
Whenever a vendor's published end-of-support date for your runtime or framework is within six months, the month's summary names the date and source and includes a quote for the matching one-off job.
Evidence: The summary section on upcoming support dates.
Sign-off. You review and merge each pull request, and you read each monthly summary. An update counts as delivered when you accept it.
If it fails. If we cannot update something safely, we say so, explain what we found and what it would take, and it does not count against the monthly limit. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- The stack is Node.js, Ruby, Python or PHP with a lockfile in the repository
- Tests run on the branch in CI or on a copy without production data
- You can give us a read-only token for the repository and a fork or branch from which we can open pull requests
- A person on your side reviews and merges the pull requests
We stop and tell you if
- There are no tests and no agreed manual checks, so an update cannot be shown to work
- Most updates are blocked by pinned private packages or vendored code we cannot change
- The repository holds several applications or more than 150 direct dependencies, so we agree a different scope
- Updates would need production secrets or production data to test
What could go wrong
Every update is a pull request that your team merges, so you can revert it as you would any other change. Ending the service leaves your repository as it is, with our open pull requests finished or handed back.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| An update passes the tests but changes behaviour the tests do not cover. | Each pull request states what changed and what was not tested, you review and merge it, and risky updates are split out as a one-off job. |
| A vendor changes a published support date after we record it. | Every date carries its source and the day we checked it, and we re-check each month. |
| A read-only token or fork gives us more access than you intended. | We ask only for read access to the repository and a fork or branch. You create and can revoke both at any time. |
Each pull request is checked by a reviewer separate from the work that produced it before it is opened, and a second person checks the support dates in each summary against the vendors' pages. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- You review and merge every pull request
- You approve any major version or runtime change
Access we would need
- A read-only token for the repository
- Access to a fork or branch for pull requests
Questions
How is this different from Dependabot?
Dependabot opens pull requests for newer versions; GitHub's documentation says you confirm the tests pass and you merge. This service also records vendor support dates each month, triages advisories and tells you when a published end-of-support date comes within six months, which that documentation page does not describe.
Do you do major upgrades?
Not inside the monthly price. A major version or runtime change is a separate one-off job with its own price and acceptance checks, quoted when a support date makes it due. The same goes for an advisory whose fix needs a major version: it is quoted as a one-off upgrade, or as the one-off job that clears dependency vulnerability findings.
Do you guarantee my dependencies are secure?
No. We act on the advisories your package manager reports and say plainly when none has a fix. This is not a security audit or a compliance service.
Do you need to merge to our default branch?
No. We only open pull requests. Merging stays with your team.
Send an enquiry
Send us
- The repository link or the manifest and lockfile names, and the language and framework
- The runtime version in production and where it is set
- How tests run and how long they take
- Who reviews and merges pull requests
Later, once you agree
- A read-only token or app installation limited to the repository, created by you
- A fork or branch from which we can open pull requests
- How to run the tests, and the severity of advisory you want treated as urgent
- The runtime version your host actually runs, taken from the host's settings
Your repository, secrets and hosting stay yours. We read through a token you create and change files only on a branch or fork, through pull requests your team reviews and merges. We never ask for passwords in the first enquiry.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “upgrade-keep-runtime-and-dependencies-supported” as the subject.