Deploying Fleet Management Software with Docker and Kubernetes: A Practical Guide

Most fleet management software documentation assumes you’ll deploy to a Windows Server and call it done. For organizations running container-based infrastructure — Docker, Kubernetes, or hybrid setups — that’s not good enough. This guide covers what containerized deployment of fleet management software actually looks like in practice.

Why Container Deployment Matters for Fleet Software

The shift to containerized infrastructure in enterprise IT is well underway. Organizations running Kubernetes clusters for their workloads don’t want to carve out a dedicated Windows VM for every business application. And they shouldn’t have to.

Container-based fleet software deployment offers:

• Infrastructure consistency: Same deployment process across dev, staging, and production
• Portability: Runs on any cloud provider, on-premise hardware, or hybrid setup
• Horizontal scaling: Multiple replicas behind a load balancer for high-availability
• Simplified updates: Pull a new image, roll it out, roll back if needed
• GitOps-friendly: Declarative configuration in version control

MobilityManager: Container-First Architecture

MobilityManager is built on .NET 10 and Angular 21 — both well-suited to containerization. The official Docker image supports:

• Multiple architectures: amd64 and arm64 (runs on Apple Silicon dev machines, Graviton AWS instances)
• Both database backends: SQL Server and PostgreSQL (configured via environment variables)
• Health endpoints: /healthz, /livez, /readyz — standard Kubernetes liveness/readiness probes
• Configurable via environment variables: No config file editing required in containers

Docker Compose Setup

A minimal production-ready docker-compose.yml for MobilityManager with PostgreSQL:

version: '3.9'

services:
  mobilitymanager:
    image: cloudkasten/mobilitymanager:latest
    ports:
      - "8080:8080"
    environment:
      - MM_DATABASE_PROVIDER=PostgreSQL
      - MM_DATABASE_CONNECTION=Host=db;Database=mobilitymanager;Username=mm_user;Password=${DB_PASSWORD}
      - MM_LICENSE_KEY=${LICENSE_KEY}
      - MM_APP_BASE_URL=https://fleet.yourdomain.com
      - MM_SMTP_HOST=smtp.yourdomain.com
      - MM_SMTP_PORT=587
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: mobilitymanager
      POSTGRES_USER: mm_user
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U mm_user -d mobilitymanager"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  pgdata:

Key configuration notes:

• Secrets (DB_PASSWORD, LICENSE_KEY) should come from a .env file or secret manager — never hardcoded
• The depends_on with service_healthy ensures the database is ready before the app starts
• restart: unless-stopped ensures automatic recovery after host reboots

Kubernetes Deployment with Helm

For production Kubernetes environments, MobilityManager ships with a Helm chart. A minimal deployment with horizontal pod autoscaling:

# values.yaml
replicaCount: 2

image:
  repository: cloudkasten/mobilitymanager
  tag: "latest"
  pullPolicy: IfNotPresent

database:
  provider: postgresql
  host: postgresql.fleet-system.svc.cluster.local
  name: mobilitymanager
  existingSecret: mm-db-credentials  # references a Kubernetes Secret

license:
  existingSecret: mm-license          # references a Kubernetes Secret

ingress:
  enabled: true
  className: nginx
  hosts:
    - host: fleet.yourdomain.com
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: fleet-tls
      hosts:
        - fleet.yourdomain.com

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 5
  targetCPUUtilizationPercentage: 70

resources:
  requests:
    cpu: 250m
    memory: 512Mi
  limits:
    cpu: 1000m
    memory: 1Gi

Install with:

helm repo add mobilitymanager https://charts.cloudkasten.net
helm repo update
helm install fleet mobilitymanager/mobilitymanager \
  --namespace fleet-system \
  --create-namespace \
  -f values.yaml

Health Probes Configuration

MobilityManager exposes three health endpoints for Kubernetes:

livenessProbe:
  httpGet:
    path: /livez
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 15

readinessProbe:
  httpGet:
    path: /readyz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

• /livez — indicates the application process is alive (Kubernetes restart if failing)
• /readyz — indicates the application is ready to receive traffic (removed from load balancer if failing)
• /healthz — detailed health status including database connectivity

Database Configuration

PostgreSQL (recommended for new deployments):

MM_DATABASE_PROVIDER=PostgreSQL
MM_DATABASE_CONNECTION=Host=db;Port=5432;Database=mobilitymanager;Username=mm_user;Password=secret;Pooling=true

SQL Server:

MM_DATABASE_PROVIDER=SqlServer
MM_DATABASE_CONNECTION=Server=db,1433;Database=mobilitymanager;User Id=sa;Password=secret;TrustServerCertificate=true

Multi-tenant deployments create separate databases per tenant automatically on tenant provisioning — no manual schema management required.

TLS Termination

In Kubernetes, handle TLS at the ingress level (nginx-ingress, Traefik, or your cloud provider’s ingress controller). MobilityManager itself runs HTTP internally; the ingress handles HTTPS termination.

For Docker Compose in smaller setups, terminate TLS with a reverse proxy (nginx, Caddy, Traefik) upstream from the application container.

Conclusion

Fleet management software has no business requiring a dedicated Windows Server in 2026. MobilityManager’s container-first architecture makes it a natural fit for organizations running modern infrastructure — whether that’s a simple Docker Compose setup on a VPS, or a full Kubernetes cluster with Helm-managed deployments, health probes, and horizontal autoscaling.

Request a technical demo with your infrastructure team →