Deployment
Choose a managed service or run Team Server in your own container environment.
Compare Deployment Models
| Consideration | Managed | Self-hosted |
|---|---|---|
| Infrastructure | Operated by Endura under the service agreement | Operated by your team |
| Database, backup, and updates | Scope defined by the service agreement | Your responsibility |
| Network and TLS | Agreed during onboarding | Fully configurable |
| Configuration changes | Coordinated with Endura | Applied directly |
| Deployment options | Managed environment | Docker, Podman, or Kubernetes |
Choose managed operations or a self-hosted guide below.
Versioning and Release Channels
Team Server uses semantic versions in major.minor.patch form:
- Major releases may change the Runtime Sensor contract.
- Minor releases add compatible functionality.
- Patch releases contain compatible fixes.
Docker and Podman examples use the mutable testing tag. Kubernetes selects the testing chart repository and pins its semantic version. See Release Channels for channel semantics, artifact naming, manifests, and update guidance.
Runtime Sensor Compatibility
Team Server and the Runtime Sensor are compatible when their major versions match. Minor and patch versions do not gate compatibility and may be updated in either order.
Team Server publishes its version through unauthenticated GET /api/version:
{"version":"1.0.85","build":"f57af95c"}The Sensor checks at startup and every 15 seconds. A major mismatch warns and pauses registration, status, heartbeats, violations, and logs while enforcement and version reporting continue. endura sensor status shows active (incompatible: team server <version>); Team Server also marks the Sensor incompatible. Submission resumes automatically after a compatible response.
Coordinate major upgrades within one maintenance window, in either order. Minor/patch upgrades need no coordination. Use ENDURA_VERSION_CHECK=false only as a temporary last resort; it permits unsupported cross-major submission. See Sensor interruption behavior.
Capacity
Start with deployment-guide resources, monitor database/application usage, and scale for Sensor count, telemetry, policy size, integrations, and retention.
Network Requirements
| Direction | Destination | Purpose |
|---|---|---|
| Inbound | Team Server HTTPS endpoint | UI, API, and Runtime Sensor traffic |
| Inbound | /api/integrations/teams/messages/<application-id>, when used | Authenticated Microsoft Teams installation events |
| Outbound | PostgreSQL, when external | Application data |
| Outbound | Configured identity providers | OIDC authentication |
| Outbound | Configured CI/CD systems | Pipeline and build discovery |
| Outbound | Configured SMTP relay and port, when used | Email violation notifications |
| Outbound | slack.com:443, when used | Slack violation notifications |
| Outbound | login.microsoftonline.com:443, login.botframework.com:443, and Microsoft-provided Bot Connector service URLs, when used | Teams setup, channel discovery, status, and violation notifications |
Private identity providers, private CI/CD endpoints, private SMTP relays, or internal certificate authorities require outbound HTTP configuration.