usekaneo/kaneo

Problem Statement Secrets can currently only be defined as values, e.g. CUSTOM_OAUTH_CLIENT_SECRET=secretvalue This is insecure, as they remain accessible in plain text within an .env or compose.yml file. Proposed Solution Support providing secrets via a file path using new environment variables. e.g. environment: - AUTH_SECRET_FILE=/run/secrets/kaneo_auth_secret - CUSTOM_OAUTH_CLIENT_SECRET_FILE=/run/secrets/kaneo_oidc_client_secret - POSTGRES_PASSWORD_FILE=/run/secrets/postgres_password (The contents of these files contain the plain text value, but are ephemeral) Alternative Solutions n/a, this approach is required to use file based Docker secrets. Relevant Context Examples in other projects: docker-library/postgres#225 autobrr/qui#661 Does this feature align with Kaneo's focus on simplicity? n/a, this is a security issue.

Problem Statement Kaneo already integrates with GitHub and Gitea but not GitLab. I run a self-hosted GitLab CE for everything (repos, CI, registry, runners) so I can't link MRs to Kaneo tasks without writing a custom webhook bridge. Pretty sure I'm not the only one, gitlab is one of the most common self-hosted Git platforms ( at least in my circle ). Proposed Solution Add GitLab as a third integration option, basically the same shape as the Gitea one: configurable instance URL (defaults to gitlab.com, overridable for self-hosted) PAT or OAuth2 auth pick a project by group/repo path import issues and MRs as task references sync MR status (open, merged, closed, draft) back to the task webhooks for live updates with HMAC signature check It should work for both gitlab.com and self-managed. Alternative Solutions None that I could think worth discussing. Relevant Context I can test against my own self-hosted GitLab CE and GitLab.com, and send webhook payload samples if useful. Does this fe

Problem Statement I use Linear at work, and the multiple repository Github integration is really nice and something I miss with the Gitea integration in Kaneo. Proposed Solution Add support for multiple repository integration with Gitea, through multiple webhooks, one per repository ? Alternative Solutions I guess the current alternative is to create one project per repository, but not having the issues from the frontend and backend together is a bit cumbersome. Relevant Context Nothing Does this feature align with Kaneo's focus on simplicity? I guess so 🤔 From my bird's view, it does not appear to be too complex to add another button next to the update one, in the Gitea integration interface.

Problem Statement Is it possible to use a sqlite db directly built into the main container so the entire app is entirely self contained and does not depend on other running services? Currently it needs a separate postgres container, but using a simple sqlite file means everything can live inside a single container. This is dramatically simplify deployment and reduce complexity. This also means you can just use a single docker command instead of a docker compose setup.

Summary During review of PR #1258 (S3 key prefix support and auto-delete orphaned assets), a potential race condition was identified in the orphaned asset cleanup flow inside apps/api/src/storage/cleanup-assets.ts. Problem The current deleteOrphanedAssets implementation uses isAssetReferencedElsewhere() to check at a single point in time whether an asset is still referenced, then hard-deletes the S3 object and DB row. This is a specific manifestation of the broader last-write-wins problem for concurrent task edits: Asset is found to be unreferenced at check time. A concurrent edit by another user re-adds the same asset to the content. The cleanup proceeds to delete the S3 object, leaving live content pointing at a missing object. Context This race condition is out of scope for PR #1258 because resolving it properly requires a larger architectural change (e.g., optimistic locking, versioning, mark-and-sweep/background GC, or a reservation + re-check pattern). The last-write-wins probl