End-of-Life Software Monitoring Policy

1. Purpose

This policy describes how Vizno tracks vendor end-of-support ("EOL") dates for the software components that run the platform and the process for upgrading those components before EOL. The intent is to ensure that no component in the production stack is running on a version that no longer receives security patches from its upstream maintainer.

2. Scope

This policy applies to all software components in the Vizno production stack:

• The language runtime (Node.js).
• The database engine (PostgreSQL).
• The application framework (Next.js).
• Container base images (Debian / Alpine, as used by Coolify-managed services).
• Operating system images on Hetzner dedicated hosts.
• Application-level dependencies tracked in package.json / package-lock.json.

3. Inventory and tracked dates

Vizno maintains the following inventory of EOL-relevant components and tracks each against the upstream project's published end-of-support date.

Component	Current version	Upstream EOL date	Source
Node.js (LTS)	24.x	2028-04	nodejs.org/en/about/previous-releases
PostgreSQL	17.x	2029-11-08	postgresql.org/support/versioning
Next.js	16.x	Rolling; previous-major support window per nextjs.org	nextjs.org
Debian (container base)	12 "bookworm"	2028-06 (LTS)	wiki.debian.org/LTS
Alpine (container base)	3.x	~24 months per release	alpinelinux.org/releases

The version numbers above are reviewed and updated whenever a component is upgraded. The inventory itself lives in this document and in the project's package.json, Dockerfiles, and database deployment configuration.

4. Continuous dependency monitoring

Application-level dependencies in package.json are continuously monitored by GitHub Dependabot, which is enabled on the Vizno repository with both alerts and security updates active. Dependabot:

• Opens a pull request when a direct or transitive dependency has a known vulnerability.
• Opens an upgrade pull request on a configured cadence for outdated dependencies.
• Is reviewed weekly; security-flagged PRs are reviewed within 7 business days.

5. Upgrade cadence and triggers

Components are upgraded under any of the following triggers:

1. Approaching EOL. A component is scheduled for upgrade no later than 90 days before its upstream end-of-support date.
2. Security vulnerability. A component with a CVE rated High or Critical is upgraded out-of-band within 14 days of patch availability, or earlier if active exploitation is reported.
3. Vendor recommendation. Where the upstream project publishes a security advisory that recommends upgrading regardless of CVE severity.
4. Operational improvement. Routine upgrades to take advantage of performance or feature improvements, on a quarterly review cycle.

6. Upgrade procedure

For each upgrade:

1. The new version is tested locally and in the staging environment (staging.vizno.com, auto-deployed from main).
2. Application test suites are run against the new version.
3. The change is deployed to staging for at least 24 hours of live exercise.
4. Production promotion follows the standard promotion workflow (/admin/infra, fast-forwards the production branch to main).
5. The upgrade is recorded in this document's revision history.

7. Exceptions

Where a component cannot be upgraded before its EOL date (for example, because the next major version introduces a breaking change still under evaluation), a documented exception is recorded with:

• The component and version in question.
• The reason the upgrade is delayed.
• A target date for resolution.
• Any compensating controls applied in the interim.

The exception is reviewed monthly until resolved.

8. Policy review

This policy is reviewed at least annually by the founder and updated to reflect changes to the production stack or to the project's posture toward dependency monitoring. The component inventory in Section 3 is updated continuously as upgrades land.

9. Contact

Questions about this policy or the current state of the inventory: security@vizno.com.