Connect
Standard MQTT over TLS or WebSocket. mosquitto, paho-mqtt, mqtt.js or a browser client — no SDK, no sidecar, no proxy. Two commands bring the stack up and exercise an allowed message end to end.
TrailMQ 3.1.0 · self-hosted evaluation
Policy-controlled MQTT.
Policy-controlled MQTT.
Decisions you can review.
TrailMQ is an MQTT broker built for auditable, policy-controlled messaging.
TrailMQ authenticates standard MQTT clients, enforces role and topic rules, and records attributable allow and deny decisions for later review—without a TrailMQ SDK, proxy or sidecar.
Public evaluation repo
Self-hosted via Docker
No cloud dependency
Commercial production licensing
eventPublish refused Denied
topicrestricted/ops/config
usertestuser
clientplantops-lf12-probe9182
reasonpublish refused:
acl_role_not_in_topic_scope
acl_role_not_in_topic_scope
evidenceRecorded no message forwarded
MQTT decision record · outside the current system/action integrity check
From MQTT request to reviewable decision
This is what TrailMQ 3.1.0 does today, from a clean clone, in about five minutes plus the first image pull.
Control
Every action passes two independent gates: the role's own permissions and the topic rule that scopes where it applies. Unknown namespaces are denied by default. Evaluation rules are managed through the REST API and configuration.
Record
Allowed operations and refusals become structured records with the authenticated account, MQTT client id, action, topic, outcome and a canonical reason for denials.
Review
Reviewers can inspect what the broker allowed or denied without reconstructing the basic decision from raw logs. TrailMQ keeps MQTT decision records distinct from its narrower system/action integrity check.
What a denial actually looks like
# A publisher attempts a topic its role does not cover
$ mosquitto_pub -t restricted/ops/config -m '{"setpoint":42}' -q 1 ...
Publish error: Not authorized
# The intended subscriber receives nothing on that topic — verified by byte count,
# with a permitted control subscriber proving the absence is not vacuous.
# In the product, Activity → filter Outcome: Denied
Publish refused restricted/ops/config Denied Recorded
Actor testuser
Client plantops-lf12-probe9182
Reason publish refused: acl_role_not_in_topic_scopeCompared with what you have now
| Question | Broker dashboard | ACL configuration | Raw logs | TrailMQ |
|---|---|---|---|---|
| Who may publish here? | Not shown | Readable, if you know the file | Not shown | Access page, per topic and role |
| Why was this refused? | Not shown | Inferable | Correlate by hand | On the row, with the topic that was evaluated |
| Who was refused? | Connection counts | Not applicable | Client id or username, rarely both | Both, and either one finds the record |
| Was it recorded? | Not applicable | Not applicable | If retention allowed | Stated per record |
| Can edits to the history be detected? | No | No | Needs an external pipeline | For system/action entries only; MQTT decisions are outside the current check |
Scroll the table sideways to see all four columns →
What ships in TrailMQ 3.1.0
Available now
- Authenticated MQTT over TLS and WebSocket
- Role plus topic-rule authorization, deny by default
- Topic-rule lifecycle through the REST API and configuration
- Allowed and denied operations recorded and attributable
- Hash-linked system and action chain, with its scope and exclusions stated
- Review-first UI plus REST APIs for topics, policies, queues and evidence
Future context, baseline and plugin concepts are kept in the public product-direction notes; none ships in 3.1.0. See the current Evaluation Preview and screenshots.
What TrailMQ does not claim
Downstream delivery
A recorded allow means TrailMQ authorized and accepted the operation at the broker. It does not show message payloads or name which subscribers received them. Delivery must be checked with a real subscriber, and the public verification does exactly that.
Evidence integrity
The chain checks internal consistency over system and action entries — sign-ins, administrative changes, policy and rule changes. It is not externally anchored, not digitally signed, and does not cover message evidence, including publish and subscribe refusals. If your requirement is a tamper-checked record of individual MQTT decisions, TrailMQ 3.1.0 does not provide that today.
Compliance
TrailMQ is a technical building block for traceability-sensitive systems. It is not a compliance certification, not WORM storage, and not a notarization service. A denied QoS 0 publish is silently discarded because the protocol carries no acknowledgement to refuse — documented, not hidden.
Evaluating TrailMQ with a real MQTT use case? Share your setup experience or request onboarding support. TrailMQ sends no telemetry: no topics, payloads, identities or operational metadata leave your machine.
The problem
Fast transport is easy.
Fast transport is easy.
Explaining it later is hard.
Months later, teams need to explain who acted, which topic was evaluated and why an MQTT operation was allowed or blocked. TrailMQ keeps those access decisions attributable and reviewable instead of leaving teams to reconstruct them from unrelated configuration and logs.
01
Request
A standard MQTT client requests connect, publish or subscribe.
02
Authenticate
TrailMQ resolves the account, MQTT client id and assigned role.
03
Enforce policy
Role permission and namespace/topic rule must both allow the request.
04
Review decision
The operation, identity, client, topic, outcome and denial reason remain reviewable.
You keep standard MQTT clients. TrailMQ becomes the broker endpoint for the evaluated message path and adds policy enforcement plus decision records at that boundary. Why MQTT alone is not GxP compliant
Capabilities
Not just transport.
Not just transport.
Controlled, reviewable messaging.
TrailMQ focuses on the broker boundary: authenticated MQTT transport, two-gate policy enforcement and attributable decision records for later review.
Policy-controlled topic access
Define which roles may publish or subscribe and which namespace or topic rule brings an action into scope. Both gates must allow the request; unknown namespaces fail closed.
Attributable decision records
MQTT operations and refusals are recorded in a dedicated decision store. The separate hash-linked integrity verdict covers system and action entries, with that boundary stated per record.
Identity & change context
Connect clients, users, services and configuration changes to the evidence record so later reviews can see who acted under which authority.
Structured, readable evidence
Not raw logs. Not binary blobs. Structured records a validation engineer, auditor, QA team or OT owner can review without a developer in the room.
Review UI & REST API
Use the self-hosted Preview to review Overview, Access, Clients and Activity. Use /api/v1 and configuration for operational changes such as topic rules and user lifecycle.
Client & queue visibility
See which MQTT clients are connected and what topics they access. Inspect queue state and dead-letter entries through the REST API without broker-level access.
Who it's for
Built for teams that need to explain later
A broker for MQTT paths whose access decisions must remain attributable, inspectable and understandable later.
OT & Production teams
Review who attempted an MQTT action, which client and topic were involved, and why the broker allowed or denied it.
Pharma & Life Sciences
You operate under GMP, and reviewers ask questions months later. Evaluate structured MQTT decision records and technical controls without treating the broker as a compliance certification.
IIoT Platform engineers
You build the infrastructure others rely on. TrailMQ runs as a Docker-based evaluation stack, accepts existing MQTT clients and exposes reviewable records through its UI and REST API.
Standard broker vs. TrailMQ
The questions transport logs often leave open
A conventional broker can be secured with TLS, identities and ACLs. TrailMQ combines that enforcement path with attributed decision review in one product.
Question you need to answer
Standard broker
With TrailMQ
Who changed this topic configuration?
Often a separate config log
System/action change record
Why was this MQTT operation refused?
Correlate ACLs and logs
Canonical reason on the record
Who attempted this MQTT action?
Product-dependent identity detail
User, client, action, topic, outcome
Can later edits to the recorded history be detected?
Needs an evidence pipeline
Hash-linked chain over system and action entries
Can this evidence support GMP review?
Depends on surrounding controls
Technical evidence for assessment
TrailMQ is the MQTT broker for the evaluated path. Existing standard MQTT clients connect directly while enforcement and decision review stay in one product path.
Regulated environments
Designed for where traceability is not optional
TrailMQ serves as a technical control in support of compliance processes. It does not replace regulatory assessment or validation, but it makes the technical decisions behind MQTT traffic easier to inspect and retain.
- Attributable MQTT decisionsReviewable allow and deny records
- Role and topic controlsTwo independent authorization gates
- Scope-defined integrity checkSystem/action chain; MQTT decisions excluded today
- Supports validation assessmentTechnical evidence to evaluate within your validation strategy
- Explicit product boundariesNo automatic compliance, delivery or immutability claim
GMPManufacturing quality context
GAMP 5Risk-based validation
21 CFR Part 11Electronic-record context
Data integrityALCOA+ concepts
TrailMQ is a technical control, not a compliance guarantee, certification, GMP/GxP validation, Annex 11 package or 21 CFR Part 11 package. Validation, risk assessment and procedural controls remain the responsibility of the regulated organization.
GMP MQTT reliability
Reliable MQTT messaging in GMP-regulated manufacturing means more than delivery
MQTT QoS, durable sessions and retained messages help with transport behavior. GMP-relevant reliability also requires evidence that the right client acted, the right policy was active, failures were handled explicitly and the record can be reviewed later.
Transport behavior
Choose QoS, retained state and session behavior deliberately, then document where message loss, duplication, replay and reconnect behavior can affect process decisions.
Controlled decisions
Design each publish and subscribe path so client identity, role, effective topic policy and configuration state can be reviewed when an allowed or blocked action is investigated.
Reviewable evidence
Review identity, client, operation, topic, outcome and denial reason as structured records instead of relying on broker logs alone. Assess the separate integrity scope explicitly.
For a deeper checklist, read how to ensure reliable MQTT messaging in GMP-regulated manufacturing
TrailMQ 3.1.0 quickstart
From clone to a reproducible MQTT allow/deny test
Start the public evaluation recipe, then exercise real MQTT and REST behavior with seven automated checks.
quickstart prepares runtime folders, creates local demo certificates, generates evaluation credentials and starts Secure MQTT Core.
verify checks runtime health, authenticated MQTT TLS, an end-to-end allowed publish, a blocked publish, its attributed denial, REST authentication and the system/action audit chain.
Standard MQTT clients need no TrailMQ SDK, proxy or sidecar. Point them to the TrailMQ endpoint with the intended credentials and CA.
The public 3.1.0 package is for local, non-production evaluation. Review the release notes and validation status; production or commercial use requires a separate agreement.
# Clone the TrailMQ deployment repo
git clone https://github.com/RainerGewalt/TrailMQ.git
cd TrailMQ
# Prepare and start the evaluation
./trailmq quickstart
# Exercise the product, not only container health
./trailmq verify[PASS] Runtime ready
[PASS] MQTT TLS accepts authenticated clients
[PASS] Authorized publish reached subscriber
[PASS] Unauthorized publish was blocked
[PASS] Denial recorded with context
[PASS] REST authentication issues a token
[PASS] System/action audit chain intact
7/7 checks passedWeb UI http://localhost/trailmq/
REST API http://localhost/api/v1
MQTT TLS localhost:8883
MQTT WS ws://localhost/mqtt
FAQ
Can MQTT be used in GxP environments?
MQTT can be used in regulated manufacturing, but a broker alone is not enough. The real question is whether message decisions can be controlled, explained and reviewed later.
Can an MQTT broker be GxP compliant?
MQTT itself is not GxP compliant or non-compliant — it is a messaging protocol. Compliance depends on the surrounding controls: identity, access policies, audit trails, data integrity, change control and validation evidence.
What about data integrity and audit trails?
Standard brokers move messages. They usually do not prove who changed what, which policy was active, why a message was allowed or blocked, whether a record stayed complete and whether the evidence is complete enough for later review.
What should an MQTT data transaction audit trail record?
At minimum: authenticated identity, client ID, operation, topic, timestamp, outcome and denial reason. It should also distinguish broker acceptance from subscriber delivery and state exactly which records any integrity check covers. Read the solution checklist
Can MQTT be used in GMP-regulated manufacturing?
Yes. MQTT can be used in GMP-regulated manufacturing when the surrounding system controls access, validates configuration, handles failures explicitly and preserves audit-ready evidence for GMP-relevant message decisions.
How do you ensure reliable MQTT messaging in GMP-regulated manufacturing?
Start with MQTT transport controls such as QoS, persistent sessions and retained messages where they fit the risk. Then add regulated controls: authenticated clients, topic-level authorization, validated configuration, explicit failure handling, dead-letter or retry review, synchronized time, audit trails and data integrity evidence. Read the full checklist
Does TrailMQ make a system automatically compliant?
No. TrailMQ provides technical controls and reviewable records that can support an assessment. Validation, risk assessment and procedural controls remain the responsibility of the regulated organization.
Does TrailMQ provide a REST API?
Yes. TrailMQ exposes product functions through a REST API so teams can inspect topics, resolve policies, review queues and records, validate the separate system/action chain and integrate TrailMQ with scripts, local checks, CI pipelines, monitoring tools or external systems.
Is TrailMQ open source?
No. TrailMQ provides public evaluation access through GitHub and Docker images. Production use in regulated or commercial environments requires a valid commercial license.
TrailMQ moves MQTT messages, enforces access policy
and keeps attributable decisions reviewable.