GoatFlow is a GoatKit based ITSM system. It is a modern, secure, cloud-native ticketing and service management platform. Although it offers a seamless upgrade path for OTRS installations, it is built as a premier standalone solution for all organizations. Written in Go with a modular monolith architecture, GoatFlow provides enterprise-grade support ticketing, ITSM capabilities, and extensive customization options.
- π Security - Every route is checked by an authorization test in CI, admin rights come only from admin-group membership, two-factor login (TOTP, passkeys/security keys, recovery codes), and a hardened plugin sandbox (OS-level isolation, ed25519 signing, SQL table whitelisting)
- π Login Options - Database passwords, LDAP / Active Directory, single sign-on through OIDC / OAuth2 (any OIDC provider such as Keycloak or Azure AD / Entra ID, plus Google and GitHub) and SAML 2.0, and passkey login; OIDC uses PKCE (S256) and JWKS verification, with auto-provisioning and post-login 2FA
- π High Performance - Go-based backend with optimized database queries and caching
- π Cloud Native - Containerized deployment supporting Docker, Podman, and Kubernetes
- π± Responsive UI - Modern HTMX-powered interface with progressive enhancement
- π OTRS Compatible - Database schema superset;
goatflow-migrateimports OTRS 6 and Znuny 6.x databases, and the filesystem attachment store reads an OTRSvar/articletree as-is - π§ Setup Assistant β First-run wizard auto-launches on clean installs and guides admins through teams, queues, agents, customers, and SLAs; re-runnable task catalog for ongoing operations with plugin-extensible tasks
- π Multi-Language - Full i18n with 15 languages at 100% coverage including RTL support, even supports Klingon! π
- π¨ Theme Engine - 4 distinct themes (Synthwave, Classic, 70s Vibes, 90s Vibe) with dark/light modes and custom fonts
- π Plugin Platform - Dual-runtime (WASM + gRPC) plugin system with sandboxed execution, hot reload, admin UI, ed25519 plugin signing, OS-level process isolation, SQL table whitelisting, live policy updates, periodic health monitoring, and bounded graceful shutdown
- π Extensible - REST API, signed outbound webhooks (Admin -> Webhooks), outbound REST/SOAP web-service calls (Admin -> Web Services), and theme customization
- Docker with Compose plugin OR Docker Compose standalone OR Podman with Compose
- Git
- 4GB RAM minimum
- Modern web browser with JavaScript enabled
GoatFlow is designed for container-first workflows and supports the following runtimes:
- Docker Engine
- Docker Compose v1 (
docker-compose) and v2 (Compose plugin:docker compose)
- Docker Compose v1 (
- Podman
- Podman with Docker-compatible Compose (e.g.
podman compose/podman-docker)
- Podman with Docker-compatible Compose (e.g.
- Rootless containers
- Supported for both Docker and Podman; may require additional host configuration for ports and volumes
- SELinux-enabled hosts
- Volumes and bind mounts are compatible; use standard SELinux options/labels as required by your distribution
- Kubernetes
- Via Helm chart (
charts/goatflow), K8s 1.25+; see Kubernetes Deployment Guide
- Via Helm chart (
- TrueNAS SCALE (24.10+)
- Docker Compose-based app catalog; the official app store package is in submission
(
docs/truenas-app/, pinsghcr.io/goatkit/goatflow:0.11.1), so TrueNAS support is from GoatFlow 0.10.0 onwards; until it's merged, install via YAML with the standard Compose stack
- Docker Compose-based app catalog; the official app store package is in submission
(
All make targets (for example, make up, make down, make restart) automatically detect whether Docker or Podman is available and choose the appropriate Compose command.
# Clone the repository
git clone https://github.com/goatkit/goatflow.git
cd goatflow
# Set up environment variables (REQUIRED - containers won't start without this!)
cp .env.development .env # For local development (includes safe demo credentials)
# OR for production:
cp .env.example .env # Then edit ALL values before use
# Start all services (auto-detects docker/podman compose command)
make up
# Alternative methods:
./scripts/compose.sh up # Auto-detect wrapper script
docker compose up # Modern Docker
docker-compose up # Legacy Docker
podman compose up # Podman plugin
podman-compose up # Podman standalone
# Check which commands are available on your system
make debug-env
# Services will be available at:
# - Frontend: http://localhost
# - Backend API: http://localhost/api
# - smtp4dev (email sandbox): http://localhost:8025
# - Adminer (database UI): http://localhost:8090 (optional)
# Start services in background
make up-d
# View logs
make backend-logs
# Run database migrations
make db-migrate
# Stop services
make down
# Reset everything (including database)
make clean# Install podman-compose if needed
sudo rpm-ostree install podman-compose
# The Makefile auto-detects podman
make up
# Generate systemd units (Podman only)
make podman-systemdTry GoatFlow without installation at https://try.goatflow.io
Demo data resets daily
GoatFlow has comprehensive test coverage across multiple layers:
# Fast unit/integration tests (Alpine toolbox, ~1 minute)
make toolbox-test
# Full browser E2E tests (Ubuntu + Chromium, ~3-5 minutes)
make test-e2e-playwright-go
# Run the full Go test suite (2,000+ test functions)
make testBrowser tests use Go + Playwright with the //go:build playwright tag and run in a dedicated Ubuntu container with Chromium. This separation keeps developer feedback fast while maintaining thorough browser coverage.
GoatFlow uses a modern, hypermedia-driven architecture that scales from single-server deployments to large enterprise clusters:
- Core Services: Authentication, Tickets, Users, Notifications
- Data Layer: MariaDB/MySQL (default) or PostgreSQL, Valkey (cache); attachments in the database or an OTRS-compatible filesystem tree (Article Storage)
- API: RESTful JSON APIs with HTMX hypermedia endpoints
- Frontend: HTMX + Alpine.js for progressive enhancement with Tailwind CSS
- Real-time: Server-Sent Events (SSE) for live updates
See ARCHITECTURE.md for detailed technical documentation.
GoatFlow has these ways to sign in:
| Method | Who | Where to set it up |
|---|---|---|
| Database password | Agents and customers | Default; always available |
| LDAP / Active Directory | Agents | AUTH_PROVIDERS + LDAP_* env vars, see docs/LDAP.md |
| OIDC / OAuth2 (generic OIDC, Google, GitHub) | Agents and customers | Admin -> Identity Providers (/admin/identity-providers) |
| SAML 2.0 | Agents and customers | Admin -> Identity Providers |
| Passkey (WebAuthn) | Agents and customers | Each user adds passkeys in their profile |
| Second factor: TOTP app, passkey/security key, recovery codes | Agents and customers | Each user turns on 2FA in their profile |
Password logins try an ordered list of providers. The first one that accepts the login wins.
database- agents and customer users stored in the databaseldap- agents from an LDAP / Active Directory server (also setLDAP_ENABLED=true, see docs/LDAP.md)static- in-memory users for demos and tests (see below)
The list is read once at startup, in this order:
- The
AUTH_PROVIDERSenvironment variable, comma separated, e.g.AUTH_PROVIDERS=ldap,database. - The
Auth::Providerssetting inconfig/Config.yaml. - If neither is set:
databaseonly.
A provider that cannot be created is skipped with a log line. If none can be created, database is used. Restart GoatFlow after changing the list.
Add static to the provider list and set GOATFLOW_STATIC_USERS at runtime. Format:
GOATFLOW_STATIC_USERS="alice:password:Agent,bob:secret:Customer,carol:adminpass:Admin"
- Do not put this variable (or sample secrets) in committed
.envfiles. GitLeaks will flag them. - Passwords may be plain text or pre-hashed (bcrypt, or the OTRS SHA formats). The format is detected automatically.
- Without the variable, the static provider is skipped.
- Database access: This project uses
database/sqlwith a thindatabase.ConvertPlaceholderswrapper to support PostgreSQL and MySQL. All SQL must be wrapped. See docs/development/DATABASE_ACCESS_PATTERNS.md. - Templating: Use Pongo2 templates exclusively. Do not use Go's
html/template. Render user-facing views via Pongo2 withlayouts/base.pongo2and proper context. - Routing: Define all HTTP routes in YAML under
routes/*.yamlusing the YAML router. Do not register routes directly in Go code.- YAML is the single source of truth for routes; hardcoded Gin registrations are prohibited.
- Health endpoints (including
/healthz) are declared in YAML. Static files are served via YAML usinghandleStaticFiles. - In test mode (
APP_ENV=test), legacy admin hardcoded routes are skipped so SSR/YAML tests donβt double-register paths. - YAML route loader is idempotent in dev/tests: it skips registering a route if the same method+path already exists and logs a dedupe message to avoid Gin panics.
- The SSR smoke test discovers GET routes with templates from YAML and ensures they render without 5xx errors.
- Non-strict by default: logs 5xx; to fail on 5xx and on invalid/missing YAML-referenced templates, set
SSR_SMOKE_STRICT=1.
GoatFlow maintains high code quality and security standards through comprehensive automated testing:
- In CI on every push, pull request and weekly: Gitleaks secret scanning, gosec (fails the build on any finding), govulncheck on GoatFlow and the plugin SDK (fails when the code calls a known vulnerability),
go vet, and the route authorization matrix test - Semgrep managed scans (Semgrep Code and Supply Chain) of the repository, and Dependabot alerts with weekly update pull requests
- By hand with Makefile targets: Trivy (
make trivy-scan,make trivy-images),bun audit(make check-deps), staticcheck and golangci-lint (make toolbox-staticcheck,make lint)
- Unit Tests: Go backend with race detection, HTMX frontend
- Integration Tests: End-to-end API testing with test database
- Coverage: Automated coverage reporting via Codecov
- Database: Full schema validation (MariaDB/PostgreSQL)
- Multi-arch: AMD64 and ARM64 container builds
- Supply Chain Security: SLSA Level 2 attestations, container signing
- Automated Releases: Tagged releases with comprehensive release notes
- Manual Builds: On-demand builds without registry pushing
- Comprehensive security scanning (8+ tools)
- SLSA Level 2 compliant build process
- Automated test coverage reporting via Codecov
Minimum (Development/Small Business)
- 2 CPU cores
- 4 GB RAM
- 20 GB storage
- MariaDB 11+ or PostgreSQL 14+
- Docker 20+ or Podman 3+
Recommended (Enterprise)
- 8+ CPU cores
- 16+ GB RAM
- 100+ GB SSD storage
- MariaDB 11+ or PostgreSQL 14+ cluster
- Kubernetes 1.25+
For production deployments, see our comprehensive guides:
- Docker Deployment Guide
- Kubernetes Deployment Guide
- TrueNAS SCALE β official app catalog submission in progress; in the meantime use Apps β Discover β "Install via YAML" with the standard Compose stack on SCALE 24.10+
π‘ Tip: Start with Docker deployment for single-server setups, then scale to Kubernetes as your needs grow.
- Getting Started Guide
- Administrator Manual
- Agent Manual
- Customer Portal
- Reports & Analytics
- Webhooks
- Architecture Overview
- API Reference
- Developer Guide
- Configuration
- LDAP / Active Directory
- Article Storage
- Observability (health, metrics, logging, shutdown)
- High Availability
- YAML Platform
- Ticket Number Generators
GoatFlow's database schema is a superset of the OTRS schema. The goatflow-migrate tool imports an OTRS 6 or Znuny 6.x database. Older OTRS versions (for example 5.x) are refused: upgrade them to OTRS 6 first.
The OTRS source can be either:
SQL=a mysqldump / mariadb-dump file, orSOURCE=a live OTRS database: MySQL/MariaDB (user:pass@tcp(host:3306)/otrs) or PostgreSQL (postgres://user:pass@host:5432/otrs?sslmode=disable).
# List the source tables, row counts and what the import does with each
make migrate-analyze SQL=/path/to/otrs_dump.sql
# Dry run: print the import plan without writing (DRY_RUN=true is the default)
make migrate-import SQL=/path/to/otrs_dump.sql
# Import for real
make migrate-import SQL=/path/to/otrs_dump.sql DRY_RUN=false
# Validate migrated data
make migrate-validateThe import covers tickets, articles, agents, customers, queues, permissions, preferences, dynamic fields and changed settings, and runs in one transaction. It also resets id sequences and the ticket number counters.
Attachments:
- Attachments stored in the OTRS database (ArticleStorageDB) are imported with the rest of the data.
- Attachments stored on disk (ArticleStorageFS) are not copied by the import. Mount or copy the OTRS
var/articletree to<STORAGE_PATH>/var/articleand setSTORAGE_TYPE=fs. See docs/ARTICLE_STORAGE.md.
See docs/MIGRATION.md for the complete migration guide.
GoatFlow provides comprehensive multi-language support:
| Language | Code | Direction | Status |
|---|---|---|---|
| English | en | LTR | β Base Language |
| Arabic | ar | RTL | β Complete |
| Chinese | zh | LTR | β Complete |
| French | fr | LTR | β Complete |
| German | de | LTR | β Complete |
| Hebrew | he | RTL | β Complete |
| Japanese | ja | LTR | β Complete |
| Persian | fa | RTL | β Complete |
| Polish | pl | LTR | β Complete |
| Portuguese | pt | LTR | β Complete |
| Russian | ru | LTR | β Complete |
| Spanish | es | LTR | β Complete |
| Ukrainian | uk | LTR | β Complete |
| Urdu | ur | RTL | β Complete |
| Klingon | tlh | LTR | β Complete (Qapla'! π) |
- Embedded translations - JSON files compiled into the binary for zero-config deployment
- RTL support - Full right-to-left language support (Arabic, Hebrew, Persian, Urdu)
- User preferences - Language selection persisted per-user in profile settings
- Locale formatting - Date, time, number, and currency formatting per language
- Validation tests - Automated coverage testing ensures 100% translation completeness
- Create translation file:
internal/i18n/translations/xx.json - Add language config to
internal/i18n/rtl.go(single source of truth) - Run tests:
make check-i18n - Rebuild:
make build
See i18n Contributing Guide for detailed instructions.
See FEATURES.md for the status of every feature in 0.10.0 and a comparison matrix of GoatFlow vs OTRS, Zendesk, and ServiceNow across 22 feature categories, including:
- β Core ticketing, email integration, reports
- β Theme engine with 4 built-in themes and dark mode
- β Cloud native, air-gapped deployment, 15 languages
- β REST API, source code access, self-hosted
See ROADMAP.md for the development timeline and planned features.
See our Contributing Guide for details on:
- Code of Conduct
- Development setup
- Coding standards
- Pull request process
- Issue reporting
For AI/Agent Contributors: See docs/development/AGENT_GUIDE.md for the canonical operating manual.
GoatFlow Community Edition is licensed under the Apache License 2.0.
For enterprise licensing options, see LICENSING.md.
See the Community section above for forums, chat, and issue tracking.
- Professional support contracts
- Implementation services
- Custom development
- Training and certification
Contact: hello@goatflow.io
Please report vulnerabilities privately through GitHub private vulnerability reporting or to security@goatflow.io, not in public issues.
See SECURITY.md for the reporting and disclosure policy, and docs/SECURITY.md for the security controls GoatFlow has today.
GoatFlow-CE is an independent, original implementation of a ticket management system. While we maintain database compatibility for interoperability purposes, all code is originally written. We are not affiliated with OTRS AG. See LEGAL.md for important legal information.
GoatFlow builds upon decades of open source ticketing system innovation. We acknowledge the contributions of the OTRS community and other open source projects that have paved the way.
GoatFlow - Enterprise Ticketing, Community Driven
Copyright Β© 2025-2026 Gibbsoft Ltd and Contributors
