Une instance qui tourne, et un ticket dedans.

Le lancer contre votre propre Postgres

Une image — le front, l'API et un proxy qui route entre les deux — sur une seule origine. Kanso ne livre pas de base de données : un conteneur qui possède vos données est un conteneur qu'on ne redémarre pas sans y penser.

docker run -d -p 80:80 -p 443:443 -v kanso-data:/data \
  -e KANSO_PUBLIC_URL=https://kanso.example.com \
  -e SPRING_DATASOURCE_URL='jdbc:postgresql://db.internal:5432/kanso?sslmode=require' \
  -e SPRING_DATASOURCE_USERNAME=kanso -e SPRING_DATASOURCE_PASSWORD=… \
  ghcr.io/tykok/kanso

Ces deux choses — l'URL à laquelle il vit et la base dans laquelle il écrit — sont toute la configuration. Caddy obtient seul un certificat pour cet hôte, en linux/amd64 comme en linux/arm64.

Pas encore de base ? docker/docker-compose.yml livre un postgres:16-alpine à côté de l'image. Copiez-le, changez KANSO_PUBLIC_URL et le mot de passe, puis docker compose up -d.

Ou le lancer depuis les sources

Le docker-compose.yml du dépôt est autre chose : il construit les deux applications depuis les sources et les sert sur deux ports, ce que pilote la suite Playwright. Renseignez les identifiants OIDC dans .env, ou posez KANSO_AUTH_MODE=dev.

cp .env.example .env
docker compose up

localhost:3000

L'application web

localhost:8080

L'API REST, le WebSocket et le point d'entrée MCP

localhost:8080/actuator/health

Vivacité, disponibilité et vérification de la base

Pour lancer les applications hors de Docker et n'y garder que Postgres :

docker compose up -d db                      # Postgres only
cd apps/api && ./gradlew bootRun             # http://localhost:8080
cd apps/web && pnpm install && pnpm dev      # http://localhost:3000

L'assistant d'installation

Le premier lancement ouvre un assistant plutôt qu'un écran de connexion, faute de quelqu'un à qui se connecter. Il a quatre étapes et seule la première est obligatoire.

1. Le compte propriétaire. Une adresse et un mot de passe. Ce compte peut configurer l'instance ; rien d'autre ne le peut.
2. Notion. Optionnel, et réouvrable. La connexion a sa propre page — voir Notion.
3. La connexion Google. Optionnelle. Une instance peut tourner avec les seuls mots de passe.
4. Les préférences. Thème, accent, barre latérale. Par personne, pas par instance.

Chaque étape après le compte est passable et réouvrable depuis les réglages — , — de sorte qu'on peut saisir des tickets en moins d'une minute et décider du reste plus tard.

Celui qui arrive ensuite entre par un lien d'invitation généré par le propriétaire, et ne voit que l'étape des préférences. Notion et Google valent pour toute l'instance : un membre n'a rien à y décider, et les étapes sont masquées plutôt que montrées désactivées.

La première équipe, et le premier ticket

Un ticket appartient à une équipe, donc l'équipe vient d'abord — la barre latérale en crée une. Ensuite le clavier est l'interface, et les mêmes touches valent dans la liste, sur le tableau et sur le planning.

c

Créer, depuis n'importe où

e

Renommer sur place

1 … 6

Les six premiers statuts de votre équipe, dans son ordre

⇧s

Choisir un statut par son nom, y compris un septième

⌘K

La palette de commandes (Ctrl+K ailleurs)

?

Tous les raccourcis, tels que ce compte les a liés

Le ticket reçoit un identifiant court propre à son équipe — KAN-1, puis KAN-2 — attribué à l'intérieur de la transaction d'insertion, depuis un compteur porté par la ligne de l'équipe. Deux personnes qui pressent c au même instant obtiennent 41 et 42 : pas de trou, pas de collision.

Où aller ensuite

• Le modèle — équipes, projets, tickets, statuts et les documents à côté.
• Travailler dedans — une requête dessinée de trois façons, filtres, cycles, charge, tri.
• Notion — ce qui est mis en miroir, ce qui ne l'est pas, et pourquoi Notion ne gagne jamais.
• Agents et API — la porte MCP pour un agent, jetons et webhooks pour un service.
• Auto-hébergement — TLS, ce que contient /data, et ce qu'il faut sauvegarder.