Andrey Kizimenko
8c6bedf661
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** N/A — internal developer tooling (`tools/hangar`). ## Summary Fleet Hangar is the local dev-environment control panel (`tools/hangar`, Go + Wails). This PR expands it into a broader **local dev-services** toolkit for contributors/QA: - **Multi-server support** — run up to 3 independent local Fleet servers in parallel, each on its own git worktree, offset ports, and docker compose project (server switcher + server-scoped Server/Logs/Database/Git tabs). - **SCEP tab** — run local SCEP CA servers using the in-repo `server/mdm/scep/cmd/scepserver` (built once to a cached binary). Per-depot profiles, `ca -init`, concurrent start/stop with live logs, and one-click copy for the SCEP URL / challenge / thumbprint (parsed from `ca.pem`). - **MDM assets tab** — run `tools/mdm/assets export` from saved configs; results list each written file with copy-contents/path + size + timestamp, plus the `FLEET_MDM_APPLE_*` env block. - **TUF tab** — drive `tools/tuf/test/main.sh` from platform checkboxes. Hangar runs the file-server itself (`SKIP_SERVER=1`) so `fleetctl package` can reach the TUF URL during packaging; streams live build output; shows ngrok tunnel + TUF-server prerequisites; and offers kill-server + delete-assets. - **Supporting work** — DB backups in app-data + cross-server restore; ngrok live public-URL links + stale-tunnel heal; per-server open-in-browser; Settings → Troubleshoot cards to reap stray `scepserver`/TUF-server processes and delete `test_tuf`. Opening as a **draft for transparency**. All changes are confined to `tools/hangar/`; nothing touches the Fleet server, agent, or any shipped code. **Architecture:** each tab is an `internal/<feature>` package (pure, unit-tested logic) behind a thin `services/<feature>_service.go` Wails adapter, reached from the UI as `api.*`. Long-running processes go through the shared process engine; everything builds from / runs against the primary repo (Server 1). # Checklist for submitter If some of the following don't apply, delete the relevant line. - [ ] Changes file added for user-visible changes — N/A: `tools/hangar` is a developer tool and is not part of a Fleet release. - [x] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented, JS inline code is prevented, and untrusted data interpolated into shell scripts/commands is validated against shell metacharacters. - External commands (`scepserver`, `go run ./tools/mdm/assets`, `bash main.sh`, the backup/restore `docker` invocation) are spawned with discrete argv slices via the process engine — no shell string interpolation — so user-supplied values (challenge, enroll secret, depot/dir paths) can't inject. Backup names are validated to `[A-Za-z0-9._-]`; server-id path segments are sanitized to `[A-Za-z0-9_-]` (no traversal); TUF asset deletion is scoped to `<repo>/test_tuf`. - [x] Timeouts are implemented and retries are limited to avoid infinite loops - Binary builds / one-shot commands run under bounded `context.WithTimeout`; the TUF-server readiness and ngrok local-API fetches use short HTTP timeouts; no unbounded loops or retries were added. - [ ] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI — N/A: no Fleet server API changes. ## Testing - [x] Added/updated automated tests - Go unit tests across the new packages: `settings` (SCEP profiles, TUF config, `migrate` incl. the empty-`servers` case), `scep` (depot/CA parsing, arg builders), `mdmassets` (export args, `wrote … in …` parsing, config persistence), `tuf` (env building, file-server args, asset delete), and `troubleshoot` (live-PID filtering) — plus the existing backups logic. - `tsc --noEmit` clean and `task build` green. - [ ] Where appropriate, automated tests simulate multiple hosts and test for host isolation — N/A. - [x] QA'd all new/changed functionality manually (ongoing local testing of all three tabs). ## Database migrations N/A — no database migrations. ## New Fleet configuration settings N/A — no Fleet server configuration settings (Hangar stores its own settings in app-data). ## fleetd/orbit/Fleet Desktop N/A — no fleetd/orbit/Fleet Desktop changes. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Multi-server support (up to three) with server switcher, server-scoped health/logs, and server-scoped Docker Compose controls. * New **Servers** settings section plus per-server configuration (including ports/compose project) and server-aware start/stop/quit flows. * New **SCEP**, **MDM Assets**, and **TUF** tabs for managing profiles/assets and discovering ngrok URLs. * Git worktree listing/creation/removal. * Centralized, server-scoped database backup management. * **Bug Fixes** * Improved process discovery to skip dead or racing entries and avoid duplicate docker-compose-up display. * Self-healing pruning of stale ngrok tunnel selections. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
News · Report a bug · Docs · Why open source? · Art
Open-source platform for IT and security teams with thousands of computers. Designed for APIs, GitOps, webhooks, YAML, and humans.
What's it for?
Fleet gives you a single system to secure and maintain all your computing devices over the air. You can do MDM, patch stuff, deploy software, and verify anything, all from one place, across every OS your organization uses.
Fleet works directly with data and events from the native operating system, down to the bare metal. Strong diagnostics let you investigate errors on end-user devices and collect accurate audit evidence in minutes.
Get started
You can try Fleet out for yourself, or grab time with one of the maintainers to chat.
Is it any good?
Fleet is used in production by IT and security teams managing thousands of devices. Many deployments support tens of thousands of hosts, and a few large organizations manage 400,000 or more.
Supported platforms
- Linux (all distros)
- macOS
- Windows
- Chromebooks
- iOS and Android (BYOD or corporate-owned)
- Amazon Web Services (AWS)
- Google Cloud (GCP)
- Azure (Microsoft cloud)
- Data centers
- Containers (kube, etc)
- Linux-based IoT devices
Infrastructure as code
Manage your fleet with GitOps, or use the GUI, REST API, webhook events, and the fleetctl command-line tool.
Linux support
First-class support for all major distros. Linux gets the same attention and visibility as macOS and Windows.
Visibility and compliance
Fleet can report on hundreds of attributes across your devices and ships with CIS benchmarks for macOS and Windows and comprehensive operating system, hardware, and software data. Check out the table reference documentation to see what's available.
Open by design
Fleet is open source and transparent about what it can and can't see. End users can verify exactly how the agent works and what data their company collects. Fleet collects only the data needed to manage and secure devices, not private activity like keystrokes, emails, or webcams.
Good neighbors
Ready-to-use, enterprise-friendly integrations exist for Snowflake, Splunk, GitHub Actions, Vanta, Elastic Jira, Zendesk, and more. Fleet also works with tools such as Munki, Chef, Puppet, Ansible, CrowdStrike, and SentinelOne.
Lighter than air
Fleet is lightweight and modular. You can use it for MDM without using it for security, and vice versa. You can turn off features you are not using.
Free as in free
The free version of Fleet will always be free. Fleet is independently backed and actively maintained with the help of many amazing contributors.
Longevity
The company behind Fleet is founded (and majority-owned) by true believers in open source. The company's business model is influenced by GitLab (NYSE: GTLB), with great investors, happy customers, and the capacity to become profitable at any time.
Fleet Device Management's company handbook is public and open source. You can read about the history of Fleet and our commitment to improving the product.
Chat
The Fleet community is full of kind and helpful people. Whether or not you are a paying customer, if you need help, just reach out.
Contributing 
Contributions are welcome, whether you answer questions on Slack / GitHub / LinkedIn, improve the documentation or website, write a tutorial, give a talk at a conference or local meetup, give an interview on a podcast, troubleshoot reported issues, or submit a patch. The Fleet code of conduct is on GitHub.
License
The free version of Fleet is available under the MIT license. The commercial license is also designed to allow contributions to paid features for users whose employment agreements allow them to contribute to open source projects. (See LICENSE.md for details.)
Fleet is built on osquery, nanoMDM, Nudge, and swiftDialog.