v0.28.0-rc.1

Major Change: Upgrading Kaya from SQLite to dedicated PostgreSQL Container.

Kaya now uses PostgreSQL 16.14 as the supported production database.

Existing Kaya installations using SQLite can be migrated using the supplied upgrade Compose configuration. The migration preserves the original SQLite database and creates a verified backup before PostgreSQL is allowed to become authoritative.

Important: Plan a maintenance window before starting. Kaya will be unavailable during the one-time database migration.

Upgrading an Existing SQLite Installation to Kaya v0.28.0-rc.1

Kaya v0.28.0-rc.1 introduces a major database change:

Kaya now uses PostgreSQL 16.14 as the supported production database instead of SQLite.

These instructions are for existing Kaya installations that were deployed using Docker Compose and currently use SQLite.

Important

v0.28.0-rc.1 is a Release Candidate.

You must explicitly use:

ghcr.io/antybubbs/kaya:v0.28.0-rc.1

Do not use latest for this upgrade.

---

1. Go to your Kaya Docker Compose directory

Change into the directory containing your current Kaya docker-compose.yml.

For example:

cd /opt/kaya

Your actual path may be different.

---

2. Stop Kaya

Stop the existing installation cleanly:

docker compose down

Do not use

docker compose down -v

The -v option can remove Docker volumes and must not be used during this migration.

---

3. Back up your existing installation

Before changing anything, make a copy of your existing Kaya data directory:

cp -a ./data ./data.sqlite-before-v0.28.0-rc.1

If you use the default uploads directory, back that up as well:

cp -a ./uploads ./uploads.before-v0.28.0-rc.1

Keep these backups until you have confirmed that Kaya is running normally on PostgreSQL.

---

4. Replace your Docker Compose files with the v0.28.0-rc.1 versions

This release changes the Docker Compose stack because Kaya now includes a dedicated PostgreSQL container.

You must update your existing Compose files before running the migration.

Replace your current:

docker-compose.yml

with the docker-compose.yml supplied with v0.28.0-rc.1.

You will also need:

docker-compose.upgrade.yml

from the v0.28.0-rc.1 release.

Place both files in your Kaya installation directory.

Your directory should now contain at least:

docker-compose.yml
docker-compose.upgrade.yml
data/
uploads/

Do not delete your existing data directory.

That directory contains your SQLite database and other persistent Kaya data required for migration.

---

5. Make sure the RC image is used

The supplied Compose files default to the normal Kaya image unless KAYA_IMAGE is overridden.

For this Release Candidate, run all relevant commands with:

KAYA_IMAGE=ghcr.io/antybubbs/kaya:v0.28.0-rc.1

This ensures both Kaya and the migration service use the correct RC build.

---

6. Pull the v0.28.0-rc.1 image

Run:

KAYA_IMAGE=ghcr.io/antybubbs/kaya:v0.28.0-rc.1 docker compose pull

This will also pull the required PostgreSQL and supporting container images.

You can confirm the Kaya image with:

KAYA_IMAGE=ghcr.io/antybubbs/kaya:v0.28.0-rc.1 docker compose images

---

7. Run the one-time SQLite to PostgreSQL migration

Do not start Kaya normally yet.

Run:

KAYA_IMAGE=ghcr.io/antybubbs/kaya:v0.28.0-rc.1 \
docker compose \
  -f docker-compose.yml \
  -f docker-compose.upgrade.yml \
  run --rm sqlite-postgres-upgrade

This is the one-time migration process for existing SQLite installations.

During the migration, Kaya will:

1. Validate the existing SQLite database.
2. Check available storage.
3. Create or reuse a verified pre-migration backup.
4. Upgrade supported historical SQLite schemas where required.
5. Start and prepare PostgreSQL 16.14.
6. Copy the SQLite data into PostgreSQL.
7. Validate row counts.
8. Validate migrated data integrity.
9. Validate foreign-key relationships.
10. Repair PostgreSQL sequences where required.
11. Validate the final PostgreSQL database.
12. Mark PostgreSQL as authoritative only after successful validation.

