TMI - Threat Modeling Improved
June 29, 2026 ยท View on GitHub
A collaborative threat modeling server built with Go.
Try it yourself at https://www.tmi.dev
API server online at https://api.tmi.dev
API clients available at https://github.com/ericfitz/tmi-clients
Overview
TMI (Threat Modeling Improved) is a collaborative platform for managing an organization's security review process, including threat modeling. Our mission is to reduce the toil of security reviewing, and to make threat modeling accessible, efficient, and integrated into the software development lifecycle.
The platform features security review organization and state management, interactive data flow diagram creation with real-time collaboration, and comprehensive threat documentation capabilities. Built with modern web technologies, TMI helps teams manage the security review process and identify, analyze, and mitigate security threats through collaborative modeling.
This project is the TMI server back-end, a Go service that implements the TMI REST API.
The associated Angular/Typescript front-end web application is called TMI-UX.
Quick Start
For detailed setup instructions, see Development Setup Guide.
Prerequisites
- Go 1.25+
- Docker Desktop (for database & Redis containers)
- Make (for build automation)
Installation
git clone https://github.com/ericfitz/tmi.git
cd tmi
make dev-up
The complete development environment (a local kind cluster running the server, plus database and Redis) will start automatically, with the server reachable on port 8080.
Project Structure
api/- API types and handlerscmd/server/- Server entry point and configurationapi-schema/tmi-openapi.json- OpenAPI specification
Architecture
Data Storage Pattern
The project uses strongly-typed concurrent maps for in-memory storage:
// Store provides thread-safe storage for a specific entity type
type Store[T any] struct {
data map[string]T
mutex sync.RWMutex
}
// DiagramStore stores diagrams by UUID
var DiagramStore = NewStore[api.Diagram]()
// ThreatModelStore stores threat models by UUID
var ThreatModelStore = NewStore[api.ThreatModel]()
Benefits of this approach:
- Type safety with generics
- Concurrency protection with mutexes
- Clear separation between different entity stores
- Easy to replace with a database implementation later
This pattern is used for all entity types (diagrams, threat models, threats) and provides:
- CRUD operations
- Atomic updates
- Support for filtering and queries
Documentation
Comprehensive documentation is organized by audience:
๐ For Developers
- Setup Guide - Local development environment
- Testing Guide - Comprehensive testing documentation
- Client Integration - API and WebSocket integration
๐ For Operations Teams
- Deployment Guide - Production deployment
- Database Operations - Database management
- Container Security - Secure containerization
๐ Complete Documentation Index
See TMI Wiki for the complete documentation catalog organized by role and topic.
Development Commands
make dev-up # Start complete dev environment (kind cluster)
make dev-status # Show dev environment status
make dev-down # Tear down dev environment (keep db data)
make build-server # Build production binary
make test-unit # Run unit tests
make test-integration-new # Run integration tests (server must be running)
make cats-fuzz # Run security fuzzing
make lint # Run code linting
Configuration
Server configuration can be set via environment variables or using a .env file:
- Copy the
.env.examplefile to.env - Modify the values as needed
- Start the server, which will automatically load the
.envfile
You can also specify a custom .env file with:
./bin/tmiserver --env=/path/to/custom.env
Available configuration options:
| Variable | Default | Description |
|---|---|---|
| SERVER_PORT | 8080 | HTTP/HTTPS server port |
| SERVER_INTERFACE | 0.0.0.0 | Network interface to listen on |
| SERVER_READ_TIMEOUT | 5s | HTTP read timeout |
| SERVER_WRITE_TIMEOUT | 10s | HTTP write timeout |
| SERVER_IDLE_TIMEOUT | 60s | HTTP idle timeout |
| LOG_LEVEL | info | Logging level (debug, info, warn, error) |
| TLS_ENABLED | false | Enable HTTPS/TLS |
| TLS_CERT_FILE | Path to TLS certificate file | |
| TLS_KEY_FILE | Path to TLS private key file | |
| TLS_SUBJECT_NAME | [hostname] | Subject name for certificate validation |
| TLS_HTTP_REDIRECT | true | Redirect HTTP to HTTPS when TLS is enabled |
| JWT_SECRET | secret | JWT signing secret (change for production!) |
| JWT_EXPIRES_IN | 24h | JWT expiration |
| OAUTH_URL | https://oauth-provider.com/oauth2 | OAuth provider URL |
| OAUTH_SECRET | OAuth client secret | |
| DB_URL | localhost | Database URL |
| DB_USERNAME | Database username | |
| DB_PASSWORD | Database password | |
| DB_NAME | tmi | Database name |
| ENV | development | Environment (development or production) |
WebSocket URLs
When TLS is enabled (TLS_ENABLED=true), clients should connect using secure WebSocket URLs:
- Use
wss://instead ofws://for WebSocket connections - Example:
wss://your-server.com:8080/ws/diagrams/123
When TLS is disabled, use standard WebSocket URLs:
- Example:
ws://your-server.com:8080/ws/diagrams/123
You can use the /api/server-info endpoint to get the correct WebSocket base URL automatically.
License
See license.txt