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 -dFollow the startup logs:
docker compose logs -f kayaDuring the first startup, Kaya will:
- Validate the existing database.
- Create a verified backup.
- Apply compatibility updates.
- Run Alembic migrations.
- Validate the upgraded database.
- 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 currentRDP 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:
- Generate a one-time bootstrap token in Kaya.
- Set
KAYA_AGENT_BOOTSTRAP_TOKEN. - Mount a persistent state directory at
/var/lib/kaya-agent. - Start the agent and confirm enrolment.
- Remove the bootstrap token.
- Restart the agent.
Example:
environment:
KAYA_AGENT_BOOTSTRAP_TOKEN: "<one-time-token>"
volumes:
- ./agent-state:/var/lib/kaya-agentNever 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