Your existing SQLite database is retained.

Verified migration backups are stored under:

./data/backups/

---

8. Do not interrupt the migration

The migration may take several minutes or longer depending on:

• SQLite database size
• number of records
• storage performance
• available disk space
• server performance

Large installations can perform substantial disk I/O during:

• backup creation
• SQLite schema preparation
• PostgreSQL data copy
• integrity validation

Important

Do not stop the migration simply because there is a period with little console output.

Wait for the migration to complete successfully or return an explicit error.

---

9. Start Kaya on PostgreSQL

Once the migration completes successfully, start Kaya normally using the RC image:

KAYA_IMAGE=ghcr.io/antybubbs/kaya:v0.28.0-rc.1 docker compose up -d

Check the containers:

docker compose ps

You should now see services including:

kaya
postgres
kaya-secure-send
kaya-guacd

Kaya and PostgreSQL should become healthy.

---

10. Check startup logs

Run:

docker compose logs --tail=100 kaya

A successful migrated installation should show something similar to:

Kaya database ready: engine=postgresql revision=20260818_02 migration_required=False

The important values are:

engine=postgresql
migration_required=False

---

11. Verify your data

Log in to Kaya and confirm your existing data is present.

Check at least:

• users
• dashboard data
• network devices
• DNS history
• Remote Manager
• hardware assets
• audit logs
• notifications
• settings
• uploaded files

Open:

About Kaya

and confirm the database backend is:

PostgreSQL

---

12. Reverse proxy users

If Kaya is accessed through a reverse proxy such as:

• Nginx Proxy Manager
• Nginx
• Caddy
• Traefik
• HAProxy
• Cloudflare Tunnel

make sure the reverse proxy that connects directly to Kaya is trusted.

Kaya uses:

FORWARDED_ALLOW_IPS

for this.

If your Compose setup already defines environment variables, set it there.

For example:

environment:
  FORWARDED_ALLOW_IPS: 127.0.0.1,192.168.1.3

Replace:

192.168.1.3

with the actual IP address of your reverse proxy.

After changing the setting, recreate Kaya:

KAYA_IMAGE=ghcr.io/antybubbs/kaya:v0.28.0-rc.1 \
docker compose up -d --force-recreate kaya

Then go to:

Site Administration → Security

and check:

Request came through a trusted proxy
Yes

If it shows No, the trusted proxy configuration is not correct.

---

13. Restart Kaya once

After confirming the migration and your data, restart Kaya:

docker compose restart kaya

Then check:

docker compose logs --tail=100 kaya

Kaya should continue to report:

engine=postgresql
migration_required=False

It should not attempt another SQLite migration.

---

If the migration fails

Kaya's migration process is designed to fail safely.

If the migration fails:

Do not delete anything.

Preserve:

./data/kaya.db
./data/kaya.db-wal
./data/kaya.db-shm
./data/backups/
./data/kaya-database-upgrade.json
./data/kaya-database-upgrade-report.json

Also preserve the PostgreSQL Docker volume.

Do not:

delete kaya.db
delete kaya.db-wal
delete kaya.db-shm
delete the migration marker
manually delete PostgreSQL data
drop the PostgreSQL schema
run ad-hoc SQL migration commands
run docker compose down -v

Capture the logs:

docker compose logs > kaya-v0.28.0-rc.1.log

Also preserve the terminal output from the migration command.

---

After successful migration

Once the migration completes successfully:

PostgreSQL becomes Kaya's authoritative database.

The original SQLite database remains as a retained migration/recovery artifact but is no longer used for normal operation.

Do not restore the old SQLite database over a working PostgreSQL installation.

The SQLite to PostgreSQL migration is a one-time process.

Do not rerun:

KAYA_IMAGE=ghcr.io/antybubbs/kaya:v0.28.0-rc.1 \
docker compose \
  -f docker-compose.yml \
  -f docker-compose.upgrade.yml \
  run --rm sqlite-postgres-upgrade

after a successful migration.

---

Staying on v0.28.0-rc.1

