@Kathy Satterlee #C01DXJL16D8 I am finding a toll for my business need and Fleets has the all the required ones. I am trying to deploy and test in my test env, I found two repos: https://github.com/ksatter/fleet-docker https://github.com/spokanemac/fleet-docker-traefik I am looking for a docker-compose base deployment. But this are updated very old around 3 long years back.. any one have the revamp version of this ? any suggestion on this ? Thanks in advance

I ran into the same problem and couldn't get any documentation to help with testing on a personal hosting deployment.

Hey @Venkatrami Reddy and @star ks 👋 Hope you're both having an excellent day! Yes, Fleet absolutely provides a sample Docker Compose configuration perfect for development and testing! You can find the main

docker-compose.yml

right here in our repo: https://github.com/fleetdm/fleet/blob/HEAD/docker-compose.yml 🚀. This base setup is quite comprehensive and includes core services like: * Redis: For caching and the job queue backend. * MinIO: An S3-compatible object storage, super handy for testing file carving. * Mailpit: An SMTP server for email testing – no more accidentally spamming real inboxes! 😉 * Prometheus: For metrics collection. * Localstack: Great for emulating AWS services like Firehose and Kinesis locally. * SAML IdP: For testing out SSO/SAML integrations. This configuration is fantastic for getting up and running quickly for internal development, customer demos, or POCs. However, before even thinking about production hardening, here are a couple of less-obvious ways you can leverage this dev setup to get even more value: 1. Embrace Controlled Chaos 🌪️*:* Don't just run the stack; try to (gently) break it! For instance, use

docker-compose stop redis

for a minute and observe how Fleet handles a temporary cache outage. This is a brilliant way to understand its resilience, fallback mechanisms, and error messaging. Similarly, with LocalStack, you can simulate more than just the happy-path AWS interactions. Try configuring LocalStack with overly restrictive IAM policies for its S3 emulation and then attempt a file carve in Fleet. Seeing how Fleet reacts when an S3 upload is unexpectedly denied can help you identify and prepare for obscure edge cases you might encounter in a customer's restricted cloud environment. 2. Master the

docker-compose.override.yml

🧙‍♂️*:* This file is your secret weapon for powerful individual developer customizations without ever touching the base

docker-compose.yml

. Beyond simple port changes, a developer could use their

docker-compose.override.yml

to: * Mount local source code of a custom plugin directly into the Fleet container for live development and testing. * Swap out a service (like Mailpit) for a different preferred tool. * Test Fleet against a different version of Redis or MinIO by overriding the image tag. For example, a developer working on a new reporting feature that uses a specific local directory for template testing might add this to their personal `docker-compose.override.yml`:

yaml
    # in docker-compose.override.yml
    services:
      fleet:
        volumes:
          - ./my-report-templates:/app/templates/custom_reports

This keeps the main

docker-compose.yml

pristine for the team while allowing deep, individual customization. 3. Get an Early Glimpse of Resource Usage 📊*:* While Prometheus is included for more detailed metrics, even running a simple

docker stats

in your terminal while performing various intensive operations in Fleet (like running a large query across many hosts or initiating multiple file carves) can give you a rough, real-time baseline of CPU and memory consumption for each service. It's not a substitute for proper production profiling, but it can be an early warning if a new feature or change suddenly makes one of the services unexpectedly resource-hungry. As the reference docs point out, this particular

docker-compose.yml

is not intended for production use as-is. For a live environment, you'd need to significantly harden the configuration (e.g., manage secrets securely – perhaps with something like HashiCorp Vault, set up robust persistent storage for MinIO and Redis data, implement strict network restrictions, use non-default credentials, etc.). Here's a small snippet from the file to give you a taste:

yaml
redis:
  image: redis:5
  ports:
    - "6379:6379"

minio:
  image: <http://quay.io/minio/minio|quay.io/minio/minio>
  command: server /data --console-address ":9001"
  ports:
    - "9000:9000"
    - "9001:9001"
  environment:
    MINIO_ROOT_USER: minio # Definitely change this!
    MINIO_ROOT_PASSWORD: minio123! # And this too!
  volumes:
    - data-minio:/data

For the full configuration, refer to the

docker-compose.yml

link above. If you need a hand tailoring this for a specific customer-facing demo, a more minimal setup, or even a more production-ready example, just let me know your requirements and I'd be happy to help you sketch something out! 🛠️ Happy to help! Cheers, ~Josh 🖖

We don't have a revamped 'fresh' guide on this because our best practice and officially supported deployment methods are AWS+Terraform and Render. We are going to be adding a GCP guide soon, and we do support Kubernetes via Terraform and helm for a lot of our customers and community members too!

Thank you @Josh Roskos @Zay Hanlon For the detail and the links I understand the AWS+Terraform and Render methods for fleet.. But we are looking for the docker compose based deployment.. Josh details are useful. I will run a sandbox in my local env and let you know any issues