Skip to content

Planning Your Deployment

Jump to bottom
Eric Fitzgerald edited this page Apr 8, 2026 · 5 revisions

Planning Your Deployment

This guide helps you plan and prepare for deploying TMI (Threat Modeling Improved) in your environment. TMI consists of two main components: a Go-based API server and an Angular-based web application.

Overview

TMI is a collaborative threat modeling platform with:

  • Real-time collaborative diagram editing via WebSockets
  • Role-based access control (reader, writer, owner)
  • OAuth 2.0 authentication with PKCE (RFC 7636) and JWT
  • RESTful API with OpenAPI 3.0.3 specification
  • Support for multiple threat modeling frameworks (STRIDE, CIA, LINDDUN, etc.)

Architecture Overview

Production Architecture

[Internet] → [Load Balancer/Reverse Proxy]
                      ↓
            [TMI Server Instances]
                      ↓
            [Database (PostgreSQL/Oracle/MySQL/SQL Server/SQLite)]
            [Cache Cluster (Redis)]
            [Monitoring Stack]

Key Components

  • TMI Server: Go HTTP server with WebSocket support for real-time collaboration
  • TMI Web Application: Angular/TypeScript frontend
  • Database: Primary data storage for threat models, diagrams, and user data (supports PostgreSQL, Oracle, MySQL, SQL Server, and SQLite via GORM)
  • Redis Cache: Session storage, caching, and real-time WebSocket message coordination
  • OAuth/SAML Integration: Authentication via configurable identity providers (Google, GitHub, Microsoft, or any OAuth 2.0/SAML provider)
  • Load Balancer: Traffic distribution, SSL termination, health checks (production)
  • Monitoring: Observability stack for metrics and alerts (recommended)

Deployment Options

1. Single Server Deployment

Best for: Small teams, development/staging environments

Components:

  • Single server running TMI server, web app, database (e.g., PostgreSQL), and Redis
  • Nginx reverse proxy for SSL termination
  • Local file-based logging
  • Basic monitoring with health checks

Pros: Simple setup, low cost, easy maintenance Cons: No high availability, limited scalability, single point of failure

Estimated Cost: $5-20/month (small VPS or Heroku Eco dynos)

2. Multi-Server Deployment

Best for: Production environments with moderate load

Components:

  • Load-balanced TMI server instances
  • Dedicated database and cache servers
  • Separate web server for static frontend
  • Centralized logging and monitoring
  • Automated backup and recovery

Pros: Better performance, some redundancy, easier scaling Cons: More complex setup, higher cost, requires load balancer

Estimated Cost: $100-300/month (cloud VMs or Heroku Standard dynos)

3. Cloud Terraform Templates (Recommended)

Best for: Deploying to AWS, OCI, GCP, or Azure with minimal effort

TMI provides 8 ready-to-use Terraform templates -- public and private variants for each of 4 cloud providers. Each template deploys a complete TMI stack (Kubernetes cluster, managed PostgreSQL, Redis, load balancer, secrets, logging) with a single terraform apply.

Public templates are internet-accessible, low-cost deployments for evaluation:

Provider Est. Monthly Cost Notes
OCI $0 Always Free tier (arm64 Ampere nodes)
Azure ~$75-85 AKS Free tier + B2s node
GCP ~$80-100 GKE Autopilot + Cloud SQL
AWS ~$140-150 EKS + t3.medium node

Private templates are for internal deployments with no public ingress -- the deployer establishes connectivity (VPN, bastion, etc.).

Pros: One-command deployment, provider-native services, automatic secret generation, WebSocket support configured Cons: Requires cloud provider account and Terraform knowledge

See Terraform-Deployment for full details.

4. Container Orchestration (Custom)

Best for: Organizations with existing Kubernetes infrastructure

Components:

  • Existing Kubernetes cluster
  • TMI deployed via Helm or raw manifests
  • External database and Redis
  • Custom ingress/load balancer configuration

Pros: Integrates with existing infrastructure, full control Cons: More setup effort than Terraform templates, requires Kubernetes expertise

Estimated Cost: Varies (depends on existing infrastructure)

Prerequisites

For All Deployments