While testing this Release Candidate, start Kaya with:

KAYA_IMAGE=ghcr.io/antybubbs/kaya:v0.28.0-rc.1 docker compose up -d

If you run:

docker compose up -d

without specifying KAYA_IMAGE, the Compose file may fall back to:

ghcr.io/antybubbs/kaya:latest

For the RC test, continue explicitly using:

ghcr.io/antybubbs/kaya:v0.28.0-rc.1

until you deliberately move to another release.

---

Quick upgrade reference

# Enter the existing Kaya directory
cd /path/to/kaya

# Stop Kaya
docker compose down

# Back up the existing SQLite installation
cp -a ./data ./data.sqlite-before-v0.28.0-rc.1
cp -a ./uploads ./uploads.before-v0.28.0-rc.1

# Replace docker-compose.yml with the v0.28.0-rc.1 version
# Add docker-compose.upgrade.yml from v0.28.0-rc.1

# Pull the RC image
KAYA_IMAGE=ghcr.io/antybubbs/kaya:v0.28.0-rc.1 docker compose pull
...

v0.27.4

Kaya v0.27.4 - Asset Manager Updates & Bug Fixes in Kaya Docker Agent/Compute Manager

This release introduces improvements to Asset Manager and resolves issues affecting Docker Agent workload monitoring, particularly for agent-managed Docker hosts.

Asset Manager

Automatic Asset Tags

Asset Manager can now automatically generate unique asset tags when new hardware assets are created.

Administrators can configure:

• Asset tag prefix, for example HAL
• Separator, for example -
• Number padding
• Starting sequence number
• Automatic tag generation
• Preview of the next generated asset tag

This makes it much easier to maintain a consistent asset identification scheme without manually assigning tag numbers.

For example:

XXX-0001
XXX-0002
XXX-0003

Asset tag configuration is managed through Kaya Settings and changes are recorded in the audit log.

Docker Agent & Compute Manager

Workload CPU and Memory Metrics

Fixed an issue where Docker Agent hosts were successfully checking into Kaya, but individual containers continued to display - for CPU and memory usage.

Protocol v2 agent check-ins now correctly process and store workload metrics including:

• CPU utilisation
• Memory usage
• Memory capacity
• Storage usage
• Storage capacity
• Uptime
• Workload tags
• Host/node information

This particularly affected Docker Agent deployments on ARM64 systems such as Raspberry Pi hosts.

Workload Metric History

Docker Agent workload metrics are now recorded using Kaya's normal Compute Manager metrics pipeline.

This brings agent-managed workloads in line with directly monitored workloads and allows Kaya to retain workload metric samples for historical monitoring.

Metric sampling and retention continue to use Kaya's existing monitoring behaviour.

Docker Agent Display Fixes

Additional fixes have been made to the Docker Agent integration to ensure workload information reported by the agent is displayed correctly within Compute Manager.

Reliability Improvements

• Improved validation of workload metrics received from Docker Agents.
• Valid zero-value metrics are now correctly preserved rather than being treated as missing data.
• Missing workload metrics remain clearly represented as unavailable.
• Stale workload handling now follows the standard Compute Manager behaviour.
• Updated the bundled Kaya Docker Agent version to include the corresponding display and reporting fixes.
• Various small UI adjustments.

v0.27.3

Quick release to fix migration issue.

v0.27.1

Small UI bug fix in notifications module

v0.27.0

Kaya v0.27.0 - Security & Reliability updates.

Kaya v0.27.0 is mainly a security and reliability release following a review of several sensitive areas of the application.

What’s changed

RDP certificate trust

RDP connections now use strict certificate validation by default.

Hosts using self-signed or privately issued certificates must be explicitly trusted by an administrator using the certificate’s SHA-256 fingerprint.

If a trusted host later presents a different certificate, Kaya blocks the connection until the new certificate has been reviewed and approved.

Certificate bypass and trust-on-first-use remain disabled.

OIDC account linking

Administrator OIDC linking has been strengthened with:

