Skip to main content

Release and upgrade model

This page explains how Stack9 platform releases reach existing instances, what is committed around them, and how they are applied without taking the service down. For the hands-on steps of upgrading an instance repository, see Upgrading a Stack9 instance.

What problem the model solves​

Long-lived enterprise systems tend to go through periodic "rip and replace" re-platforming. The most common cause is the glue code and sync logic that accumulates between separately sourced products, until an upgrade to one breaks the others. Stack9 is designed to avoid that cycle:

  • One shared data and permission model. Stack9 Core and Stack9 Experience share one data model, so new capability extends the model rather than adding a system that must be integrated.
  • Layered images. Each client's instance is a dedicated Docker image layered over the standard Stack9 Core base image, so a base-image release applies without being blocked by, or breaking, the client's customisations.
  • A guaranteed upgrade path. Providing a path for major version upgrades without forcing a costly rebuild is a core platform commitment. April9 considers forced re-implementation on major upgrades poor practice and designs against it.

How it works​

Base image and instance image​

April9 manages the rebuild and deployment of both the Core base image and each client's instance image. Clients are not required to perform or manage upgrades themselves. Under the Managed Service Agreement (MSA), Core instances receive regular security updates delivered without breaking changes.

On the developer side, an instance repository picks up a new core version and the current dev tooling with stack9 stack up, which syncs canonical files from the instance template and bumps the @april9au/stack9-* package pins. See Upgrading a Stack9 instance.

Versions, LTS and the annual uplift​

  • Clients may stay on a Long-Term Support (LTS) version for as long as that version's underlying dependencies continue to receive security patches.
  • An annual framework uplift is recommended and included in the MSA, to keep instances current.
  • All version rollouts are managed through April9's Request for Change (RFC) process: controlled, tested and scheduled.

Release commitments​

CommitmentDetail
Future releases at no additional costDuring the maintenance or subscription term, a release is an update to the existing instance, not a separately billed re-implementation
Available at general distributionThe client receives a release when it is generally released. Adoption into the live instance is then scheduled through the RFC process, keeping availability and go-live timing distinct
Applies to customised componentsClient configuration sits in its own image layer, so a base-image release applies without being blocked by, or breaking, customised components
DocumentedEach release ships with documentation of the changes and amendments to existing documentation, in electronic format
Tested firstEvery platform upgrade is tested in non-production before it reaches production

Notice periods​

ChangeNotice
Upgrades, principally the annual framework uplift60 business days
Planned outages (scheduled maintenance, upgrades and patches)15 days
Where disruption is unavoidable7 days, in addition to the 15-day notice
Routine security patchesDelivered continuously, without breaking changes, and notified under the planned-outage rules

Applying a release without downtime​

No disruption is the norm, at both the application and the database layer:

  • ECS container hot-swap. The new version starts alongside the running one, and traffic cuts over once it is healthy.
  • Automated schema migrations. When the new container starts, its bootstrap applies the framework's and the instance's migrations and synchronises the schema with the instance's entity definitions, without manual intervention or a scheduled outage. The new schema and the application version that depends on it come into service together.
  • Automatic TLS renewal ahead of certificate expiry.

Because releases are engineered not to consume the availability budget, the 99.90% availability commitment is not spent on routine maintenance.

Writing migration-safe changes

The bootstrap re-runs on every container start and must stay safe against a partially completed earlier run. When you add migrations or change entity definitions, make them idempotent (for example, guard column additions) so a restart mid-rollout cannot leave the instance unable to boot.

How new capability reaches existing instances​

The roadmap runs on two tracks:

  1. The published product roadmap, funded by a dedicated innovation budget independent of any single client engagement.
  2. Client-driven modules. When a project needs new capability, April9 often builds it as a proper platform module. Because every client runs on the same codebase, that module becomes optionally available to other instances.

Both reach existing instances through the same managed upgrade path (LTS versioning plus RFC-based change management) as an update to the current instance, not a separate re-implementation.

Under an Enterprise licence, every capability April9 makes generally available is included at no additional licence cost. The effort to implement, configure, integrate or change-manage a new capability into a client's solution is quoted separately, and bespoke work built for another client is not automatically extended.

Limits​

  • LTS is bounded. It lasts only while the version's underlying dependencies still receive security patches.
  • The annual uplift is recommended, not forced. A client who declines it indefinitely will eventually reach that dependency boundary.
  • New modules are optional. A module built for one client is not a commitment to support every client's variant of it.
  • "No additional cost" applies to the licence, not to implementation effort.
  • Zero-downtime release is the norm, not an absolute. Where a change genuinely cannot be delivered without disruption, it is scheduled and notified (7 days) rather than performed silently.