Files
fleet/server/platform
Victor Lyuboslavsky 8c2ad7f901 Run multiple independent Fleet dev servers in parallel (#41865)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or
remove if NA -->
**Related issue:** Resolves #41848 

Docs updates: https://github.com/fleetdm/fleet/pull/41868/changes

# Checklist for submitter

- changes not needed since this is a dev environment and test issue

## Testing

- [x] QA'd all new/changed functionality manually

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Tests**
* Enhanced test infrastructure to support environment-variable-based
configuration for SAML, mail, database, and S3 services, enabling more
flexible and dynamic test setups.

* **Chores**
* Updated Docker Compose configuration to use environment variables for
service ports, allowing runtime customization while maintaining backward
compatibility with default values.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-03-18 13:58:58 -05:00
..

Platform packages

This directory contains infrastructure and cross-cutting technical concerns that are independent of Fleet's business domain. These packages provide foundational capabilities used across the codebase.

Platform vs domain

Following separation of concerns, we distinguish:

  • Platform (infrastructure): Technical concerns like database connectivity, HTTP utilities, middleware, and transport-level error handling. These packages have no knowledge of Fleet's business domain.
  • Domain (business logic): Feature-specific code organized into bounded contexts. Domain packages depend on platform packages, not the reverse.

Guidelines

  • Platform packages must not import domain packages
  • Platform packages should be general-purpose and reusable
  • Architectural boundaries are enforced by arch_test.go