• Recipient-bound invitations
• Expiring and revocable links
• Fresh authentication checks
• One-time invitation use
• Additional protection against account takeover

Existing unused administrator-link invitations should be cancelled and recreated after upgrading.

Backup Agent protocol v2

The Kaya Docker Agent now uses a new authentication and encryption protocol.

Protocol v2 introduces:

• Agent-owned signing and encryption keys
• Signed, replay-resistant requests
• One-time bootstrap tokens
• Encrypted job dispatches
• Agent key rotation and revocation
• Removal of bearer-token secret delivery

Kaya Docker Agent v0.2.1 or later is required.

The agent state directory must be persistent and must not be copied between hosts.

Public demo removed

The shared public demo and all demo-mode application behaviour have been retired.

This removes the demo deployment, reset scripts, seeded demo data and demo-specific security controls.

Table exports

Supported Kaya tables can now be exported as:

• CSV
• Plain text

The export control sits beside Table Settings and works across the shared table interface.

Mobile sizing and dark-mode visibility have also been improved.

Database migration improvements

Further work has been completed on Kaya’s automatic database upgrade process.

Kaya now provides:

• Better compatibility with older databases
• More detailed schema validation
• Automatic pre-migration backups
• Clearer migration logging
• Safer failure handling
• Additional migration test coverage

Database migrations still run automatically during startup.

Interface improvements

This release also includes:

• A more compact Remote Manager host list
• Improved RDP certificate information
• Better mobile toolbar behaviour
• Table and dropdown fixes in light and dark mode
• Layout fixes across several Kaya modules
• Removal of obsolete DNS Manager interface elements

Dependency update

The Python cryptography package has been updated to address CVE-2026-69247.

Before upgrading

Back up the complete Kaya installation, including:

data/
uploads/
data/remote-recordings/
docker-compose.yml
.env

Make sure you preserve:

data/kaya.db
data/.runtime.env

The original ENCRYPTION_KEY is required to recover encrypted credentials, Push configuration and Backup Agent signing keys.

Upgrade

From the Kaya installation directory:

docker compose down
docker compose pull
docker compose up -d

Follow the startup logs:

docker compose logs -f kaya

During the first startup, Kaya will:

1. Validate the existing database.
2. Create a verified backup.
3. Apply compatibility updates.
4. Run Alembic migrations.
5. Validate the upgraded database.
6. Start the application.

Do not interrupt Kaya while the migration is running.

After upgrading

Confirm that:

• Kaya reports healthy.
• Users and module permissions remain present.
• Notifications are running.
• IP/WAN monitoring is active.
• Pi-hole HA status is correct.
• SSH connections still work.
• RDP hosts connect or request certificate approval.
• Backup Manager hosts remain available.

Check the current migration revision with:

docker compose exec kaya \
  alembic -c /app/alembic.ini current

RDP hosts

Self-signed RDP hosts may need to be trusted after the upgrade.

Open the host in Remote Manager, retrieve its presented certificate, verify the SHA-256 fingerprint and explicitly trust it.

Do not restore connectivity by disabling certificate validation.

Backup Agents

Upgrade agents to Kaya Docker Agent v0.2.1 or later.

For each agent:

1. Generate a one-time bootstrap token in Kaya.
2. Set KAYA_AGENT_BOOTSTRAP_TOKEN.
3. Mount a persistent state directory at /var/lib/kaya-agent.
4. Start the agent and confirm enrolment.
5. Remove the bootstrap token.
6. Restart the agent.

Example:

environment:
  KAYA_AGENT_BOOTSTRAP_TOKEN: "<one-time-token>"

volumes:
  - ./agent-state:/var/lib/kaya-agent

Never reuse the same agent state directory across multiple hosts.

Known limitations

The following areas remain open for further work:

• Encrypted RDP connection data is still present in WebSocket query data.
• Some Pi-hole HA transitions may hold a coordination lock during hold-down.
• Some background workers still require further supervision.
• Multiple Kaya application replicas must not share one SQLite database.

Remote Manager should remain restricted to trusted users and networks.

