Skip to content

v0.28.0

Choose a tag to compare

View all tags
@antybubbs antybubbs released this 02 Sep 14:37
· 13 commits to main since this release
Immutable release. Only release title and notes can be modified.
v0.28.0
0110786
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Kaya v0.28.0

Kaya v0.28.0 is a major reliability and platform release.

Since v0.27.4, a significant amount of work has gone into preparing Kaya for larger and more resilient deployments. This release introduces the move to PostgreSQL, strengthens High Availability and DHCP failover behaviour, expands Asset Manager, improves Remote Manager reliability, and includes a substantial amount of security, migration, deployment and operational hardening.

** Please follow the guide here for migrating from SQLite to PostgreSQL

Highlights

  • PostgreSQL is now the primary database platform.
  • Existing SQLite installations can be migrated to PostgreSQL using the supported upgrade workflow.
  • High Availability DHCP failover has been significantly hardened.
  • Asset Manager now supports equipment photography and automatic asset tags.
  • Remote Manager connection startup is more reliable.
  • Docker and upgrade Compose configurations have been simplified.
  • Development and release publishing workflows have been cleaned up and strengthened.
  • Numerous security, filesystem, migration and regression checks have been added.

PostgreSQL

PostgreSQL becomes the primary database

Kaya's production Docker deployment now uses PostgreSQL rather than SQLite.

This removes a number of limitations associated with SQLite under concurrent workloads and provides a stronger foundation for larger installations, background services and High Availability environments.

The standard Compose stack now includes:

  • Kaya
  • PostgreSQL
  • Secure Send gateway
  • Guacamole / guacd
  • Persistent application and database storage
  • Health checks
  • File-backed secrets

SQLite to PostgreSQL upgrade path

Existing Kaya installations are not expected to start from scratch.

v0.28.0 introduces a dedicated SQLite to PostgreSQL migration process designed to preserve existing application data while moving an installation onto the new database platform.

The migration tooling includes:

  • Preflight checks
  • Source database fingerprinting
  • Backup and recovery handling
  • Schema validation
  • Migration reporting
  • Foreign-key-aware table ordering
  • Sequence repair
  • Role and topology validation
  • Post-migration verification
  • Failure-safe handling when a conversion cannot be completed cleanly

A dedicated docker-compose.upgrade.yml workflow is provided for the migration process.

Complex foreign-key migration support

Kaya's schema contains relationships that cannot safely be migrated using simple alphabetical or table-by-table insertion.

The migration engine now builds a dependency graph from the reflected PostgreSQL schema and uses deterministic strongly connected component detection to handle cyclic relationships.

Where required, nullable foreign-key relationships are temporarily deferred during import and restored after the related records exist.

Rejected inserts now fail the migration rather than being silently retried into an uncertain database state.

High Availability

A significant amount of work in v0.28.0 has focused on making Kaya's HA behaviour safer and more deterministic.

DHCP failover fencing

Kaya now applies stronger fencing rules before allowing a node to provide DHCP service.

A node can no longer become DHCP-active simply because it briefly observes itself as the VIP owner.

Promotion repair now requires 10 seconds of continuous eligible VIP ownership before DHCP is enabled.

Kaya also persists vip_stable_since, allowing the HA subsystem to reason about whether ownership is genuinely stable rather than treating a single heartbeat observation as authoritative.

Protection against stale HA commands

Additional safeguards have been added around DHCP_PROMOTE and DHCP_DEMOTE.

A stale promotion is rejected when:

  • The local node is not ACTIVE
  • The node does not currently own the VIP

A stale demotion is rejected when:

  • The node still owns the current VIP
  • No authorised handover is taking place

If VIP ownership is lost while promotion is in progress, DHCP is disabled rather than being allowed to continue on a node that no longer owns the service address.

These changes reduce the risk of split-brain DHCP operation during transient HA transitions.

Existing HA protections retained

The new fencing work builds on, rather than replaces, Kaya's existing protections, including:

  • Generation checks
  • Signed agent communication
  • Lease validation
  • Runtime and DNS checks
  • Locking
  • Rollback handling
  • Alerting
  • Preferred-node semantics

Asset Manager

Asset Manager received a substantial set of improvements in v0.28.0.

Asset photographs

Assets can now have photographs associated with them, making it considerably easier to identify physical equipment.

Support includes:

  • Multiple photographs per asset
  • Image thumbnails
  • Larger image viewing
  • Improved photo layout within the asset page
  • Upload processing designed to avoid unnecessarily storing oversized source images

The information layout on the asset detail page has also been adjusted to accommodate the new photo area without changing Kaya's established branding or button design.

Improved asset photo layout

The image and information panels have been aligned more closely so the asset page feels like a single cohesive interface.

