Support

Where to get help with a self-hosted Future AGI install, what to include so the team can answer, and how to report a security vulnerability privately.

In this page

Check Troubleshooting & FAQs first. If your problem isn’t there, this page says where to ask, what to include, and how to report a vulnerability.

📝
TL;DR

Ask in Discord or open a GitHub issue, with your setup (Standalone, Distributed or Helm), the release, docker compose ps and the failing service’s logs. Report vulnerabilities privately to security@futureagi.com, never in a public issue.

Where to get help

Reporting a security issue

Warning

A vulnerability never goes in a public GitHub issue. Report it privately to security@futureagi.com, which is what the repo’s SECURITY.md asks for. You’ll get an acknowledgement within 24 hours on weekdays, and disclosure is coordinated with you rather than announced.

Before you post

A question is easier to answer with the basics attached:

  • What you ran and what happened, with the exact error
  • Your setup (Standalone, Distributed or Helm) and the release you run. On Docker Compose, the first command prints the compose file, profiles and versions that .env records, and the second lists the image and tag each container runs, since an unset version variable falls back to a default tag:
    grep -E '^(COMPOSE_FILE|COMPOSE_PROFILES|[A-Z_]+_VERSION)=' .env
    docker compose images
    If you start the stack with -f or --env-file flags, as with the production overlay, grep that env file and pass the same flags to docker compose images. The images tell the setups apart: an app container on futureagi/standalone is Standalone, and backend and worker containers on futureagi/future-agi are Distributed. An install made before Standalone became the default is Distributed even when .env has no COMPOSE_FILE line. Roll back a bad release lists what each version variable pins. On Helm, helm list -n futureagi shows the chart version, which matches the platform release.
  • Output of docker compose ps so the team can see which service is down
  • Logs from the failing service: docker compose logs app --tail=200 on Standalone, or docker compose logs <service> --tail=200 for the service that fails on Distributed. When you can’t tell which service fails, attach every log instead: docker compose logs > all-logs.txt 2>&1. Review logs before you post them: Standalone’s start-up summary never prints a secret’s value, but logs can still hold credentials inside URLs or provider error messages.
  • If ./bin/install failed, its install-YYYYMMDD-HHMMSS.log from the repository root. It never records the account password, which the installer passes to create_user on stdin, but it holds your email address, the host name and kernel version (uname -a), the host’s LAN IP address and sometimes its public one, and, after a failed start, the last lines of the service logs. Read it before you attach it.
  • On Helm, a support bundle instead of the Compose commands above
  • Your platform (Linux host, EC2, GCE, or your Kubernetes distribution) and whether you’re on managed data stores

Commercial support

For managed hosting, an SLA, or help with a production rollout, reach out at sales@futureagi.com.

Dive deeper

Was this page helpful?

Questions & Discussion