Rollback warning

Downgrading below the v0.27.0 security migrations is not supported.

Do not run an older Kaya image against a database upgraded to v0.27.0.

Where recovery is required, preserve the upgraded database and roll forward to a corrected or later build.

Full Changelog: v0.26.2...v0.27.0

v0.26.2

Emergency Release to mitigate CVE-2026-69247

What's Changed

• Bumped cryptography from v49 - v50 to mitigate CVE-2026-69247 by @antybubbs in #57

Full Changelog: v0.26.0...v0.26.1

v0.26.0

Kaya v0.26.0 Release Notes

Kaya v0.26.0 introduces the Notification Centre, optional PWA Web Push, durable background delivery, more resilient IP/WAN monitoring, quieter Pi-hole HA recovery reporting, and automatic versioned database migrations.

Notification Centre

• A new notification inbox provides retained, per-user operational history with unread counts, dismissal, filtering, and links back to the affected Kaya module.
• Users can manage notification preferences and registered Push devices from their profile. Administrators can control framework-wide channels, retention, event-category policy, cooldowns, and whether users may customise their own preferences.
• In-application notifications are enabled by default. Push and email remain disabled until an administrator enables and configures them.
• Initial production publishers cover IP/WAN host outage and recovery, failed Kaya-managed backup jobs, notification worker failures, and Pi-hole HA node, cluster, sync, failover, and failback events.
• Recipient selection respects active accounts and module allocation. Active administrators receive infrastructure-wide events, while resource-specific access remains enforced by the destination route.
• Duplicate polling and repeated reconciliation do not create notification storms. Active conditions retain one incident identity and recovery resolves the matching condition.

PWA Web Push

• Administrators can generate, rotate, enable, disable, test, and delete VAPID keys from Site Administration → Notifications.
• Kaya validates generated key pairs with the production Web Push library and encrypts UI-managed private keys using the installation ENCRYPTION_KEY.
• Deployments may instead provide VAPID_PUBLIC_KEY, VAPID_PRIVATE_KEY, and VAPID_SUBJECT. Deployment-managed values take precedence and incomplete or invalid configuration fails closed.
• Push permission is requested only after a user explicitly enables it for the current device. Kaya includes guidance for installing the PWA and enabling Push on supported iPhone and iPad versions.
• Signing out revokes that account's device subscriptions. Disabling a user also revokes their active subscriptions; rotating or deleting keys revokes subscriptions tied to the old key.
• Push delivery validates approved HTTPS browser-push endpoints, public DNS resolution, redirects, payload routes, and response limits. Subscription endpoints and key material are never returned in normal device APIs or diagnostic output.

Durable delivery and diagnostics

• Operational state changes and their notification outbox work are committed together. Browser sessions, open pages, and provider availability are no longer required for event creation.
• In-app history is created before optional Push or email delivery. Provider failures cannot remove history or roll back a completed monitoring, backup, or HA action.
• Delivery uses bounded retries and explicit states for queued work, provider acceptance, temporary failure, expired subscriptions, cancellation, and retry exhaustion.
• Dedicated outbox, delivery, and reconciliation workers expose heartbeats, restart counts, queue age, retry state, and quarantined work in the administrator Delivery Health view.
• A failed reconciliation item is isolated from other monitored resources, retried with backoff, and quarantined for administrator review rather than silently dropped.
• Administrator diagnostics exercise the same durable pipeline as production events and report safe stage counts and correlation references without exposing addresses, subscription endpoints, keys, or provider payloads.

IP/WAN Monitor

• Monitor ordering now persists per user across the dashboard and authenticated Wallboard. Reordering either view updates one shared preference; new monitors append automatically and deleted monitors are ignored.
• Reset layout restores canonical monitor ordering without changing unrelated Wallboard display settings.
• Saved monitor-order input is type-checked, size-limited, restricted to existing monitor IDs, and committed transactionally.
• Every changed derived state now has a retained transition linked to the observation that caused it. Scheduled checks and Check now use the same transition and notification path.
• Offline incidents and their notification outbox entries commit atomically. Startup and periodic reconciliation restore only genuinely missing active incidents and resolve stale ones without duplicating history.
• The monitoring scheduler is supervised by an independent watchdog. Unexpected task exit or stale heartbeat is diagnosed, reported, and restarted without cancelling the rest of the scheduler.
• Administrator-only, non-cacheable scheduler diagnostics expose safe liveness information such as task state, heartbeat, pending count, observations, and restart state.