Photo areas no longer require an internal scroll simply to inspect their contents, and unwanted hover-border behaviour has been removed.

Automatic asset tags

Asset Manager now supports automatically generated asset tags.

Administrators can define a prefix, for example:

HAL

Kaya can then allocate sequential identifiers such as:

  • HAL0001
  • HAL0002
  • HAL0003

This provides a simple built-in asset numbering system without requiring organisations to manually assign every identifier.

Asset and IP association

Asset records can also be associated with their relevant network identity, making Asset Manager more useful for infrastructure equipment that also exists elsewhere within Kaya's network management data.

Filesystem hardening

The Asset Manager storage paths were reviewed as part of the v0.28.0 work.

Photo, thumbnail, attachment and deletion operations now resolve storage locations through validated asset records rather than constructing filesystem paths directly from request-derived identifiers.

The review covered:

  • Asset directory resolution
  • Photo reads
  • Thumbnail reads
  • Photo deletion
  • Attachment reads
  • Attachment deletion
  • Upload writes
  • Upload cleanup
  • Generated filenames
  • Original upload filenames
  • Whole-asset removal

Remote Manager

More reliable first connection

Remote Manager previously exhibited an issue where the first attempt to start a session could be refused, while immediately retrying with the same credentials succeeded.

The session startup sequence has been corrected so connection establishment is properly coordinated before the client attempts to use it.

This removes the common "first attempt fails, second attempt works" behaviour and makes Remote Manager feel considerably more predictable.

Deployment

Simplified Docker Compose configuration

The main Compose configuration has been cleaned up as part of the PostgreSQL transition.

The production stack is now focused on the services Kaya actually requires at runtime, while database conversion is kept in the dedicated upgrade workflow.

Temporary migration and development artefacts have also been explicitly excluded through additional .gitignore rules.

Cleaner repository structure

A wider repository clean-up accompanied the release work.

This included reviewing obsolete or temporary migration artefacts, test harness output, local database files and generated reports so they do not accidentally become part of normal source control.

Development and Release Workflow

The Docker publishing workflow has also been improved.

Development builds

Pushes to the dev branch now publish:

ghcr.io/antybubbs/kaya:dev
ghcr.io/antybubbs/kaya:dev-<short-sha>

Development builds:

  • Do not create GitHub Releases
  • Cannot publish or overwrite latest

This makes the distinction between development, release candidate and production images much clearer.

Release protection

RC and stable release behaviour remains separate from normal development publishing, helping prevent development builds from accidentally becoming production images.

Production Compose continues to default to the stable latest image unless another image is explicitly selected.

Reliability and Engineering

v0.28.0 contains a broad set of regression tests and safety checks covering areas touched by the release.

Particular attention has been given to:

  • Database migrations
  • PostgreSQL foreign-key integrity
  • HA transitions
  • DHCP ownership
  • Asset filesystem safety
  • Docker publishing
  • Upgrade recovery
  • Configuration validation

A number of changes were deliberately implemented as targeted fixes rather than broad rewrites so existing behaviour such as authentication, agent signing, rollback handling and established UI branding remained intact.

Security

Security-sensitive areas reviewed or hardened during this release include:

  • Asset filesystem path validation
  • HA command fencing
  • Signed agent flows
  • Database migration integrity
  • Upgrade failure handling
  • Docker publishing boundaries
  • Persistent secret handling

Migration and HA operations are designed to fail closed where Kaya cannot establish that continuing would be safe.

Upgrading from v0.27.4

v0.28.0 changes Kaya's primary database platform from SQLite to PostgreSQL. Existing installations should use the documented upgrade process rather than replacing their deployment configuration and starting Kaya directly against an empty PostgreSQL database.

Before upgrading:

  1. Back up your existing Kaya data and configuration.
  2. Pull the v0.28.0 image.
  3. Follow the SQLite to PostgreSQL migration procedure.
  4. Confirm that migration validation completes successfully.
  5. Start the normal PostgreSQL-backed Kaya stack.
  6. Verify your installation before removing any previous SQLite backups.

Existing SQLite databases should be retained until the PostgreSQL migration has been fully verified.

Container image

docker pull ghcr.io/antybubbs/kaya:v0.28.0

For normal production deployments:

docker pull ghcr.io/antybubbs/kaya:latest

Thank you

v0.28.0 represents a substantial amount of work below the surface of Kaya.

While there are visible additions such as Asset Manager photography and asset tagging, much of this release has been about making the platform safer to upgrade, more reliable under concurrent workloads, and better prepared for High Availability and larger self-hosted environments.

As always, issues and feedback are welcome through the Kaya GitHub repository.

Assets 3
Loading
0 Join discussion