PXLPOD Media LLC · Cashflow HUD
Software Lifecycle and End-of-Life Policy
- Version
- 1.0
- Effective
- 13 September 2026
- Review
- Quarterly, with the access review
- Owner
- Christopher Foley
1.Purpose
Software stops receiving security fixes long before it stops working. The risk is therefore invisible by default: an end-of-life runtime behaves exactly as it did the day before support ended. This policy states how unsupported software is found and replaced before that gap is exploited.
2.What is tracked
| Layer | Component | How support status is known |
|---|---|---|
| Runtime | Node.js, Next.js, React | Vendor release schedules; major versions tracked deliberately |
| Database | PostgreSQL, managed by the database platform | Platform upgrade notices; platform performs the upgrade |
| Hosting | Serverless runtime images | Platform-managed; deprecation notices in the dashboard |
| Dependencies | npm packages, direct and transitive | Automated dependency alerts on the repository |
| Workstation | macOS and installed tooling | Vendor update channel, automatic updates enabled |
| Third-party APIs | Payment processor, CRM, bank connectivity | Vendor API version deprecation notices |
| WordPress estate | Core, themes and plugins at pxlpod.co | Patchstack via WP Umbrella — continuous monitoring, including components that become unmaintained |
3.How end-of-life software is detected
- Automated dependency alerting is enabled on the repository, with automated security patch pull requests. This is the primary detection mechanism for the layer that changes most often.
- The production build runs on every push and type-checks both the application and its scripts. A dependency that has broken compatibility fails the build rather than reaching production.
- Platform notices from the hosting and database providers are read when received. Both perform their own upgrades of the layers they manage.
- Patchstack, via WP Umbrella, monitors the WordPress estate continuously. An abandoned plugin or theme is an end-of-life component in the layer where abandonment is most common, and is reported there before it is reported anywhere else.
- A quarterly review, conducted alongside the access review, checks each component in §2 against its vendor’s current support status.
4.Response
| Situation | Action | Window |
|---|---|---|
| A component has a published end-of-life date in the future | Schedule the upgrade before that date | Before end of support |
| A component is already unsupported | Upgrade, or replace if no upgrade path exists | 90 days |
| An unsupported component has a known exploited vulnerability | Treat as Critical | See the Vulnerability Remediation SLA |
| A dependency is unmaintained but has no known vulnerability | Replace at the next convenient change, or remove | Next quarterly review |
5.Pinned versions
Some versions are pinned deliberately and must not drift. The payment processor’s API version is pinned in code, because response shapes change between versions and an unpinned client would silently change the meaning of the ledger on the vendor’s release schedule rather than ours.
A pinned version is not exempt from this policy. It is reviewed on the same quarterly cycle, and moving it is a deliberate change accompanied by re-running the projection fixtures.
6.Reducing the surface
The cheapest way to manage an end-of-life component is not to have it. Dependencies are added reluctantly and removed when the need passes. Functionality available from an already-trusted platform is preferred over a new package.
7.Record
Upgrades, replacements and removals are recorded in the repository history, which is the authoritative log of what changed and when. The quarterly review is recorded even when it finds nothing.
Questions about this policy: chris@pxlpod.co