Pi-hole High Availability

• Pi-hole HA now publishes central notifications for cluster degradation and recovery, node unreachability, automatic-sync failure, controlled failover/failback lifecycle stages, and verified automatic failover completion.
• Notification persistence and provider delivery are isolated from service movement: notification failure cannot reverse a verified failover or failback.
• Failover history includes redacted per-channel delivery counts for diagnosis without storing subscription endpoints or provider responses.
• Routine configuration comparisons no longer invalidate the last successful current-generation sync. A healthy standby remains STANDBY_READY through PENDING, RUNNING, and IN_SYNC background checks.
• Starting a routine sync does not reset the recovery stability timer or create repeated recovery synchronising, verifying, and standby-ready Activity events.
• Supported configuration drift still invalidates readiness when it is actually observed. After guarded synchronisation and stability verification, the node returns once to STANDBY_READY.
• Active synchronisation and verification windows are no longer shown as a red Recovery state appears stale warning while recent progress is present. The warning remains available after five minutes without meaningful progress.

Versioned database migrations

Kaya now uses Alembic for versioned database migrations. Existing SQLite installations are not recreated and should not require users to rebuild their database.

On the first upgrade, Kaya validates the database, creates a verified timestamped backup under /app/data/backups, runs the retained historical compatibility path where required, validates the resulting schema, and records the baseline revision. Migration runs before user traffic and background services start.

Pre-Alembic upgrades use targeted schema validation and a verified SQLite API backup. A slow PRAGMA quick_check no longer blocks routine startup or masquerades as corruption; strict quick-check diagnostics remain available from the database CLI. If backup, compatibility, or migration validation fails, Kaya aborts startup and reports the recovery location in its logs.

Docker now allows a 120-second startup grace period before health-check failures count, while genuine startup failures still become unhealthy. Administrators can inspect the current revision with alembic -c /app/alembic.ini current inside the container. See Administrator Database Upgrades for recovery guidance.

Interface and documentation

• Values calculated in powers of 1,024 are now labelled KiB, MiB, GiB, and TiB.
• The README now provides a fuller capability guide across Kaya's dashboard, infrastructure, networking, security, documentation, remote access, administration, and deployment features.
• New notification documentation covers setup, user enablement, Web Push, privacy, retention, backup and restore, delivery semantics, diagnostics, and troubleshooting.

Upgrade notes

• Pull and start the new Kaya image normally. Required database backup and migration work runs automatically; routine upgrades require no manual Alembic commands.
• Preserve /app/data and review available disk space before upgrading. Migration backups and notification records may contain sensitive application data and must remain protected.
• Preserve the original ENCRYPTION_KEY separately from database backups. UI-managed VAPID private keys and Push subscriptions cannot be recovered from a restored database without it.
• Web Push requires a secure HTTPS browser context, except for browser-supported localhost development. Reverse proxies must forward the real scheme through Kaya's trusted-proxy configuration.
• All three deployment-managed VAPID values must be supplied together and valid. Correct or remove an incomplete set before starting Kaya.
• Kaya supports one application process per SQLite database. Multiple application replicas sharing one SQLite file remain unsupported.
• Existing notification preferences, Push configuration, subscriptions, history, and monitor ordering are preserved when their corresponding channel or view is disabled.

Security and privacy

• Notification APIs enforce authentication, active-session checks, role or module access, CSRF protection for browser mutations, object-scoped reads, and bounded input validation.
• Sensitive Vault and Secure Send event families use generic safe notification text because Push content may appear on a locked device. A notification never grants access to its destination.
• VAPID private keys and Push subscriptions are encrypted at rest. Secrets, endpoints, provider response bodies, and sensitive payload fields are excluded from logs, audits, diagnostics, and operation history.
• Push endpoint validation constrains outbound requests to supported browser providers over HTTPS port 443, rejects private or non-public resolution, and refuses redirects.
• Background worker and operational-event fa...