System Requirements

  • Operating System: Linux, macOS, or Windows (with WSL)
  • Database: PostgreSQL 12+, Oracle, MySQL, SQL Server, or SQLite (PostgreSQL recommended for production)
  • Redis: Version 6 or higher
  • Node.js: Version 22+ (for web app)
  • Go: Version 1.26+ (for building server)

Network & Security

  • Domain name with DNS configured (for production)
  • SSL/TLS certificates (Let's Encrypt recommended)
  • Inbound access on configured ports (default: 8080 for API server)
  • Outbound HTTPS access to OAuth providers
  • Firewall configured to restrict database/Redis access

OAuth Applications

You need to register OAuth applications with at least one provider. TMI supports any OAuth 2.0 provider via environment-variable-based configuration (OAUTH_PROVIDERS_<NAME>_*). Common providers include:

Each OAuth application needs:

  • Client ID (Client Secret for confidential clients; public clients use PKCE)
  • Authorized redirect URIs configured
  • Appropriate scopes enabled

For Docker/Container Deployments

  • Docker Engine 20.10+ or Docker Desktop
  • Docker Compose 2.0+ (for local development)
  • Kubernetes 1.24+ (for orchestration)
  • Container registry access (Docker Hub, GCR, ECR, etc.)

For Kubernetes Deployments

  • kubectl configured and authenticated
  • Helm 3+ (optional but recommended)
  • Ingress controller configured
  • Persistent volume provisioner
  • Certificate manager (cert-manager recommended)

Deployment Decision Matrix

Use this matrix to choose your deployment approach:

Criteria Single Server Multi-Server Kubernetes
Team Size 1-10 users 10-100 users 100+ users
Budget $5-20/mo $100-300/mo $500+/mo
Availability Needs 95% OK 99% required 99.9% required
Setup Complexity Low Medium High
Scaling Manual Semi-automated Fully automated
Maintenance Effort Low Medium Medium-High
Skillset Required Basic Linux Moderate DevOps Kubernetes expertise

Platform-Specific Considerations

Heroku Deployment

Best for: Quick deployment, minimal DevOps overhead

Pros:

  • Simple deployment from GitHub
  • Managed PostgreSQL and Redis addons
  • Automated scaling and health checks
  • Built-in SSL/TLS
  • Easy environment management

Cons:

  • Higher per-unit cost
  • Less infrastructure control
  • Vendor lock-in

See Deploying-TMI-Server

Traditional Server (VPS/Bare Metal)

Best for: Maximum control, existing infrastructure

Pros:

  • Full control over configuration
  • Predictable costs
  • Can use existing infrastructure
  • No vendor lock-in

Cons:

  • More manual setup required
  • Need to manage OS updates
  • Security hardening is your responsibility

See Deploying-TMI-Server

Docker/Docker Compose

Best for: Consistent environments, easy local development

Pros:

  • Consistent deployment across environments
  • Easy to replicate locally
  • Good for dev/staging environments
  • Portable to different hosts

Cons:

  • Requires Docker knowledge
  • Single-host limitations
  • Need orchestration for production HA

See Deploying-TMI-Server

Kubernetes

Best for: Large-scale deployments, cloud-native architecture

Pros:

  • Excellent scalability
  • Built-in high availability
  • Self-healing capabilities
  • Industry standard orchestration

Cons:

  • Steep learning curve
  • Operational complexity
  • Overkill for small deployments

See Deploying-TMI-Server

Security Planning

Authentication Strategy

  • OAuth Providers: Choose which providers to enable (any OAuth 2.0 or SAML provider)
  • PKCE: OAuth 2.0 authorization code flow uses PKCE (RFC 7636) for public clients
  • JWT Configuration: Plan token expiration and refresh policies
  • Session Management: Redis for session storage with appropriate TTLs
  • HTTPS: Required for all production deployments

Network Security

  • Firewall Rules: Database and Redis should not be internet-accessible
  • Network Segmentation: Separate application, database, and cache layers
  • SSL/TLS: Use TLS 1.3 for all communications
  • Rate Limiting: Implement at load balancer or reverse proxy level

Data Security

  • Database Encryption: Enable encryption at rest for your database
  • Backup Encryption: Encrypt all database backups
  • Secret Management: Use environment variables or secret management tools (Vault, etc.)
  • Audit Logging: Enable application and database audit logs

Capacity Planning

Database Sizing

Small deployment (< 100 users):

  • PostgreSQL: 2GB RAM, 20GB storage
  • Redis: 256MB RAM
  • Expected growth: ~1GB/month

Medium deployment (100-1000 users):

  • PostgreSQL: 4-8GB RAM, 100GB storage
  • Redis: 1GB RAM
  • Expected growth: ~5GB/month

Large deployment (1000+ users):

  • PostgreSQL: 16GB+ RAM, 500GB+ storage
  • Redis: 4GB+ RAM
  • Expected growth: Monitor and scale proactively

Server Sizing

TMI API Server (per instance):

  • Small: 1 CPU, 1GB RAM (10-50 users)
  • Medium: 2 CPU, 2GB RAM (50-200 users)
  • Large: 4 CPU, 4GB RAM (200-500 users)

TMI Web Application (static hosting):

  • Minimal resources needed (served via CDN or static hosting)
  • nginx: 512MB RAM sufficient for any load

Network Bandwidth

  • Average: 100-500 KB per user session
  • WebSocket traffic: Minimal for real-time updates
  • API requests: 1-10 KB per request
  • Diagram data: 10-100 KB per diagram

Pre-Deployment Checklist

Infrastructure

  • Servers/VMs provisioned and accessible
  • DNS records configured for production domains
  • SSL/TLS certificates obtained and validated
  • Firewall rules configured
  • Backup storage configured and tested

Database & Cache

  • Database installed and configured (PostgreSQL, Oracle, MySQL, SQL Server, or SQLite)
  • Redis installed and configured
  • Database backups scheduled
  • Connection pooling configured
  • Performance tuning completed

OAuth Providers

  • OAuth applications created
  • Client IDs and secrets generated
  • Redirect URIs configured with production URLs
  • Required scopes enabled
  • Test users configured (if applicable)

Monitoring & Logging

  • Log aggregation configured
  • Metrics collection setup
  • Alert rules defined
  • Health check configured (TMI uses the root endpoint / for health checks)
  • Dashboard created

Documentation

  • Deployment runbook created
  • Rollback procedures documented
  • Emergency contact list prepared
  • Architecture diagram updated
  • Configuration documented

Common Deployment Patterns

Development Environment

Developer Machine
├── TMI Server (localhost:8080)
├── TMI Web App (localhost:4200, Angular dev server)
├── Database (Docker container or SQLite)
└── Redis (Docker container)

Use case: Local development and testing Setup time: 10 minutes with make start-dev

Staging Environment

Staging Server
├── TMI Server (staging-api.example.com)
├── TMI Web App (staging.example.com)
├── Database (managed service or dedicated server)
└── Redis (managed service or dedicated server)

Use case: Pre-production testing, QA Setup time: 1-2 hours

Production Environment (Recommended)

Load Balancer (HTTPS)
├── TMI Server Instances (2-3 replicas)
├── TMI Web App (static hosting or CDN)
│
Database Layer
├── Database (primary + read replicas, PostgreSQL recommended)
└── Redis (cluster or sentinel)
│
Monitoring Stack
├── Metrics (Prometheus)
├── Logs (ELK/Loki)
└── Tracing (Jaeger/Tempo)

Use case: Production deployment with high availability Setup time: 4-8 hours initial setup

Next Steps

  1. Choose your deployment approach based on the decision matrix above
  2. Review Deploying-TMI-Server for detailed server deployment instructions
  3. Review Deploying-TMI-Web-Application for frontend deployment
  4. Set up Setting-Up-Authentication with your chosen OAuth providers
  5. Configure your Database-Setup for your environment
  6. Integrate Component-Integration to connect everything together
  7. Complete Post-Deployment verification and testing

Getting Help

Related Pages

Detailed Guides (GitHub Repository)

For in-depth technical documentation, see these guides in the source repository:

Home

Releases

Getting Started

Deployment

Operation

Troubleshooting

Development

Integrations

Tools

API Reference

Reference

Clone this wiki locally