v0.27.0

[antybubbs]

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

---

This discussion was created from the release v0.27.0.