v0.25.8

Fixed

• Corrected disabled-module dashboard coverage and Backup Manager permission-test setup, and repaired shared Wallboard redirect and cookie paths to use the validated public route token.

Security

• Upgraded cryptography from 48.0.1 to 49.0.0. Kaya does not use the raw "ChaCha20" API affected by the release's nonce/counter compatibility change; its direct cryptographic integrations continue to use Fernet, AES-GCM, Scrypt/HKDF, Ed25519, and RSA without changing stored ciphertext or key formats. The upstream platform changes remove 32-bit Windows and Intel macOS wheels; Kaya's supported Python 3.12 Linux container remains supported.
• Remediated CVE-2026-48710 by pinning Starlette 1.3.1. This release contains the upstream malformed Host header fix introduced in Starlette 1.0.1 and later fixes for StaticFiles path validation, URL authority parsing, and form parser resource limits.
• Added the stable HTTPX2 test-client dependency required by Starlette 1.3.1. FastAPI remains at 0.136.3 because its published dependency metadata officially supports Starlette 1.3.1 (starlette>=0.46.0); Kaya's existing Pydantic Settings 2.14.2, HTTPX 0.28.1, and Uvicorn 0.34.0 pins remain within their declared compatibility constraints.
• Added direct and trusted-reverse-proxy regression coverage for authentication, authorisation, module access, CSRF, redirects, WebSockets, static files, file uploads, and malformed or manipulated Host headers.

Full Changelog: v0.25.7...v0.25.8

v0.25.7

New Kaya Release - IP/WAN Monitor, Backup Manager and High Availability changes

This release delivers a major redesign of the IP/WAN Monitor, including state-aware monitoring, detailed performance history, live graphs, per-host thresholds, and a secured operations Wallboard.

It also improves module administration, Proxmox backup monitoring, High Availability checks, navigation consistency, documentation, and test coverage.

Highlights

IP/WAN Monitor redesign

• Added explicit Healthy, Warning, Critical, Offline, Recovering, Maintenance, Paused, and Unknown states.
• Separated responding Critical hosts from genuinely Offline hosts.
• Added configurable confirmation counts for degradation, failure, and recovery.
• Added state explanations and state-transition timestamps.
• Added per-host thresholds with support for inheriting Site Administration defaults.
• Added maintenance handling that continues recording observations while suppressing new incidents.
• Improved incident evidence, recovery tracking, and retained event history.
• Preserved sub-millisecond latency values instead of displaying them as zero.
• Added unmistakable full-card Offline styling in dark and light themes.

Live monitoring dashboard

• Replaced static card graphs with rolling five-minute Apache ECharts graphs.
• Graphs now use stored backend observations instead of launching browser-side probes.
• Added live dashboard check-rate controls:
  • Live
  • Every 5 seconds
  • Every 10 seconds
  • Every 60 seconds
• Dashboard rates temporarily override saved monitor intervals while an authorised dashboard is active.
• The fastest active dashboard rate wins when multiple dashboards are open.
• Saved per-monitor intervals resume automatically after dashboard leases expire.
• Improved graph resizing, browser zoom handling, clipping, theme changes, and reduced-motion support.
• Added clearer summary statistics for Healthy, Warning, Critical, Offline, Paused, availability, latency, incidents, and checks per minute.

Performance history

• Added selected-period performance views for:
  • 1 hour
  • 6 hours
  • 24 hours
  • 7 days
  • 30 days
  • 90 days
  • 1 year
  • Custom date and time ranges
