A visual, node-based chat management system for Large Language Model interactions.
LLM Canvas replaces the traditional linear chat interface with an interactive canvas where conversations are organised as interconnected, branching nodes — like a mind-map for your AI chats. Built as the SE3022 Case Study Project at SLIIT by Group 18.
- �️ Multiple Canvases — create isolated workspaces for different topics
- 🌿 Branching Sub-Nodes — explore tangential questions without polluting the main thread
- 🧹 Context Decay & Snapshots — automatic context management to prevent token bloat
- �️ Visual Mind-Map — drag-and-drop canvas powered by React Flow
- � Note Generation — synthesise notes from any combination of nodes
- � Export — download notes as PDF or plain text
- 🔒 Secure Authentication — JWT-based auth with BCrypt password hashing
- 🔑 BYOK Provider Settings — save and manage personal OpenAI, Claude, Gemini, and LM Studio keys
- 💬 Canvas Workspace — the primary frontend experience now lives in the unified canvas workspace on
/
| Layer | Technology |
|---|---|
| Frontend | React.js (functional components + hooks), React Flow |
| Backend | ASP.NET Web API (.NET 8), ADO.NET |
| Database | MySQL 8.0 hosted on Supabase |
| AI | OpenAI, Anthropic Claude, and Google Gemini APIs |
| Proxy | Nginx reverse proxy |
| DevOps | Docker, GitHub Actions CI/CD |
| Hosting | Azure App Service (API) + Azure Static Web Apps (frontend) |
Coliee/
├── .github/workflows/ # GitHub Actions CI/CD pipelines
├── backend/Coliee.API/ # ASP.NET Web API — Controllers, Services, Data Access
├── frontend/ # React.js application
├── .env.example # Environment variable template
├── .gitignore
├── docker-compose.yml # Local multi-service orchestration
└── init.sql # MySQL database initialisation script
- Docker & Docker Compose
- .NET 8 SDK (for backend development outside Docker)
- Node.js 18+ (for frontend development outside Docker)
- A provider API key for OpenAI, Claude, Gemini, or LM Studio if you want to use the BYOK chat flow
- Optional built-in guest preview API keys for OpenAI, Claude, and Gemini if you want logged-out users to get one real AI action before sign-in
git clone https://github.com/<your-org>/Coliee.git
cd Colieecp .env.example .envOpen .env and fill in your values:
MYSQL_DATABASE=coliee_db
MYSQL_USER=coliee_user
MYSQL_PASSWORD=your_password
MYSQL_ROOT_PASSWORD=your_root_password
JWT_KEY=your_jwt_secret
Llm__EncryptionKey=replace-with-base64-32-byte-key
Llm__GuestPreview__OpenAI__ApiKey=
Llm__GuestPreview__OpenAI__Model=gpt-5.2
Llm__GuestPreview__Claude__ApiKey=
Llm__GuestPreview__Claude__Model=claude-sonnet-4-20250514
Llm__GuestPreview__Gemini__ApiKey=
Llm__GuestPreview__Gemini__Model=gemini-2.5-flash
# LM Studio does not require auth by default; a placeholder such as
# "lmstudio" is enough for the saved provider key when auth is off.
# If the backend runs in Docker, point LM Studio at a host-reachable URL such as
# http://host.docker.internal:1234/v1.
Llm__Providers__LmStudio__BaseUrl=http://localhost:1234/v1
Llm__Providers__LmStudio__Model=local-model
# Backend API URL (used by frontend)
VITE_API_URL=http://localhost:5000
# Google OAuth Web client ID
VITE_GOOGLE_CLIENT_ID=your-google-web-client-id.apps.googleusercontent.com
Authentication__Google__ClientId=your-google-web-client-id.apps.googleusercontent.com
⚠️ Never commit your.envfile. It is already listed in.gitignore.
For Google Sign-In, create an OAuth 2.0 Client ID in Google Cloud Console with application type Web application.
Add http://localhost:3000 and http://localhost:5173 to Authorized JavaScript origins, then copy that same client ID into both Google variables above.
If Google shows Error 401: invalid_client, the client ID is usually deleted, from the wrong OAuth client type, or copied incorrectly.
docker compose up --buildThis starts:
- Frontend at
http://localhost:3000 - Backend API at
http://localhost:5000 - MySQL database (auto-initialised via
init.sql) - Nginx reverse proxy
docker compose downTo also clear the database volume:
docker compose down -vcd backend/Coliee.API
dotnet restore
dotnet runThe API will be available at https://localhost:7000 (HTTPS) or http://localhost:5000.
cd frontend
npm install
npm run devThe dev server runs at http://localhost:5173.
LLM Canvas follows a three-tier architecture:
React Frontend → ASP.NET REST API → MySQL (Supabase)
↓
OpenAI API
The backend follows a layered structure:
Controller → Service → Data Access (ADO.NET) → MySQL
All LLM providers are abstracted behind an interface, and the current BYOK flow supports OpenAI, Claude, Gemini, and LM Studio using user-managed keys stored encrypted at rest. Logged-out guest canvas actions can also use dedicated built-in preview keys for a single real AI action before sign-in is required.
- All passwords are hashed using BCrypt (work factor ≥ 10)
- All protected endpoints require a valid JWT token — unauthenticated requests return
HTTP 401 - Users can only access their own canvases and nodes — enforced at the API layer
- All credentials are stored as environment variables — never in source code
- All traffic is served over HTTPS; HTTP redirects to HTTPS in production
- Database queries use parameterised statements to prevent SQL injection
The project uses GitHub Actions for automated pipelines:
| Trigger | Action |
|---|---|
Push to develop |
Build + run tests |
Push to main |
Full deployment to Azure via SSH |
Secrets (API keys, DB credentials, SSH keys) are stored in GitHub Secrets and injected at runtime — never stored in the repository.
- Backend test coverage target: > 80% for all service and data access layers
- All API endpoints are documented in a Postman collection committed to the repository
Run backend tests:
dotnet test ./backend/Coliee.API.Tests/Coliee.API.Tests.csprojRun frontend tests:
cd frontend
npm test| Component | Platform |
|---|---|
| Backend API | Azure App Service |
| Frontend | Azure Static Web Apps |
| Database | Supabase (MySQL 8.0) |
Environment variables in production are configured via Azure App Service Configuration — not .env files.
Please read CONTRIBUTING.md for our branch naming conventions, commit message format, and pull request process.
This project is developed over 4 Sprints using Scrum methodology as part of SE3022 at SLIIT. Each sprint includes role rotation — every team member acts as BA, Developer, QA, and DevOps across the four sprints.
Tickets are tracked on the project board using the SCRUM-XX format, which is reflected in all branch names and commit messages.
This project was developed for academic purposes as part of the SE3022 Case Study at SLIIT by Group 18.
🚀 Deployed via CI/CD — auto-deploy verified