• Added latency minimum, average, maximum, jitter, packet loss, availability, and health-state history.
• Added interactive crosshairs, inspection tooltips, zooming, panning, and reset controls.
• Added threshold, incident, recovery, maintenance, and pause overlays.
• Added state-aware period shading without changing historical evaluation.
• Added server-side historical-data filtering, sorting, and pagination.
• Added bounded CSV exports with spreadsheet-formula neutralisation and redacted audit events.
• Missing historical measurements are shown as unavailable rather than being converted to zero.

IP/WAN Monitor Wallboard

• Added a standalone network-operations Wallboard.
• Added Auto and fixed 2, 3, 4, 5, 6, and 8-column layouts.
• Added Comfortable, Compact, and Dense display modes.
• Added saved per-user card ordering and presentation preferences.
• Added optional graphs, statistics, actions, addresses, result times, averages, availability, and header controls.
• Added full-screen support and responsive card layouts.
• Layout controls and move handles are hidden unless Edit layout is enabled.
• Wallboard controls apply immediately without reloading the page.

Secured shared Wallboard access

• Added optional passcode-protected shared Wallboard links.
• Shared access is disabled by default.
• Wallboard URL identifiers are random and encrypted at rest.
• Passcodes are stored using Argon2 hashes.
• Sessions use opaque hashed tokens and path-scoped, HttpOnly, SameSite cookies.
• Added configurable session and remembered-display lifetimes.
• Added monitor allowlists and configurable action permissions.
• Added challenge rate limiting and temporary lockouts.
• Regenerating or revoking a URL invalidates existing shared sessions.
• Passcode changes and explicit invalidation also revoke active sessions.
• Sensitive tokens, passcodes, and URL identifiers are excluded from audit metadata.
• Shared operations continue to enforce CSRF and object-level monitor authorisation.

Site Administration and navigation

• Relocated IP/WAN Monitor defaults and Wallboard configuration to:
  Site Administration → Module Settings → IP/WAN Monitor
• Added module-aware access controls to Site Administration settings.
• Users can only see and access settings for modules granted to them.
• Direct module-settings links now enforce administrator and module-level permissions.
• Added consistent module navigation and settings links across Kaya.
• Expanded settings pages to use the available page width more effectively.

Retention changes

Default IP/WAN Monitor retention is now:

• Raw checks: 30 days
• Five-minute summaries: 90 days
• Hourly summaries: 365 days
• Daily summaries: unlimited
• Incidents and events: unlimited

Proxmox backup monitoring

• Improved matching between configured Proxmox backup jobs and completed tasks.
• Added stronger matching using node, storage, mode, workload IDs, and execution signatures.
• Added grouping for multi-workload backup executions.
• Improved diagnostic logging for rejected and accepted task matches.
• Added richer backup history to compute-monitor results.

High Availability

• Fixed the five-minute HA configuration monitor.
• Added regression coverage for the corrected monitoring interval and behaviour.

Documentation and contributor experience

• Added a comprehensive contributor guide.
• Expanded IP/WAN Monitor, API, database, networking, Site Administration, and security documentation.
• Updated module-navigation and inventory documentation.
• Improved installation and project information in the README.

Upgrade notes

• Back up the Kaya database before upgrading.
• Database schema updates are applied automatically during startup unless migrations have been explicitly disabled.
• Existing IP/WAN monitors are migrated to the new state-aware threshold model.
• Monitor state counters are reset during threshold migration. Monitors will display an awaiting-check state until their next result.
• Existing retained history may not contain newly introduced minimum-latency or jitter fields. Kaya displays these values as unavailable instead of fabricating data.
• Shared Wallboard access remains disabled until an administrator generates a URL, configures a passcode, and enables sharing.

Breaking changes

No intentional API or deployment-breaking changes are included.

Administrators should review the new inherited IP/WAN Monitor thresholds after upgrading because monitoring defaults and state-confirmation behaviour have changed.

v0.25.4

What's Changed

• Fix the Backup Manager reporting wrong Successful backup date. by @antybubbs in #40
• HA Sync Fix by @antybubbs in #41
• Dev Update from Main by @antybubbs in #42
• Pull updates from dev branch. by @antybubbs in #43

Full Changelog: v0.25.1...v0.25.4